Slashdot Mirror
Why iptables (Linux 2.4 Firewalling) Rocks
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 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?
Yep, I never spell check.
More incorrect spellings can be found he
..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 ?
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
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.
"Building Linux and OpenBSD Firewalls" by Wes Sonnenreich, Tom Yates is a good resource that explains all this.
BdosError
Complexity is Easy. Simplicity is Hard.
...all of which is useless to me until iptables-save can do it IN ORDER. Geez...
--
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.
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?
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 care if they globalize against free speech. All my best free thoughts are done in my head.
I don't believe the book was intended to be eaten. Although, I had a cousin who would eat books.
---
"I'll spot you a NAND gate, and this guy here,..."
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
.... um, i lost you after "0110100001101001".
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
---
Video meliora proboque deteriora sequor - Ovidius
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...
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?
and of course, it will very useful for the script kiddie that used the root toolkit of the day to take over your machine....
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".
---
Video meliora proboque deteriora sequor - Ovidius
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
---
Play Six Pack Man. I
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...
Do not meddle in the affairs of dragons, for you are crunchy, and taste good with ketchup.
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?
- Pithy comment goes here.
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.
There comes a time in every man's life when he must say, "No mother! I do not want any more Jell-O!"
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!
The Web is like Usenet, but
the elephants are untrained.
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...
---
Play Six Pack Man. I
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
very friendly way of specifying firewall rules, regardless of what the underpinnings are (ipchains, iptables)
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?...
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.
There is much cruelty in the universe, John.
Yeah, we seem to have the tour map.
"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?
Try out Firestarter (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.
I played with iptables and one of the 2.4 pre
releases last fall. I found it to be incredibly
slow to load all the rules. Thinking I was
doing something very wrong, I also tried a
fairly vanilla table from one of the 'generator'
sites. Same problem. Can somebody shed some
light on this beyond 'your a dope'?
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.
And it would be nice if you noted the 'OpenBSD' solution is IP Filter by Darren Reed.
If it was said on slashdot, it MUST be true!
Its a great improvement over what was there before, but I wonder if they are ever going to look at active content filtering. At least in a corporate firewall environment it would be great if we could allow active content such as Javascript, Java, Activex only from specific hosts, or thru specific interfaces. To be able to do this in one place, rather than relying on another product would be awesome.
Sure its a huge leap from where it is now to move to active content filtering, but the gains would also be huge. I can see that it would probably add a lot to the processing requirements, but if its rule based then the admin can decide whether or not to implement it.
"Linux users never complain about Microsoft. They don't need to!"
This is the third time that the interface to this functionality has changed, essentially based on a different implementation. Frankly, I don' care if its chains or tables or what, I just need to Masquerade. However, it seems that every time we get a new kernel version we have to change the interface to the functionality because of improved implementation. Just my 12 centimes.
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."
echo Prpv a\'rfg cnf har cvcr | tr Pacfghnrvp Cnpstuaeic
It's not 'elite' to use BSD. It's just practical.
Nobody in the BSD community is trying to be 'cooler than thou'. I think you're looking in the wrong free-software community for that.
Hay thar.
Sure they *could* have used BSDs ipf.
Lets see.
the License for the ipf (IP Filter code) is:
Copywrite (c) 1993-1997 by Darren Reed
The code is *NOT* 'BSD's' The code is Darren Reed's.
If it was said on slashdot, it MUST be true!
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.
Zapman
Snort can do this now.
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.
gd
Yahoo for Linux! One thing that bugged me though was, if I were to use stateful firewalling on my Linux servers, how much memory (and processing) does such take up? Do I have to have a processor running at gigaherz speeds just to firewall my web server farm?
If you don't actually plan on doing anything with the file after opening it, just use access(filename, F_OK). Save yourself a close() system call.
Keep in mind that on top of the file overhead you're also taking hits for transitions to and from userspace for every packet. Best to keep system calls to a minimum in such a case.
DNA just wants to be free...
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...
Actually 2.4 supports the 2.0 and 2.2 interfaces too, as optional (extremely small) kernel modules.
DNA just wants to be free...
Would you shut the hell up please?
/. is so linux centric".
/. crowd'' even though /. is fairly objective (as long as you read posts of a score that is >= 1)
This attitude is all over slashdot. It's funny, because I've seen more posts pointing out how Linux is simply catching up than posts about anything else.
It's just like when an MS story comes out, and 20 million people post that "I know I'll get modded down for this because
It almost seems to me that people who post such things are trying to be ``31337'' by ``going against the
He who knows not, and knows he knows not is a wise man
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?
cpeterso
Configure a firewall that blocks access to all but a single "drive" to which you can get to with some rudimentary h4x0r1ng skillz. fill that directory with a bunch of files, programs, etc. except make every file infected with the most virulent stuff you can find for a variety of OS's. that way, some script kiddy thinks he's hacked your server, and then, BAM! If only you could find a virus that did weird things with the power pathways on the motherboard. Then you could eliminate the kiddie as well as his computer.
----------------------
Opportunities multiply as they are seized. --Sun-Tzu
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.
stateful firewalls = excellent... But LRP will NOT readily support 2.4 kernal size!
(LRP is the Linux Router Project at http://lrp.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 LRP distro,
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.
Heh, the AC has a good point. Linux stateful inspection? Ho-hum, FireWall-1 has been doing that for a while, too, and it has a programmable virtual machine that lets you program your own inspection code for protocols that aren't supported out of the box.
Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, DEATH, SubGenius, mhm21x16
I'm proud of my Northern Tibetian Heritage
I used it a while back when I read about it on Slashdot in one of the users' comments. The only thing I don't like about it is that it has a tendency to make 40,000 files in /etc/firestarter/
All I do is delete the stuff in the script in the first few lines to do with the deny-host-all etc etc and use the rest of it - works very well. It's just the initial setup of the firewall that I think most users hate. I know that was the case with me. I don't mind adding rules manually afterwards...anyway, I highly recommend your program...Congrats!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:
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 ? I see Linux 2.4, Windows 2000, AIX, Tru64, and HPUX.
cpeterso
Which takes so much time.
No, it's an operating system. i386 is a little-endian architecture, though.
Network byte order is big-endian. What are you talking about?
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.
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.
I've used iptables a bit. It's even running a firewall or two here with it. However, I have heard very good things about BSD ipfilter, of which I think iptables is a derivative work. Plus, ipfilter has been out longer in production. I would be curious to see a ./ shoot-out between the two.
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.
Engineering and the Ultimate
Read ACM/SIGCOMM papers. It's all there.
I am talking CURRENT (not plain Reno) TCP stack. (Try google and don't foolishly flame without reading all the many great papers they publish)
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???
Seems to me that 'coolness' is only a issue if it's made an issue.
/.?
I'm busy using computers to do stuff.
Then again, I guess we're all here to strut our stuff... or else why would we post on
Hay thar.
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
John
Will this allow me to use a 2.4 Linux box as a firewall for rtp streams? My BSD firewall at home allows me to do this. I didn't read the article so feel free to tell me to RTFM.
The Information Revolution will be fought on the command line.
I beg to differ. Stateful firewalling has been available under linux. Maybe not out of the box, but Checkpoint's FW-1 will run on linux and is indeed stateful. Maybe you meant to say that stateful firewalling was unavailable under linux for FREE, but that's not to say it wasn't available.
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 addressDoes 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--
Program Intellivision!
Well then, invent your own language to speak first and then get back to us, using the new language of course. Maybe it will be called "eliteistspeak" or something.
Ashes of Empires and bodies of kings,
The truth about Michael
We didn' t have the wherewithal to "invent" a language. We coded in grunts and if I used it now none of you whippersnappers would get it. You guys with your MIT degrees and your god Chomsky always talking about Language and Liguistics and Fortran and LISP and C and all the rest of your newfangled languages and crazy language ways. This is what happens when you try to build a tower to god. A babel-esque plethora of OS's and more languages than you know what to do with. Before it was just about moving from roaches to gerbils as that other guy pointed out. That was called progress! Then it became competitive and now look what you have! A mess I tells ya a MESSSSSSSSSSSSSSS!!!!!!!!!!!! Why if I wasn't in this iron lung I'd whip the lot o' ya!!!!
Hey, you think your house is cool?
--
I don't have numbers comparing their stacks, or SMP ability data (why do you need a multi-proc firewall unless you're doing it for a large company?), but from a user standpoint, I think OpenBSD is fantastic and I recommend that anyone remotely interested in security find a P-166MHz with a 2 gig drive and throw it on, just to try out.
psxndc
The emacs religion: to be saved, control excess.
Go to K5, collect $200, wanker.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
psxndc
The emacs religion: to be saved, control excess.
Does anyone know how I would go about setting up a VPN using this stuff? I know how to do it using Checkpoint and SecuRemote, but what's the open source way? Please feel free to email me if you don't want to answer here.
Dive Gear
--- Think of it as evolution in action ---
Comment removed based on user account deletion
Cool, but why the hell didn't they do this in 2.0, instead of screwing yet again with sysadmins around the world? First it was ipmasq, then ipchains, now it's iptables. Yet another thing for sysadmins to learn ... again. Why can't they do it right the first time, or at least make it compatible?
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
go here http://www.sun.com/solaris/binaries/
it's $75 for the cost of the media plus shipping and handling...
-andy
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!"
By either using SOCKS or redirecting incoming traffic to a specific port on the box behind the firewall.
e.g.
rdr de0 port 4000 -> port 4000 udp
Paul.
End dual-measurement, let's finish going metric!
http://gometric.us
Damn slashdot stuffed up my code:
it should be:
rdr "ext interface" "ext ip" port 4000 -> "internal machine ip" port 4000 udp
Paul.
End dual-measurement, let's finish going metric!
http://gometric.us
Iptables does not just limit the number of syn packets from a single source. You can rate limit SYN packets from any/all sources. The howto even has an example
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
Consider the trustix product then. A linux firewall, and a windows program to configure it.
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.
Read the howto
/Styx