Skip to content

Securing SSH without fail2ban on tiny RAM

VPS Hosting by tallinnying 24 replies 3.3K views
#21

For anyone who wants the knockd route, fwknop is the modern take. SPA instead of port knocking, single packet auth. Still needs a daemon but much harder to replay. I run it on a 512MB RamNode box, memory around 3MB.

Not worth it below 256MB. The iptables-only solutions are correct for this thread's actual constraint.

#22

I host for friends in Zagreb, they don't pay me enough to debug port knocking at 2am when they're drunk and locked out. I give them WireGuard, ssh only through tunnel. Same zero-exposure benefit, but they understand VPN apps.

The 128MB boxes I don't take. Too much headache for party-hosting rates.

#23

Did anyone test crowdsec? Open source, lighter than fail2ban supposedly. I haven't benchmarked memory myself, their docs claim 50MB for the agent which is still too much for this thread.

The bouncer can be pure iptables though. Maybe split architecture helps if you run the agent elsewhere. Overkill for 128MB.

#24

Following this thread. I have a 64MB NAT VPS from HostHatch Stockholm, no iptables at all, only their shared IPv4. I use Dropbear instead of OpenSSH, smaller memory footprint, and their control panel firewall for rate limiting. https://hosthatch.com

Different constraints entirely. Not helpful to OP but maybe someone else needs the data point.

2 #25

cat_search said:
No iptables at all, only their shared IPv4

NAT VPS with panel firewall is a different threat model. The control panel filters before your VM sees packets, so your 64MB is never touched by the SYN flood. Smart provider-side filtering makes this whole discussion moot.

For dedicated IP with local kernel filtering, the iptables recent module remains the correct minimal answer. Everything else is preference or compliance.

mitigated 800Gbps before breakfast

Post a reply

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

Post reply Preview Save draft