OS-Kerneled Firewalls (n0c)

[chsh1ca]

Originally posted by: n0cmonkey
We could, but there isn't a point. I'm right.

Hahaha.

If you have a suggestion, go ahead and let me know. I'd be interested to see a firewall that has the features of PF, isn't bloated (think iptables), is fast, has a SIMPLE rule language, and runs on as many systems as PF. I think only IPF comes close in the arch and rule language depts.

For sure PF is a nice package, however the last time I looked at it, it lacked some of the more nifty features that netfilter offers.
Your criteria are flawed when examining kerneled firewalls though, since what appeals to you, does not necessarily appeal to everyone, nor does it by necessity make a firewall more secure. To me, the syntax of the firewall rules is entirely irrelevant, to others it matters. There is no clear advantage to english-style rulesets IMO -- it doesn't offer you more security, nor does it simplify writing of the rulesets. I don't quite get what you mean about SIMPLE rule languages though.

I also don't get why you're saying Netfilter is bloated. Please elaborate on that, as well as what specifically you mean by "as many systems as". Is the latter a reference to architectures, or a reference to production in use systems?

 

[n0cmonkey]

I'm going to answer these points out of order. But first, I want you to know that I do believe this is all subjective, so there is no correct answer really. My criteria isn't flawed, it's just my opinion.

As many systems as PF: Pf runs on OpenBSD, FreeBSD, and NetBSD. That's 3 operating systems. Netfilter runs on Linux. (IPF has FreeBSD, NetBSD, Solaris, and HP-UX I believe ) So we have roughly 50 hardware archs, and 3 OSes for Pf.

The language matters to me. If it's difficult for me to understand, it will be harder for me to write a good ruleset for it. If I write a bad ruleset, the security benefits are nil. IPTables/netfilter/whatever it will be called tomorrow () has a nasty configuration language. I don't like it. A lot of that is probably due to the fact I was used to IPF and Pf before I had to touch it. So yes, there is bias.

I'm really tired at the moment, so please correct mistakes here. I'm being lazy and not looking for documented proof to help me actually remember things.

I think I've read that IPTables isn't a truely L3 firewall. It can look at the silly things like MAC addresses and whatnot. I don't think that belongs in a firewall. Also, IIRC, it can look at some payload? What's that doing in a simple firewall?

I've also read that IPTables doesn't do true state checking. Now that might have changed since the last time I read that. Does it check the sync IDs now?

Pf is truely a thing of beauty.

 

[Nothinman]

I think I've read that IPTables isn't a truely L3 firewall. It can look at the silly things like MAC addresses and whatnot. I don't think that belongs in a firewall. Also, IIRC, it can look at some payload? What's that doing in a simple firewall?

Noone said it was a simple firewall, it can examine and change pretty much anything in a packet from MAC addresses up to payload data. But it's also modular, so if you don't need things like state tracking, limiting, logging, etc they're not loaded. The match module that inspects payload is a really basic substring match, it would be really nice if a regexp module was done but that would need quite a bit of CPU time to anayze a decent amount of traffic.

I've also read that IPTables doesn't do true state checking. Now that might have changed since the last time I read that. Does it check the sync IDs now?

It does real state tracking and you can write custom conntrack modules so things like FTP, quake, IRC/DCC work properly even though they're not normally NAT friendly.

Pf is truely a thing of beauty.

PF is nice and simple, but netfilter was aiming to do a lot more and it succeeds.

 

[n0cmonkey]

Thanks for the corrections Nothinman.

I'mm a firm believer in the K.I.S.S. principles.

 

[chsh1ca]

Originally posted by: n0cmonkey
I'm going to answer these points out of order. But first, I want you to know that I do believe this is all subjective, so there is no correct answer really. My criteria isn't flawed, it's just my opinion.

When I said it was flawed, I was trying to point out that certain things can be quantified, and certain things cannot. Whether an english-language ruleset is capable of improving security is subjective. A featureset is not.

As many systems as PF: Pf runs on OpenBSD, FreeBSD, and NetBSD. That's 3 operating systems. Netfilter runs on Linux. (IPF has FreeBSD, NetBSD, Solaris, and HP-UX I believe ) So we have roughly 50 hardware archs, and 3 OSes for Pf.

50 archs? Are you kidding me? Linux will run on way more architectures than all of the BSDs combined. Its goal is portability remember. NetBSD has the most supported processors architectures it would seem, but it still doesn't stack up to linux considering linux will run on any platform with a GCC port. In total it is easily more architectures than the BSDs. As the BSDs are merely variants of one another that have split off one another at one point or another, you can hardly call them completely separate OSes, anymore than I could call Linux 2.4 a separate OS from 2.6. As I would like to avoid a semantical argument regarding at what point an OS begins and ends, I'll concede they are separate enough to not call one operating system. Even still, 3 "operating systems" that are close variants of one another and some indeterminate number of architectures -- you listed 50 architectures, but NetBSD which is by far the most portable BSD only lists some 15 processor types it will run on. Each architecture is a variant of the processor type.

