Slashdot Mirror

"Why the hell don't you have port knocking enabled for SSH?"

Because http://www.giac.org/paper/gsec... maybe.

Have you even read it? Or did you "think" no one else would?.

Was that the only thing you could find about portknocking in your Google rush?

It only says three "bad" things about portknocking:-

• Portknocking is bad because malware might install some form of portknocking
• portknocking is bad because it's security through obscurity - which is stupid as saying running ssh on a non-standard port is security through obscurity. i.e. obscurity is only bad if it's the only security.

• . Which is irrelevant because not installing portknocking doesn't affect in any way whether malware might install it's own portknocking.

• Knowing the knock can open your system. If it's the only system authentication you use. It shouldn't be.

There are other, more valid risks with port knocking which your "security powerslide presentation for n00bs from 2004 overlooked":-

• The knock sequence could be captured. Only if you don't enforce sequence rotation. Or better, use SPA
• It's another piece of software that could go wrong. Maybe, it's pretty well time tested and audited.
• It's hard to log. Not really. But if you find it hard you can do the same thing with iptables or authpf.

Portknocking is not a perfect solution - it's a way to lower your profile, just like using a non-standard port, which it very effectively does - which is why it's one way of meeting the mandatory requirements for ASD privileged networks. Keeping the hordes from the gates is just as important as securing the gates.
Employ it using default settings is not recommended, I'd increased the time outs (port knock fails, the port is locked out for a few minutes).

There are alternative solutions (I've already mentioned using iptables to achieve the equivalent of kernel level portknocking, and authpf) but there are also others. But you're the expert.

Allowing ssh passwords is certainly not Best Practise security. TFA is.

fail2ban? It works with IPv6 does it? (try sshguard it does). With passwords enabled, your ssh port visible and protected from bruteforce attacks only by fail2ban you must chew a shitload of bandwidth and log space. Given that, and your earlier post, you're definitely not in a position to decide whether I'm a security professional. I don't claim to be - that'd be a full-time job in itself, but the people who work for me are, as are the clients. Just about every client here is defence or directly connected, failing an audit would be to costly to rely on the sort of citations you supply to justify using well documented Bad Practice security.

Sometimes you have to access from other IPs, or don't have a known, fixed IP from where you could have to connect, or you could have to fix something when in a trip. I'd suggest a mix of several of those (no root access, non standard port, explicitely enabling in fw just the IPs you know that must enter by that service) but adding portknocking for the rest of the world (only if you could need to access from elsewhere), specially using Single Packet Authorization to prevent the chance of someone (specially 3-letters agencies) capturing/replaying how you entered there. And not just for ssh, every service that is not meant for the whole internet shouldn't be even visible for the rest of the world.

I haven't used psad for a long time but if i recall correctly it had an option to execute a program/script of your choice if a portscan reached a specific threshold.

Hrm, it appears that the author of shwatchr hasn't updated it since 2001.

I do like Mike Rash ( Cipherdyne.com ) and have used some of his software (psad will analyze my firewall logs using Snort fingerprints, to help determine the type of attack).

But I would hesitate to use any software which has not been updated in nine years.

IMNVHO this would be better done in the netfilter (aka iptables) kernel subsystem than in the qdisc system. Not only can it then be used for more than just rate limiting (but also for firewalling, transparent proxying etc), but there is limited similar functionality already available in the patch tree (the STRING match) that could be extended to run regular expressions. Importantly, netfilter can communicate with the qdisc subsystem by tagging packates appropriately, enabling the rate-limiting and advanced queueing already discussed. I'm sure that the core work already done could be ported from one subsystem to to the other, although perhaps not overnight.

The fwsnort tool has proved the concept, I think, by translating rules from the Snort intrusion detection system into iptables rulesets.

For more complex protocols, such as FTP or IRC DCC, you'd also get Netfilter's connection-tracking support code for free.

I also think beginners will find the iptables tool easier to deal with that the tc tool, which has a steeper learning curve.