Response to the update: You're wrong (and this is one reason why you're reasoning is wonky on this entire thread). The OS is always listening to all ports on an active network interface. The decision on whether to pass a packet to a userland process listening to a specific port is taken after the packet is inspected by the routing and firewalling subsystems of the kernel (this is how it works on any sane OS anyway). You could theoretically create a userland process which is able to make this decision faster than the kernel subsystems but almost certainly only for the case of very overloaded (usually meaning crappily designed) firewall rulesets. You certainly won't be able to implement a service which inspects several packets (such as required for your protocol-specific request) faster than the kernel can inspect one. The kernel also still has to handle the entire TCP handshake process before handing the connection to your service, which is usually a far more resource-intensive process than dropping the initial packet at the firewall.
Also, from a network load POV, having nothing listening on a port is worse than a firewall blocking that port. A SYN packet (for opening a network connection) to a closed port (i.e. one without a listening service) requires the OS to respond with an RST packet. A well behaved remote network client will recognize that the port is closed and not try to send another SYN. A bot can/may/will just try again. In the case of an active firewall on that port no RST will be sent, thus you've halved the traffic on your network (disclaimer: I realise this last sentence is a very naive take on the subject, but it is valid in the context of this discussion).
Do a little research on basic networking (reading the Wikipedia page on TCP will already take you a long way) and you'll become much clearer on this subject.
| [reply]
[d/l] |
| [reply] |
Again, that's because you appear to not know firewalling and you should read up on the topic. All major UNIXes and derivatives (Solaris,Linux,the BSDs,OS X) implement the firewall as a kernel subsystem for the very reason of performance. You are correct that there are vendors which will sell you firewalls as specialized boxes which either run a derived version of said OSes or implement their own OS (more often than not far inferior, see Cisco OS for example). Except for the extreme high end these just contain PC hardware though, the main difference between them and a standard server designed for fast network performance and running a general-purpose OS is just the fancy box and the price-tag.
The term "Personal Firewalls" is from the Windows world and indeed does refer to the toy firewalls implemented as Windows userland programs AFAIK. I believe though that even newer Windows versions implement their firewall at a kernel level (not sure, haven't touched that OS in years).
I didn't think you were talking about running a firewall as a separate box, because in that scenario it is even more obvious that you should block the DOS at the entry point to your network. Otherwise you'd be letting the DOS traffic add load to your internal network traffic as well as the external connection. Also, a dedicated firewall (regardless whether consisting of so-called specialised hardware or a standard UNIX box) will most certainly be much more effective at blocking unwanted traffic than userland programs running on an application server. That's what it's there and designed for after all.
I imagine that it could still read IP tables from a machine that does run application servers however.
Hmm, don't understand this sentence, what do you mean by "IP tables"? Do you mean the Linux iptables firewall?
Marked OT because these are firewall arcana, not Perl
| [reply]
[d/l] |