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

You're still sieving bits, even if the port is closed, even if there's no actual firewall in place. Suppose, to stay with your example, there's no firewall in place and there's no HTTP server listening on port 80 but packets destined for port 80 arrive. Your TCP/IP handler necessarily must inspect those packets to determine where they're destined even if there is no route and no endpoint. Bit sieving is unavoidable.

The "perceived chance of success" isn't even a consideration in modern bots. The bots are being run from compromised hosts, primarily windoze machines on broadband connections, so the bot operators don't much give a fiddler's frock about efficiency.

Hmmm... just for the sake of argument, let's do a high-level stream of consciousness build of your system. You've mentioned NetServer::Generic which is a fine choice if you're not handling a ton of traffic and don't need a select based server, but it attaches meaning to line terminator characters. If you can't jam all of your data into one long string, you'll need something else. Just for giggles, though, we'll implement DJB's silly Netstrings idea via Text::Netstring to solve that problem. Now we have the guts of the beastie, and we have to give it a thick hide. Let's wrap our streams in SSL to keep the nosy neighbors out of our business, and plug in some sort of authentication that's invulnerable to replay. Pick one of the trendy ones just for geek points. So far, so good. Okay, now we get to address the original points, probing and DoSing. Let's do some rolling state maintenance, SQLite works well for this. But we don't want our server to have to deal with the load because all we really need to know is that ww.xx.yy.zz shouldn't be talking to us on port nn (deja vu!) so we'll enlist the help of IPTables::IPv4. There, problems all solved. It's a lot of work, but we've done it... never mind that our server isn't going to stand up to the load if we get really popular, for now.

Or you could save a lot of time and make the server side of your wonder widget a web service running Apache on a non-standard and unprivileged port, get SSL and authentication with very little effort, add in Zdziarski's mod_evasive Apache module to avoid much DoS nastiness, take advantage of scads of CPAN modules that are already written for extending Apache and maybe even manipulating the server's iptables (assuming Linux), and focus most of your energy on the client side. Sounds like a fairly simple approach with few unnecessarily reinvented wheels and leveraging some time tested code, to me.

Whaddaythink? Spend lots of time to get something that cannot handle big loads, or spend much less time to get something that can handle big loads and much of which will continue to get better over time without any help at all from you?

  • Comment on Re^5: How to implement a fourth protocol

Replies are listed 'Best First'.
Re^6: How to implement a fourth protocol
by Moron (Curate) on Mar 28, 2007 at 12:51 UTC
    Good ideas...I could also slightly modify apache by layering something over at the source level that supports a specialised set of protocols. There is another motivation I didn't mention yet: to try and make a protocol specific to certain types of traffic rather than have just the ridiculously generic http versus the sublimely specific ftp to choose from. Actually I did look at the list of non-internet protocols at the same level and tty looked the best although it has been sort of butchered over to ftp. i still don;t know what is doing that yet -- the browser or the server.

    Update: Just one nit I noticed: It appears to my naive mind that there is a difference in denial-effect between a firewall listening and nothing listening to a port. If N bits/s are thrown at a port which doesn't have any listener, zero bits get sieved per second whereas if the firewall is listening it sieves the N bits per second and impacts system resources. Or am I wrong?

    -M

    Free your mind

[reply]

      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.
[reply]
[d/l]
        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]

In Section Seekers of Perl Wisdom