The language matters to me. If it's difficult for me to understand, it will be harder for me to write a good ruleset for it. If I write a bad ruleset, the security benefits are nil.

Well, to me personally as a developer, I have no issues understanding the method used to create it. Granted, you ARE speaking to someone who was in the midst of writing the basis for a perl script that would convert PF-style syntax into netfilter rules when his drive crashed.

IPTables/netfilter/whatever it will be called tomorrow () has a nasty configuration language.

No more than say, cron IMO. By the way, it has ALWAYS been called Netfilter, people mistake it for "iptables" which is merely the command used to add/delete/update firewall rules. The entire package of packet filter + cli management tools is called Netfilter.

I don't like it. A lot of that is probably due to the fact I was used to IPF and Pf before I had to touch it. So yes, there is bias.

I can respect that.

I think I've read that IPTables isn't a truely L3 firewall. It can look at the silly things like MAC addresses and whatnot.

Depends. If you load any extra modules, no, it is a L3/4 firewall.

I don't think that belongs in a firewall.

I've had people on several forums (and usenet) basically call me an idiot for saying that a proxy is not a firewall, and several 'experts' came and 'corrected' my view of it. The question really is do you consider *just* a packet filter a firewall. I believe there is some information that should be used that exists solely at the network and protocol layers (L3/4), but in essence I do tend to agree with you, though I would define the separation of layers differently.

Also, IIRC, it can look at some payload?

Again, as Nothinman said, IF you load that module.

What's that doing in a simple firewall?

Busily dropping Code Red hits and the like so I don't have to put up with grepping the logs myself and blackholing those IPs.

I've also read that IPTables doesn't do true state checking. Now that might have changed since the last time I read that. Does it check the sync IDs now?

Yes, it does true state checking as far as I'm aware. It doesn't HAVE to though, if you don't want it to.

Pf is truely a thing of beauty.

No disagreement on it from me there, but I would disagree that it is the most feature-rich and lean firewall out there. Iptables can be configured to be so FAR simpler than PF IME.

EDIT:
I'd be very interested to see what others have to say on this as well (this means at least spidey, and JackMDS! ), so feel free to chime in.

 

[cmetz]

chsh1ca, "Linux will run on way more architectures than all of the BSDs combined. Its goal is portability remember. NetBSD has the most supported processors architectures it would seem, but it still doesn't stack up to linux considering linux will run on any platform with a GCC port."

This is just plain wrong.

"I've had people on several forums (and usenet) basically call me an idiot for saying that a proxy is not a firewall, and several 'experts' came and 'corrected' my view of it."

A firewall is a function, or use, of technology in a network topology. As such, a wide spectrum of technologies could be used to serve that function. Proxies such as SOCKS or TIS Firewall Toolkit (remember that, folks?) were the way it used to be done before PAT became the dominant technology. Anyone who tells you that only a particular technology could be properly called a firewall is confused, and in particular they're confused because a firewall is a role, not a technology.

pf vs. netfilter, BSD vs. Linux, Coke vs. Pepsi:

Each has their own strengths and weaknesses. I use both. If a need requires a feature that one or the other is the only one with it, then the choice becomes clear. If both will do the job (which is common), then it typically comes down to which of the two OSs will work better in the customer's environment. I assert that if either will do what you need them to do, whichever one you have more human competence available for it is the better choice. That is to say, if I'm putting a box somewhere I know there's a guy available who knows Linux, then I lean towards netfilter, and same for OpenBSD. Both pf and netfilter can be great if properly configured and maintained and useless if managed improperly, so competent support is a must.

 

[n0cmonkey]

I'm going to try not to be a total ass about this.

Originally posted by: chsh1ca

50 archs? Are you kidding me?

I think NetBSD -CURRENT is on 50. 1.6.2 was released on 40.

Linux will run on way more architectures than all of the BSDs combined.

I don't see suppport for more than a handfull in the kernel source I have.

Its goal is portability remember.

Linux's goal was not portability. In fact, Linux and friends have been awfully slow in including non-x86 architectures up until recently. You want alpha support? Go to this site. Later it was "go to this site and get these patches, it's still broken in tree." Remember NetBSD supports 50 arches in the main source tree, and by support it typically means "it works and is just about on par with the rest of the archs."

NetBSD has the most supported processors architectures it would seem, but it still doesn't stack up to linux considering linux will run on any platform with a GCC port.

This is really a dumb thing to be arguing about. It gets argued all of the time on crapsites like /. and osnews. Basically it comes down to: Linux gets ported, the port doesn't make it into the main tree, and the port stagnates, but it's "supported!" NetBSD gets support in their source tree, keeps it fairly up to date, and doesn't seem to bother if they don't plan on supporting it.

In total it is easily more architectures than the BSDs. As the BSDs are merely variants of one another that have split off one another at one point or another,

