Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Why iptables (Linux 2.4 Firewalling) Rocks 209

Posted by timothy from the get-outta-my-place dept.
Jay writes: "There's a story on Linux 2.4's new Stateful firewalling. Rusty and friends have vastly improved Linux capabilities, allowing it to filter against many stealth scans and DoS attacks. Their code rewrite brings powerful "stateful" firewalling that was originally impossible under Linux. The muchly improved packet mangling allows not only better transparent proxies, but load-sharing clusters and stuff. Actually, the coolest thing about the new architecture is that it's designed so anybody can add filtering methods, for stuff like rate limiting and MAC address-based filtering."
This discussion has been archived. No new comments can be posted.

Why iptables (Linux 2.4 Firewalling) Rocks More

Why iptables (Linux 2.4 Firewalling) Rocks

Comments Filter:
  • This is the greatest benefit to me. We have tons of open RJ45 jacks around that anyone can plug into and siphon off data from the inside of our filrewall. Now we can track down to the mac address, this should make it much simpler to place a stronger secondary wall around the more sensitive servers.

    On a side note, is there any downfall to this?
  • ..why do the authors not want to put this on their mainstream systems to keep all the nasty script kiddies out ?

    Sounds like they're choosing to keep a firewall full of holes just because its stable(r). However if someone breaks in, what price stability ?

  • Transparent Proxies aren't such a Good Thing (Score:4)

    by mnot ( 71203 ) on Monday January 22, 2001 @09:51AM (#490348) Homepage Journal
    Inserting a proxy when the client doesn't have knowledge isn't something to be proud of; it breaks browsers, violates the end-to-end principle at the IP layer, and brings some serious privacy/data integrity problems to light.
  • At the least, one would hope that they would have acknowledged the other open source solution that provides this: BSD (Open BSD for sure, I'm not positive about others).
    "Building Linux and OpenBSD Firewalls" by Wes Sonnenreich, Tom Yates is a good resource that explains all this.

    BdosError

  • Re:MAC filters (Score:4)

    by crow ( 16139 ) on Monday January 22, 2001 @09:55AM (#490350) Homepage Journal
    This just requires that the person inside your building be a little smarter. MAC addresses can be changed, so all that is required is to wait until a trusted box goes offline, and then just borrow its MAC address.

    Of course, this eliminates a good portion of those who would try to hack in. Just don't rely on it to be fool-proof.

    I was always tempted to use a laptop running Linux to spoof one of the main campus Unix systems at Dartmouth when it went down for backups, but never did. (I think they had some public systems on the same subnet as the machine room.)
  • ...all of which is useless to me until iptables-save can do it IN ORDER. Geez...
    --

  • Stateful firewalling. (Score:4)

    by fantom_winter ( 194762 ) on Monday January 22, 2001 @09:56AM (#490352)
    This sounds like a very interesting idea, but it also makes me wonder about the computational resources a system like this would require, as well as the complexity of the grammar that represents it.

    As it stands now (or previously... in ipchains), rules were defined in a way that could be reduced to a regular expression, which as everyone knows are fast and don't require a stack to interpret.

    However, as soon as you introduce "state" into a grammar, you require of yourself a stack, which means that additional memory is going to be needed to store these values to aid in parsing the grammar.

    This doesn't sound too bad, even though it may slow the process of packet interpretation, but it seems like there still would be a signifigant performance hit on busy servers.

    Also, since these rules have state, I wonder if there will be ways send packets that will cause something similar to a stack overflow (infinite recursion) by sending it a quasi-infite series of packets.

    (Imaging sending a C++ compiler the following ..

    [I can't send what I want, a string of open parens, so this will have to suffice. /. lameness filter]

    String= (*

    Eventually there will be a stack overflow from all the parens.

  • And what price security if your firewall doesn't stay up long enough to provide it?

    As always, a series of tradeoffs.

  • Someone will have to explain to me why they keep up with the cryptic syntax. That's one of the reasons why i switched to ipf (OpenBSD) some time ago.

    Now both (iptables, ipf) have states. Can someone infom me about the advantage of iptables over ipf?

    ---------------------------
    "What is the most effective Windows NT remote management tool?
  • I know that several hundred people hate me for asking this stuff, but I've got to ask anyway: can this be done in Win2K? Would it require a download, like IPv6 on Microsoft's web site, or is it just not possible.

    It'd be cool to filter out junk on my Apache/Win2K box. :)

    -
    -Be a man. Insult me without using an AC.

  • I don't believe the book was intended to be eaten. Although, I had a cousin who would eat books.
    ---

  • Each has their strong points. Why not be a little more optimistic about what each can achieve?

  • Yep, OpenBSD has a very thorough out-of-the-box NAT firewalling solution. It's extremely powerful (and in my experience far superior to linux 2.2 ipmasq)... I use it at home and work with OLD Sparcs (25-40mhz) and still achieve near 10mbps on all 10mbps interfaces.

    Iptables under the 2.4 kernel has impressed me. I use it for a test lab at work, and the first thing I noticed was that it allows active FTP through its implementation of NAT. It's probably due to some funky extension they've added to FTP standards, i'm not sure, nor good enough of a programmer to figure it out from the code... Nonetheless, they've finally made a decent product that starts comparing to the cleanliness and quality of BSD's NAT.

    The other BSDs also use the same BSD NAT, however, my last experience of using NAT on FreeBSD (back on 3.3) was that it was quite erratic in behavior compared to the same setup using OpenBSD. I might have been royally screwing something up, too :)

  • Re:Stateful firewalling. (Score:5)

    by Anonymous Coward on Monday January 22, 2001 @10:08AM (#490359)
    How important the computational time is will depend upon how fast it has to be. If you're firewalling a 1Mbps Internet link, there are many nanoseconds between packets. With 1KB per packet, there are only 100 packets per second at most (1Mbps/1Kbps/10bits-per-byte). Not much computer time is needed for this type of processing.

    (anonymous to avoid giving info about my network)

  • Spoken like someone who has their network certification at a night tech school based out of someone's garage.

    Grow up....

    sure one can purchase a "pre-made" firewall, but to have a computer running Linux gives Administrators more options when working in companies that work with budgets...

  • I havent used linux firewalling since the days of ipfwadm, but from what I see here, iptables has some rather extreme leaps here, the likes of which have usually only been seen in commercial firewall packages. What I want to know though, is exactly how *does* this compare to commercial firewall packages, inparticular: Checkpoint Firewall1

    ---
  • Oh wait, this is linux, you guys are playing catch up... :-P...

    But seriously, any more questions on the maturity/performance of the BSD's networking code? this stuff has been posible for AGES...
  • I use ipchains w/ masquerading on my 2.2 linux box to implement NAT and allow the internal network to see the outside world -- allowing only packets with the SYN bit set back in.

    This works fine for web and ssh and outgoing mail and dns and all -- but not when I need to use Win2k's VPN client to establish a tunnel -- my understanding is that the VPN server tries to establish a connection back (expecting to hit Win2k, but hitting to the linux box) which is refused.

    How can I configure IPTables so I can tunnel and stay firewalled?


  • I don't know that you could filter the stuff, but you could at least log it using Snort Win-32 [snort.org].

  • Re:iptables/ipchains syntax (Score:4)

    by greebly ( 133856 ) on Monday January 22, 2001 @10:13AM (#490365) Homepage
    I think I can sum up the one and only advantage (if you can call it that) that iptables has over ipf (aka ipfilter) in one short sentence...

    You can run iptables in Linux.

    Linux has its uses, don't get me wrong, but I'll take an OpenBSD firewall over any Linux firewall, regardless of which distro, or firewalling software it runs. The TCP stack in the BSDs is much more robust than the Linux stack, and its just plain faster.

    Don't belive me? That's fine, but don't go flaming me unless you have actually used both Linux and *BSD firewalls extensively.


    9 little greeblys sitting on a plate...
  • and of course, it will very useful for the script kiddie that used the root toolkit of the day to take over your machine....
  • you would need to forward ports, and as far as I know, autofw doesn't work with 2.4

    in 2.2 you would use ipmasqadm to forward the ports back from public to private
  • /usr/local/bin/iptables -A OUTPUT -d 209.242.124.241 -j REJECT It makes reading slashdot so much easier on the eyes [goatse.cx]. (Don't click!)
  • And so when you finally do get SMP, we will rain all over your parade, proclaiming:

    "That's a great way to make yourself look good. Go from crappy to average, and have the press all over you. Meanwhile, Linux has been doing it all along.."

    Not everything done well is revolutionary, but just because it has been done before doesnt make it easier when someone else does it. Sure they *could* have used BSDs ipf. But they didnt. They did it their own way, and it was hard. Just acknowledge the effort. THAT isnt hard. Why not just be happy that there is one less crappy TCP firewalling mechanism in the world. Ever heard of a pat on the back and say "Well done".


    ---
  • These are neat features, just when i was thinking of replacing my linux masq box with a FreeBSD box to use it's spiffier NAT support and all that good stuff, this looks like it takes care of that. I may still do it for security though...

    Now: Does anybody here know offhand if the packet filtering support in FreeBSD supports these features? (stateful ftp support, DNS probe rejection, etc...?) i know it has rate-limiting to make DOS attacks not work as well...

    Thanks
  • Har-de-har-har. Someone mod this bitch up. He wins the prize.

    -
    -Be a man. Insult me without using an AC.

  • I believe you need to use ipsec for that.
    If you have it compiled as a module just insert it. I haven't tried it myself though so I couldn't
    say if it works. Last I remember seeing it was
    labelled experimental.
    *********************************** *********

  • Personally i dont know absolutely anything about commercial firewalls except some cheap soho fw's that ive tested but i remember reading just few days ago from /. comments that Nokia's [nokia.com] Firewall-1 solutions are based on linux os and some hardware... This was mentioned in Nokia's mediaterminal thread.

    Btw, i dont know if it's really known outside finland but Nokia started it's "Empire" in finland by manufacturing RUBBER BOOTS. I think they still do but businesses have been seperated to different companies ;)
    --

  • Win2K itself doesn't have such fancy features. But you can pick up something like Checkpoint Firewall-1 that provides a very nice firewall for NT or 2000. The ISP I work for when I'm not at college uses it, and works surprisingly well. In fact, it uses a GUI (which helps for the CLI-impared.) And it works a lot better than some of the other stuff they run on 2000 (namely DNS and mail, which tend to choke on themselves daily at least -- Microsoft gave them free copies of 2000 to keep them from using Solaris, basically).
  • Using ipfilter (ipf) in *BSD supports all of these features on top of one of the most robust and mature TCP stacks on the planet. I wouldn't use another OS for firewalling. Period.


    9 little greeblys sitting on a plate...
  • Yeah, but only if you're reading slashdot from your firewall host (the OUTPUT chain only filters locally generated packets)...
  • A serious answer for once - just buy Checkpoint's Firewall-1 (they popularised stateful inspection). Quite expensive, licensed per host behind the firewall, and not peer reviewed like Linux or BSD firewalling, but pretty popular.
  • I found the article very informative and they mentioned this. Sure enough a stateful firewall will eat up memory but you have a stateless firewall in front to get rid of most of the flak, thus making the stateful firewalls job easier but maintaining flexibility. And it should be better at preventing dos attacks.
    Anyway the same goes for other stateful firewalls so if a linux box doesn't cut it for a large company they still have their expensive proprietary solutions, but for a nice home firewall this rox.
  • What a chronically overworked sysadmin would really like to see is a graphical, gee-whiz, easy-to-use utility to organize and edit rulesets without having to delve so incredibly deeply into the guts of the syntax. I've looked over at Freshmeat, but nothing has really rung my chimes. It's not that I don't _care_ about system security and upgrading to the latest packet filtering gadgetry, it's just that I'm chronically short of "Round Tuits", and this huge pile of Luser Requests doesn't seem to be getting any smaller. Suggestions?

  • Re:MAC filters (Score:3)

    by Cato ( 8296 ) on Monday January 22, 2001 @10:33AM (#490380)
    The real solution to open ethernet ports is to use authenticated VLANs - require the workstation user to authenticate before being put into a suitable VLAN, and just ignore the MAC address.

  • Yes, it has been supporting these for a lont time, so it is a mor emature solution.

    stateful inspection (ipf) and rate limiting (dummy net thru ipfw).

    ratelimiting agains't many DoS type attacks is actually built into the default kernel.
  • I think I can sum up the one and only advantage (if you can call it that) that iptables has over ipf (aka ipfilter) in one short sentence...

    You can run iptables in Linux.

    Actually, non-glibc Linux 2.0.x kernels can use ipfilter as a kernel module.

    Linux has its uses, don't get me wrong, but I'll take an OpenBSD firewall over any Linux firewall, regardless of which distro, or firewalling software it runs.

    I completely agree, ipfilter has done stateful firewalling for a long time now, where Linux has just added it. I'll take the more tested codebase any day, it's only logical.
  • We have tons of open RJ45 jacks around that anyone can plug into...

    Why not go to the wiring closet and remove the jumper cable between the patch panel to your switch/hub on those ununsed ports?
  • Except that FreeBSD's SMP is already damn good. When BDSi's code makes it in (5.0), it will blow Linux away.

    OK. ipchains is a good effort. It still isn't as good as ipf.

  • I needed to block a list of thousands of ip addresses at the firewall. Here's how I did it:

    First, I read the sample code for how to implement user-space queueing. That's where you pass a packet to a user-space program so it can decide what to do with it. Then I made some trivial changes to that program so that it looks for a file in a certain directory with a name equal to the IP address in the packet header.

    If the file exists (i.e. an open() call succeeds), then the packet is denied; otherwise it is allowed. Anytime I want to add a new IP address to the blocking list, I just create a file in that directory. Since I run reiserfs, the test for file existence is as efficient as a hashtable lookup, but much simpler to code.

    Not as sophisticated as a commercial firewall program, but not as much overhead, either. (Simplistic) benchmarks show no significant increase in network latency. Works for me!

  • Check out Firewall Builder... sourceforge.net/projects/fwbuilder very similar to Check Point's config GUI...
  • Cool =:-) I'm just starting to experiment with FreeBSD. Of the UNIX systems i've had a machine running, it is the nicest. I've had Linux machines (still do infact), and i've also had a System V.r3 machine (boy was _that_ one a pain...) Yeah. It was an old 3B2/310. In any case, thanks for helping my UNIX knowledge...
  • Hehe. ever since that crap started up, I've checked urls in /. comments by waving my mouse over it (and then disabled javascript when that mouse-over hack started, but it didn't last long:). But yes, this sort of things is very good. eg, put doubleclick's network in there instead :)

    Bill - aka taniwha
    --

  • If this replaces ip_chains? Will it allow me to host a game of Tiger Woods 2001 on one of my masqed doze boxes?

    I have to have my priorities in order :)
  • not graphical, but check out ferm [geo.vu.nl].

    very friendly way of specifying firewall rules, regardless of what the underpinnings are (ipchains, iptables)

  • Oh, come ON! Still hiding behind firewalls, are we? Why don't you just connect that default install to the web 24/7 like a *real* man? What's a little break-in now and then? Sure, I bet all your data is valuable, especially those pic.s of Natalie P.

    And .mp3s - real valuable since you are sharing them with Napster anyway, why not just open Windows file shares or Samba to the whole world? Shouldn't open source types who want information to be free lead by example?...

  • Re:Win2K? (Score:2)

    by Anonymous Coward
    Yes, you can do this with Win2K:

    1. install Win2K in its most secure mode
    2. hook it to the Internet
    3. wait 3-4 hours
    4. at this point, the system should have been hacked by at least five 13 year olds, and one of them has formatted your hard disk, and installed Linux for you
    5. login (root, password is 1337)
    6. man iptables
  • This sounds really interesting to me. I do have a question about 2.4 in general though. How well does it run on pre-pentium hardware?

    I remember when 2.2 series came out, many were saying to stay at 2.0.x for pre-pentium hardware because 2.2 would just not run adequately. Was this true in the first place, and does 2.4 'raise the bar' at all for hardware requirements?

    I only ask because my linux firewall/masq box for my cable at home is running a 2.0.36 kernel on a 386 and there probably isn't any hope.

    For a while I was using a P-150 running a 2.2.x kernel (RedHat 6.2 install, probably) and ipchains seemed to be much better than ipfwd.

    At some point I decided I needed that box for another project, so I dusted off that crap old Compaq (a laptop, no less!) and pressed it into service as my masq box using a docking station (two ISA slots, WOOHOO!) and a couple of $7 SMC cards and slink. It works great as long as I don't try anything fancy.

    But, the question is... what is a reasonable amount of hardware to expect to have to use for a 2.4-kernel firewall? I'd love to play with this. Think a 486-100 w 32Mb would be enough? It's not doing much, just sitting around for compiling kernels for the 386. ;-)

  • Re:A Question -- Can it allow Win2k VPN? (Score:3)

    by PhilBrut ( 87389 ) on Monday January 22, 2001 @10:49AM (#490394) Homepage
    You're getting bit by the fact that there's more to MS PPTP than meets the eye - the tunnel itself is actually a GRE tunnel with some funky MS-proprietary encryption, with a control connection at 1723/tcp (or something like that).

    It can be done, but a 2.2 kernel needs to be patched to do it. I've not tried it, but the 2.4 kernel should allow you to "port-forward" the tcp connection and the GRE tunnel back to the Win2k system.

    Just keep in mind that there's no connection tracking, so it has to be the same Windows system making the VPN each and every time, and one and only one VPN can be going at any one time.
  • "This has been in BSD forever..."

    I bet by the time I'm done typing and hitting submit there will be several posts saying something like this. Why can't everyone stand back and go "great job guys for implementing it on a new platform!" instead of "you lamers...we had this X years ago". If they had implemented this on MacOS(random OS picked off the top of my head) would the BSD guys say the same thing?
  • Prior "wire techs" labelled nothing. It would be a month long job to figure out. We do clean it up as we upgrade though.

  • Re:I'm sure iptables is great and wonderful, but.. (Score:4)

    by Majix ( 139279 ) on Monday January 22, 2001 @10:55AM (#490397) Homepage
    Try out Firestarter [sourceforge.net] (Disclaimer: I wrote the program, so I'm biased). Supports both ipchains and netfilter, several nics, NAT/Masq, ToS/ICMP filtering etc.

    I, just like you, got really tired of editing scripts all day long, the end result is this GNOME program. First the program presents a wizard for quickly setting up a firewall, then you can monitor the firewall hits you get and close/open/stealth ports with just a few clicks. Easy of use was the goal with this program.

  • in that's big-endian, like say from Solaris (the most popular Internet platform) the translation must occur before any filtering gets done. So a saavy hacker can mount an attack from any Solaris box and easilt Ddos any Linux box by doing a reverse htons() packet flood.

    Nope. Just store the targets in network order and do a normal compare. All that matters is that the target list (hash or whatever) and the packet be in the same order.

  • The point here is not "BSD is better than Linux." The point: "it's unfair that Linux gets good press for doing something everyone else has been doing for so long."

  • Re:I Can Hear It Now (Score:3)

    by bugg ( 65930 ) on Monday January 22, 2001 @11:10AM (#490409) Homepage
    Ok, I am the AC that had the original post WRT this topic that's since been moderated up to 4: Informative (I post regurarly, it gets moderated down, I post AC, it goes up. Who woulda thunk it?) and perhaps I'm being misunderstood.

    Yes, it's a good thing. Congratulations Linux folks, I'm sure you did a good job, having stateful firewalls are handy for everyone to have. I don't mean to say the typical "we've had this for X years"

    My issue was, and still is, mainly with the slashdot title. Why it rocks. It doesn't generally rock, it just rocks compared to the implementation in Linux 2.2.

    Now, if the article had been "Why it's a great improvement over 2.2" that would have been great, and I would have continued on my day. But the fact that the title makes it seem revolutionary, when it's actually quite evolutionary, made me step up to the plate.

    What rocks? Stateful firewalling. Does the article discuss Linux's implementation in detail, explaining why it's better than other stateful filters? No. It discusses the old and proven technique of stateful firewalling, and therefore tries to further Linux based on that alone.

  • I've been using stateful firewalling(with an OpenBSD box) for quite some time now. A PII for this system is overkill for a firewall absorbing ~100000 hits daily with ~100 hosts behind it.

    You should also consider that your firewall should be just that, and nothing else. No X, no Apache, no extraneous servers that don't need to be running on that particular machine.

    YMMV - but a firewall, even one that keeps state, is not an especially computationally intense undertaking.

  • I keep hearing that *BSD's IPstack is faster, more robust, etc. But I never see hard numbers to back it up. I want a identical hardware benchmark that can push both stacks, and see which one is better. The nearest I've seen compare linux 1.2.* and FreeBSD 2.0. Ancient history in otherwords.

    If you've got numbers, and the testing details that produced them, I'd like to see them.
  • What you said may very well be true for OpenBSD vs. Linux 2.2.x.

    I don't think Linux 2.4.x has been out there long enough for anyone to be making absolute statements about which TCP stack is more robust or fast... but remember, the Linux 2.4 TCP/IP was specifically rewritten to be very fast and highly deserialized (i.e. SMP-capable) so even if [Open,Free]BSD TCP/IP was faster and better, it might not be now.

    Especially on SMP hardware, which current BSD's don't support. And even though I'm not flaming you, I should mention that I have used both Linux and BSD for firewalls. Currently my firewall is OpenBSD, and I'm not in any rush to change it - not much need for speed on a DSL connection.


    Torrey Hoffman (Azog)
  • Packet filter is not supposed to look into the payload of the packet. That is done by something called proxy. Regarding FTP, well, let's face it, it is a badly broken protocol, period.

    Also, "limit the number of SYN packets from a single source" doesn't really help in defending the DoS attack. The attacking machine doesn't use its real ip as the source ip nor does it use a single source ip.

    I agree with other posters: iptable is playing catch up with ipfilter.

  • Why iptables (Linux 2.4 Firewalling) Sucks (Score:4)

    by Penico ( 101227 ) on Monday January 22, 2001 @11:37AM (#490426)

    I was eagerly waiting for Linux 2.4 from the day I heard somewhere it would support ipfilter. I run mostly BSD boxes, due to personal preference, while still keeping a few Linux systems up and running. All systems run perfectly well and cause me little grief, if any at all.

    However, once again the Linux camp is "doing things their own way" and contributing even more to the separation between different Unix flavors (as well as making those sigs that go something like "Linux - the Unix defragmentation tool" even funnier). Don't get me wrong, iptables seems to have a few cool features that are not present in ipfilter, but just why was ipfilter not used instead ? It is present in a few platforms already (runs on all BSD's, as well as Solaris / SunOS and IRIX), it is tried and tested, and it does most of the stuff iptables does. And it can probably be extended to do everything iptables does as well, with some extra work. But the Linux folks, however talented and bright they undoubtedly are, and however good a kernel they have produced, have just taken a completely silly route this time. Not only have they duplicated effort towards the same (or at least, a very similar) end, they have also created another headache for busy sysadmins who maintain a few different systems. I had high hopes on ipfilter being "officially" supported under Linux (the ipfilter code mentions sketchy support for Linux, which I have admittedly not tested, but from the looks of it it has not been maintained for a long time --- the most recent kernel mentioned in the HISTORY file is 2.0.34, the last reference to Linux appears in 1998), but now I will be forced to get rid of the only Linux box I still maintain as a server (for various reasons, none of which related to the quality of the OS --- that little box has run great for ages, and causes me no grief at all) if I ever need firewalling for it. Yes, I could learn to work with iptables (and I probably will anyway, out of curiosity), but the Linux folks could probably learn to cooperate better with the rest of the world in certain aspects. It really is a shame, because I honestly think Linux is great --- the mindset of some of it's users (and by the looks of it, some developers as well) is however a different matter...

  • i know it has rate-limiting to make DOS attacks not work as well...

    I'm sorry, but once that barrage of packets is queued up at the remote end you have NO hope in averting it. rate-limiting only works if you are doing the rate-limiting on the remote end of the network.

    On a slightly different note: I've considered going to BSD firewalls off and on over the years since learning about Linux and Unix in general but I haven't been able to find a really strong reason to. Ok it's more mature. Sure it's got a better stack. But honestly, unless you're running on super fast networks the Linux stack seems good enough and Linux seems mature enough. A reasonably-skilled admin can lock it down and anything short of a kernel exploit keeps it secure. For me, it just doesn't seem worth it to pick up an entirely new OS.

    Yeah it smells like firelighters but I'm being honest. Anyone who's been on /. as long as I have should know that I'm no troll. Are there any really convincing reasons to move to BSD?

  • FreeBSD SMP support is akin to Linux 2.0 in 1996! FreeBSD uses a BFL (big fuckin' lock). Sure FreeBSD 5.0 might include experimental Linux 2.2 (1998) SMP support merged from BSDi code, but when will that be? 2002?

  • While it's true that it is usually 10 bits per byte on asynchronous links (1 start bit, 8 data bits, 1 stop bit, no parity), that's not true for things like leased lines. They use synchronous serial communication, so it is 8 bits per byte. IIRC, ISDN is also synchronous, but I don't know about some of the newer signaling schemes.

    Just tryin' to keep the math straight.

  • 2.4 Linux Kernal too big for LRP! (Score:3)

    by npendleton ( 255215 ) on Monday January 22, 2001 @12:07PM (#490440)
    stateful firewalls = excellent... But LRP will NOT readily support 2.4 kernal size!
    (LRP is the Linux Router Project at http://lrp.c0wz.com/ [c0wz.com] a kick ass firewall/router/NAT distro that needs a single floppy, 486 or better, 2 nics, and NO harddrive!)

    Joshua Jackson, of the impressive www.coyotelinux.com [coyotelinux.com] LRP distro, [coyotelinux.com]
    said "I wish I could move to the 2.4 kernels for Coyote, but not in the floppy version I am afraid. By the time you get all of the necessary options built into the kernel, it is roughly 350kB larger than the 2.2 kernel... in addition, the full iptables and iptroute2 package are quite a bit larger than their 2.2 equivs. The Embedded project is already running on the 2.4.0 final kernel, but it does not run from a floppy."

    -Nathaniel
    Bummer for the rest of us.
  • >So I also say, give 2.4 a try on your 386 if it has the memory (you might get away with 8M) - you might be pleasantly surprised...

    Thanks, I might just do that. It is a 4Mb machine with a 6Mb add-on card (25 Mhz, 500 Mb drive, of which over 1/2 is trashed - I installed a 50Mb root part on the internal drive then have a 200Mb IDE drive sitting in the docking station with the rest of the OS and swap on it - picked the thing up for $5 at a garage sale, not working).

    Someone asked why I didn't run *BSD... cause I wasn't smart enough to figure out how to install it! Now, I'm not saying I'm too stupid to install BSD - I've actually got a OpenBSD 2.6 install on a PPro-200 that I play with. Problem was installing on this low-mem machine.

    It died at the end creating the /dev tree. The FAQ says to interrupt the install towards the end to mount the swap and then resume. I finally got past this only to have it lock up on boot trying to load services (rpc, I think). So, yeah, I booted from floppy and poked around trying to stop it from starting services to see if I could get it to boot. No luck, gave up.

    I _really_ wanted to give BSD a try - I've obviously heard a lot about it. In the end I installed Debian and got it to work and put it in service and have since forgotten about it.

    Now I've got this 486, I'll have to decide... oh - maybe I'll find something more productive to do with my free time like play WarcraftII again :-)

  • Remasqing Packets (Score:3)

    by Srin Tuar ( 147269 ) <zeroday26@yahoo.com> on Monday January 22, 2001 @12:35PM (#490449)

    I am trying to find out if iptables does remasqing: Masquerading a packet with a destination back inside the masq'd LAN.

    I know ipchains doesnt do this, and its been a considerable headache. Some of the things I cannot do are:

    • access my port forwarded apache box from its external internet address from within the LAN; I must use its internal LAN address.
    • join a battlenet game of starcraft hosted by someone on the same LAN.

    I know there is a kernel patch for 2.2 that will introduce this ability, but it breaks the ipchains code's security.

    Looking at the way iptables works, I think this should be possible (Port forwarding would be done before routing, and masqing done post-routing), but it is not addressed specifically anywhere that ive seen.

    Anybody know?

    Disclaimer: Ive asked this question before on K5, but nobody seemed to have a ready answer. Maybe the broader audience

  • If BSD/OS is sooo much faster than Linux 2.4, then why does NO ONE use any BSD for SPECweb benchmarks [spec.org]? I see Linux 2.4, Windows 2000, AIX, Tru64, and HPUX.
  • The typical Linux user does NOT have a multiprocessor machine.

    Actually dual Celeron and P2/P3 Linux boxes are pretty common. While certainly not everyone has one, I do, and I probably know at least 6 or 7 other people who do as well.

    Deciding what a 'typical' user is, now that is the problem.

  • FTP monitoring is BAD! (Score:5)

    by bug ( 8519 ) on Monday January 22, 2001 @01:11PM (#490454)
    For those of you not familiar with stateful firewalling, it is an incredibly good thing. I've gone from using ipfwadm to using ipchains to finally using ipfilter on BSD. Because of ipf's support of stateful filtering, my firewall rulesets were *much* simpler. Given that many (most?) problems associated with firewalls is the complexity of the configuration, this is a Very Good Thing(tm). After migrating from linux/ipchains to BSD/ipf, I was able to add serious protection for my network, including my high ports (which often run the most vulnerable services, namely RPC services). I haven't used netfilter/iptables, but it looks to be a *huge* step forward for Linux.

    All that being said, I have a major problem with this article. It seems to suggest to users that FTP monitoring to handle active FTP clients is a good idea. In fact, this is a *terrible* idea. I got to watch Dug Song et al at BlackHat walk right through a CheckPoint FW1 system like it wasn't even there by exploiting some assumptions that FW1 made when monitoring FTP for the PORT commands. It sounds to me like the netfilter/iptables support for FTP functions in a very similar manner as FW1. If you must support FTP through your firewall, make your users use passive FTP. Every modern FTP client and every modern FTP server that I've seen all support passive FTP. Of course, a better approach is to encourage secure communications, like scp or SSL.

    Bottom line, the best firewall design is the simplest one possible that gets the job done. Adding neato features like payload monitoring to poke extra holes in the firewall is diametrically opposite this philosophy.

    Also, please remember that a firewall only serves as a method of blocking traffic between network segments. It does not magically secure network traffic from viewing, spoofing, manipulating, or hijacking (you need to use protocols that support strong authentication and strong cryptography to achieve this). It does not secure the applications or systems which you allow traffic to touch (you need to use secure OSes under secure configurations to accomplish this). It does not magically protect your systems against insider threats (you need to have good people working for you, restrictions on outside connectivity, and thorough physical security to accomplish this). Remember, crunchy on the outside and soft and gooey on the inside is great for candy, bad for networks.

  • BTW, Linus is from Finland, not Sweden, although ethnically he is swedish and speaks swedish as his 'native' language.

  • However, once again the Linux camp is "doing things their own way" and contributing even more to the separation between different Unix flavors (as well as making those sigs that go something like "Linux - the Unix defragmentation tool" even funnier). Don't get me wrong, iptables seems to have a few cool features that are not present in ipfilter, but just why was ipfilter not used instead ?

    Being compatable at the cost of better functionality isn't allways a good idea. Would iptable's "cool new features" have fit into the ipfilter framework? Is there some fundomental reason that iptable might be faster, or even just simpler to implment?

    I don't even run Linux (three diffrent BSDs, no Linux), but I wouldn't want them to give up useful features just to stay compatable with me any more then I would want FreeBSD to adopt some else's FireWire framework if that framework could never do foo, or was boud to allways suck in some way.

    In fact OpenBSD has a framework for Crypto cards. It works great for IPSEC, but poorly for other things (like cryptoFS, or userland crypto apps). If FreeBSD adopted it as is they would get half a dozen working crypto cards, bitchn' fast IPSEC. I think it would also be a giant mistake. I would rather end up with an incompatable framework that is better, then a compatable one that isn't so hot. It would be nice if the new one was very similar and could be "backported" to OpenBSD if they were so inclined...

    Sometime the first implmentation isn't such a good idea, so the second should be diffrent. Or the third, or the sixtyith. That is why we run Unix-like OSes rather then TOPS-8086.

  • The MAC address can be set by software. Any hardware solution is more expensive.
    Some cards even explicitly give you the option to change it (although they shouldn't).

    The MAC address is part of the lowest and therefore hardware level of the ethernet.

    Normally, a ethernet-adapter filters any packages which are not targeted for its MAC address(although even this behaviour can be altered).
    Furthermore, any package send contains the MAC address of the sender. This all happens in hardware and is the ethernet-protocol.

    The change of the MAC address in the OS should only affect the ARP request, which translate an IP-address into a MAC-address.
  • access() is in POSIX, so portability isn't a concern.
    cool hack, too.

    "If ignorance is bliss, may I never be happy.
  • No, actually you probably want a 'stat' call. To quote the man page: "access checks whether the process would be allowed to read, write or test for existence of the file (or other file system object) whose name is pathname." You actually want to do the existence test, you don't want to see if you can do it. Hence 'access' is inappropriate.

    'stat' may have more overhead than the 'open' call, depending on the implementation of your filesystem. So it's probably just fine to keep that 'open' call the way it is.

  • Re:Why iptables (Linux 2.4 Firewalling) Sucks (Score:3)

    by ion++ ( 134665 ) on Monday January 22, 2001 @01:34PM (#490467)
    You seem to describe linux NOT using ipfilter, but making their own, iptables, as a bad idea.
    It might not neassesarely be a bad idea.
    I will write a few analogies, but basicaly my response is
    Competition is good
    If you buy into that, you dont have to read on, if not, please do.

    Why even have Linux in the first place, we have BSD. But wait, there is 3 BSD's, (there was 4), BSDi/FreeBSD, OpenBSD and netBSD??
    But BSD is just a further devellopment of earlier *nix systems (i'm not too knowledgeable of the unix history). But Unix was built on Multics, so lets keep that, or better yet, some system before that.

    Why do we have xx different OS's ??
    One should be enough!
    Why do we have xx different webservers ??
    One should be enough!
    Why do we have xx different GUI's ??
    One should be enough!
    Why do we have xx (2) different chipmakers ??
    One should be enough!
    Why do we have xx harddrive makers ??
    Why do we have xx monitor makers ??
    [high pitched voice getting estatic]
    kabinets? keyboards? cola? beer? car?
    clothes? tvchannels?
    [voice cramming over]
    political views ??
    [breating normal]
    Because, competition is good
    It's good having choice, not everyone likes the same, or chooses the same over something else.
    Naturaly we can work together, and we should, but that doesnt mean one implementation, one manefacturer, ... is a bad idea. Multiple choices enhances life and survival (imagien living from just one sort of food, and it becomming extingt).

    So, be thankfull for being able to choose, and not having the goverment, or some company choose for you. While the first is becomming less and less apparent in the world, the second is becoming more and more widespread.
    And the worst part is that people doesnt seem to care :(

    ion++
  • Actually, identical hardware benchmarks are very poor, because it assumes that each system exploits that hardware to its fullest. The best benchmarks is to have two camps, give them each X number of dollars, and build the best server, and then compare those. For example, if the system has a TULIP ethernet card, and OS A supports it well, and OS B doesn't, then the OS A will win, even if OS B is fater on an EEPro. So, for stuff like this, its better just to do it based on dollars.
  • Afaik it does all this. It's described in netfilter howto (http://netfilter.kernelnotes.org/unreliable-guide s/).

  • Stateful firewalling isn't exactly new technology, and it's even been with the rest of the open source world (BSDs) in the form of ipf for quite a long time- it's gotten so ubiqutious, for example, that FreeBSD's ipfw is now stateful as well.

    Darren Reed's IP Filter ("ipf") is very cross-platform and not exclusive to BSD. It works with several other *nixes as well.

    What's really interesting is that linux used to have stateful firewall support, via ipf! That's right, IPF used to work with Linux. But somewhere along the way with all of the changes to the Linux kernel IPF stopped working and nobody bothered to do the maintainence.

    Instead of doing the required work on the mature stateful firewall package that is ipf, the linux folks put up with stateless ipchains for the longest time before finally adding state to ipchains. Shame!

    This isn't exclusive to Linux though. FreeBSD's IPFW was made stateful even though IPF has always worked under FreeBSD. Reason? IPFW supports ethernet bridging, while IPF doesn't. No doubt there are similar reasons for ipchains over ipf: filtering based on MAC addresses was mentioned (although the desired results have always been do-able with static ARP).

    Instead of re-inventing the square wheel, why didn't these people enhance IPF with the desired functionality? Isn't that what open source is all about? Must NIH prevail???

  • Re:You sissy!!!! (Score:3)

    by plover ( 150551 ) on Monday January 22, 2001 @02:10PM (#490477) Homepage Journal
    Yeah, well, we had it tough.

    Wood and metal scraps. Paper. What luxury! We had to scratch the O.S. into stone tablets with just our fingernails, using only zeros and ones. And we never had enough ones. Whenever we ran out of ones, we had to make do with just zeros.

    And we'd have given anything to have a gerbil. We had to get a group of half-starved cockroaches running in the same direction on an old 45 RPM turntable, and that's not easy, let me tell you. And for blinking lights, we had to rent fireflies, we couldn't afford to actually buy them outright, you know.

    You kids today, you don't know how lucky you have it.

    John

  • Of course not. BSD comes under a fair license that actually gives you choice and control of your code, unlike the GPL, which forces everyone who uses it to keep it open for the world to see. No choice, just forced openness.
    So if the BSD license(s) are so great and fair while has it taken a GPL'd Unix to catch peoples' attention? Why is Linux the free OS that so many big companies have decided to support?

  • The MAC address is hardwired in, but it's the software layers that put the address in the packet or program the Ethernet MAC's registers with most cards. As I understand it, in many cases under Linux, you can change the effective MAC address for a card with ifconfig.

    I believe this is the flag that does the magic:

    hw class address
    Set the hardware address of this interface, if the device driver supports this operation. The keyword must be followed by the name of the hardware class and the printable ASCII equivalent of the hardware address. Hardware classes currently supported include ether (Ethernet), ax25 (AMPR AX.25), ARCnet and netrom (AMPR NET/ROM).

    Does that answer your question?

    At any rate, I know it's possible to do this by hacking the driver in the kernel (at least for NE2K clones), as I've done this personally in a previous life...

    --Joe
    --
  • I used to think that as software got better, it should run on slower, older, hardware better than the older software.

    One of the things I liked when I discovered Linux, was that instead of a 'shiny new things' focus, it was an effort of convergence. Things would just keep getting better, instead of the 'rip out the old one and plug in the new one' ethos of Microsoft's OS products.

    So somebody please, do explain why kernel 2.4.0 shouldn't work better and faster in my 386DX-20 than 1.2.28 does....

    Tell me it isn't like Microsoft.

  • You seem to describe linux NOT using ipfilter, but making their own, iptables, as a bad idea. It might not neassesarely be a bad idea. I will write a few analogies, but basicaly my response is Competition is good

    What competition? Iptables has a monopoly on stateful filtering under Linux.

    It's not about competition. It's about NIH. That's the only reason I can see why Linux went so long without a stateful firewall instead of doing the maintainence on IPF. Would you suggest that not having stateful firewall should "win the competition" over having a stateful firewall? Apparently it did for over two years, only because the terms of that competition made it counter-productive at best.

    I wonder... How many firewalls were left configured to allow all UDP access as long as the sender claimed source port 53, because most mortals didn't know how to permit DNS responses in a stateless config without opening such a wide hole? (FreeBSD's default /etc/rc.firewall used to have just such a hole when ipfw was stateless, but at least ipf was available as an alternative (that's competition)).

  • Throw another in the pit here. My first firewall was 2.2 on a 486sx 33, no issues. I then went to the 2.3 and 2.4 test stuff, still no problems. It seems to me that the sweet spot for the kernel has always been a 486, but remember, its all in the compile. My current firewall is sitting on a K6-2 450, but that machine does a lot more then what my old 486 used to do.

    ...and the geek shall inherit the earth...
  • Ok troll let's be objective. Linux firewalling (ipchains/iptables/whateveranewoneis) has always been humbled by other OS ability in this area. Compare it to Solaris and *BSD for example. Stateful filtering has been out available for a long ass time. It's still possible on Linux as if as you're not using glibc (yuck!). The title for the story is flamebait in itself "...Linux 2.4 firewalling Rocks!" Kudos to the guys who worked their keisters off on it. They deserve it. But there are more mature implementations out there as it is. A better topic would've been "Linux 2.4 firewalling improvements" or something.

    ...would the BSD guys say the same thing?

    You don't even realise that people are behind the monitors do you? We're all people you troll. No one is out to get you you paranoid megalomaniac troll.

    Try to be an ambassador for whatever your choices may end up being.

  • Re:FTP monitoring is BAD! (Score:3)

    by Admiral Burrito ( 11807 ) on Monday January 22, 2001 @03:34PM (#490495)

    If you must support FTP through your firewall, make your users use passive FTP. Every modern FTP client and every modern FTP server that I've seen all support passive FTP. Of course, a better approach is to encourage secure communications, like scp or SSL.
    Bottom line, the best firewall design is the simplest one possible that gets the job done. Adding neato features like payload monitoring to poke extra holes in the firewall is diametrically opposite this philosophy.

    Even worse, payload monitoring and encryption (SSL, IPSec) prevent each other from working. If you're using payload monitoring, encrypted packets will be un-monitorable and things like the "port" command will never be seen, thus preventing the connection from being allowed through the firewall. So in cases where payload monitoring is in place it discourages the deployment of crypto. Likewise, when crypto is deployed it discourages stateful filtering, but that seems to be a relatively good thing because proper encryption should be considered more important than filtering hacks IMHO.

  • The subject says it all. Not all FTP sites of major players allow passive FTP. Most do but not all. How will you explain to a user trying to download a firmware update for something that he has to go home to do it because your firewall won't let him out? That might work at a large company, but at a place where people pay for 'Net access like a University, that doesn't fly.

    --

  • >explain why kernel 2.4.0 shouldn't work better and faster in my 386DX-20 than 1.2.28 does

    Yes, indeed. That was my question, not an assertion on my part. I think if you build a kernel with support for everything, needed or not, then you run the risk of maxing out a slower processor. Course, compile in just exactly what you need, should be the same right?

    See Windows do that! ;-)
  • TIS (now NAI) had the right idea. Gauntlet provides a nice transparent application gateway firewall. Unfortunately since they EOL'd their BSDI version the only support on x86 hardware is NT. It'd really be nice if they came out with a Linux or even OpenBSD version. The only other options are Solaris or HPUX. Somehow I doubt that's going to happen. I just hope NAI keeps their head above water so they don't end up getting bought out by a company like Checkpoint. I think Firewall-1 points out that having the most popular product doesn't make it the most secure.
  • It's not just a matter of having the features, but also implementing them cleanly. I think it's pretty clear that Rusty used Darren Reed's ideas throughout. But from what I've read 2.2 kernel firewalling sounds severely damaged and needed to be scrapped.

    The new implementation is not only more flexible and powerfull but much cleaner. I think before the firewall code was spread out in something like 11 different files?

    I also like the new abstractions where you just break things down into simple catagories:
    You can filter a packet (1)as it comes to the computer or (2)as it leaves. (3)You can filter a packet if it comes from outside and is destined to this computer. (4)You can filter a packet if it comes from outside the computer but is just passing through to another computer. (5)Or you can filter a packet if it was created on this computer.

    Simple! Any packet can be fit into at least two of those five catagories.

    In Linux 2.2 masquarading was a seperate hacked on peice of code. But in linux 2.4 you don't need it any more because you can just say, "If I'm masquarading a packet then it would come from outside and it would pass through my computer with out stopping so I can just filter those types of packets."

    So in the end rewriting it from scratch not only adds cool features but makes it easier to write kernel code because you don't have to edit as many files and the code is cleaner. It provides a simple abstraction so life is easier for users. And kernel hackers can be lazier because because they don't need to code ip masquarading as a seperate feature. I think laziness is something we all can appreciate.

  • The Windows kernel supports things like antialiased fonts and drop-shadows on mouse-pointers... iptables is nothing compared to such advanced technology.

    You Unix people read too much, that's old-fashioned. Try clicking on something once in a while and you'll see that clicking on things is the future of computing.

    That and sound effects.

    "Oh twap!"

  • No it's not typical... but there are a lot of ignorant rednecks here in the U.S. Just like any other country. It's not like human nature makes sudden dramatic shifts when crossing artificial borders.

    More than likely it's just some kid trying to get a rise out of you. The question is, why did it strike such a nerve with you? Why the hostility directed at U.S. citizens rather than ignorant and hateful human beings in general?

    The U.S. governments do not place any blame on minorities, a public official who said any such thing would likely be canned within the week. Racists who do blame minorities for their problems are unfortunately common, but not generally in the majority (depending on where you live).

    The U.S. is just like anywhere else, mostly normal people trying to get by, raise some kids and be happy... I think you're as guilty of prejudice and ignorance as the poster to whom you were responding.

    "Oh twap!"

  • Think of this: you are an ISP, your only uplink is a satellite connection with high latency. Using a transparent proxy to cache web pages will help a LOT in a situation like this.

    Though not so clever if they decide to do the same thing with HTTPS. Also there can be problems with stale data being cached.
  • people use transparent proxies on other protocols (smtp, nntp) without any problems/side effects.

    Two different protocols, with different side effects. The obvious side effects with SMTP would be additional headers appearing in emails and a loss of the redundancy RFC 974 provides.
  • Changing the MAC address is typically not very easy. If you have the source to the Firmware and you know how to really tickle the LAN chip, then you might be able to do it. MAC address ranges are assigned to vendors. The chip (node, card, whatever) must identify itself to the local ethernet network. It get's this number from a ROM (firmware) database usually. I *suppose* it could be hardwired in, though. There's probably a way to program the chip to tell it has a different MAC address.

    What you are missing is that the ROM is actually separate from the ethernet chip. This is rather more obvious on an older card. The only connection between what is in the ROM and the ethernet hardware is the driver. Even if the ethernet chip generates the souce MAC address all it has to go on is what is in it's own registers.
  • Prior "wire techs" labelled nothing. It would be a month long job to figure out. We do clean it up as we upgrade though.

    Well the obvious jumpers to pull would be those where you have no light on the hub/switch to indicate there is anything at the other end :)
  • I dunno, but diablo may be client/server.

    Starcraft on the other hand uses a peer/servant networking paradigm. The reason for this is so: A hosts a game. B and C join the game. A dies. The game must continue so that B and C can continue to fight each other even if A's machine is powered off. In a pure client/server model- the game is over when A quits. In starcraft, ever computer is an equal, so B and C are both clients and servers= the game goes on.

  • IP Filter does not itself do Bridging. On OpenBSD, it's done with virtual bridgeN interfaces, and on FreeBSD with kernel sysctls.

    If you meant that ipf can be used as a transparent firewall on a bridging box, then yes, it can do that.
  • Because a buffer overflow in TUX would lead to total system comprimise.
  • Keep tasks that can be reasonably accomplished outside of the kernel outside of the kernel. It's that simple.

    So we can't easily take [filesystem_here] out of the kernel and expect reasonable results. But, we can and do implement a webserver in userland.

    Tell me- would you like apache to run as root, keep root, and have full access to your hardware? That's what you're doing with TUX.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close