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