Discover LinuxSecurity Features
Oskar Andreasson IP Tables Tutorial
LinuxSecurity.com: Why did you decide to write the iptables reference?
Oskar Andreasson: When I started using Linux 2.4 I noticed a huge black hole in the documentation for the netfilter code and how to use it. Sure, there was the howtos written by Rusty Russell and the man page. There was no documentation at all describing how to get started, nor was there any examples available. During the time, I was also doing a lot of "work" for our site www.boingworld.com, writing news and so on.
I have always been proposing more material of our own on the BoingWorld site and since I found an area that I thought needed more/better documentation, I started writing. After some 1-2 months I had the first version of the tutorial published. It was quite small, only 20-30 pages or so, and didn't cover all the intricacies of iptables and the more I used iptables and tested it; the more things I found that needed documentation. In other words, I continued writing on the tutorial, and today it is much larger and contains much more information, to say the least.
LinuxSecurity.com: Who are your target audience and why?
Oskar Andreasson: Tricky question, I don't know really. At the beginning it was mainly aimed at the beginners and novices of iptables and who had a little bit of experience with TCP/IP networking as well as Linux basics. I still think the tutorial is aimed at those, but it contains more information today about the advanced functions of netfilter and iptables so it might be fairly well suited for the advanced users as well who might find some interesting reads in the tutorial.
Of course, the tutorial also aims at the security interested people out there and anyone who might be interested in setting up a local network with Internet access.
LinuxSecurity.com: How did you get started with Linux and security?
Oskar Andreasson: Computer security has always intrigued me ever since I started using a PC for the first time around 1992 or so. Previously, I had used Amigas since I was 7-8 years old. In those days (Amiga days), it was mainly viruses I found interest in.
Later on I got an Internet connection and got more and more interested in network security and, to be honest, different kinds of exploits, DoS attacks and spoofing. However, I was locked to a 486 50 MHz jar with 8 Megs of ram at the time and had no other OS than Windows 3.11 and MS-DOS 6.2.
It was not until 93-94 or so that I started seeing Linux around and tested it. At the beginning, I can't say I liked it. The first time around I never got it to install at all. The second time around, "it" crashed my monitor (OK, I had to blame something, didn't I) and I had to get another monitor out on the warranty.
After that it took a year or so until I tried getting Linux to run again, and by that time it had evolved incredibly (I could get it to install, isn't that evolution?). By that time, I went up to the second or third step on the ladder to becoming a "Linux Guru" (I got saved from the Windows hell and started preaching), and I think I'm still stuck somewhere around there.
LinuxSecurity.com: What are your future plans for the iptables reference?
Oskar Andreasson: Currently there are quite a lot of plans. As I said before, the more I write, the more I find that I want to write about. This constitutes a small problem since I only have so many hours to write. As it looks now, I want to finish the chapter about how a rule is written, and then I want to add a chapter about the state machine.
After this I need to go through the explanation of the rc.firewall.txt script again since the actual script has changed quite a lot but I haven't had the time to update the text describing the script. Then there is a request by some people that want to know how to make a transparent http proxy with iptables and squid. I know the last has already been described by the squid documentation, so it is not high priority right now, however I feel that it should at least be mentioned.
One of the long-term goals of this project is actually to print a book of the whole tutorial and sell to the readers who liked the tutorial. This would not change the fact that the tutorial will be available on the Internet, it will always be. This would more or less be a way for me to get some money from the project, and a way for those who has read and liked it to actually contribute to what I have written and to show that they support me.
Of course, I would have to see what kind of support I have among the readers/visitors for doing this before actually printing it. I hope that there will be at least a 200 persons or so willing to buy the printed version for a reasonable price. If so, I think it's worth printing a series. If not, well, it would be sad if not even 200 persons liked it enough to actually buy it.
LinuxSecurity.com: What are some of the major pitfalls Linux Administrators fall into? How can your iptables reference help to avoid these problems?
Oskar Andreasson: One of the main problems of Linux today is in my way of seeing things, that there is a huge lack of documentation, especially when you start digging into the deeper aspects of Linux. Also, some commands and functions are clearly not documented enough.
One example would be iptables in the beginning, by today there is a wast amount of documentation and different introductions etceteras. Another example that I have noticed is the iproute2 package, which in my way of seeing things is one of the most complex and hardest to understand packages for Linux that is available today. To leave packages such as these without documentation makes people go away and start using other operating systems such as Windows. To leave these extremely powerful parts of Linux undocumented should almost be criminal, it is horrendous to see these parts undocumented. Sure, there are a lot of pieces of information available out there, but a lot of it raises more questions than they answer.
My answer to the first question would, hence, be that they might do errors due to a lack of documentation. These errors might be unknown to the Linux administrator for a long time and, in the long run they may notice the error to late. For example, after the hacker/cracker found the erroneous set-up and exploited it. What I hope that this tutorial do, is that it gives people new knowledge about the Linux firewalling possibilities, how they work, and a general knowledge of how to set it up properly. I hope that the iptables-tutorial give Linux administrators the possibility to easily learn about netfilter and iptables and in an as complete document as possible.
LinuxSecurity.com: What do you feel is the most common Linux system vulnerability? What can be done to prevent this?
Oskar Andreasson: I don't think there is a single most common Linux system vulnerability, and it will definitely not stop a determined attacker. If you have fixed the most common vulnerability and someone is determined to get into your host, then you can be certain that the attacker will leave the second most common vulnerability out, or the third for that matter.
However, good security practices on a server includes installing only the absolutely necessary packages. For example, if a box is supposed to run as only an DNS and HTTP server, well keep it to the A, N and D Slackware packages, and do the expert installation and select which packages you want exactly. For Red Hat, do the same thing select the installed packages. When finally installed, erase everything not needed, including the man reader. All you really should need is a text editor, HTTP, SSH server, DNS, login programs and all the standard ls, cd commands etc. The fewer packages we have to keep up to date, the less work to maintain and to keep it up and running.
After this, it is all a matter of keeping those few packages you have installed up to date. Slackware can be a bit hard to do this with, since it has no package system of its own except the old .tgz packages and installer, and there is no real "errata" site for it to my knowledge. Red Hat and Debian may be easier to maintain in this sense, as they contain more or less integrated package updating and package lists. On the other side, this may be a bad thing for the really hard working administrator who wants to keep his packages up to date by hand, and who does it faster than Red Hat and Debian, for example, updates their packages.
Also, a nice firewall will always be handy when it comes to security. Iptables is an excellent choice when it comes to this, though it takes a lot of work to get it up and running in comparison to some Windows firewalls (BlackIce Defender, etc.), it is extremely versatile and can do pretty much whatever you want to. However, a firewall is never near good enough based on only a packet filtering mechanism. I would suggest at least installing a NIDS (i.e., snort) and an IDS (i.e., tripwire) on the same box. At the top of that, if you're really security conscious, I'd suggest using kernel security patches and such.
LinuxSecurity.com: Do you believe the open source nature of Linux provides a superior vehicle to making security vulnerabilities easier to spot and fix?
Oskar Andreasson: I most definitely think so. Open source gives everyone the chance to look at the source code, and it becomes easier to spot errors for a third party, and hence report to the producer. A person using an open source product is more likely to actually look at the code and to try and fix the problem, and then send the bug over to the developer, in my own experience. Of course, there are those who don't report the bugs, and instead start using it to their own advantage (for example, hack sites with the bug and so on). However, the percentage of users doing the latter is a dwindling small amount of people, I think.
Closed source on the other hand is harder to debug for a third party, and if you really do find a bug, you are more likely to just throw the bug on the crap pile and hope for it to be fixed in the next release, they don't feel anything in common for the actual development of the product nor do they actually have a good reason for telling the developers about the bug.
In open source, you can have the problem fixed within 3 minutes by yourself and have a bug report sent away and how to fix it, in closed source, you find a bug, send a bug report and then sit down and wait for 2-6 weeks before anything happens. Finally, you get a reply that this is not a bug; this is a feature(TM) (strangely enough removed in the next version of the program).
LinuxSecurity.com: Are there other documents you have written that you think might be beneficial to the Linux and open source security communities?
Oskar Andreasson: Yes, I think there is. I have currently written an online course about Linux and Unix for a company called Libendo. This is about the same size as the iptables tutorial, but is elementary and guides a total new user to Linux through their first experience. This is one of the more peculiar basic documents written about Linux, I believe since it is 100% based on the shell, and there is more or less no graphical user interface used throughout the whole course. I believe that this course may actually hold a lot of interest even for the Linux zealots out there who may not have a lot of experience with the console of Linux. If there is any Swedish speaking people, I suggest them to check out https://www.libendo.com in a couple of months when this course goes online.
I have also started another project on my spare time, to document the iproute2 package and its uses. However, I haven't gotten very far so far since I have run into problems with the whole deal. Anyway, my aims with this documentation is to get more people to understand the extremely advanced routing functionalities that really are part of Linux. Some good examples of what this document will contain is explanations on how the ip command works and the syntax, how all the different options and flags to the command is used and information on how each "subcommand" works. I haven't put a lot of time into this project so far, mainly because I want to finish up a lot of loose ends with the iptables tutorial before walking into another huge project. I think that this project will look a lot like the iptables tutorial when it gets going, especially in writing style and how it will be built up with a lot of examples among other things. However, I don't plan to get this project really moving until the iptables tutorial has stabilized, in perhaps 2-3 months.
LinuxSecurity.com: Is there something the community can do to assist you with writing and maintaining your security research?
Oskar Andreasson: There is actually something people could do to contribute to this tutorial. I am in an extreme need for a lab network at the moment since I lost the main part of it when I moved 5-6 months ago. At the moment of writing this, I have only two computers available, one Pentium 200 MHz MMX and one Pentium 120 MHz laptop.
If anyone living in Sweden (Stockholm) knows about a party of 4-5 computers of any type that some company or private person is willing to give away, either as junk, or just as a contribution, I will owe them extremely much. Any kind of computer would suffice, even Pentiums at the moment, as long as I can have a few network cards with them (9 or so, but less would suffice too).
My private budget would not in any way make this possible at this stage, and to be able to finish both the iptables tutorial, and the iproute2 tutorial this would be more or less necessary.
LinuxSecurity.com: Oskar, thanks much for your time, and we look forward to reading your future Linux security documents.