top | item 42430024

Scanners Beware: Welcome to the network from hell

109 points| vailunka | 1 year ago |medium.com | reply

27 comments

order
[+] thepuppet33r|1 year ago|reply
It's an interesting idea, but I'm not sure it actually accomplishes much.

I do some purple team work for my company occasionally, and if I scanned a network and got back a bunch of delayed traffic and an active host at every IP, I wouldn't think that I had 255 hosts to check, I'd think the scan failed. I'd tweak the parameters and try again. Unless you're setting your actual servers to respond differently, it wouldn't take much trial and error to filter out the noise. And once it's out that this tool exists, and the parameters are hard set by default (3 ARP calls to non-existent IPs), it'll just be another saved scan setting I can flip to if I get all the noise back.

You might be able to make this harder in the short term by varying the parameters (e.g., 2 ARP scans, only return a host for every third empty address, etc.), but then your solution is not as effective as it takes me less time to check each host for life.

Also, do your fake hosts respond to Telnet on their fake ports? Do they respond to ping? Do they show up on DNS lookups? If you're not altering the traffic at some deeper level or employing something like a custom honeypot that dynamically reacts, these fake hosts are just going to be another static artifact to filter out in the long run. The more straightforward you make the response to a scan, the easier it'll be to dismiss it as noise rather than something to investigate further.

[+] altairprime|1 year ago|reply
Simply reacting with “>5% of honeypot IPs have issued an ARP response” would be a valuable alert about a network scan in progress, no matter how long the delay between addresses pinged. The point isn’t to make the network inscrutable, it’s to make it much more risky to scan at all. That the ARP is delayed to the third attempt is interesting but presumably tunable based on whatever the reactivity thresholds for the customer are.
[+] c22|1 year ago|reply
This approach is nothing more than security via obscurity and nmap is an extremely useful tool that I run against my own networks all the time.
[+] zrobotics|1 year ago|reply
My main concern is, if an attacker has the ability to nmap against my private IP range, they're already in the network and I'm already pwned. Am I missing something here? Plus, with this tool running I would lose the ability to run nmap scans, which are a super useful diagnostic tool.

I do have a honeypot machine setup, but that's mainly as a last line of intrusion detection than an active defense (plus, it was a fun way to spend a Friday afternoon). I've seen proposals for similar systems before and while the idea is interesting I just don't think it accomplishes anything useful. My honeypot also doesn't accomplish anything truly useful, but it also doesn't negatively affect the network by not allowing me to run scans.

[+] waterproof|1 year ago|reply
> Most scanners send three requests per IP address. Our solution observes the first two requests to check if a device exists at that IP

So all an attacker has to do to avoid the tarpit is reduce their retries to 2? And they can detect all your fake devices by seeing who responds on the 3rd try?

I get that this is just one step in the cat-and-mouse game, but the brittleness of this approach makes the grandiose closing statements a little grating:

> Lightweight yet powerful, it empowers you to take control of your network security with minimal effort.

[+] ternnoburn|1 year ago|reply
Why wouldn't someone just set a timeout on individual port scans such that long responders were pruned from the search? Seems like this behavior is extremely recognizable...
[+] BLKNSLVR|1 year ago|reply
I think the time difference in scans is not that each individual scan takes longer, it's that there are a lot more scans to be performed.

It's somewhat of a DoS for a network scanner overall, rather than a DoS for each individual network scan action (as per a traditional tarpit).

[+] linsomniac|1 year ago|reply
Back when I ran a small hosting provider, I'd monitor outbound SSH connections and page someone if there were too many from any individual host. On a couple occasions we had to increase the threshold for certain users, but most of the time it was an immediate indication that a host had gotten compromised. Super effective.
[+] BLKNSLVR|1 year ago|reply
What were your characteristics to define an SSH connection? Port only, or protocol(s), or traffic pattern matching?

(I want know more!)

I have flags on my firewall(s) for outbound connections to a list of ports that are commonly attacked, so I get notified if it looks as if attacks may be originating from my networks. It's purely based on port numbers though, nothing smarter than that.

[+] krunck|1 year ago|reply
I have fond memories of running Labrea during the Code Red worm days(2001).
[+] ssklash|1 year ago|reply
Notably this only works on internal networks that rely on ARP at layer 2.
[+] Faaak|1 year ago|reply
Yeah, I get they mixed up how arp works.. For requests on the same L2, and just TCP replies. When you connect to another network you'll never send/receive arps..
[+] sir-alien|1 year ago|reply
Could you not instead of using one nmap process to scan 200+ addresses, just instead initiate 200+ nmap processes scanning just one IP.

Still effectively hits your spoofing system but now they bring their time back down to what it would take to scan a single IP address.

I'm sure there are many other ways around this but like all security it's merely a case of making it difficult enough that an attacker would need serious incentive to make the attack.

[+] morbicer|1 year ago|reply
I am curious how would this technique fare against masscan [1] that scans in a massively parallel fashion. I think it would either crash it or it could cost you a lot. It's a nice dream of "owning" the attackers but it doesn't have a real security value.

[1] https://github.com/robertdavidgraham/masscan

[+] nubinetwork|1 year ago|reply
Why send anything back at all? Let them scan, find nothing, and move on... you know they're looking for stuff, if they find anything, it's just more incentive for them to waste your CPU cycles and bandwidth... if they find nothing, they're more likely to ignore you in the future.
[+] djaouen|1 year ago|reply
I would be wary of adding ghost hosts as that might attract more scans and potential hacks. This is the equivalent of adding 1000 fake locks to your door, all of which appear open, in the hopes that an intruder guesses that you are actually using one of the fake locks.
[+] BLKNSLVR|1 year ago|reply
By the sounds of it, it's a single additional service that just looks like 1,000 locks.

Additionally, this is to slow down an intruder that's already in the local network, so "might attract more scans and potential hacks" is somewhat moot - it doesn't announce to the Internet that port 22 is open, for example. Although, if the intruder works out they're ghost hosts, then they might assume that there must be gold in them thar hills given the additional levels of protections / obscurity, and thus redouble their efforts in mapping the network and discovering real hosts.

The point appears to be to slow down an already-intruder, to give more time to lock down the real hosts and remove said intruder. In which case it seems to act as a detection mechanism to notify that there is an intruder attempting to map the network - which could possibly be the most value it brings.

[+] daghamm|1 year ago|reply
Yeah, I have experienced this myself.

Many years ago we worked on a project that deployed fake vulnerable services (SMTP, SSH and so on) to a /16 network. At some point so many people were trying to exploit these that the admins asked us disable it. I guess we got on some kind of list...

[+] CliveBloomers|1 year ago|reply
What is this doing?
[+] oherrala|1 year ago|reply
TL;DR A tarpit that detects network wide scans (e.g. nmap) and starts to slow down the scanning as much as possible by intercepting the scanning.