Given these differences, a number of products over the years have been coded to look at incoming SYN packets for the attributes associated with security scanners. You don’t get to mangle it, morph it, or corrupt it. When you call connect(), you get pretty much the same kind of packet every time. The connect() method, however, is a packaged deal. Common applications of this include spoofing the source address, changing checksums, and lighting up odd TCP flag combinations. The raw socket technique can be thought of as “building” packets it’s a method for modifying actual packet headers before they leave the machine. This is the “regular” way of building a SYN packet, and as we’ll see in a moment, the packets made in this way are quite different than those made by scanner applications. This is what happens when you want to use a regular application on your system, like a web browser or a mail client. Legitimate SYN packets, however, are created by the OS’s connect() syscall. The SYN packets created by most port scanners out there are created via the raw socket interface, and they tend to have some fairly standard characteristics that stand out to both humans and computers (as we’ll see below). Anatomy of a SYNĪs it turns out, there’s a very tangible reason for the two packets being different. In short, the only way for the host (or a filtering device in between) to react to one SYN differently than another is for the packet itself to be different. If these two SYN packets weren’t different, then the target host would have no way of knowing that the SYN-scan’s SYN packet wasn’t legitimate, and as such would respond with a SYN-ACK as with the standard connect scan. Well, after a couple of minutes of head-scratching, logic revealed the path to the truth: Fair enough, but if I sent just the SYN from nmap or tcpdump, the host would not respond at all. So if I did a “regular” scan, I’d send a SYN, get back a SYN-ACK, and then respond with an ACK. one that completes the three-way-handshake, I would get back a ton of open ports on the same host. That’s normal enough for sites that drop incoming scan traffic, but the weird part was that if I used a standard connect scan, i.e. During a recent assessment I noticed that I was getting back (or, not getting back, as it were) a filtered response to nmap and hping SYN scans.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |