Hey All

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 http://www.zeroflux.org/proj/knock/files/knock-0.6.tar.gz
Debian http://packages.debian.org/unstable/net/knockd
RPM http://www.invoca.ch/pub/packages/knock/

Client: Windows http://gregsowell.com/wp-content/plugins/download-monitor/download.php?id=19
MAC http://www.zeroflux.org/proj/knock/files/knock-macos.tar.gz
Iphone http://www.dannysung.com/main/?q=node/25
Andriod https://play.google.com/store/apps/details?id=com.droidknocker


Also check your Distributions repos for knockd and knock.


Once installed we now need to configure knockd


vi /etc/knockd.conf

This example uses a single knock to control access to port 22 (SSH). After receiving a successful knock, the daemon will run the start_command, wait for the time specified in cmd_timeout, 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.

[options]
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:

/etc/init.d/knockd start

Make sure it's running

ps fax | grep -i knock

Just as a fail safe ensure you have a iptables rule like

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

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

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's not really a SSHD exploit, not a vuln in sshd. AFAIK that vector was trojaned sysadmin computers with keyloggers and password auth.

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. Also there was an incident where the Debian project broke the entropy mixing code and shipped an OpenSSH version that generated keys from a limited pool of random numbers.

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.

Typically port knocking shouldn't be viewed as a security measure because, well, it isn't. I've always viewed it as just a way to reduce noise in the logs generated by script kiddies. fail2ban and similar don't reduce log noise and typically create more problems (e.g. locking out legit users which takes time to unlock, generating even more noise in logs, heavy overhead in iptables with lists of thousands of hosts to block, etc.)

If you really need to hide ports in a secure way you should consider running OpenVPN (http://openvpn.net/) or at least run a secure port knocker: http://www.thoughtcrime.org/software/knockknock/

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.

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.

Peer Review - it's what keeps engineering (and science, tech, etc) honest.

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.

_________________
Either provide enough details for people to help, or sit back and listen to the crickets chirp.
Security thru obscurity is a myth - and really really annoying.

There have been vulnerabilities discovered in OpenSSH before, although none have been found for a reasonable length of time it *could* happen again - any day.

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.

Seriously. This is an informative thread to those of us who are less familiar with this world.

Thanks

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 daemon
* VPN: 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

http://tech.slashdot.org/story/01/07/23 ... snt-so-bad

"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.