Show HN: No PortScan
git.encryp.chSomething 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
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.
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
"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.
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...)
Ah, of course. Guess I should have checked first :)
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.
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.
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.
Drone ( the only standalone non-SaaS CI system I've used) was easy to install and connect ( it was a matter of 3-4 config options, and a single auth/app creation flow).
It's not that it's hard to setup external CI for something like gittea, it's that GitLab CI works REALLY well and is deeply integrated. I have no doubt that gittea/drone can work, I just doubt it can work as flawlessly as gitlab and be maintained and operated so seamlessly (seriously i've never seen a software package as complex as gitlab be as simple to install/maintain/upgrade over years).
GitLab team member here. Thanks for the kind words. I shared them with our product team. :)
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.
> 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.
Gitea is cozy, I like to s/Organization/Folder/ in the html templates.
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.
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.
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.
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.