Skip to content

Securing SSH without fail2ban on tiny RAM

VPS Hosting by tallinnying 24 replies 3.3K views
#1

So I got this 128MB RAM box from Leaseweb right, and fail2ban was eating like 40MB just sitting there. Anyway I swapped to iptables rate limiting, 3 attempts per minute then drop. Heres the mess at 3am:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Works, zero memory basically. Idk why I do this anyone got better?

builds at 3AM, sleeps at noon
#2

My nephew set this up on our internet box at the shop. He said fail2ban too heavy. I told him we only have 1GB RAM total from CloudCone. He put in the IP tables thing. Seems fine? Our IT support guy at LocalTech said port knocking is more secure but nephew said too complex.

#3

Iptables rate limiting is layer 4 filtering. Effective against brute force, not distributed. For reference, SSH brute force is 10-100 attempts/sec from single IPs, easily caught. Real DDoS on 22 starts at 1Gbps. Your 128MB box dies before filtering matters. This solution fits your constraint.

mitigated 800Gbps before breakfast
#4

Went down again. Not related. Ticket open. Waiting.
Port knocking good. Used on 256MB box. No fail2ban. Never down from ssh.

world record: 4min Arch install
4 #5

Back in 2009 I ran ssh on a PIII with 64MB RAM. No fail2ban existed. We used tcp_wrappers and hosts.allow. They dont make them like that anymore. Your iptables trick is basically the same spirit. Port knocking was new then, overkill for most. Now sensible on tiny ram.

SPARCstation 20, still serving HTTP
#6

The port knocking is good solution for server small. Is more secure than only rate limit. I use both together on my box at HostHatch. Memory footprint is 2MB only. How much cost the fail2ban? Too much RAM. The KnownHost has guide good for this setup: https://www.knownhost.com. ¿why not use both together¡ is best I think

#7

Both together is the move honestly

#8

mateo_dragon said:
The port knocking is good solution for server small. Is more secure than only rate limit. I use both together on my box at HostHatch. Memory footprint is [b]2MB only[/b].

2MB for what, the knock daemon? Which one, knockd? That pulls libpcap. On a 128MB box with nothing else running, sure. With a web server and database, you're back to swapping.

The real issue with port knocking: it adds latency to every connection. My automation scripts hate it. Ansible, rsync over ssh, all break or need wrapper scripts.

mitigated 800Gbps before breakfast
#9

danfra said:
On a 128MB box with nothing else running, sure. With a web server and database, you're back to swapping.

This. I run nginx and sqlite on mine, total idle is like 90MB. Adding anything else is pain. The iptables thing is literally just kernel rules, no userspace.

Also re: distributed attacks, yeah my box would vaporize before the rules matter. But the rules stop the log spam, which was the actual problem. Auth.log was 200MB in a week.

builds at 3AM, sleeps at noon
#10

Has anyone mentioned sshguard? It's lighter than fail2ban, reads logs directly without a persistent daemon in the same way. C implementation, not Python. I ran it on a 192MB BuyVM slice for two years, memory stayed under 5MB resident.

The iptables recent module is fine until you hit connection table limits on very busy boxes. For 128MB with low traffic, it's perfectly adequate.

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft