I have a number of custom applications that act as servers, accepting TCP connections. They aren't web servers and don't speak http; it's all custom protocols. They are open to the world, though generally on obscure ports. And they get probed fairly often, mostly I think from scanners trying to find unguarded web servers.
I'm trying to come up with the best way to discourage this. It's trivial for me to check for the first arriving token being a GET or POST, etc, which isn't part of any of my custom protocols, so signals I'm being poked by a scanner. I'd like to discomfit people trying that, simply as a public service.
I'm not familiar with the code used in scanners, and I'm hoping someone here is. Ideally I could reply with something to crash a scanner, confuse it, or waste its time.
The constraint is, I'd rather not have to keep the socket open very long. If I do, someone might respond with hundreds of connections, resulting in a DoS.
So far I've tried replying with a 308 (permanent redirect) to the CIA's website. But are port scanners likely to follow redirects?
I've tried sending back a request body with ill-formed UTF-8 in the hope someone didn't handle that well. But I have no way to know how effective that is.
The string I'm currently sending back is:
"HTTP/1.1 308 I'm a teapot. And you're an annoyance.\r\n" "Content-Type: text/html; charset=utf-8\r\n" //"Content-Length: 7673\r\n" //ugh, browser makes connection linger //send him somewhere nice: "Location: https://www.cia.gov\r\n" "\r\n" //make the body incomplete, ill-formed trash "<html \xF0\x9F\x96\x95 \xf3\xf3\xf3\xf3\xf3\xf3\xf3\xf3\xf3\xf3"
My question, simply, is "is there a better way?" This has to be a problem people have frequently dealt with. Am I better off just closing the connection, or spewing binary trash...? Note: I draw the line at shipping virusware out. There's a tiny chance my users would point a browser at these ports by mistake.