TOTP SSH port fluxing
blog.benjojo.co.uk
blog.benjojo.co.uk
[1] https://github.com/fail2ban/fail2ban/blob/master/config/jail...
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.
Someone spamming your SSH listener is bad for other reasons, and blacklisting obvious ne'er-do-wells is never overkill.
> unless it's in a shared hosting environment
Aren't most hosting environments shared these days? :-)
If it is, you've got something seriously wrong with your setup. You should make fixing that your first priority.
>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.
> > > 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?
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.
Edited to add: I'm asking for a clue. Thanks in advance. :)
Suddenly your whole VPN infrastructure became an attack surface.
I don't quite understand why you're saying it adds nothing at all.
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."
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
I'm not sure how what you said is related to what I said.
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?
I like the project as a cool and creative experiment,though, and that's what it says it is :)
you shouldn't expose your services for convenience
A more easy, yet secure, way would be to simply use the google authenticator module, which does the same task but not at the "port/network" level.
It'll help you with logs but certainly not provide the same peace of mind that key auth or even post login TOTP provides.
Cool project nevertheless.
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.
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.
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.
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.
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. :)
Absolutely not.
... better avoid that whole cloud thing in general then! :)
585 years to scan a single /64 at one billion packets per second.
Takes the last digit, if the result is above 65536, do that again
If you want make things harder for attackers, check out IPtables rate limit[1], nicely implemented also in Shorewall[2]
[1] https://debian-administration.org/article/187/Using_iptables...
[2] http://www.shorewall.net/4.6/manpages/shorewall-rules.html
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.)
> 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.