The scannings will continue until the Internet improves?

[DrPozo]

http://blog.shadowserver.org/2014/03/28/the-scannings-will-continue-until-the-internet-improves/

OK. How do I block them?

All IP ranges owned by The Shadow Server Foundation?

 

[DrPozo]

How to prevent The Shadow Server Foundation from scanning my ports? When this firewall rule appears first in the chain, it will hide your open ports from them. I don't really understand the motivation for allowing the "good guys" to probe my router about 2-3 times per day.

/jffs/scripts/firewall-start

#!/bin/sh
/usr/sbin/ipset -N banned_net nethash
/usr/sbin/ipset -A banned_net 64.62.202.96/27
/usr/sbin/ipset -A banned_net 66.220.23.112/29
/usr/sbin/ipset -A banned_net 74.82.47.0/26
/usr/sbin/ipset -A banned_net 184.105.139.64/26
/usr/sbin/ipset -A banned_net 184.105.143.128/26
/usr/sbin/ipset -A banned_net 184.105.247.192/26
/usr/sbin/ipset -A banned_net 216.218.206.64/26
/usr/sbin/ipset -A banned_net 141.212.0.0/16
/usr/sbin/iptables -I INPUT -i eth0 -m set --match-set banned_net src -j DROP

When some firewall rules must be kept first in the chain, here's how I figure out the insertion point for subsequent rules. In this example, the "state INVALID" rule was added by the firmware and it is hopefully a good reference point that will never change. So I insert my secondary rules before the firmware's "state INVALID" rule, but after my network blacklist, to hide my OpenVPN server port from these Internet port scanners:

/jffs/scripts/openvpn-event

# ...
RuleNum=$(/usr/sbin/iptables -nL INPUT --line-numbers | /bin/grep "state INVALID" | /usr/bin/cut -f1 -d' ')
/usr/sbin/iptables -I INPUT ${RuleNum} -p tcp -m tcp --dport 443 -j ACCEPT
/usr/sbin/iptables -I INPUT ${RuleNum} -i tun21 -j ACCEPT

Otherwise, it looks like the "good guys" at Shadow Server Foundation are attacking my VPN server.

/tmp/syslog.log

Apr 1 02:22:00 openvpn[4386]: 141.212.122.222:34641 WARNING: Bad encapsulated packet length from peer (7111), which must be > 0 and <= 1563 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Apr 1 02:22:00 openvpn[4386]: 141.212.122.222:34641 Connection reset, restarting [0]
Apr 1 02:22:00 openvpn[4386]: 141.212.122.222:34641 SIGUSR1[soft,connection-reset] received, client-instance restarting

 

[Nullity]

I only glanced at the link, but it seems like they are scanning for open ports... a common and easily avoided problem for consumers.

Unless you have a damn good reason, all your externally facing ports should be closed/firewalled. If they need to be open, verify that the listening service on that port is as secure as possible.

If you are unaware of the external ports you may have open, you can use the online nmap scanner.

 

[jack901]

sheilds up will also check open ports and service ports.
https://www.grc.com/x/ne.dll?bh0bkyd2

 

[Nullity]

sheilds up will also check open ports and service ports.
https://www.grc.com/x/ne.dll?bh0bkyd2

That site only scans 2 ports out of the 65535 possible UDP ports... (137 & 1900), which is logical, being that the scan focuses on UPnP & SSDP.

The internet primarily uses TCP, and secondarily UDP, and both have 65535 ports... so, that grc site is virtually useless with regard to the topic of this thread.

 

[sfx2000]

http://blog.shadowserver.org/2014/03/28/the-scannings-will-continue-until-the-internet-improves/

OK. How do I block them?

All IP ranges owned by The Shadow Server Foundation?

I think this is fairly harmless activity to be honest, and if you review their mission statement, they're not BlackHats, on the contrary, they're a WhiteHat group looking for BotNets and common security threats...

 

[jack901]

really ie:https://www.grc.com/x/ne.dll?rh1dkyd2

ShieldsUP!! Services

You may select any service from among those listed above
Or enter a port to lookup, or the ports for a custom probe to check, then
choose the service. Your computer at IP will be tested.

it tests file sharing, common ports ,ALL SERVICE ports as well as other tests. as well as the upnp stuff.
maybe you should click thru again.

