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? | [reply] |
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?
| [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.
| [reply]
[d/l] |
Having nothing listening on port 80 and having the firewall block it are basically identical from a network perspective: either way, a bot sends a packet, and gets back either a response indicating the port isn't open, or else no response at all. So unless the bots know in advance that you don't have anything listening on that port, it's not going to save your firewall or your network anything to actually not have anything listening on that port.
Assuming that bots attack across all valid IP address space fairly evenly, you could reduce the impact of these attacks by having fewer IP addresses routed to you. Using nonroutable IP addresses (such as RFC 1918 addresses) might help with this. If you use private addresses on the client and server network and configure routing on both ends to ensure only your real clients can talk to your server, your firewall won't have to deal with packets sent to these private addresses, since in general they can't be sent. You could get a similar effect with a nonroutable protocol (such as NetBEUI), though it would be quite a bit more work. Both of these are most easily done through a VPN, though they can be done with physical network links as well.
Still, the network and router resources used by blocking a connection are so small, going to these great lengths won't make much of a difference on the vast majority of networks.
| [reply] |
Creating a scalable private club via blocks of IP addresses is a good idea for me to consider, thanks.
| [reply] |