Slashdot Mirror

Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk...

Better than port knocking is single packet authorization.

http://www.cipherdyne.org/fwknop/docs/SPA.html

Unless they have either a correct password or gpg private key and an exact port number and protocol, they aren't even going to have the slightest idea that a computer even exists at the IP address they are scanning.

Try psad. I've been running it for years, in addition to selinux and iptables. It auto-drops all kinds of connection attempts based on parameters you can set, but the defaults are very reasonable. Works for all connections, not just ssh. It can report to D-Shield.org and ISC (internet storm center), and you can script attack responses with your normal shell. *very* highly recommended.

I test it from time to time with nmap and nope, it doesn't allow nmap to get anything.

http://cipherdyne.org/psad/

To be fair, RDP does use encryption, so it isn't wildly wrong to expose RDP to an external site. I wouldn't want to do it myself, but then I use much prefer Linux and use VNC behind SSH tunnels (use -localhost for the VNC server so that it only allows connections from itself).

Hiding RDP behind a VPN should protect from external attacks on this, so security through layers is the answer. I often wonder why FWKNOP http://cipherdyne.org/fwknop/isn't more widely used to hide and protect services.

http://cipherdyne.org/fwknop/

This was posted above. It accomplishes the same goal as port knocking, but removes all of the timing issues and replay attack vectors. All of the communication is cryptographically signed and encrypted and done via a closed port.

They can't fail authentication if they don't know it's there. http://cipherdyne.org/fwknop/

fwknop http://www.cipherdyne.org/fwknop/ is a SPA (Single Packet Authorization) tool designed to be the replacement for port knocking, addressing the issues you mention and more. I recommend looking into it.

Just to follow onto your comment.... I'm actually surprised this hasn't been a bigger deal in distros. Port knocking is a fantastic way to virtually eliminate these sorts of threats.

For a home server, this one's nice and easy to use:
http://www.zeroflux.org/projects/knock

ISPs may want to run an SPA tool like fwknop, allowing each user to have their own code:
http://www.cipherdyne.org/fwknop/

I personally use knocking on my home server as if I'm really in a bind, I can attempt to use the local telnet client rather than having to have a program to create the magic packet.

While I've heard talk of it, I haven't actually seen any software that ties together with ssh (or login) that only allows the user from a particular IP to log in. That'd really be the ideal thing for ISPs or any system with lots of users. This way, even if you hack one of the codes, you still have to know which user that code is for. And of course you still have all of ssh's normal authentication mechanisms you have to go through.

references:
http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/

I was thinking about this myself recently and managed to find fwknop - http://www.cipherdyne.org/fwknop/
It's an advanced version of port knocking that uses single packet authentication to get around the problem of replay attacks that plagues other port knockers.

By running fwsnort (covered extensively in the Linux Firewalls book), iptables is endowed with true application layer matching capability for Snort rules, and this takes Linux firewalling far beyond port-based filtering. Many fwsnort iptables rules apply to port 80 for example, but only trigger when malicious data is sent at the application layer.

Portsentry is dead, and while it was interesting several years ago, it has serious architectural problems that in my mind make it unsuitable for use as a security application when compared to something like psad. Here are the reasons why: http://www.cipherdyne.org/psad/docs/faq.html#diff_portsentry

True, port knocking is outdated technology for several reasons:

1) Difficult to solve the replay problem.
2) Extremely easy to bust knock sequences just by connecting to spurious ports.
3) Knocking sequences appear like a port scan to any intermediate IDS.
4) Cannot transfer a reasonable amount of data.

To name a few...

There is a better way that actually offers a real security benefit and solves all of the above problems; Single Packet Authorization (see http://www.cipherdyne.org/fwknop/). Here is a paper that describes all of the benefits of SPA over port knocking: http://www.cipherdyne.org/fwknop/docs/SPA.html).

True, port knocking is outdated technology for several reasons:

1) Difficult to solve the replay problem.
2) Extremely easy to bust knock sequences just by connecting to spurious ports.
3) Knocking sequences appear like a port scan to any intermediate IDS.
4) Cannot transfer a reasonable amount of data.

To name a few...

There is a better way that actually offers a real security benefit and solves all of the above problems; Single Packet Authorization (see http://www.cipherdyne.org/fwknop/). Here is a paper that describes all of the benefits of SPA over port knocking: http://www.cipherdyne.org/fwknop/docs/SPA.html).

and last but not least

3. install a port knocking daemon, like fwknop, or knockd

Try fwknop. The single-packet strategy it implements provides many advantages beyond port knocking: http://www.cipherdyne.org/fwknop/

fwknop prevents replay attacks in server mode by keeping track of MD5 sums of valid (decrypted) messages. The fwknop client prepends all messages with 16 bytes of random data which ensures that no two messages are the same. This way the same command can be sent without matching to a previously seen MD5 sum.

No one is claiming that Netfilter (or any other software) is perfect. One of the main advantages of this strategy is that at least the number of code paths is minimized by intercepting packets at the lowest level possible; i.e. within the kernel. In addition, because fwknop uses libpcap, the authentication packet can be destined for a seemingly totally unrelated IP but open up the firewall in a system that can watch this traffic go by on the wire.

Because certain things should not be implemented within iptables. For example, fwknop supports encrypted knock sequences with the Rijndael block cipher; psad supports email alerts to DShield, parsing of Snort rulesets, whois and reverse dns lookups, etc. Such functionality does not belong in iptables itself.

Because certain things should not be implemented within iptables. For example, fwknop supports encrypted knock sequences with the Rijndael block cipher; psad supports email alerts to DShield, parsing of Snort rulesets, whois and reverse dns lookups, etc. Such functionality does not belong in iptables itself.

You might want to check this link out:

Hos is psad different from portsentry?

Am I the only one to wonder why the author made a deamon that watches iptable-logs and then modify the ruleset when a matching knock sequence is found instead of implementing a iptables match module instead?

Same goes for psad (by same author) -- I thought the purpose of iptables was to allow plug-in modules to be COMBINED.