Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512of course the point is not to be able to withstand an attack by a persistent attacker. it prevents my logs from filling up with the constant scans from scripts
- Fails when packet loss is high.
- Fails when lags make the attempts arrive in changed order
- Fails when multiple people try to execute the sequence at the same time (yes, you can track source IPs, but then it doesn't work from behind a NAT)
Agreed, none of this is a problem on a small scale. Agreed, you can work around that but it's a PITA.
This is correct and worth considering.
In actual practice (again, over 15 years, all over the world, etc.) I have found that the only place I ever run into this is on airplane (in-air) wifi. I don't know if they are specifically blocking random fragments or if they are just too laggy to make this scheme work.
A quick workaround is to ssh to some other host that you control that isn't behind a knock, but does have 'knock' installed and then jump through it.
There are a lot of things that fail if packets arrive out of order and with random packet loss your experience is going to be awful, so both of these are rare.
> 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.
This link: wget http://www.thoughtcrime.org/software/knockknock/knockknock-0...
Yes I suppose one of the forks is better nowadays
edit: That specific scheme looks naive and susceptible to replay attacks.
If the argument is that a steganographic layer that involves cryptography does a better job at concealing than a similar layer that doesn't I'm also not convinced. Cryptography helps against MITM scenarios, but at that point the existence of the service is already revealed.
How can anyone measure the effectiveness of the advice given by a security consultant? It saved a client from disasters that did not happen? How can anyone prove that such disasters would have happened? Answer: Proof of concept.
To question the effectiveness of port knocking, one needs some real stories of real disasters where port knocking was being relied on. Proof of concept. Otherwise all the discussion is still just speculation.
failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.
Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good.
I can't help but think this would be interesting...
We started by altering the ssh daemon to disallow all logins over this ssh daemon and to log all the usernames and passwords attempted. After a week we gathered thousands of attempts to brute force into the honeypot. Interestingly enough, the passwords used were a combination of the very commonly used ones but also ones that were clearly from other popped boxes.
After a week or so of this we altered the ssh daemon again. This time it would log all attempts but also grant access on the 3rd attempt no matter what the credentials were. The few bots that managed to get in all tried to install various rootkits on the machine, all of which where targeted at a different distro of Linux than we were using so it mostly just busted up our shells output.
It was a long time ago but a great experience.
EDIT: Source: https://github.com/fail2ban/fail2ban/issues/1123
It appears they have moved forward a little in supporting IPv6, but it's still incomplete. It's unacceptable to not support it fully in 2020.
[0]: https://github.com/fail2ban/fail2ban/blob/0.11.1/ChangeLog
There are people who do just that.. and then try connect back to that IP with the same credentials. Easy way to find some shells..
So it's the people running knockd that are actually the ones generating all these ssh login attempts...
also, lots of people sing the praises of fail2ban, which needs to watch log files to operate, but you can get most of its utility by simply rate-limiting using iptables' session tracking without any additional mechanisms.
https://selivan.github.io/2018/07/07/limit-new-connections-f...
Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password authentication --- which you must do anyways --- the probes aren't a meaningful threat.
There are myriad bits and bobs of software and services that promise to do anomaly detection in logs, but an easier approach for now is to just move ssh off 22. It affords basically zero extra real security but makes any subsequent login attempts more worthwhile to look at.
Broader answer after reading some of your other comments in this thread: in your ideal, highly secured network environment, none of this is necessary because everything's wired up tighter than a gnat's ass hole. Unfortunately I've never had the pleasure of working for one of those places.
The networks I'm describing aren't "ideal" or "highly secured". I am describing table stakes. While I was at Latacora, most of the clients we engaged with were already at this level of maturity when we joined up.
> The networks I'm describing aren't "ideal" or "highly secured". I am describing table stakes. While I was at Latacora, most of the clients we engaged with were already at this level of maturity when we joined up.
One of the most valuable things you do here is describe things that you believe are table stakes to people and organizations that have never heard of them. Companies like Latacora tend to self-select for clients that are at least aware that security should be a sensible line item in their quarterly budget. There are many many more organizations for whom moving ssh or even port knocking amount to a real improvement to their infrastructure. :-(
https://canary.tools/help/canarytokens
But the concept is really simple: come with any kind of thing you'd want to tripwire --- the AWS key is particularly slick --- and put it somewhere in your infra, then wait for alerts.
What if the attacker does not use software that automatically loads images, like the "canary token" tracking pixels?
What is the attacker opens the files offline?
Canary tokens still work? How?
Why would anyone advise using canary token instead of port knocking? Makes no sense. Why not use both?
thankfully, i dont have properties which attract determined scanners. and i imagine that's true for 99% of public ip addresses, too.
even if security through obscurity is not real protection from targeted attacks, it is at minimum significant noise reduction, and quite possibly a reasonable barrier against drive-bys which assume default configurations. i'm sure you know how many scanners try to access some default php/wordpress admin route. how much of that would disappear if wordpress was simply installed behind a random 32-char route instead of /wp-admin? all it is is obscurity, sure. but is it not security?
I call BS. These are pretty much the same thing* which is to say: an adversary trying to get the file needs to know something that they don't know, and can't reasonably guess/discover any time soon. Did you secure it or obscure it? Whatever you call it, you require a "something you know" factor.
*Obviously, there's the fact that other parts of the stack -- browser history, access logs, rate limiting, etc. -- actually treat a password payload with the respect it deserves and assume there's nothing sensitive about a URI path... kindly pretend my example doesn't have this flaw.
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.
The best argument in favor of knockd that I can think of is the same of fail2ban, which is that ssh connection is actually a finite resource. You can only have so many simultaneous TCP connections. Rejecting packages in the firewall has no limits, and I have had servers which has received service disruption in the past because swarms of ssh bots used up the available tcp connections that the web server could handle. fail2ban in my case was a less intrusive change to our work flow so we use that rather than knockd to solve the problem.
I will add as a small note that the default of not logging firewall events has come to bite us once in a while. Just like keeping the default in ssh to log, keeping the default to not log is a trade off between resource usage and keeping logs of events.
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 static IPs, is with mobile Internet tethering. They seem to frequently change my IP, so I guessed at my provider's IP range and whitelisted it with a pretty broad wildcard mask. Still much better than accepting connections from any old address.
I can see that my rather simple approach might not scale very nicely.
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.
If you put ssh on another port, all of those automated login attempts disappear from your logs. The determined human attacker probably has port-scanned you and found ssh on another port, so you'll see just that attacker and can look into it more deeply if you feel the need. On port 22, you probably never bother to look at your failed-attempt log, because there's so much noise.
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?
If I only got an email per week or so, I'd probably not filter them to a folder, and actually look at them.
[0] At work, other people deal with intrusion detection there, and ssh access is gated behind a VPN anyway.
But we realized that as attacks increased, it was pointless to look at who or how often we were being attacked, because it wasn't making our systems more secure. What did make them more secure was actually securing them: patching systems, implementing firewall rules, blocking or slowing down multiple login attempts.
Non-sophisticated attacks are trivial to prevent, and sophisticated attacks won't show up in logs. Everyone needs to stop logging ssh attempts and just secure their boxes and move on with life.
And that's why port knocking is stupid.
Just because you see or don't see attacks doesn't mean you are more or less secure. It just means you've finally noticed there is risk. It doesn't mean there is more or less risk. It's the same risk, it's just more visible.
Assume you move ssh to another port, say 23. In that case, anyone trying to connect to port 22 would find a closed port and the connection would fail, on a layer before login attempts get logged.
That principle is taught in school and echoed by every junior netsec professional out there.
After almost 20 years of work, I can say that these layered techniques, are invaluable. OF COURSE, the core security has to be bulletproof. But once you've covered that base, there is an enormous value in keeping your assets under the radar.
At the very least, it reduces the number of alerts you need to review by several orders of magnitude. Logs become READABLE.
I wrote up how having a server on the internet is scary now (http://redgreenrepeat.com/2020/03/20/why-you-should-secure-y...) and how to protect it (http://redgreenrepeat.com/2020/04/10/how-to-secure-your-serv...)
One thing I didn't get into more was port knocking/knockd as there were not many resources for it.
I'd love to learn more about how you have used knockd.
The command that gets run when the (correct) knock comes in is an ipfw command:
/sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22,443 setup
I then have a cron job that runs every night at midnight that deletes those rules:
0 0 * * * /sbin/ipfw delete 01021
The following is a little lame, but I want to see who has knocked so far today (should just be me and my own IPs) so I do this every minute:
* * * * * /sbin/ipfw show|/usr/bin/grep ^01021 | awk '{print $7}' > /tmp/.knock_list
Knocking a poet is bound to get you into trouble. Poets fight back, and hard. Just don't do it.
* Does not bind to sockets
* Is not written in C
* Prevents replay attacks
* The only code that runs as root is just tailing kern.log and is like 15 lines
It probably needs to roll from SHA1 to SHA256 and Python2 to Python3, but otherwise seems sound.
Edit: It appears there may be an active fork here: https://github.com/indyprime/knockknock
Still digging through to see if the encrypt-then-authenticate change made it into this version.
Edit 2: It looks like it still uses authenticate-then-encrypt. I sent an email to the maintainer of that fork, we'll see what happens. ^__^
How I set it up specifically: https://peekread.info/tech/20190513-fwknop/
https://www.howtogeek.com/105693/how-to-knock-into-your-netw...
Sounds pretty cool, but do SSH clients (e.g. PuTTY need special support for it)
Port knocking (which I think I learned about first at defcon ... perhaps 18 years ago ?) stands out as one of the very few things that made my network(s) substantially safer at nearly zero cost. I love, and continue to love, both the idea and the implementation.
Pay no attention to the nay-sayers and their comical straw-man argument against deploying port knocking by itself. Of course it's not deployed by itself - it is the last layer of defense-in-depth on top of all the other authentication methods you may be doing.
The substantive critique is that you add some amount of complication to your network and introduce a point of failure with knockd - and that is correct. I am happy to report that 15+ years of knockd in production use, all over the world, has produced exactly zero lock-outs or unintentional self-DoS.