Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Port knocking

en.wikipedia.org

Post reply on HN
Print view View original

141–150 of 185 posts

Re: Port knocking

#141

Post by belorn »

kelnos wrote: post #68
peterwwillis wrote: post #45

Earlier quoted context omitted.

> moving ssh off of port 22 cuts your drive-by log noise I didn't know logs made me unsafe! I'm turning off all logging immediately.

The point is that most login attempts are automated, and the automated scripts just try port 22 and move on if they fail. If you run ssh on port 22, you see in your logs all the failed attempts from the giant sea of automated scanners, and will probably miss the one or two humans who might know something about you specifically (like your username) and are trying a targeted attack. If you put ssh on another port, all…

I would be interested to read about peoples process and procedures from those that regularly read their ssh failed attempts, identify human attackers, and react to that information.

My question is basically: Do they exist? How is the work flow and how much time per year do they spend on it? What incident occurred and what value did they derive from the process. Was it cost-effective?

Re: Port knocking

#142

Post by iso1631 »

MaxBarraclough wrote: post #129
leeoniya wrote: post #42

Earlier quoted context omitted.

from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.

> simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. Is there a reason you can't use some form of IP whitelisting? I'm not a proper sysadmin, but when I play about on EC2 I always configure the security-group to block incoming connections to TCP port 22 except from whitelisted IPs. The only time I've had to broaden the whitelist beyond just a few…

> I'm not a proper sysadmin, but when I play about on EC2 I always configure the security-group to block incoming connections to TCP port 22 except from whitelisted IPs.

Because I have multiple IPs I connect to, most of which are unknown. Maybe I'm connecting from a coffee shop, maybe from a tethered phone, maybe from work, maybe from an airplane, or a train, or a friend's wifi, etc.

Re: Port knocking

#143

Post by teddyh »

blauditore wrote: post #117
teddyh wrote: post #104

Port knocking is stupid. The only possible real reason anyone should have for actually using it is if they really don’t want their logs to be flooded with the normal internet attacks. Logs which the SSH daemon really shouldn’t (by default) be creating in the first place, since what’s the use? It’s like having a weather station on your roof which always says “it’s raining”, since you live on the ocean floor . It’s the…

I agree with 1. and 3., but not 2.: It's basically like a password where ports are your alphabet. Assuming you use most of the 2^16 ports, and a typical text password is based on an alphabet of ~70 characters, each knocking step is roughly equivalent to log_70(2^16) ≃ 2.61 traditional password characters. For example, 5 steps of knocking already entail (2^16)^5 ≃ 1.2*10^24 steps to check. With 1000 attempts per secon…

I’m unconvinced that most people use such complicated knocking schemes to contain that many bits.

It’s still trivially sniffed, since it’s sent in the clear.

And it’s hard to change, since you have to change all the places which needs it.

Re: Port knocking

#144

Post by cheweh »

tptacek wrote: post #52
fao_ wrote: post #49

Earlier quoted context omitted.

If you're exposing a developer instance to the network and it has port knocking deployed, why does it matter? The discoverability of such a service is basically zero. What are the chances of the cracker finding the exact combination of ports to knock on, and then the exact key to use? If they're able to do that then they are a dedicated attacker and they're mitm'ing a presumably encrypted connection on your network,…

The premise of your comment is that you're deploying dev instances on routable IP addresses on networks without default-closed filtering, in a configuration where it's theoretically possible that people could directly get a remote shell into that machine. Don't do that. In AWS (for example), have a dev VPC, and a WireGuard forwarder on it (or, if you're doing things 2010-style, an SSH bastion). If the machine needs t…

Re: sniffing, if I were implementing port knocking I would use the "single packet authorization" variant like in knockknock, which makes sniffing much less useful to an attacker.

Re: Port knocking

#145

Post by cheweh »

heftig wrote: post #122
steerablesafe wrote: post #93

Earlier quoted context omitted.

I would argue that port knocking doesn't implement cryptography, but it implements steganography. It's purpose is not to cryptographically secure your service but to conceal its existence.

Can't we do both? Like, the content of the UDP packet is the output of `date -uIs | gpg --sign`.

From knockknock:

> When you want to open a port from a client, you run 'knockknock', which sends a single SYN packet to the server. The packet's IP and TCP headers are encoded to represent an IND-CCA secure encrypted request to open a specified port from the source IP address.

https://moxie.org/software/knockknock/

Re: Port knocking

#146

Post by steerablesafe »

heftig wrote: post #122
steerablesafe wrote: post #93

Earlier quoted context omitted.

I would argue that port knocking doesn't implement cryptography, but it implements steganography. It's purpose is not to cryptographically secure your service but to conceal its existence.

Can't we do both? Like, the content of the UDP packet is the output of `date -uIs | gpg --sign`.

You already do both when you are concealing an ssh server. The cryptography part is the responsibility of the ssh server.

edit: That specific scheme looks naive and susceptible to replay attacks.

Re: Port knocking

#147

Post by moring »

steerablesafe wrote: post #146
heftig wrote: post #122

Earlier quoted context omitted.

Can't we do both? Like, the content of the UDP packet is the output of `date -uIs | gpg --sign`.

You already do both when you are concealing an ssh server. The cryptography part is the responsibility of the ssh server. edit: That specific scheme looks naive and susceptible to replay attacks.

The suggestion is nice though since an attacker would have to break both at once. If you conceal an SSH server, you'd first break the obscurity, then proceed with attacking the SSH server. The suggestion seems to be that you would have to break the cryptographic part to reveal the server (which is then supposedly secured by "normal" cryptographic means, such as a regular SSH server). That is, you are dealing with cryptography just to be sure the server exists at all.

Re: Port knocking

#148

Post by metalliqaz »

ape4 wrote: post #140
simias wrote: post #131

Earlier quoted context omitted.

For me changing the default port for SSH achieved much of the same result at an even lower cost IMO. That is, unless you're high profile enough that attackers might want to target your server specifically and you're not just randomly scanned by botnets which won't generally bother looking beyond port 22.

Put ssh on port 80 and http on port 22 - perfect security ;)

for my internet-facing machines I black-hole everything below 1024 and move SSH to something high but easy enough to remember like 22222

Re: Port knocking

#149

Post by hunter2_ »

heavenlyblue wrote: post #95
hunter2_ wrote: post #76

Earlier quoted context omitted.

The whole "obscurity isn't security" thing is a super interesting topic. Suppose you have a static file on a public web server and you want to control access to the file... confidentiality. Many people would agree that if you come up with a long string, don't disclose it to untrusted parties, and use it as a basic auth password, then you have secured the file to some extent. And many people would claim that if you ta…

Semantics of this is wildly different. You may accidentally enable the directory listing. While you may say that certain methods of withholding the information are isomorphic at certain conditions it doesn’t mean that they are semantically equivalent.

I admit that my example is flawed for a few reasons and autoindex is another in that list. While obscurity and security are not identical by any means, and therefore not semantically equivalent in general, I'm just pointing out how the "something you know" factor inherently utilizes what common ground they do share, whether you call it a secret, a key, a password, a URL with a long random portion.

Re: Port knocking

#150

Post by bkanber »

bkanber wrote: post #33

What does port knocking look like on the client side? Does ssh have some option that makes it easy? Does everyone just write a custom bash script that wraps ssh client?

If anyone else was curious like I was, it looks like yes, most people do write a custom bash script to wrap (or use before) SSH. The makers of knockd also make a `knock` util that serves as a client, but other people also do something like:

``` for x in 9000 8000 7000; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x server_ip_address; done ```

Post reply on HN