Yes, all of the free BSDs (not FreeBSD ) came from the same roots, BSD. Big surprise there. OpenBSD forked from NetBSD. NetBSD came out of 386BSD, and FreeBSD out of 4.2 BSD. IIRC.

you can hardly call them completely separate OSes, anymore than I could call Linux 2.4 a separate OS from 2.6.

100% incorrect. OpenBSD is different than NetBSD which is different than FreeBSD which is different than OpenBSD. If they weren't seperate OSes I could take a driver from FreeBSD and use it on OpenBSD without having to modify code. They are different OSes.

As I would like to avoid a semantical argument regarding at what point an OS begins and ends, I'll concede they are separate enough to not call one operating system. Even still, 3 "operating systems" that are close variants of one another and some indeterminate number of architectures -- you listed 50 architectures, but NetBSD which is by far the most portable BSD only lists some 15 processor types it will run on. Each architecture is a variant of the processor type.

Mac PPC is different than other PPC varients. What does the processor matter?

I've had people on several forums (and usenet) basically call me an idiot for saying that a proxy is not a firewall, and several 'experts' came and 'corrected' my view of it. The question really is do you consider *just* a packet filter a firewall. I believe there is some information that should be used that exists solely at the network and protocol layers (L3/4), but in essence I do tend to agree with you, though I would define the separation of layers differently.

I think firewall can mean a lot of things these days.

Busily dropping Code Red hits and the like so I don't have to put up with grepping the logs myself and blackholing those IPs.

Must be a Windows requirement. I just ignored them and filtered my Apache logs to ignore them.


Basically it comes down to personal preference. If BSD didn't exist I would be using Linux and netfilter would be fine. For now, there is absolutely no reason for me to use it since I prefer Pf. We have two choices for great, mostly free, open source firewalls.

Some cool things though, with OpenBSD you can now have automatic failover (and their latest song35 is GREAT, everyone should check it out, especially if you have nasty things to say about the IETF and Cisco )

EDIT:
I'd be very interested to see what others have to say on this as well (this means at least spidey, and JackMDS! ), so feel free to chime in.

And Garion and Scottmac and probably a bunch of others we forgot

 

[chsh1ca]

Originally posted by: n0cmonkey
This is really a dumb thing to be arguing about. It gets argued all of the time on crapsites like /. and osnews.

Very true, plus it is getting us off the original point, which was PF versus Netfilter.

Basically it comes down to: Linux gets ported, the port doesn't make it into the main tree, and the port stagnates, but it's "supported!" NetBSD gets support in their source tree, keeps it fairly up to date, and doesn't seem to bother if they don't plan on supporting it.

To me the difference is really neither here nor there, since it basically falls to whom you go to to ask the question. In one instance, it's the port maintainer, in another, it's NetBSD's core group of devs. I'm not sure who is more likely to actually DO something in the event of a problem related to a specific architecture.

Mac PPC is different than other PPC varients. What does the processor matter?

It matters because citing architectures just inflates the number, and does nothing practical IMHO. Next you'll be telling me that every PC instruction set since i386 should count: i386, i486nc, i486c, i586, i686, AMD64, etc..

I think firewall can mean a lot of things these days.

Unfortunately, the media and marketing divisions of companies who make "software firewalls" have made the term its bitch and now use it incorrectly like 'hackers'.

Must be a Windows requirement. I just ignored them and filtered my Apache logs to ignore them.

Yes, and the reality is, people still use IIS as their web application server. Not me personally, mind you, but it does happen.

Basically it comes down to personal preference. If BSD didn't exist I would be using Linux and netfilter would be fine. For now, there is absolutely no reason for me to use it since I prefer Pf. We have two choices for great, mostly free, open source firewalls.

The issue comes when either PF or Netfilter fails to do something you or I want.

Some cool things though, with OpenBSD you can now have automatic failover (and their latest song35 is GREAT, everyone should check it out, especially if you have nasty things to say about the IETF and Cisco )

They're actually developing failover functionality in Netfilter itself as well at the moment.

And Garion and Scottmac and probably a bunch of others we forgot

Yep. I think they are avoiding this thread...

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey
This is really a dumb thing to be arguing about. It gets argued all of the time on crapsites like /. and osnews.

Very true, plus it is getting us off the original point, which was PF versus Netfilter.

Basically it comes down to: Linux gets ported, the port doesn't make it into the main tree, and the port stagnates, but it's "supported!" NetBSD gets support in their source tree, keeps it fairly up to date, and doesn't seem to bother if they don't plan on supporting it.

To me the difference is really neither here nor there, since it basically falls to whom you go to to ask the question. In one instance, it's the port maintainer, in another, it's NetBSD's core group of devs. I'm not sure who is more likely to actually DO something in the event of a problem related to a specific architecture.

Mac PPC is different than other PPC varients. What does the processor matter?

It matters because citing architectures just inflates the number, and does nothing practical IMHO. Next you'll be telling me that every PC instruction set since i386 should count: i386, i486nc, i486c, i586, i686, AMD64, etc..