That site only scans 2 ports out of the 65535 possible UDP ports... (137 & 1900), which is logical, being that the scan focuses on UPnP & SSDP.

The internet primarily uses TCP, and secondarily UDP, and both have 65535 ports... so, that grc site is virtually useless with regard to the topic of this thread.

 

[sfx2000]

Worse comes to worse - just head down to the local coffee shop and fire off an nmap scan against your WAN IP...

 

[Nullity]

really ie:https://www.grc.com/x/ne.dll?rh1dkyd2

ShieldsUP!! Services

You may select any service from among those listed above
Or enter a port to lookup, or the ports for a custom probe to check, then
choose the service. Your computer at IP will be tested.

it tests file sharing, common ports ,ALL SERVICE ports as well as other tests. as well as the upnp stuff.
maybe you should click thru again.

You are kinda correct, you can specify a port range, but it seems to be limited to 64 TCP ports, which leaves many ports unscanned... over ~130,000 if you count both TCP & UDP. Not really "ALL SERVICE ports".

 

[Fitz Mutch]

While sitting at the computer and having a beer today, I decided to add the xt_TARPIT target to Iptables for Asuswrt-Merlin (ARM kernels). This version of xt_TARPIT is supposed to have a "honey pot" mode that allows one to investigate the intentions of those Internet port scanners. While I have not yet tried capturing data from these probes via honey pot mode, I did try the normal tarpit mode. Now my router is getting swarmed like never before by the Internet port scanners. Do their algorithms smell the food and then tell their friends about it?

asuswrt-merlin-380.63_2-ARM-tarpit.patch
https://cryptobin.co/t101e5r8, password is lol

My patch is based on this version here:
Xtables addons 1.47.1
https://sourceforge.net/projects/xtables-addons/files/Xtables-addons/

 

[Fitz Mutch]

This was fun, so I did you another. It's a patch for Asuswrt-Merlin bundled with these additional Xtables addons. The purpose is for defense against those Internet port scanners. There's also miscellaneous addons included.

asuswrt-merlin-380.63_2-ARM-xtables_addons.patch
https://cryptobin.co/x7p689z4, password is lol

Xtables targets: CHAOS, DELUDE, RAWDNAT, RAWSNAT, STEAL, TARPIT
Xtables matches: fuzzy, iface, ipv4options, lscan, pknock, psd, quota2

 

[sfx2000]

While sitting at the computer and having a beer today, I decided to add the xt_TARPIT target to Iptables for Asuswrt-Merlin (ARM kernels). This version of xt_TARPIT is supposed to have a "honey pot" mode that allows one to investigate the intentions of those Internet port scanners. While I have not yet tried capturing data from these probes via honey pot mode, I did try the normal tarpit mode. Now my router is getting swarmed like never before by the Internet port scanners. Do their algorithms smell the food and then tell their friends about it?

Comes down to odd behavior actually with how port-scanners work - it's all automated...

By putting out a tarpit, this is a change in behavior of the scan, so the robots tend to dig deeper...

a tarpit is a big change in the connection compared to a accept/drop/limit...

 

[sfx2000]

This was fun, so I did you another. It's a patch for Asuswrt-Merlin bundled with these additional Xtables addons. The purpose is for defense against those Internet port scanners. There's also miscellaneous addons included.

Not fun as scanners happen - and if one gets glommed on - then it takes resources away on the host - even though a tarpit sucks up resources on the scanner - which might be fun - there are many more scanners than there are the target host...

FWIW - a tarpit in iptables basically sets the TCP window size to zero - which keeps the socket open, and the source side can't do much with it as even trying to disconnect, nothing can be sent from the source to the dest... so that socket is basically stuck until the scanner decides to kill that thread... and perhaps it won't - flooding the tarpit until the dest host crashes by running it's TCP/IP stack out of resources - and on a small device like a consumer Router/AP, that won't take long...

 

[sfx2000]

One can be much more effective with iptables by limiting connections - see below for an example..

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP

Pretty simple... and this will keep things settled - I'm using the default ssh port (22/tcp) - and this doesn't attract too much attention from the 'bots, as they expect this.. and they move on when the ports is no longer reachable.