Blacklisting seems popular, honeypot made simple

Joni · Mon Aug 20, 2018 1:26 pm

Inspired by the now defunct Linux Portsentry (by Psionic, accuired by Cisco in 2002) revive by https://github.com/BinaryDefense/artillery (which unfortunately is still a bit rough around the edges)

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:

1433 - Microsoft SQL Server
8080 - alternative HTTP port
21 - File Transfer Protocol (FTP)
5060 - Session Initiation Protocol (SIP)
5061 - Asterisk, Freeswitch, Vonage (IPBX)
5900 - Virtual Network Computing (VNC)
25 - Simple Mail Transfer Protocol (SMTP)
110 - Post Office Protocol - Version 3 (POP3)
1723 - Point-to-Point Tunneling Protocol Virtual Private Networking (PPTP VPN)
1337 - DNS / Shadyshell
10000 - Multiple / Webmin
5800 - Virtual Network Computing (VNC)
44443 - ColdFusion / Siteminder
16993 - Intel(R) AMT SOAP/HTTPS

In addition, in light of recent events, you might want to add 8291 - Winbox and 23 - Telnet to the list

/ip firewall filter

add action=add-src-to-address-list address-list=Artillery-blacklist address-list-timeout=336h13m chain=input comment="Artillery Blacklist TCP" connection-state=new dst-port=1433,8080,21,5060,5061,5900,25,53,110,1723,1337,10000,5800,44443,16993 \
    in-interface=ether1-WAN log=yes log-prefix="Artillery-blacklist TCP" protocol=tcp src-address-list=!whitelist tcp-flags=""

add action=add-src-to-address-list address-list=Artillery-blacklist address-list-timeout=336h13m chain=input comment="Artillery Blacklist UDP" dst-port=123,53,5060,5061,3478 in-interface=ether1-WAN log=yes log-prefix="Artillery-blacklist UDP" protocol=\
    udp src-address-list=!whitelist tcp-flags=""
    
add action=drop chain=input in-interface=ether1-WAN src-address-list=Artillery-blacklist comment="Drop Artillery Blacklist Input"

add action=drop chain=forward in-interface=ether1-WAN src-address-list=Artillery-blacklist  comment="Drop Artillery Blacklist Forward"

Jotne · Mon Aug 20, 2018 1:42 pm

There are many thing you can do to improve this.

1. Use a find command to find outside interface so that you do not need to change it when pasting commands.
2. Use the "place-before" commands, so that its not put at the bottom where it does nothing.
3. 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.

Joni · Mon Aug 20, 2018 1:55 pm

There are many thing you can do to improve this.

1. Use a find command to find outside interface so that you do not need to change it when pasting commands.

There are many things you can do too, post a updated version improving it accordingly

2. Use the "place-before" commands, so that its not put at the bottom where it does nothing.

Lets let people break their own routers in their own pace...

3. 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.

My bad, failed paste. *fixed*

Steveocee · Mon Aug 20, 2018 6:03 pm

This is a fantastic start!

I'll grab hold of this later and push it to a test router I have to see what it does or doesn't break.

Thank you

Joni · Mon Aug 20, 2018 6:15 pm

I'll grab hold of this later and push it to a test router I have to see what it does or doesn't break.

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...

nostromog · Mon Aug 20, 2018 7:58 pm

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?ti ... ervice=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

Joni · Mon Aug 20, 2018 8:41 pm

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 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.

eXS · Wed Aug 22, 2018 4:49 am

Don't be afraid to get out there a little more on ports, ranges and some UDP in there too.

- Although taken to an extreme you may want to make sure you know how to track down inadvertently blocked traffic first :>

Steveocee · Wed Aug 22, 2018 5:50 pm

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.

# SET WHITELIST IF NEEDED
# SET IN-INTERFACE
/ip firewall address-list
add address=8.8.8.8 list=WHITELIST
/ip firewall filter
add action=accept chain=input comment="ACCEPT ESTABLISHED & RELATED SERVICE" connection-state=established,related in-interface=WAN.INTERFACE
add action=accept chain=input comment="ACCEPT WHITELIST" src-address-list=WHITELIST in-interface=WAN.INTERFACE
add action=accept chain=input comment="ACCEPT PING" protocol=icmp in-interface=WAN.INTERFACE
add action=add-src-to-address-list address-list=honeypot-blacklist address-list-timeout=none-dynamic chain=input comment="BLACKLISTING TCP" in-interface=WAN.INTERFACE protocol=tcp src-address-list=!WHITELIST
add action=add-src-to-address-list address-list=honeypot-blacklist address-list-timeout=none-dynamic chain=input comment="BLACKLISTING UDP" in-interface=WAN.INTERFACE protocol=udp src-address-list=!WHITELIST
add action=drop chain=input comment="DROP BLACKLISTED INPUT" in-interface=WAN.INTERFACE src-address-list=honeypot-blacklist
add action=drop chain=input comment="DROP ALL (SHOULD NOT FILL UP)" in-interface=WAN-INTERFACE log=yes log-prefix=non-bl-dropped-traffic

Steveocee · Fri Aug 31, 2018 4:33 pm

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?

pe1chl · Fri Aug 31, 2018 4:49 pm

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.

Joni · Fri Aug 31, 2018 8:29 pm

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).

Code: Select all

/ip firewall filter

add action=add-src-to-address-list address-list=Artillery-outlist address-list-timeout=336h13m chain=output comment="Artillery Outlist TCP" connection-state=new \
    out-interface=ether1-WAN log=yes log-prefix="Artillery-outlist TCP" protocol=tcp

pe1chl · Fri Aug 31, 2018 8:55 pm

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.

Blacklisting seems popular, honeypot made simple

Do you find this?

Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Re: Blacklisting seems popular, honeypot made simple

Who is online