AMD64 is different. The rest are the same. OpenBSD is doing some neat things with AMD64 that previously couldn't be done well/at all on x86 based machines.

I think firewall can mean a lot of things these days.

Unfortunately, the media and marketing divisions of companies who make "software firewalls" have made the term its bitch and now use it incorrectly like 'hackers'.

Must be a Windows requirement. I just ignored them and filtered my Apache logs to ignore them.

Yes, and the reality is, people still use IIS as their web application server. Not me personally, mind you, but it does happen.

I think that has to do with less knowledgable people designing the whole application architecture. The smart ones either use apache, zeus, or know how to secure IIS

Basically it comes down to personal preference. If BSD didn't exist I would be using Linux and netfilter would be fine. For now, there is absolutely no reason for me to use it since I prefer Pf. We have two choices for great, mostly free, open source firewalls.

The issue comes when either PF or Netfilter fails to do something you or I want.

I can't think of anything off hand that I have wanted to do that neither would be able to accomplish. It's a comfortability thing for me.

Some cool things though, with OpenBSD you can now have automatic failover (and their latest song35 is GREAT, everyone should check it out, especially if you have nasty things to say about the IETF and Cisco )

They're actually developing failover functionality in Netfilter itself as well at the moment.

In netfilter? ew. One of the nice things about how OpenBSD is doing it, is the fact that it kind of sits out side of the firewall. CARP can be used for any number of things. Any clue whether Linux is going to be using CARP, or are they going to be using some horribly patented POS?

And Garion and Scottmac and probably a bunch of others we forgot

Yep. I think they are avoiding this thread...

Can you blame them?

 

[chsh1ca]

Originally posted by: n0cmonkey

Originally posted by: chsh1ca
It matters because citing architectures just inflates the number, and does nothing practical IMHO. Next you'll be telling me that every PC instruction set since i386 should count: i386, i486nc, i486c, i586, i686, AMD64, etc..

AMD64 is different. The rest are the same. OpenBSD is doing some neat things with AMD64 that previously couldn't be done well/at all on x86 based machines.

Yes, and the reality is, people still use IIS as their web application server. Not me personally, mind you, but it does happen.

I think that has to do with less knowledgable people designing the whole application architecture. The smart ones either use apache, zeus, or know how to secure IIS

Sometimes it is impossible to secure IIS without taking a box online, esepecially if you are waiting for a patch from microsoft that WON'T undo the previous four patches.

I can't think of anything off hand that I have wanted to do that neither would be able to accomplish. It's a comfortability thing for me.

They're actually developing failover functionality in Netfilter itself as well at the moment.

In netfilter? ew. One of the nice things about how OpenBSD is doing it, is the fact that it kind of sits out side of the firewall.

If it is done in Netfilter, the two boxes can exchange routing information, and pass the conntrack table from one machine to the other. The big advantage being that if one firewall were to go down, the other could seamlessly take control and STILL keep all your connections alive. You'd have to use pfsync to achieve the same effect, but then you are going from just PF to needing PF + CARP + PFSYNC in order to achieve the same effect you could be able to achieve by loading a kernel module in NF. Anything that generates less calls to the IT dept. is a good thing IMO.

CARP can be used for any number of things. Any clue whether Linux is going to be using CARP, or are they going to be using some horribly patented POS?

Patented? I have no idea what the plans are, I'm not on the mailing list.

Can you blame them?

Yes, because they COULD change whatever they don't like about the thread by posting

 

[n0cmonkey]

Originally posted by: chsh1ca

If it is done in Netfilter, the two boxes can exchange routing information, and pass the conntrack table from one machine to the other. The big advantage being that if one firewall were to go down, the other could seamlessly take control and STILL keep all your connections alive. You'd have to use pfsync to achieve the same effect, but then you are going from just PF to needing PF + CARP + PFSYNC in order to achieve the same effect you could be able to achieve by loading a kernel module in NF. Anything that generates less calls to the IT dept. is a good thing IMO.

Part of the Unix philosophy is smaller applications that do less individually, but together can do quite complex things. OpenBSD tries to stick to it's Unix based roots. I personally like the idea of different pieces doing different things. Qmail does this, and I think it would be perfect, if it were free

Patented? I have no idea what the plans are, I'm not on the mailing list.

CARP was born because other methods out there are patented. VRRP is not free.

Yes, because they COULD change whatever they don't like about the thread by posting

Good point

 

[chsh1ca]

Originally posted by: n0cmonkey
Part of the Unix philosophy is smaller applications that do less individually, but together can do quite complex things. OpenBSD tries to stick to it's Unix based roots. I personally like the idea of different pieces doing different things. Qmail does this, and I think it would be perfect, if it were free

