I change the SSH port to stop the damn logs filling up so fast, for my own logins I have a key. If you're using passworded SSH on the internet you're just asking for trouble.
A few years ago I started installing fail2ban on all my server instances, which comes with sane defaults and the SSH filter enabled out of the box (on Debian/Ubuntu, at least).
The defaults in debian for fail2ban are too short, in my opinion, it's useful to turn the ssh, postfix and other daemons' fail2ban time up to 3000 seconds.
I've read that some scanners are now doing a few probes here and there and only give up on an IP address after a week or two of no response. I adapted my ssh scan blocking software (part of some custom syslog software I wrote just to play around with: https://github.com/spc476/syslogintr) to block for 31 days. I figure it couldn't hurt.
> > > Doesn't that seem a little overkill just for controlling logs?
> > Someone spamming your SSH listener is bad for other reasons, and blacklisting obvious ne'er-do-wells is never overkill.
> If it is, you've got something seriously wrong with your setup. You should make fixing that your first priority.
Are you describing a Debian server instance running an SSH daemon listening on a public IP address as "something seriously wrong?" Are you implying that DoS and brute force attacks are not real threats? Is there another solution you prescribe to address these and related issues other than the solutions discussed in this thread, such as fail2ban, port fluxing, port knocking, and VPN?
> > > To me fail2ban for SSH seems a little strange unless it's in a shared hosting environment, as the real solution is simply key auth.
> > Aren't most hosting environments shared these days? :-)
> Generally not, and that'd obviously only apply if you were operating the environment as generally only the host has root on such systems.
If you don't own and operate your own data center, which is becoming a rare thing these days, your servers are in a shared hosting environment. How do you define "shared hosting environment," and how is fail2ban "a little strange" unless in that context? What does root access (or the lack thereof) have to do with protecting daemons from network attacks?
>Are you implying that DoS and brute force attacks are not real threats?
Brute force should not be, we have key auth to prevent that. Use it. If you're using fail2ban to prevent DoS attacks you probably shouldn't be the person trying to prevent DoS attacks.
>Is there another solution you prescribe to address these and related issues other than the solutions discussed in this thread, such as fail2ban, port fluxing, port knocking, and VPN?
Key auth to stop brute forcing, VPN would be preferable to mitigate potential key compromise.
>If you don't own and operate your own data center, which is becoming a rare thing these days, your servers are in a shared hosting environment. How do you define "shared hosting environment," and how is fail2ban "a little strange" unless in that context?
"shared hosting" is a pretty clear term, and anyone who's dealt with hosting should know what it means. But in case you don't, it's almost always used to refer to setups where you've got multiple customers hosting their content on unprivileged accounts on a shared server.
>What does root access (or the lack thereof) have to do with protecting daemons from network attacks?
You need root for fail2bans SSH blocking to function.
It's a password. Sent in plain text. But because users pretend that it's stealthy they pretend that it's something else.
Yes, you can have your port-knocking be an OTP. But why? Why not just listen to an UDP port that takes this plain text password or OTP like a sane person? Why sniff SYN packets?
What exactly does port knocking add to this, except make it MUCH more probable that your raw-packet-sniffing-oh-so-coolness has a security hole than that your "open UDP socket, read packet, check for equality" has a security hole?
With IPv6 TCPMD5 (or TCP AO) becomes a much more interesting way to solve this.
* attacker can't do successfull bruteforce attemps at the same rate or at all
* attacker can't reliable intercept (MITM) traffic, as he does not what port is being used
* attacker can' launch sshd DoS attacks, as he does not know where does sshd listen at (at least he has to try 65000 x bigger space, this precludes a lot of time based attacks
Sure, but I also trust it a hell of a lot more than any port knocking implementation. If SSH is your point of trust... make it your point of trust. Throwing up an extra layer of obscurity on top doesn't help anything.
If the port knocking was obscuring an unauthenticated root shell then you would have a good point, but this is a defence in depth measure that adds to the security. It helps because it's one more hurdle for an attacker to bypass.
Layering two actual security measures makes sense. Layering an obscurity measure on a security measure is not really any safer than just having the security measure, just as obscurity alone is not really any safer than nothing.
It is a security measure, as it involves authentication through the series of knocks. It's a weak security measure on its own, so you obviously wouldn't want to rely on port knocking by itself, but it does have utility in preventing an attacker from discovering the service through a simple port scan.
I don't quite understand why you're saying it adds nothing at all.
In essence, it's the same argument as "everyone should use encryption, even if it's barely non-trivial for state-level actors to break."
You're not defending against the attacker who is targeting you with this. You're defending against the attacker who is targeting "anyone who is trivially accessible."
Neat project. What we've been doing is using provider (software) firewalls for whitelisting IPs at the bastion level.
In AWS we have a security group just for the Bastion inbound, and adding/removing IPs to that on-demand to allow access. I kind of assumed this was standard practice by now?
Filtering by IP addresses and ranges only gets you so far. What if one of the people who needs to log in logs in remotely? Or if a contractor is behind a dynamically changing IP address? Or if you have too many IP addresses and ranges to fit the limit of rules in a security group? So, while IP restriction is a standard practice, it is by no means the end of it all.
I like the project as a cool and creative experiment,though, and that's what it says it is :)
filtering IP-adresses is an important security feature, if personnel needs to access it from non-white listed adresses, they first have to tunnel into Corporate Intranet
you shouldn't expose your services for convenience
I know that TFA acknowledges this but, I think it still needs to be stated that scanning all open TCP ports on a single IP generally takes less than a second.
It'll help you with logs but certainly not provide the same peace of mind that key auth or even post login TOTP provides.
You could presumably still just SYN scan to find the ports and then use proxies to identify the real sshd.
Obviously my approach would be somewhat involved but I'd imagine this would mostly be intended to protect against someone who may already have likely password candidates, rather than just random scanners.
About a decade ago I worked at a small web-hosting company where I installed the LaBrea tarpit software (http://labrea.sourceforge.net/Intro-History.html) on an otherwise unused system and had our routers route all non-allocated IPs to said system. The intent was to use that to track IPs that were attacking (since otherwise, no legitimate traffic would hit that server) and then block them at the router level.
Sadly, source level routing on routers is slow, and even if it wasn't, I wasn't sure how to automatically block said IPs at the router level.
Under a second?! I guess I never tried NMAP on aggressive, but I think that if you take 1ms per port you still get 65535ms which amounts to 65s... I mean, you could probably send all of those at the same time.. under a second?! really is that a feasible amount of time?
If so, I have been using the port scanners wrong [which btw I never use often, as this AFAIK was still frowned upon and even illegal if I'm not mistaken]
Line rate for 1gbps ethernet is over 1 million PPS, so you can definitely send the packets that fast. No promises the target will be able to respond that fast.
nmap is a bit of a joke to be fair, it is incredibly slow and there's no amount of fiddling with the settings that'll make it faster (even for simple SYN scans).
Scanning every single TCP port on a host will require 65536 packets, those packets will all be about 40 bytes in size. That's only 2.6 megabytes, so on a 100Mbit link that should take around 200ms to send.
This is a pretty trivial exercise to implement yourself, but for pre-existing tools you can look at masscan and zmap. However, these will not provide the version detection nmap does.
So you are saying to use a different tool to be fast but to use name for feature detection... Nmap is pretty darn fast if you disable feature detection!
>Nmap is pretty darn fast if you disable feature detection!
No it isn't, nmap is ridiculously slow no matter what you do.
The only thing it does well is version detection, but you can do that too way faster.
If you specifically need nmaps version detection, sure use it. Otherwise you might be better off using masscan, it tends to do a pretty good job even with the default banner grabbing.
Cool idea, and as long as your connection was completed before the port number changes, you'd be good to go.
Except..
* you're sharing a TOTP secret with one (or more) servers (probably all of your servers), or else you'll have to track multiple TOTP codes for each server
* throughly defeats legitimate automated scripts (i.e., backups, fabric, security scans, etc) that need SSH for automation
* hard to fix (increased complexity)
We recommend fail2ban or denyhosts at Userify[1] (plug: ssh key management), which do a pretty reliable job of blocking inbound traffic after a few (configurable) failed key attempts. They watch failed login attempts in the log file and then block the originating IP.
Still, as recommended in the article, consider running your sshd on a high port (standardize across your org), since it will definitely keep your logs cleaner, perhaps the same port throughout your org. It's amazing how many script kiddies this simple trick blocks. This is also handy on a jumpbox[2]. The time cost does represent a real increase in time for scanners (depending on the scanning pattern, possibly thousands of times slower), and so actually ramps up the time cost in attacks. It's kind of like blocking spam... this trick might seem like security through obscurity, but it will dramatically slow down/eliminate automated attacks against random targets of opportunity (which is what most attacks are). Also it truly does almost completely wipe out the random attack spam from your logs, leaving room for the good stuff.
Of course, the author states this TOTP trick was really a joke and a cool experiment. Don't actually do it in production. :)
What would happen if I, as an unprivileged user on the box running this, did this:
for port in $(seq 1024 65535); do ./my-ssh-sniffer-thing $port &; done
I leave my ssh at port 22 to make sure only root can bind to whatever i send my password/keys to and/or the AllowGroups directive in sshd_config(That way I dont accidentally allow my test:test1234 SSH-access.)
Nit: You do not "send your keys" to the SSH server. You only sign a statement using them. The statement contains some session data that is generated by the server and client together while setting up the session; this makes the signature useless for trying to impersonate the client in any future or concurrent connections.
I appreciate this is tongue in cheeck but given that it should be possible for me to constantly scan his server and get each port change is there anything I can do with that? i.e. derive his 2FA private key
IANA cryptologist, but it should not be possible to derive the shared secret from the token, if I understand correctly this is discussed in the HOTP spec[0]
> Assuming an adversary is able to observe numerous protocol exchanges and collect sequences of successful authentication values. This adversary, trying to build a function F to generate HOTP values based on his observations, will not have a significant advantage over a random guess.
