
TOTP SSH port fluxing - benjojo12
https://blog.benjojo.co.uk/post/ssh-port-fluxing-with-totp
======
suprjami
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.

~~~
mwpmaybe
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).

~~~
walrus01
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.

~~~
ytch
I use recidive[1] jail to ban an IP if it tries again and again.

[1]
[https://github.com/fail2ban/fail2ban/blob/master/config/jail...](https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf#L740)

------
btym
They then have 30 seconds to find the port, which is feasible. So... combine
TOTP with port knocking and make sshd unnecessarily difficult to find!

~~~
est
+1 for port knocking. Should be used more.

~~~
xenophonf
I don't get the love for port knocking. If you need such a thing, wouldn't a
proper VPN implementation be more robust?

Edited to add: I'm asking for a clue. Thanks in advance. :)

~~~
throwaway2048
I trust openssh a hell of a lot more than any vpn software.

~~~
lmm
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.

~~~
geographomics
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.

~~~
lmm
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.

~~~
geographomics
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.

~~~
ethbro
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."

------
pquerna
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?

~~~
tie_
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 :)

~~~
killerpopiller
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

------
Faaak
Cool, but not useful at all when using already written scripts (scp, rsync,
…)…

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.

------
ryanlol
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.

Cool project nevertheless.

~~~
jgrahamc
Back in 2007 I came up with something similar. It opened a bunch of decoy
ports that changed frequently so that a scanner would quickly get blocked.

[http://shimmer.sourceforge.net](http://shimmer.sourceforge.net)

~~~
ryanlol
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.

~~~
jgrahamc
The idea was that if you sent a packet to a decoy port then your IP was
banned.

~~~
ryanlol
I don't think shimmer will catch half open connections, and if it did you
could somewhat easily get large parts of the internet banned.

~~~
jgrahamc
Maybe not. It's been 8 years since I last looked at that code...

------
jamiesonbecker
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. :)

1\. [https://userify.com](https://userify.com)

2\.
[https://userify.com/docs/tips/jumpbox/](https://userify.com/docs/tips/jumpbox/)

~~~
Xiol
"Cloud SSH Keys".

Absolutely not.

~~~
jamiesonbecker
> "Cloud SSH Keys". > > Absolutely not.

... better avoid that whole cloud thing in general then! :)

------
ph4te
I have been using sslh
([http://www.rutschle.net/tech/sslh.shtml](http://www.rutschle.net/tech/sslh.shtml))
on my servers where it is just myself logging in for a while and it works
great for me!

------
superobserver
The real solution is to move beyond the ridiculous limitation of 65535 ports
to choose from.

~~~
tracker1
Or just use ipv6, which would be insane to even guess at the IP.

~~~
Sephr
Attackers can still scan the IPv6 subnets owned by you if you are being
specifically targetted.

~~~
knorker
Depends if you have entropy in your addresses or not.

585 years to scan a single /64 at one billion packets per second.

------
homero
How's a last digit 5 digits?

Takes the last digit, if the result is above 65536, do that again

~~~
bartbes
I think they mean "remove the last digit".

------
basemi
Nice!

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...](https://debian-
administration.org/article/187/Using_iptables_to_rate-
limit_incoming_connections)

[2] [http://www.shorewall.net/4.6/manpages/shorewall-
rules.html](http://www.shorewall.net/4.6/manpages/shorewall-rules.html)

------
u123u4
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.)

~~~
robryk
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.

------
pandog
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

~~~
riffraff
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.

[0]
[https://tools.ietf.org/html/rfc4226#section-6](https://tools.ietf.org/html/rfc4226#section-6)

------
CipherC
Interesting project. Support port range would be more kind since you won't
want all the ports to be on firewall whiltelist.

