Show HN: No PortScan

36 points by jimsi 4 years ago | 19 comments

mmh0000 4 years ago |

Something like this can be implemented in Linux's NetFilter quite easily using the recent module:

    iptables -A FORWARD -i eth0 -m recent --update --seconds 600 --hitcount 10 --name scan --mask 255.255.255.255 --rsource -j DROP
    iptables -A FORWARD -d 173.165.141.72/29 -i vmexfwbr -m recent --update --seconds 86400 --name instaban --mask 255.255.255.255 --rsource -j DROP
    …PUT STANDARD ACCEPT/REJECT RULES HERE…
    iptables -A FORWARD -d 173.165.141.72/29 -i vmexfwbr -p tcp -m multiport --dports 21,23,110,1433,3389,5060,8080,8088 -m recent --mask 255.255.255.0 --set --name instaban --rsource -m comment --comment "Instabans port scanning bots."
    iptables -A FORWARD -d $YOUR_IP_RANGE/29 -i eth0 -m recent --mask 255.255.255.0 --set --name scan --rsource
    iptables -A FORWARD -j REJECT --reject-with icmp-port-unreachable

The above would start dropping packets from anyone who hits 10 or more ports not previously accepted by an accept rule, and block the /24 of anyone who hits one of the more commonly scanned ports.

LinuxBender 4 years ago | |

Use care when blocking scans with iptables. This is mostly safe for TCP if you have a dummy socket listener for the attacker to connect to and you look for established connections in iptables. If you block on SYN or UDP packets then I can disable your traffic with simple spoofing. I can even get you to block your own gateway unless you whitelist it.

jimsi 4 years ago | |

This might be a way better solution in terms of performance, but I cannot imagine way to run more complicated stuff rather only blocking IP in the firewall using iptables

tyingq 4 years ago |

"to check counters ratio in a background - if it exceeds some value (i.e. 1.5) we will execute user-defined action and reset counters for triggered IP"

Interesting approach, though it seems like it should have a "floor/minimum" count first. Otherwise, 2 syns, 1 syn-ack is 2:1. Fairly easy to trigger accidentally with bad timing.

jimsi 4 years ago | |

This ratio is only applied if there are more than 1000 SYNs, forgot to mention that in the README (https://git.encryp.ch/g00g1/no-portscan/src/branch/master/cm...)

tyingq 4 years ago | | |

Ah, of course. Guess I should have checked first :)

hartator 4 years ago |

Not the subject of the thread but the GitHub clone used here seems pretty neat. Gitea. https://gitea.io/en-us/

What do you guys think about GitHub vs Gitlab vs Gitea? Kind of want to make me give a try.

sofixa 4 years ago | |

Gitea is a perfectly fine lightweight Git hosting platform. However you need external CI/CD, project management and what not; with GitLab that and a lot of other things come included.

So, it will depend on what you need.

remram 4 years ago | | |

How hard is it to set up CI? I know there are open-source CI solutions (Drone, SourceHut) but I don't know how hard they are to install and connect to Gitea. I don't think I'd use a platform with no CI.

DoubleFree 4 years ago | |

I find the interface of GitHub (and therefore gitea) much more usable than gitlab's. Gitea is also easier and lighter to self-host than gitlab. Gitlab's CI offering is awesome though and really makes it stand out among software forges. Honorable mention towards sr.ht which is very appealing to me because of its lightweight design and usage of email for "PR's" and issues and soon IRC for chat.

tomxor 4 years ago | | |

> I find the interface of GitHub (and therefore gitea) much more usable than gitlab's

Agreed, we switched from bitbucket to gitlab a few years ago, which was comparably better... but I still get lost in gitlabs interface when compared with github, it feels way too complex for the most common UI pathways. I now try to limit myself to the command line to avoid putting up with the complexity of gitlab UX.

majou 4 years ago | |

Gitea is cozy, I like to s/Organization/Folder/ in the html templates.

rsync 4 years ago |

Port scanning is neither irregular nor is it abuse.

We should treat attempts to block port scanning the same way we treat blocking ICMP ECHO or traceroute traffic: with derision and contempt.

If your (infra) is so fragile that you're worried about port scans, you're doing something wrong.

mordechai9000 4 years ago | |

I kind of agree. It's mostly automated searches for targets with known vulnerabilities or default credentials. It's fine to block it, but it's not really contributing much to overall security.

The fact is, a serious attacker isn't going to trigger an "x events in y seconds" rule, and even if they do it's not going to stop them.

People get very worked up about port scans and ping sweeps, even spending time manually managing block lists or responding to alerts for simple bot traffic. It's security theater.

shaicoleman 4 years ago |

Port scanning can be trivially distributed over multiple IP addresses and rate limited. So blocking one IP address won't do much to block a port scan coming from another IP address.

When I tried to apply somewhat similar solutions in the past (e.g. fail2ban), I ended losing access to the server a few times (misconfiguration/bugs/daemon killed/firewall rule conflicts/etc.).

A more secure way to prevent port scanning is Single Packet Authorization, e.g. fwknop [1]

"SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance"

Port scans happen all the time, and your security shouldn't rely on hiding that information.

Port scans are a mild annoyance, as they litter the logs. I changed SSH to an uncommon port, and saw about a 100x reduction in connection attempts, which is good enough for me.

1. https://github.com/mrash/fwknop

Anunayj 4 years ago | |

to add to that, I absolutely despise any IP related blocks, Since most residential ISPs use Dynamic IPs, you can easily end up being on one of these "IPs" with poor reputation and have to restart your router because cloudflare blocks you.

iptables -A FORWARD -i eth0 -m recent --update --seconds 600 --hitcount 10 --name scan --mask 255.255.255.255 --rsource -j DROP iptables -A FORWARD -d 173.165.141.72/29 -i vmexfwbr -m recent --update --seconds 86400 --name instaban --mask 255.255.255.255 --rsource -j DROP …PUT STANDARD ACCEPT/REJECT RULES HERE… iptables -A FORWARD -d 173.165.141.72/29 -i vmexfwbr -p tcp -m multiport --dports 21,23,110,1433,3389,5060,8080,8088 -m recent --mask 255.255.255.0 --set --name instaban --rsource -m comment --comment "Instabans port scanning bots." iptables -A FORWARD -d $YOUR_IP_RANGE/29 -i eth0 -m recent --mask 255.255.255.0 --set --name scan --rsource iptables -A FORWARD -j REJECT --reject-with icmp-port-unreachable