If there's a remote-root buffer overflow for sshd that does not involve login at all, doesn't hiding the sshd add quite a bit of value ?
That is, there are attack vectors that we know exist, and that we have seen in the past many times for server daemons, that occur before, and override, any authentication mechanism.
By hiding the service, you take yourself out of that population of low hanging fruit ...
You don't find that valuable ? I personally find it extremely valuable and consider port knocking to be one of the very few security optimizations that has such low cost/complexity for such a pronounced and well defined gain. I would not think of deploying an Internet facing system without port knocking on the daemons that don't need public access.[1]
But it's something.
You have to decide if the tradeoff between a thousand bot's scans and a sole eavesdropper noticing the knocking pattern and marking your host as "(incompetently) trying to hide" is really worth it.
Edit: heh, same thing is going on a few comments down :)
Not true. Modern port knocking is provably secure and requires network layer attacks to bypass.
More surface (both spiped and ssh are accepting connections):
|
→ |ssh
|
→ |spiped
|
→ | spiped ↝ | ssh
|
spiped is a tiny program, uses symmetric crypto (small surface). SSH isn't a tiny program, uses more complex asymmetric crypto (larger surface).
To learn more: http://www.daemonology.net/blog/2011-07-04-spiped-secure-pip...
To learn how to put it in front of SSH, see https://github.com/Tarsnap/spiped#example-usage
-> | SPA / fwknop | ssh
There are important differences too though (beyond the fact that SPA is not encrypting/decrypting traffic for SSH itself). SPA is a UDP authenticator so it cannot be scanned.
Design goals: http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#d...
Then the attacker can just compromise every single sshd on the internet and have enough bandwidth to bruteforce most port knocking setups.
How does public key authentication protect you from a 0day in sshd or something like the Debian OpenSSL Predictable PRNG key issue?
In a perfect world where there will never be a 0day in sshd or any further weak key issues, but we don't live in a perfect world.
The one time I've ever had one of my linux machines compromised was from CVE-2001-0144.
When the Debian key issue first came out all of my keys were vulnerable. None of my hosts were compromised because I used port knocking.
Look: it is legit to be paranoid about ssh zero-days (I am not, partly because that vulnerability is so valuable that I am very far down on the food chain for it). But if you're paranoid about those, be serious about them. Put an encrypted tunnel in front of sshd, not some goofy authentication scheme.
Remember: if there's a preauth sshd zero day, the SSH connections themselves are attack vectors. TCP is easily hijackable.
Sure.. but now you have to worry about vulnerabilities in whatever software you are using for that. Other than maybe something like a locked down spiped I wouldn't trust anything more than ssh in the first place.
From my perspective the nice thing about something like the 'simple non cryptographic knockd' was that other than decoding ip packet headers it did not read any data from the network.
> if there's a preauth sshd zero day, the SSH connections themselves are attack vectors. TCP is easily hijackable.
Hah, I am not that paranoid :-)
My main concern was always this sort of scenario:
I am on vacation with no internet access, an ssh (or openssl or openvpn) 0day is released, patches are not available. Do I come back from vacation to a compromised host? If I had not been using port knocking when the debian ssh key issue happened, I would have had multiple hosts compromised. So, you can call it goofy, but it made a very real difference in my experience.
The threat model here simply does not make sense.
I had a machine compromised in 2001 by script kiddies and worms scanning the internet on port 22 and compromising any host they could find with CVE-2001-0144. Not by attackers hijacking TCP connections.
In 2016 I am worried about a 0day being released and scripts kiddies or a worm compromising every host they can find running sshd. This effectively happened to debian systems in 2008. I don't know how you can say that it doesn't make sense when it happened.
In fact, it can give you a false sense of security from such 0-day exploits.
Really? How are they going to do this?
http://www.cipherdyne.org/fwknop/docs/fwknop-tutorial.html#w...
There are benefits beyond security: for example, less strange login attempts mean less clutter in your logs. If you're actually trying to investigate login attempts (don't!), it means less time wasted.
The "security by obscurity" screaming people are usually thinking too narrowly, in my opinion.
Running sshd on port 22, seeing repeated authentication failures in the logs. conclusion: business as usual for sitting on the internet. signal to noise ratio: almost 0.
Running sshd on port $RANDOM, seeing ANY authentication failures in the logs. conclusion: someone is specifically targeting me or my network, I might want to pay some attention to this. signal to noise ratio: 1.
Nope. At least, not frequently enough to make a lucky guess more likely than a concerted attempt. Not one auth attempt since I switched the SSH port, and this is for a public-facing website, too.
No, you really won't.
Scanning every single port on /0 simply takes way too much time even with millions of nodes, you're much better off improving your coverage over the common ports and catching new (and old) equipment coming online.
Of course, this wouldn't necessarily be true with the "preauth opensshd 0day" brought up in TFA. Such an exploit would certainly give you more than enough BW to do whatever you want, and break the internet while doing it.
With regards to the former, I emphatically agree with you. If you've been singled out by a competent attacker, you're subject to his statistical probing of your system, which is bound to reveal most (if not all) of the configuration/parametrization info you're trying to hide.
In the case of dragnet attacks, however, I emphatically disagree. There is asymmetric cost imposed upon the attacker: time.
Your door doesn't have to be impenetrable; it just has to be stronger than your neighbor's.
Thoughts?
Your home-made CMS isn't going to attract attackers because the spoils are limited to one site, and the code isn't readily available.
That doesn't mean your CMS is more secure; it probably isn't. But it's going to take a focused effort to attack, and an exploit becomes less likely.
Also such measures do not help any kind of a system that has to be really exposed. Want to hide your http and mail server behind a port knocking mechanism? A rarely supported or proprietary TLS method only?
With regards to that, not stopping automated attacks in general is fully-independent of being a less appealing target for such attacks. The latter -- even on it's own -- improves security.
You are correct that a properly configured sshd has nothing to worry about with respect to these mass scanners. However, can we guarantee that we'll never make a configuration error? You're also correct that a pre-auth sshd vuln would be a HUGE deal. But can we guarantee one will never happen? Do you disagree that if a misconfiguration or a world-changing vulnerability were to happen, that a little time more to deal with it would be helpful?
If I run something that is in any way vulnerable (whether via bug or misconfiguration) on port 22, it will be found within minutes (based on how often I see that port getting scanned today). Unless I'm being specifically targeted, an sshd running on an arbitrary port isn't going to get hit until/unless someone is running full port scans across the internet looking for it. I don't understand how you can argue that this is worthless. A measure that isn't useful against a determined and targeted attacker can still be useful. The adversaries that most of us face in the real world are looking for the path of least resistance, not access to our specific systems.
Moving from port 22 to $RANDOM will only net you annoying log bloat from things that you don't really care about.
The claim is that obfuscation makes it less likely that a mistake will be spotted by an attacker.
To be clear, I agree with you to the extent that a properly configured SSH server with good keys and no 0-day exploit is more effective than what I'm proposing. My point is rather that such a setup makes a lot of assumptions (key exchange, configuration, secure updates, etc...) and that obfuscation is a complementary security layer for when those things occasionally fail.
Just to reiterate, SSH was an example of the general problem that is misconfigured/buggy software. OpenSSH is certainly one of the most secure programs I'm aware of, but the same can't be said for things like wordpress.
Eventually, something gets messed up (if only momentarily), and being nonstandard makes you less susceptible to scripted breaches.
We can debate whether the tradeoff is worthwhile (and in many cases it's not), but it's a valid gosh-darn secruity layer!
You're responding to an argument I haven't made.
What are those ways?
You can? how? I just logged into a server using port knocking. what was my knocking sequence? What do you have access to?
> I can deny you service by messing up your knocks by sending packets with a fake IP
Ok, I'm ready when you are.
> insanely inefficient in the amount of data and time spent vs the amount of information exchanged
I don't even know what this means. How is a few extra packets at the start of a tcp connection "insanely inefficient" ?
Port knocking is silly. If you're scared of preauth sshd zero-day, deploy an encrypted tunnel.
2. What's your point?
Replay attacks don't work against proper port knocking.
Take for example, knockknock-daemon. It sends just one SYN packet where packets IP and TCP headers are encrypted request to open a specified port. Port is closed after connection.
https://github.com/moxie0/knockknock/blob/master/knockknock-...
I don't know python but this implementation seems broken in the same way (or more precisely, under the same circumstances). I just realized, you don't even need to copy the knock. If you have access to the network traffic (which you would need to copy the knock in the first place), you also have access to the TCP sequence numbers. You can just connect from the user's IP after he performs the knock, or even let him connect and inject packets at some later point. This program seems to rely on the TCP authentication of IP address which is completely negated if the attacker can monitor traffic.
Am I misunderstanding how this program works?
An observer watching packets has no way to know that the SYN packet transmitted is a port knocking request. Even if they know, there is no way to determine which port was requested to open.
Let's say the attacker has no idea you're using port knocking and even somehow missed your port knock packet completely, but after that captures subsequent traffic. He will still see the sequence numbers in the SYN/ACK from the server which is all he needs. Once he has that, he is an equal party to you (the legitimate client) in that connection.
Tell me what percentage of attackers on the net have full access to the network traffic and can do full MITM attack?
If the goal is layered defense and minimizing exposure, worst case scenario is not good counterargument.
And if you believe this is an unreasonable assumption, why did you link me a program which says in its description "The problem with the original concept was that if your port sequence was observed by passive eavesdropping, it was easily replayable." ? It tries to solve this exact problem - a sniffing attacker.
I am just explaining why this program fails to solve the problem you claimed it solved in your original reply. Surely you can understand that.
Without knocking:
Service is listening and accepting new connections in well known port. When client makes connection attempt, attacker can replay the connection attempt and server starts handshake. Even without sniffing attacker can initiate handshake by just requesting connection.
With knocking:
Server/firewall opens requested port for client who knocks. That port is _not_ open for subsequent connection attempts. Simple replay is not going to initiate handshake. You need to block client from sending.
It is irrelevant whether the legitimate client connects or the attacker does if the attacker is sniffing traffic. This is just how IP and TCP work.
If I am sniffing traffic, I can fool the server into thinking I am the client and do what I want, while fooling the client into thinking I am the server and make him happily drop the connection after he sent the initial packet I needed to find out the port.
Basically, in IP protocol you can say you are any IP address you want in your packet. There is no way for the receiver to tell whether you're lying[1]. Then TCP introduces sequence numbers -> if I say I am 1.1.1.1, but I am actually 2.2.2.2, the server will send a sequence number to 1.1.1.1, and expect that number + 1 in response, but as I am not 1.1.1.1 I will not receive his sequence number and be unable to reply with number + 1 - I don't know the number. However, if I am sniffing traffic, I will see the sequence number he sent to 1.1.1.1 anyway, and I will correctly reply with number + 1 while continuing to lie I am 1.1.1.1. So it makes no difference to the attacker whether the server is talking to 1.1.1.1 or 2.2.2.2 (attacker's IP) as long as he can sniff traffic. It also makes no difference whether the legitimate client initiated the connection or the attacker did. It is just packets, it doesn't matter who sent them.
I am not sure if I am understanding what you're asking correctly. Basically, you don't need MITM capability to pretend you're a different IP than you are. Lying about your IP is a basic feature of the IP protocol. And if you are sniffing traffic, it is also not in any way prevented by TCP.
[1] except in special cases when the sender claims something clearly impossible, like claiming to be an IP from a different interface (claiming to be 127.0.0.1 for example) than the one the packet was received on
If client has already sent connection request, replay is not going to work if only one connection is accepted. You need to be able to block the traffic from legitimate server or be faster (how?) to get there first.
I do not believe that port knocking and single-packet authentication are good examples of this; both are sort of textbook examples of cosmetic security mechanisms that are made irrelevant by SSH public key authentication.