Scanners Beware: Welcome to the network from hell
medium.com
medium.com
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.
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.
> 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.
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.
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).
(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.
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. :-)
> 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.
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.
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.
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.
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...