Damn Vulnerable Linux

If you need an all-in-one great penetration testing kit, look at Backtrack. If you need a test bed to try out your penetration testing skills, look at Damn Vulnerable Linux. Yes. There actually is something with that snazzy name. It is a small Linux distribution, based on Damn Small Linux, which provides a vulnerable platform for beginning and intermediate security peeps to try their acquired knowledge and skills on.

The following article on Linux.com briefly introduces Damn Vulnerable Linux. Thanks to BBBart for pointing it out.

Space tabs are evil.

I take back what I said earlier.

Tabulators are the way to go. Spaces in place of tabs really suck. I learned it the hard way. If you go ahead and re-indent a piece of code that is space tabulated, you will know how quickly the spaces leap out to bite you (and also how nastily they bite).

Hats off to Fedora Core 6 (all the pun that can be intended intended)

I think there is a pun somewhere there in the topic.

BBBart threw my attention to Eric Steve Raymond’s rant-cum-open-letter in which he vents out his frustrations on Fedora Core and Red Hat, in general, and Fedora Core 6, in particular. I can’t say whether he did the right thing coming out like that, but I do identify with his anguish and acknowledge many of the points he has raised. The open source world, and especially Linux, is all about the freedom to choose what you want to use. There are so many different forms of the same thing that sometimes it is hard to settle on one. However, the trend prevailing in the Open Source world is moving towards the egocentric “If you don’t like it, use something else” attitude (perhaps, egocentric doesn’t quite describe it). I know, I know, the code is free, and most of the open source projects don’t get paid for or not as much as they would had they been proprietary, but, I believe, this very mindset and attitude is against the principles of software development (and Open Source Software, in greater part). I can’t say whether it harms the quality of individual software products, but it harms, without a doubt, the image of Open Source Software. That is a sad thing.

Wait. Phew. I nearly went off on a tangent. I got the fifth ISO last night, burned it, ran the text-based installer, and had Fedora Core 6 running within an hour. The installation was smooth. What irked me this time was the fact that, though the installer did ask for the fourth and fifth CDs, it didn’t quite install anything from those. No sooner had I popped in the fourth CD and clicked OK did the CD-ROM tray eject and the installer asked for the fifth CD. And, again, (surprise, surprise) no sooner had I popped in the fifth CD (isn’t this becoming boringly repetitive?) did the installation quickly finished, and the try popped out, and the system waited to be rebooted.

On the flip side, Fedora Core 6 is running without a hitch. I would have to probably download latest drivers for my Intel onboard display adapter, but other than that, everything seems to stick to its place.

The issues I highlighted in my previous post still exist. You are only lucky if they don’t bite you soon enough.

Fedora Core 6: A few quirks you need to watch out for.

Trying Fedora Core 6 out, I had a horrifying experience. The last Red Hat-like distribution I had installed was Red Hat-9.0 (codenamed Shrike, if I remember correctly), and that must have been years ago. I discovered Slackware (years ago) and migrated to it. Ever since (years ago), I’ve stuck with Slackware (and quite contentedly so). I use a variant of Red Hat Enterprise Linux, CentOS, at work, however, where I do all of the Linux software development.

After all these years of not touching Fedora Core, and yet being fascinated by the frequency with which newer releases have been coming out, I felt an itch down somewhere to give it a try. I scratched that itch, not only because I wanted to try it out, but also because I had been dying to test Linux on the desktop system I had bought. Besides, with an Intel 2.4-GHz and a blasting 512-MB RAM (it might not be blasting for you, but it is for me), that system seemed well off to run Fedora Core.

ISOs of Fedora Core 6 were lying in the office, and I grabbed them one day and burned CDs.. The fifth ISO was missing, and thinking that it would only contain extra packages that I wouldn’t have any dying need of anyway, I popped the first CD inside and rebooted the system to boot from the CD. The first time (yes, and we’ll see why I say this) I booted from the CD and proceeded along with the installation, the setup crashed with an Exception when I unwittingly clicked on “Add Additional Fedora repositories” on the package selection menu. The system rebooted.

On my second attempt, I avoided that option like the plague, and moved ahead. I selected nearly all the packages (for I had a whopping 20-GB waiting to be filled, and a lot of curiosity waiting to be quenched). Before the setup could format the drive and start copying the files, it showed a notification that said to the effect that all the five CDs are required, and if I don’t have them, I can either go back or reboot. Blindly assuming that any sane installer supports an option to skip a CD if it isn’t available without disturbing the installation process, I quietly shrugged off the message and continued. Half an hour later, when it asked for the fifth CD, I realised how stupid I had been to have discarded that message I got before starting the installation. The glaring prompt on the screen read, “Please insert the fifth CD and click OK”. And, sure enough, there was only one clickable button, and it read ‘OK’, fair and clear. I tried a variation of different things, from clicking Escape, to putting different CDs one by one (and even no CD at all), only to somehow force the installer to complain that “the fifth CD isn’t available, so I am skipping installing those packages that are to be found in the fifth CD, and will continue with the post-installation procedures”. But, to my utter dismay and complete anguish, the stubborn prompt just wouldn’t go away. I had to reboot.

