Comments on: scanrand - Download Stateless TCP Scanner with Syn Cookies

By: eM3rC

eM3rC — Sun, 06 Jan 2008 22:14:10 +0000

I would personally prefer nmap over scanrand but very nice post.

@Sir Henry and mumble

It would be awesome to hear what you guys come up with.

By: Sir Henry

Sir Henry — Mon, 17 Dec 2007 15:39:57 +0000

@mumble:

Will do. It would be cool to work on something like this with you.

By: mumble

mumble — Mon, 17 Dec 2007 15:11:21 +0000

@Sir Henry
Drop me a line. GPG Key ID: D005B227. You can use the email address on the keyserver. I’d post it here, but…spambots.

By: Sir Henry

Sir Henry — Mon, 17 Dec 2007 14:08:12 +0000

@mumble:

Your last comment is exactly that of which I am speaking. Let me know what you find out with your testing. I would be very interested to find out the results.

By: mumble

mumble — Mon, 17 Dec 2007 12:22:56 +0000

Thinking about this in slightly more depth — there’s probably a good article in this for Phrack or 2600… Especially if you can identify the scanner’s signature well enough that the false positive rate is down in the noise.

I know that you can immediately forget about the idea of detecting the difference between a “Connect” scan and the real deal, because the scanners all use the OS connect() implementation, as far as I know. Fin and Xmas-tree scans are easy to see on a stateful inspection firewall, and most will just drop the packet. (PF, for example, will happily drop it on the floor…) I’ll have to set up a few boxes and see what happens.

By: mumble

mumble — Mon, 17 Dec 2007 12:12:54 +0000

It would have to be a pretty tight environment for the admin to get away with using a passive OS-specific firewall rule on a box. I do know the the OpenBSDs PF firewall can do it, but very few people would. Too high a probability of running into one or two machines which are running an odd OS version and flag incorrectly.

When NMAP is running as root, it can be set up to use direct packet injection. It does so by default on windows boxes to get around the WinXP-SP2 raw sockets disabled problem. If NMAPs packet structure is a problem, it really wouldn’t be all that hard to make it look like anything you want it to.

As the cook says, “Use the Sauce…”

By: Sir Henry

Sir Henry — Mon, 17 Dec 2007 11:35:18 +0000

I agree, goodpeople, but my interest is eliminating a potential for a false negative as much as I can. Just one example of that is to simply make sure that my probes are going out in the same way a legitimate connection probe would. I would hate to be doing consulting work for a firm and realize only after the fact that, had I crafted the packets in a different way than how they are sent from a scanner, I might have gotten different, perhaps more sensitive, responses.

By: goodpeople

goodpeople — Mon, 17 Dec 2007 11:29:07 +0000

Different target OSses have different responses. You can never be sure that you don’t have false positives or negatives.

By: Sir Henry

Sir Henry — Fri, 14 Dec 2007 17:33:25 +0000

Nor would I proclaim expertise in the ways of IDS/IPS. I do know, however, that if I am sending a SYN packet, I do not want there to be a false negative or drop from the FW because it is crafted in a way that can be detected as a scanner packet. With my SYN scan, I would want to know which hosts are truly alive and not just dropping because they know I am scanning and not embarking on a true SYN request. So, although I do agree with some points, my point is to know that my scan is obtaining all information available and not experiencing false negatives.

By: net2004eng

net2004eng — Fri, 14 Dec 2007 17:10:36 +0000

@Sir Henry

Isn’t the goal of sending a syn scan to illicit a response or no response from the end host. I know you can craft packets with hping, nemesis, etc.. but the goal here is typically different.

In respect to the actual syn’s sent by nmap, scanrand, unicornscan, etc… I would inspect the packets with tcpdump/windump while they leave your machine, and take a look at the way they appear when they arrive at the destinaition. I know MS and Linux implement the tcp stack in different ways, and this very well could imapct he way packets leave your machine, but that would be independent of the tool… Also, I know with snort, that it can identify what scanner you are using, but I think this is based off of a collection of multiple captures…if you send a single syn to one host, I don’t think Snort, nor any other IDS/IPS system, would be so sensitive to be able to tell you what tool is performing the scanning…and you wouldn’t want it to either (at least that might be way too sensitive for me)!

This being said, I’m not an IDS/IPS expert by any means…