Secure SSH using Port Knock
Just a quick how to……
First and formost you need to use key based authentication… See http://macnugget.org/projects/publickeys/
Port knocking is a stealth method to externally open ports that, by default, the firewall keep closed. It works by requiring connection attempts to a series of predefined closed ports. When the correct sequence of port "knocks" (connection attempts) is received, the firewall opens certain port(s).
The benefit is that, for a regular port scan, it may appear as the service of the port is just not available.
Download Locations
Server: Source
Debian http://packages.debian.org/unstable/net/knockd
RPM http://www.invoca.ch/pub/packages/knock/
Client: Windows
MAC
Iphone http://www.dannysung.com/main/?q=node/25
Andriod
Also check your Distributions repos for knockd and knock.
Once installed we now need to configure knockd
This example uses a single knock to control access to port 22 (SSH). After receiving a successful knock, the daemon will run the startcommand, wait for the time specified in cmdtimeout, then execute the stop_command. This is useful to automatically close the door behind a knocker. The knock sequence uses both UDP and TCP ports.
logfile = /var/log/knockd.log
[opencloseSSH]
sequence = 2222:udp,3333:tcp,4444:udp
seq_timeout = 15
tcpflags = syn,ack
start_command = /usr/sbin/iptables -A INPUT -s %IP% -p tcp –syn --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp --syn --dport 22 -j ACCEPT
Change the sequence line to your preferred port sequence
Now that you've changed the port sequences to your liking you now can start up knockd:
Make sure it's running
Just as a fail safe ensure you have a iptables rule like
Before closing your ssh port
Use the client software to run the port sequence, quickly ssh and WHOOOOP you're in!
See iptables sample output below
:INPUT DROP [5:240]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1183:743831]
-A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.1/32 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
I Hope everyone understands what im going on about, not very good at tutorials
Thanks
Richard
17 Replies
Maybe port knocking is useful somewhere else though. I'm not sure where.
@sednet:
Great.. But unless you are using password authentication SSH is a perfectly secure service and doesn't need to be hidden by methods like these. Port knocking is just one more thing to go wrong.
Maybe port knocking is useful somewhere else though. I'm not sure where.
HHHHMMMMMMMMMMM
@richardschmd:
HHHHMMMMMMMMMMM
http://www.cloudlinux.com/blog/clnews/sshd-exploit.php
That's not really a SSHD exploit, not a vuln in sshd. AFAIK that vector was trojaned sysadmin computers with keyloggers and password auth.
@richardschmd:
@sednet:Great.. But unless you are using password authentication SSH is a perfectly secure service and doesn't need to be hidden by methods like these. Port knocking is just one more thing to go wrong.
Maybe port knocking is useful somewhere else though. I'm not sure where.
HHHHMMMMMMMMMMM
http://www.cloudlinux.com/blog/clnews/sshd-exploit.php
That was not a SSH issue. If you give away your house keys it doesn't matter how good your locks are.
OpenSSH has an excellent security history. You can read about known issues in old versions at http://www.openssh.org/security.html
Turn off password authentication, use long ECDSA key pairs, turn on privilege separation, and for no money you have the best security going. The other things people put around SSH like port knocking, fail2ban, iptables rate limiting, and using non-standard ports may save some disk space because they log fewer attacks but I don't believe they improve security at all.
If you really need to hide ports in a secure way you should consider running OpenVPN (
I used to run port knockers when I was running some servers with high hacker value, but those were the days before phones and other devices that can be hard/impossible to generate knocks. Now I just run on a non-standard port (to reduce log noise without overhead of fail2ban) but I'm probably going to move to OpenVPN.
I was just trying to help……
Thats the first and last post from me…….
@richardschmd:
Crysis
I was just trying to help……
Thats the first and last post from me…….
Don't sweat it. Saying the sky is blue would provoke an argument around here.
Debate (i.e. the naysayers) is good. Either your idea is defensible, or it's not.
Bringing up both sides of the idea allows people that find your article to rethink whether it's worth them deploying (or not).
So don't take it personal, you posted a nice article, and others brought up the point that it might not be the most secure method out there. It's all good.
If a serious 0day for OpenSSH was dropped tomorrow then it could be disastrous, all of the low hanging fruit would be picked off first.
Changing your default port raises the fruit a little.
Using port knocking raises the fruit even further.
You have to decide about the trade-offs you are willing to make in reducing your attack surface (which I feel should be reduced where possible). Is mitigating against an 0day threat something you need? For some absolutely!
Some port knocking implementations are more secure than others but it's all about finding a balance that works best for your requirements. Even the weaker port knocking implementations will still help with defence in depth.
@sednet:
@richardschmd:Crysis
I was just trying to help……
Thats the first and last post from me…….
Don't sweat it. Saying the sky is blue would provoke an argument around here.
Seriously. This is an informative thread to those of us who are less familiar with this world.
Thanks
@jebblue:
I think it's a valid idea. People who say fail2ban and port knocking are not security measures and only reduce log noise need to review the fact that they are security measures because they reduce or positively affect attack surface.
http://en.wikipedia.org/wiki/Attack_surface
People say they are not security measures because they are not. A service which is secure without fail2ban or port knocking does not have its security increased by using them, and their addition does not provide security to an insecure system. If password or key strength is low, the kind of limiting done by fail2ban won't help, and port knocking is pretty much the definition of security by obscurity.
For people looking to further lock down SSH and similar services, I'd suggest these, in rough order of decreasing reward/work ratio:
2 factor auth (Google's PAM repo is easy to configure:
https://code.google.com/p/google-authenticator/ )fwknop (
https://github.com/mrash/fwknop ) or knockknock (https://github.com/moxie0/knockknock ), both of which use signed requests to actually accomplish what "port knocking" claims to: providing an authentication layer before communicating with the real SSH daemonVPN: Putting your services inside a VPN does roughly the same thing, with the downside of being a bit more configuration work and the upside of covering a much larger range of services.
Les
@akerl:
@jebblue:I think it's a valid idea. People who say fail2ban and port knocking are not security measures and only reduce log noise need to review the fact that they are security measures because they reduce or positively affect attack surface.
http://en.wikipedia.org/wiki/Attack_surface People say they are not security measures because they are not. A service which is secure without fail2ban or port knocking does not have its security increased by using them, and their addition does not provide security to an insecure system. If password or key strength is low, the kind of limiting done by fail2ban won't help, and port knocking is pretty much the definition of security by obscurity.
For people looking to further lock down SSH and similar services, I'd suggest these, in rough order of decreasing reward/work ratio:
2 factor auth (Google's PAM repo is easy to configure:
https://code.google.com/p/google-authenticator/ )fwknop (
https://github.com/mrash/fwknop ) or knockknock (https://github.com/moxie0/knockknock ), both of which use signed requests to actually accomplish what "port knocking" claims to: providing an authentication layer before communicating with the real SSH daemonVPN: Putting your services inside a VPN does roughly the same thing, with the downside of being a bit more configuration work and the upside of covering a much larger range of services.
Les
"But it doesn't hurt to obscure things sometimes just to make it tougher for your attacker."
My original point is that security through obscurity is a way to improve security posture and for me that makes it a security measure. Is it security on its own? No. Is "engineered security" enough, no, look at Heartbleed as an example of why. Or the RSA scare a few years ago.
edit: Or the SSH scare on debian.
These days, just having a strong password or key is enough to project your from roving bots. The remaining threat pool is "targeted attacker", and a targeted attacker isn't going to be affected by your port knocking or changed port or fail2ban.
- Les
I've stated, clearly, twice, what it is and what I'm saying it is. Hurdles, using your term, are a deterrent. I have over a decade in the military and am speaking English as a sign of the fact that deterrents do work. They are not a guarantee, they are not a total solution. What they also do not do is hurt to use them.
"a precautionary measure warding off impending danger or damage or injury etc."
You could also Google "warding off".