The third time around, I opted for the ‘Upgrade Installation’. A couple of packages from the first CD were installed, and then, the system rebooted. The messages whizzing by on the boot-up screen gave me the sort of feeling you get when you know your system is screwed up. Sure enough, it was. I couldn’t log in as root. I booted into single user mode to reset the password for root, but the subsystem that handles authentication and book-keeping seemed dead. Furiously, I booted off, and restarted the installation, again.

This time, on the package selection menu, I carefully selected packages so as to avoid choosing those that might be found on the fifth CD. How did I know which would be on the fifth CD? I didn’t. There is no way to tell. I only relied on my gut feeling and whatever little experience I have had with the likes of Red Hat. I got no-where with that. I logged on to #fedora on irc.freenode.net to release my frustration and find any possible workarounds. Suffice it to say, I realised it wasn’t my lucky day.

I restarted installation once more. I didn’t touch anything on the package selection menu, even with a ten-foot pole. Installation proceeded, showing me the same alert again that “You need CDs one to three for installation”. I sighed. The install process went smoothly, and within an hour, I was soundly using Fedora Core 6, jumping up and down at the revolving screens and wobbling window effects.

That wasn’t the end of my worries, though. I really wanted most of the packages I had missed out during installation. And thinking that as with any Linux distribution post-installation of packages is as easy as anything, I invoked the ‘Add/Remove Software’ system, which is a graphical Package Manager for Fedora Core. I want to go on and on into grinding details, but I
think it would suffice to say that the Package Manager is bitchy enough not to work without a network connection. Not only that, whatever packages you select to install, it downloads them from Remote Repositories over the Internet and installs them. What that means is that the Package Manager, currently, does not support the feature to do post-installation from CD/DVD media. Sucks.

I love Slackware. And I can’t emphasize it enough.

syslog-ng: the neXGen syslog

syslog-ng is a flexible, scalable, easy-to-use logging system that works on Unix and Linux platforms. syslog-ng does what the stock syslog does and much much more. It is syslog enhanced in terms of functionality (I don’t know if it works on the codebase of syslog). I wouldn’t do justice to it if I described it myself, so instead, I’m jotting down a few links anyone who is serious about and is looking for a powerful logging system to work on Unix/Linux platform should consider.

• http://www.balabit.com/products/syslog_ng/
• http://sial.org/howto/logging/syslog-ng/
• http://www.campin.net/syslog-ng/faq.html
• http://linux.cudeso.be/linuxdoc/syslog-ng.php

syslog-ng supports a huge set of options and configurations. I admit I have not even explored half of the set.

To provide a quick glimpse into what syslog-ng can do, I will set up a small distributed logging environment.

• Client (10.1.0.10) running syslog, from where we need to pick up logs
• Server (10.1.0.1) running syslog-ng, where we want all logs to gather.

Let’s assume, for the sake of example, that we want to grab all INFO level (logs generated vai syslog(2) are categorised by level which indicates the severity of the logs, such as being of ‘alert’, ‘warn’, ‘error’, and so on severity) logs being generated on Client. Client is generating logs via syslog. As I explained in Syslog Remote Logging, syslog can be configured to send logs remotely over to systems running syslog. In order to make Client send INFO level logs to Server, we’ll have to add the following line into /etc/syslog.conf on Client:

*.info @10.1.0.1

That’s it for Client. As soon as the syslog daemon on Client is re-started, it will start sending logs over to 10.1.0.1, which is the Server.

Now, on the Server we plan to set up syslog-ng instead. Before we do that, we need to decide a few things. Server will be receiving logs on UPD 512 (that is the default port on which syslog or syslog-ng, for that matter, listens for data sent from remote syslog daemons). Although the Client is sending INFO logs, it can send any other type(s) of logs if configured to, we, at Server, are only interested in logs with the INFO level. Finally, we would like to store the logs for each remote syslog we receive logs from inside /var/log/hosts/ with filenames that represent the IP addresses of corresponding remote syslog systems. With that in mind, let’s write the following in /etc/syslog-ng/syslog-ng.conf:


options { long_hostnames(off); sync(0); };
src info_src { udp(); };
destination info_dst { file("/var/log/hosts/$HOST.log"); };
filter info_filter { level(info); };
log { source(info_src); filter(info_filter); destination(info_dst); };


Refer to links given in this post for clear, detailed explanation of how these rules are constructed and what they do. In the nutshell, however, these set of rules do the following: read logs coming on UDP port (512, default), filter them based on level, and store them into files named after the IP address of the remote system.

That’s it. Start up syslog-ng with the -f switch and /etc/syslog-ng/syslog-ng.conf as the argument to the -f switch.