in reply to Re^6: How to implement a fourth protocol
in thread How to implement a fourth protocol

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.


All dogma is stupid.

Replies are listed 'Best First'.
Re^8: How to implement a fourth protocol
by Moron (Curate) on Apr 02, 2007 at 12:53 UTC
    It occurred to me that a real firewall isn't implemented in the O/S at all in the way you are talking about and that until now, unless I am wrong again, what we have been talking about is personal firewalls. It doesn't seem to me to be a good idea to run that type of firewall on anything larger scale to the extent that it would attract DOS attacks, but rather that the firewall should be implemented as separate hardware specialised enough to perform well at the right networking level.

    I imagine that it could still read IP tables from a machine that does run application servers however.

    -M

    Free your mind

[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


      All dogma is stupid.
[reply]
[d/l]
        I think you are saying dedicated firewalls can and should (?) be implemented on unix boxes rather than on specialist networking hardware and I will look into that, thanks.

        re IP tables. I was vague because I have a number of ideas of where tables of IP addresses might have to be kept. The firewall can't (I imagine) detect the attack all on its own. So the application server has to keep records of activity against IP addresses and then tell the firewall (i.e. updating yet another table of IP addresses) to block some of them while maintaining others as "unresolved status" and others as formal client (probably more statuses than these to boot). For example, if a real (i.e. formal) customer has a DofS hacker in their midst, you might want to discuss it with them first rather than blocking the IP address and damaging business that might be worth more than a temporary performance hit while the issue is still being resolved.

        -M

        Free your mind

[reply]

In Section Seekers of Perl Wisdom