Reproduction only allowed if written consent from responsible Boingworld crew-member is given. Table of Contents Introduction Why? Who are you? Preparations Where to get it?
|Published (Last):||7 April 2010|
|PDF File Size:||3.44 Mb|
|ePub File Size:||4.31 Mb|
|Price:||Free* [*Free Regsitration Required]|
Become a full participant in the LinuxSecurity. Oskar Andreasson: When I started using Linux 2. 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. After some months I had the first version of the tutorial published. It was quite small, only 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. Oskar Andreasson: Tricky question, I don't know really.
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. Oskar Andreasson: Computer security has always intrigued me ever since I started using a PC for the first time around or so. Previously, I had used Amigas since I was 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. It was not until 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. 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. 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.
I hope that there will be at least a 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 persons liked it enough to actually buy it. 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. 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. 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 Red Hat, do the same thing select the installed packages. When finally installed, erase everything not needed, including the man reader. 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. 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. However, a firewall is never near good enough based on only a packet filtering mechanism.
I would suggest at least installing a NIDS i. At the top of that, if you're really security conscious, I'd suggest using kernel security patches and such. 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 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. 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. 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.
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 months. 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 months ago.
If anyone living in Sweden Stockholm knows about a party of 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.
Linux Security Week. Linux Advisory Watch. No Thanks. Login Now. Remember me. Log in. Forgot Username? Forgot Password? Not a Member Yet? Share Your Story. Date 26 Nov Category LinuxSecurity. Posted By Brittany Day.
Oskar Andreasson IP Tables Tutorial