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
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.
What do you guys think about GitHub vs Gitlab vs Gitea? Kind of want to make me give a try.
So, it will depend on what you need.
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.
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.
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.
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.