Re^3: How to implement a fourth protocol

Yep, and the firewall is at a pretty darn low level already since it's working at the packet level, isn't it? You cannot stop J. Random Cracker from spewing packets at your network unless you unplug from it. Or go to his house and unplug him from the internet :-) Short of that, his packets are coming at you even if they're just bouncing off of ports with no listeners.

I'm assuming that we're talking about a public service here, and not something that can be very easily protected by something akin to VPN. In order to detect a bot, you have to allow it some initial degree of access so you can discern its intent. There's really no other way to determine the intent of a previously unseen client. After something at the server level determines that the client is malicious, then it has to work to defend itself. The lowest level available to us is the TCP/IP layer, where we can decide at the packet level whether to accept, reject, or drop the packets without the overhead of reassembling them into messages. This is the level where the firewall lives, very efficiently sieving bits. So, the easy way to implement a defensive measure is to give the server or some lightweight middleware the smarts to detect malicious activity and the means to communicate to the firewall "I don't want to hear from IP address ww.xx.yy.zz on my port nn any more". Bam, problem solved. From that point forward you don't analyze payloads, and the firewall just sieves bits. The best efficiency comes if you just drop those packets without bothering to tell the client that you don't want them. It's a bit rude, but it's efficient.

So, again, how would the certain to introduce vulnerability new protocol be faster/easier/better than the existing tools which are readily available today?

Comment on Re^3: How to implement a fourth protocol

Replies are listed 'Best First'.
Re^4: How to implement a fourth protocol by Moron (Curate) on Mar 27, 2007 at 18:20 UTC
I think in a way you've answered your own question and that helps me too! If the HTTP port is closed there is no need to have a firewall listening to it so more efficient than sieving those bits which could grow to high volume unwanted traffic. A new protocol would mean no old bots getting at it. I should have said that the protocol for my own purposes isn't intended to replace typical HTTP traffic but for traffic between contracting parties rather than anyone to anyone. Technically that can be as public as you like but more bother (and more security!) to hook up to. It is more likely someone spins a bot if it has a perceived chance of success - that is where I can see one sort of gain, given that no bot will ever have succeeded on this protocol, given that I can use the firewall AS WELL on the open port with the new protocol. Moreover, where ftp requests can spin your readdir, the new protocol I have in mind is intended to be more of a pure traffic session rather than file and directory rendering one - there are no directories or files to be got at with it! - And it is less likely you will be hit by a pure packet-volume attack. -M Free your mind	[reply]
Re^5: How to implement a fourth protocol by gloryhack (Deacon) on Mar 27, 2007 at 20:06 UTC
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]
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]
Re^7: How to implement a fourth protocol by tirwhan (Abbot) on Apr 02, 2007 at 12:17 UTC
Re^8: How to implement a fourth protocol by Moron (Curate) on Apr 02, 2007 at 12:53 UTC
Some notes below your chosen depth have not been shown here
Re^5: How to implement a fourth protocol by sgifford (Prior) on Mar 27, 2007 at 19:48 UTC
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. -- sgifford's Web page	[reply]
Re^6: How to implement a fourth protocol by Moron (Curate) on Mar 28, 2007 at 12:41 UTC
Creating a scalable private club via blocks of IP addresses is a good idea for me to consider, thanks. -M Free your mind	[reply]