Scanners Beware: Welcome to the network from hell(medium.com)
medium.com
Scanners Beware: Welcome to the network from hell
https://medium.com/sensorfu/scanners-beware-welcome-to-the-network-from-hell-86989f29f17b
30 comments
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.
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.
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.
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.
I think an honeypot is always a good idea and it sure helps to know that you're being targeted but...
> My main concern is, if an attacker has the ability to nmap against my private IP range
For a start I consider that chinese IoT shits and SmartTVs are attackers. So the attackers are already in my network. And if they're not, they've got very easy targets: these IoT (Internet-of-(Insecure-and-Shitty-)Things) devices.
Note that you can run several LANs too. I've got 192.168.x. and 10.x.x.x. One is way more secure than the other (no WiFi device on the more secure one, a very strict firewall in between the two LANs, etc.).
Heck, even my ISP by default hands a router that separates the home LAN and the "guests" LAN.
A nmap from 192.168.x.x shall not give any result for stuff on 10.x.x.x and vice-versa.
You can do it by configuring trunking / VLANs or physically. Mine is just physical: unmanaged switches, a few of them on one LAN, another one dedicated to the more secure LAN.
The box that does the routing between the two LANs only does two things: firewalling and routing traffic. Nothing else. No SSH port open. No ports open whatsoever. No nothing. Firewalling and routing and that's it.
> ... they're already in the network and I'm already pwned.
Not really though. You should be able to work properly and securely if your main computer isn't compromised.
It should really be no different than using a laptop from a public place.
> My main concern is, if an attacker has the ability to nmap against my private IP range
For a start I consider that chinese IoT shits and SmartTVs are attackers. So the attackers are already in my network. And if they're not, they've got very easy targets: these IoT (Internet-of-(Insecure-and-Shitty-)Things) devices.
Note that you can run several LANs too. I've got 192.168.x. and 10.x.x.x. One is way more secure than the other (no WiFi device on the more secure one, a very strict firewall in between the two LANs, etc.).
Heck, even my ISP by default hands a router that separates the home LAN and the "guests" LAN.
A nmap from 192.168.x.x shall not give any result for stuff on 10.x.x.x and vice-versa.
You can do it by configuring trunking / VLANs or physically. Mine is just physical: unmanaged switches, a few of them on one LAN, another one dedicated to the more secure LAN.
The box that does the routing between the two LANs only does two things: firewalling and routing traffic. Nothing else. No SSH port open. No ports open whatsoever. No nothing. Firewalling and routing and that's it.
> ... they're already in the network and I'm already pwned.
Not really though. You should be able to work properly and securely if your main computer isn't compromised.
It should really be no different than using a laptop from a public place.
> 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.
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.
[deleted]
Somewhat reminds me of a project out of IBM some years back: "Billy Goat" https://dominoweb.draco.res.ibm.com/reports/rz3609_revised.p... (bummer looks the site certificate expired a few days ago.. sign of the times for IBM, eh).
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...
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).
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).
> When scanners attempt to identify open TCP ports by sending SYN packets, our solution introduces a second layer of disruption. It delays SYN-ACK responses, sending them after a set time. While the delay for a single port may seem minor, the impact compounds when attackers scan thousands of ports across a network teeming with virtual devices.
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.
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.
(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.
It was based on outbound connections per local IP address, but I don't remember exactly how I achieved it. It might have been port 22 SYN, or it might have been using the conntrack module. IIRC it used the rate limiting module to set the rate, and then just the log module to log a message which the monitoring system would pick up.
My routers were Linux boxes running in an HA configuration (heartbeat), with quagga for BGP to the upstreams. I had more cores than interfaces so the system would never livelock due to interrupt storm if a burst of packets came through (interrupt mitigation wouldn't happen if all cores are saturated handling interrupts). Firewalling was kept pretty simple, to reduce load and end boxes all had their normal firewalls, but I did block users sending IP source addresses that they weren't assigned. I also had a custom kernel module that would account traffic on the transit interfaces, so customers were only charged for traffic outside our network, anything internal (backups, apt/yum updates to our local mirror, etc) were all free.
I loved having a router that had more than enough memory to hold full BGP tables no problem (while others were worried about the growth of the tables blowing out their RAM), and I liked that my slow path and fast path were the same speed. :-)
My routers were Linux boxes running in an HA configuration (heartbeat), with quagga for BGP to the upstreams. I had more cores than interfaces so the system would never livelock due to interrupt storm if a burst of packets came through (interrupt mitigation wouldn't happen if all cores are saturated handling interrupts). Firewalling was kept pretty simple, to reduce load and end boxes all had their normal firewalls, but I did block users sending IP source addresses that they weren't assigned. I also had a custom kernel module that would account traffic on the transit interfaces, so customers were only charged for traffic outside our network, anything internal (backups, apt/yum updates to our local mirror, etc) were all free.
I loved having a router that had more than enough memory to hold full BGP tables no problem (while others were worried about the growth of the tables blowing out their RAM), and I liked that my slow path and fast path were the same speed. :-)
I have fond memories of running Labrea during the Code Red worm days(2001).
Notably this only works on internal networks that rely on ARP at layer 2.
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..
In what way did they "mix up how arp works"? They say
> That’s where our solution comes in — a solution designed specifically for internal networks, one that doesn’t just defend but creates chaos for attackers.
> That’s where our solution comes in — a solution designed specifically for internal networks, one that doesn’t just defend but creates chaos for attackers.
Agreed. They’re quite clear about what this is and how it works.
It’s just usually tremendously impractical to extend the tar pit to all your layer 2 domains in many modern network architectures, so while this is interesting, it’s unlikely to see production use.
It’s just usually tremendously impractical to extend the tar pit to all your layer 2 domains in many modern network architectures, so while this is interesting, it’s unlikely to see production use.
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.
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.
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
[1] https://github.com/robertdavidgraham/masscan
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.
[deleted]
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.
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.
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.
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...
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...
What is this doing?
[deleted]
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.
Thanks, The article did not make this clear.
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.