To an extent I agree (and I am a fan of QMail, but I don't get what you mean by not free), however for something like a firewall there is some critical security related data you don't necessarily want replicated elsewhere in apps that could potentially be less secure.

CARP was born because other methods out there are patented. VRRP is not free.

Ah, for all I know they may just come up with one of their own methods. It would make sense to NOT reinvent the wheel, but they may have issues with using NON-GPLed methods since the module's license would have to 'taint' the kernel.

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey
Part of the Unix philosophy is smaller applications that do less individually, but together can do quite complex things. OpenBSD tries to stick to it's Unix based roots. I personally like the idea of different pieces doing different things. Qmail does this, and I think it would be perfect, if it were free

To an extent I agree (and I am a fan of QMail, but I don't get what you mean by not free),

The license is crappy.

however for something like a firewall there is some critical security related data you don't necessarily want replicated elsewhere in apps that could potentially be less secure.

Smaller programs are typically easier to work with and ensure correctness.

CARP was born because other methods out there are patented. VRRP is not free.

Ah, for all I know they may just come up with one of their own methods. It would make sense to NOT reinvent the wheel, but they may have issues with using NON-GPLed methods since the module's license would have to 'taint' the kernel.

Not at all. There is some BSD code already in the Linux kernel. You can include free licensed software inside the linux kernel, but you can't include parts of the kernel in free licensed software.

 

[chsh1ca]

Originally posted by: n0cmonkey

Originally posted by: chsh1ca
To an extent I agree (and I am a fan of QMail, but I don't get what you mean by not free),

The license is crappy.

Pfft. You BSD types ALWAYS bitch about licenses. If someone handed you a fork and said "I need it back when you're done with it", you'd likely complain about THAT too. Are you annoyed you can't make money by boxing up CDs of QMail and selling them retail or something? I really fail to see how free can get any freer.

Smaller programs are typically easier to work with and ensure correctness.

I understand that, but BSD has in the past favoured a single piece of code where many might do for security over modularity, so why can't linux do it?

Not at all. There is some BSD code already in the Linux kernel.

Yeah, like the BSD process accounting stuff? Licenses can be altered on a whim though, consider the SSH fiasco.

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey

Originally posted by: chsh1ca
To an extent I agree (and I am a fan of QMail, but I don't get what you mean by not free),

The license is crappy.

Pfft. You BSD types ALWAYS bitch about licenses. If someone handed you a fork and said "I need it back when you're done with it", you'd likely complain about THAT too. Are you annoyed you can't make money by boxing up CDs of QMail and selling them retail or something? I really fail to see how free can get any freer.

From the qmail page: If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

That's annoying at best, the bolded part is part of the reason it is not free. I don't care if you can package up someone's project and sell it closed source under a different name (although I prefer the BSD or free-er licenses), but requirements like that are beyond ridiculous, IMO.

Smaller programs are typically easier to work with and ensure correctness.

I understand that, but BSD has in the past favoured a single piece of code where many might do for security over modularity, so why can't linux do it?

I'm not saying they can't or even shouldn't. I am saying that I prefer the Unix philosophy when it comes to things like this, and my statement was one of the reasons why. I do see your point about how one big program might make it easier on the admin though, and I think it is definitely valid and something to take into consideration.

Not at all. There is some BSD code already in the Linux kernel.

Yeah, like the BSD process accounting stuff?

The drivers were really what I was thinking about. Now that the BSD license has been properly used (instead of abused ) in the Linux source.

Licenses can be altered on a whim though, consider the SSH fiasco.

Fiasco? As far as I am aware, OpenSSH has always been free. Unless you mean the commercial SSH.com being spawned from a decently licensed ssh client before OpenSSH forked the previously mentioned client.

 

[n0cmonkey]

Since we have gone a little off topic, here are some of the features of Pf on OpenBSD (using it on another BSD may or may not have these particular features) listed in no particular order:

• passive OS fingerprinting

• round robin load balancing

• automatic failover (with CARP and pfsync)

• Packet queueing and prioritization through ALTQ (paper on prioritizing ACKs to help asyncronous internet connections)

• SYN proxy (protects spoofed SYN floods by doing a TCP handshake with the client first then replaying it to the server)

• scrub ("Scrubbing" is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.

• anchored rulesets (can be synamic sub-rulesets)

• authpf (authentication through SSH to change rules based on user logging in)

• And of course little things like NAT, port redirection, and packet filtering

EDIT: Cleaned it up to make it easier to read, I hope.

 

[chsh1ca]

Originally posted by: n0cmonkey
From the qmail page: If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval. This does not mean approval of your distribution method, your intentions, your e-mail address, your haircut, or any other irrelevant information. It means a detailed review of the exact package that you want to distribute.

That's annoying at best, the bolded part is part of the reason it is not free. I don't care if you can package up someone's project and sell it closed source under a different name (although I prefer the BSD or free-er licenses), but requirements like that are beyond ridiculous, IMO.

No, it isn't. Remember, he's put money on the line to say that nobody can break his software. If they go around making ported versions so QMail (which is a security-first MTA) becomes a swiss-cheese riddled hole of a mailserver that introduces vulnerability, its reputation and credibility disappears. If you don't like the license, use something else, there are plenty of alternatives, though I have never played with any that approach the sheer simplicity and coolness of QMail.
Still, I want my fork back.

Yeah, like the BSD process accounting stuff?

The drivers were really what I was thinking about. Now that the BSD license has been properly used (instead of abused ) in the Linux source.

Hahaha.

Licenses can be altered on a whim though, consider the SSH fiasco.

Fiasco? As far as I am aware, OpenSSH has always been free. Unless you mean the commercial SSH.com being spawned from a decently licensed ssh client before OpenSSH forked the previously mentioned client.

Well, considering to my recollection it was one or two of the head devs who decided OpenSSH was going to become commercialized, and there were several legal conflicts that put OpenSSH's distributability on shaky ground (far shakier than say, where Linux is under fire from SCO). OpenSSH has always been free, however, the transition from Free -> closed by SSH.com, which was an attempt by the head dev to CHANGE the license, and a community rebelling against it.

passive OS fingerprinting

Anyone with TCPDump can do the same, so I don't know why that's a valuable thing for a firewall.

round robin load balancing

Netfilter supports this by default as well, all you need do is specify the targets to round robin to.

automatic failover (with CARP and pfsync)

Being discussed/developed/worked on.

Packet queueing and prioritization through ALTQ (paper on prioritizing ACKs to help asyncronous internet connections)

IIRC there is this kind of functionality in NF as well.

SYN proxy (protects spoofed SYN floods by doing a TCP handshake with the client first then replaying it to the server)

I'm curious as to how that actually achieves anything, since you could simply use the LIMIT directive to limit an IP to X SYNs per minute. If the host OS supports something like SYNCookies, it also won't really matter.

scrub ("Scrubbing" is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.

I believe NF always drops packets with invalid flag combinations, and packet normalization can be done as well.

anchored rulesets (can be synamic sub-rulesets)

This is one of NF's best implemented features IMO.

authpf (authentication through SSH to change rules based on user logging in)

AuthPF is nice, and I am unaware of anything equivalent on Netfilter.

And of course little things like NAT, port redirection, and packet filtering

One of the best features of Netfilter has got to be the fact that you can modify the packets as you see fit, which comes in pretty handy if you are doing any kind of networked experimentation and/or honey pot/neting. Some of the patch-o-matic modules are pretty nifty as well (such as TARPIT, which emulates LaBrea but inside NF without needing the hardware or extraneous software), and offer a whole slew of logging and statistical capabilities.

 

[n0cmonkey]

Originally posted by: chsh1ca

No, it isn't. Remember, he's put money on the line to say that nobody can break his software. If they go around making ported versions so QMail (which is a security-first MTA) becomes a swiss-cheese riddled hole of a mailserver that introduces vulnerability, its reputation and credibility disappears. If you don't like the license, use something else, there are plenty of alternatives, though I have never played with any that approach the sheer simplicity and coolness of QMail.
Still, I want my fork back.

It is not free. It's his, so he can do what he wants though.

Hahaha.

And GPL zealots complain when their license isn't lived up to.

Well, considering to my recollection it was one or two of the head devs who decided OpenSSH was going to become commercialized, and there were several legal conflicts that put OpenSSH's distributability on shaky ground (far shakier than say, where Linux is under fire from SCO). OpenSSH has always been free, however, the transition from Free -> closed by SSH.com, which was an attempt by the head dev to CHANGE the license, and a community rebelling against it.

IIRC, the guy who first wrote a BSD licensed SSH client/server decided to start SSH.com. His source is still out there, and was the basis of OpenSSH (started by members of OpenBSD). SSH.com decided they should have control over the term SSH, even though it was the name of theprotocol and everything else at that point. They petitioned IETF or IANA or whichever corporate group handles that to get OpenSSH to change their name. OpenSSH didn't like that, but had the backup of opensecsh instead. SSH.com lost, SSH is the name of the protocol, they still get emails about OpenSSH.

Unless you meant how the guy that bought openssh.org wouldn't transfer it to the OpenSSH group so they used openssh.com for the first several years.

passive OS fingerprinting

Anyone with TCPDump can do the same, so I don't know why that's a valuable thing for a firewall.

I missed that feature in tcpdump.

round robin load balancing

Netfilter supports this by default as well, all you need do is specify the targets to round robin to.

automatic failover (with CARP and pfsync)

Being discussed/developed/worked on.

Packet queueing and prioritization through ALTQ (paper on prioritizing ACKs to help asyncronous internet connections)

IIRC there is this kind of functionality in NF as well.

Something similar.

SYN proxy (protects spoofed SYN floods by doing a TCP handshake with the client first then replaying it to the server)

I'm curious as to how that actually achieves anything, since you could simply use the LIMIT directive to limit an IP to X SYNs per minute. If the host OS supports something like SYNCookies, it also won't really matter.

Syncookies? I never looked those up, but I guess I should. I thought I always saw them marked as experimental though.

scrub ("Scrubbing" is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.

I believe NF always drops packets with invalid flag combinations, and packet normalization can be done as well.

anchored rulesets (can be synamic sub-rulesets)

This is one of NF's best implemented features IMO.

authpf (authentication through SSH to change rules based on user logging in)

AuthPF is nice, and I am unaware of anything equivalent on Netfilter.

The best way to do wireless

And of course little things like NAT, port redirection, and packet filtering

One of the best features of Netfilter has got to be the fact that you can modify the packets as you see fit, which comes in pretty handy if you are doing any kind of networked experimentation and/or honey pot/neting. Some of the patch-o-matic modules are pretty nifty as well (such as TARPIT, which emulates LaBrea but inside NF without needing the hardware or extraneous software), and offer a whole slew of logging and statistical capabilities.

Most of the modification needed in Pf is it will help change the sequence numbers in a TCP packet from a weak host (win9x, linux 2.0/2.2I think, etc) to make them more random.

I knew NF did most of the stuff Pf did, and vice versa. Netfilter is fine for some people, but no one ported it to OpenBSD, so I'm "stuck" with Pf. And very happy about it

 

[chsh1ca]

Originally posted by: n0cmonkey
It is not free. It's his, so he can do what he wants though.

The license says free use. Just don't package it whichever way you like.

And GPL zealots complain when their license isn't lived up to.

Big difference between disliking the terms of a license, and outright breaking the terms of a license.

IIRC, the guy who first wrote a BSD licensed SSH client/server decided to start SSH.com. His source is still out there, and was the basis of OpenSSH (started by members of OpenBSD). SSH.com decided they should have control over the term SSH, even though it was the name of theprotocol and everything else at that point. They petitioned IETF or IANA or whichever corporate group handles that to get OpenSSH to change their name. OpenSSH didn't like that, but had the backup of opensecsh instead. SSH.com lost, SSH is the name of the protocol, they still get emails about OpenSSH.

Yeah, I looked up the history of it, your version is more or less accurate.

Anyone with TCPDump can do the same, so I don't know why that's a valuable thing for a firewall.

I missed that feature in tcpdump.

It isn't a feature of TCPDump, it's something people who have the tool can do, albeit not on an automated basis. As I said, not sure why that's a valuable thing for a firewall, but obviously SOMEONE had a use for it.

Syncookies? I never looked those up, but I guess I should. I thought I always saw them marked as experimental though.

Concept is rather simple. Instead of allocating full network resources upon receiving a TCP-SYN, it sets a "cookie", and waits until it receives the appropriate ACK completing the handshake to actually allocate the connection resources. In a sense, it keeps TCP connectionless until such time that a valid connection has been established, to limit the effect of a SYNflood.

I knew NF did most of the stuff Pf did, and vice versa. Netfilter is fine for some people, but no one ported it to OpenBSD, so I'm "stuck" with Pf. And very happy about it

One thing is for sure, they both beat any of their server-os equivalents in terms of feature set and useability, at least as far as I'm aware.

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey
It is not free. It's his, so he can do what he wants though.

The license says free use. Just don't package it whichever way you like.

Which is not free.

And GPL zealots complain when their license isn't lived up to.

Big difference between disliking the terms of a license, and outright breaking the terms of a license.

Agreed. This was in regards to when a Linux developer accidentally broke the terms of the BSD license while porting an IDE driver to Linux from FreeBSD. Plenty of GPL zealots didn't care, and insisted it was a mistake (which it was), but they go off when someone else takes a GPLed piece of software and possibly makes a mistake with it. Not everyone does this of course, just the annoying GPL zealots

IIRC, the guy who first wrote a BSD licensed SSH client/server decided to start SSH.com. His source is still out there, and was the basis of OpenSSH (started by members of OpenBSD). SSH.com decided they should have control over the term SSH, even though it was the name of theprotocol and everything else at that point. They petitioned IETF or IANA or whichever corporate group handles that to get OpenSSH to change their name. OpenSSH didn't like that, but had the backup of opensecsh instead. SSH.com lost, SSH is the name of the protocol, they still get emails about OpenSSH.

Yeah, I looked up the history of it, your version is more or less accurate.

More or less. I'm a BSD zealot, but usually my memory is worse.

Anyone with TCPDump can do the same, so I don't know why that's a valuable thing for a firewall.

I missed that feature in tcpdump.

It isn't a feature of TCPDump, it's something people who have the tool can do, albeit not on an automated basis. As I said, not sure why that's a valuable thing for a firewall, but obviously SOMEONE had a use for it.

I can't come up with a great reason for it either. But it's still neat

Unless of course, your network is populated with 1 OS, and you want to make sure that if anyone hops on the network with a different OS that they wouldn't get anywhere. I could use that on my wireless network...

Syncookies? I never looked those up, but I guess I should. I thought I always saw them marked as experimental though.

Concept is rather simple. Instead of allocating full network resources upon receiving a TCP-SYN, it sets a "cookie", and waits until it receives the appropriate ACK completing the handshake to actually allocate the connection resources. In a sense, it keeps TCP connectionless until such time that a valid connection has been established, to limit the effect of a SYNflood.

Any SYN flood worth it's weight in salt is going to do more than just take up resources on the target machine. But still interesting, if it's not "experimental" still.

I knew NF did most of the stuff Pf did, and vice versa. Netfilter is fine for some people, but no one ported it to OpenBSD, so I'm "stuck" with Pf. And very happy about it

One thing is for sure, they both beat any of their server-os equivalents in terms of feature set and useability, at least as far as I'm aware.

I haven't found anything better for my uses. If my new Ultra 1 works, it will be the first non-linux, non-bsd, non-Mac OS X machine that I have owned in a while. And that will probably get OpenBSD in the near future, once I get tired of solaris again

 

[chsh1ca]

Originally posted by: n0cmonkey
Agreed. This was in regards to when a Linux developer accidentally broke the terms of the BSD license while porting an IDE driver to Linux from FreeBSD. Plenty of GPL zealots didn't care, and insisted it was a mistake (which it was), but they go off when someone else takes a GPLed piece of software and possibly makes a mistake with it. Not everyone does this of course, just the annoying GPL zealots

IMHO, Breaking a license is breaking a license, regardless whose license it is, it's not a good thing, inadvertant or not.

I can't come up with a great reason for it either. But it's still neat

Unless of course, your network is populated with 1 OS, and you want to make sure that if anyone hops on the network with a different OS that they wouldn't get anywhere. I could use that on my wireless network...

Yeah, that could be a situation where it would be useful, but what happens if you start getting false positives?

Any SYN flood worth it's weight in salt is going to do more than just take up resources on the target machine. But still interesting, if it's not "experimental" still.

My explanation was far from complete after looking at the sources. As far as I'm aware, it isn't 'experimental' and hasn't been since the mid-2.4 kernels, but I could be mistaken.
Ironically... http://cr.yp.to/syncookies.html. He's just full of good ideas it would seem. Apparently there's a FreeBSD implementation of it, though I'm not sure if it would still be in use.

I haven't found anything better for my uses. If my new Ultra 1 works, it will be the first non-linux, non-bsd, non-Mac OS X machine that I have owned in a while. And that will probably get OpenBSD in the near future, once I get tired of solaris again

Heheh, how long will that take, a week or two?

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey
Agreed. This was in regards to when a Linux developer accidentally broke the terms of the BSD license while porting an IDE driver to Linux from FreeBSD. Plenty of GPL zealots didn't care, and insisted it was a mistake (which it was), but they go off when someone else takes a GPLed piece of software and possibly makes a mistake with it. Not everyone does this of course, just the annoying GPL zealots

IMHO, Breaking a license is breaking a license, regardless whose license it is, it's not a good thing, inadvertant or not.

Agreed, but I'm willing to cut someone a little slack if it was an innocent mistake.

I can't come up with a great reason for it either. But it's still neat

Unless of course, your network is populated with 1 OS, and you want to make sure that if anyone hops on the network with a different OS that they wouldn't get anywhere. I could use that on my wireless network...

Yeah, that could be a situation where it would be useful, but what happens if you start getting false positives?

Any SYN flood worth it's weight in salt is going to do more than just take up resources on the target machine. But still interesting, if it's not "experimental" still.

My explanation was far from complete after looking at the sources. As far as I'm aware, it isn't 'experimental' and hasn't been since the mid-2.4 kernels, but I could be mistaken.
Ironically... http://cr.yp.to/syncookies.html. He's just full of good ideas it would seem. Apparently there's a FreeBSD implementation of it, though I'm not sure if it would still be in use.

Interesting, I'll have to read that later. I am using mid-2.4 kernels

I haven't found anything better for my uses. If my new Ultra 1 works, it will be the first non-linux, non-bsd, non-Mac OS X machine that I have owned in a while. And that will probably get OpenBSD in the near future, once I get tired of solaris again

Heheh, how long will that take, a week or two?

Probably. I'll set up netboot though, so I can have Solaris or OpenBSD when I want it

 

[chsh1ca]

Originally posted by: n0cmonkey
Agreed, but I'm willing to cut someone a little slack if it was an innocent mistake.

Yep, same here. Doesn't make any one case less evil than another when done intentionally tho.

 

[n0cmonkey]

Originally posted by: chsh1ca

Originally posted by: n0cmonkey
Agreed, but I'm willing to cut someone a little slack if it was an innocent mistake.

Yep, same here. Doesn't make any one case less evil than another when done intentionally tho.

Agreed.

Maybe if we started flaming in this thread we'd get more attention

 

[chsh1ca]

Hmm, YOU SUCK YOU DAMN BSD-HUMPING BUTTMONKEY!

Don't wanna get banned ya know.