This is just a quick “oneliner” draft I’m running, YMMV, do not just blindly copy paste! You need to select your WAN interface and make sure you’re not actually running these services or alter ports.
Feel free to add as many ports as you like to broaden the “honeypot”.
Basically blacklists (on WAN interface) anything trying to connect to TCP / UDP:
Use a find command to find outside interface so that you do not need to change it when pasting commands.
Use the “place-before” commands, so that its not put at the bottom where it does nothing.
Add the access list “Artillery-blacklist—” to to incoming interface with a block on it. This way a person who tries an illegal port, will be blocked for a timed periode.
Basically the only thing it can break at its current state is blocking non-whitelisted ip-addresses if you for some reason would have incoming WAN traffic from trusted IPs trying to access non-existing ports on the router WAN interface, still resulting in something that needs fixing (as WAN traffic to non-existing ports shouldn’t occur normally). One scenario I could imagine would be having two IPsec sites with public IP services (port forwarding / routing) for each other and a user trying to access a wrong hostname, resulting in the other site (IP) getting blacklisted, but that is the reason for whitelists.
AND
Should your upstream gateway for an unknown reason do portscans or masquerading (src-nat) then it could lead to a completely disconnected WAN, as the upstream gateway IP (default route) would get blocked. Maybe the code should whitelist the default gateway IP automatically but… it would only work for static WAN IP configs as a DHCP gateway wouldn’t get updated, which in turn could be avoided by adding a WAN DHCP client script to whitelist it but…
I wrote a small combination of white/blacklist, download and parsing of the dshield 20 top attackers lists (which I download every hour with a timeout of 1w, so it keeps growing but not beyond ~60 hosts) and fail2ban for failed ssh attempts. The combo is mostly lightweight, like yours, and is dropping consistently between 2/3 and 3/4 of all incoming traffic, and fractions of forwarded (to dstnatted hosts). While inspecting the results I noticed that the majority of the connection attempts of my three managed routers are going to the telnet (23) port, and thought about complementing my approach with something like your idea.
So please add the port 23 to the “popular” list. At least in my case there is nothing there, but people keeps trying it.
I see in my logs also people trying to brute force or guess common ipsec PSKs, and I have been thinking on ways to detect and send them to blacklist…
In my current version it is a script that runs every hour and does:
download and update of the dshield list (quite effective in one of my providers, the others are probably filtering it or something similar already)
I also download the recently reported at blocklist.de (something small like https://api.blocklist.de/getlast.php?time=300&service=ssh , or 600) and add it to the pre-blacklist4 address-list with a timeout of 1 hour. This is not really well tested or tuned, but the idea is to send them to the blacklist on first contact, but don’t store big lists
I scan the log for login attempts and add the addresses with enough of them to the blacklist
My script was built upon ideas and fragments of code found around here, and evolves as I tune it
I must admit the port list is straight from Artillery and for some reason they left port 23 (Telnet) out… however I can’t figure out a specific reason for leaving it out. I’ll add it on my next revision, and obviously everyone can add it themselves if they like.
I’ve stuck the following onto a spare IP we have kicking about just to see what is prodding at it. It’s harvesting a lot of IP’s at the moment, forward planning is to have the IP’s added dynamically then upload them to a server centrally then all border routers pull from that.
You need to set a whitelist and your WAN interface but in short it perma-blocks the “prodder” from your router, it takes the OPs idea and makes it significantly more brutal. As I push it along I’ll probably time the “prodders” out for a week rather than block until reboot.
A couple of days ago I think I may have found a slight “hiccp” with my brutal approach. The kids couldn’t get Amazon prime to work and last night I also couldn’t watch an Amazon video. Disabled my drop blocklist rule and they started working, looks like something from Amazon “poked” my router without it expecting it and in turn got blocked which was also an IP used as part of content delivery.
I guess weeding out legitimate “pokes” are the difficult bit of this blacklisting malarkey?
Remember that most internet users will be able to feed your blacklist by sending spoofed TCP SYN packets (with source address that they want you to block).
IP source address filtering (to allow only source addresses that you “own”) is not widely deployed.
This makes it easy to DDoS and it would be very easy for a botnet to send every address on internet a TCP SYN from 8.8.8.8 and 8.8.4.4, for example.
With such a firewall, and the rules living before the “accept established” rule, this will effectively lock you out of Google DNS or whatever is sent.
So your gist, to keep this working relatively reasonably, would be to whitelist all exiting dst-addresses…? (considering the list wouldn’t get overly populated).
No that is no different. You would have to check for incoming data in “established” state and for that to occur you need an actual listening TCP socket on the port you are using.
So you need to sacrifice some service running on the router or your inside network, dst-nat the incoming connections to that IP/Port, which accepts the connections, and then look for incoming data on the actual connections and if it occurs you can add the IP to the blacklist.
Of course you then need some way to cleanup the unwanted connections.
And it would not work for UDP.
