7 ms·
TOTP SSH port fluxing
- ryanlol 10y agoI 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 10y agoBack 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 10y agoYou 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 10y agoThe idea was that if you sent a packet to a decoy port then your IP was banned.
- spc476 10y agoAbout 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 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.
- joantune 10y agoUnder 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]
- devicenull 10y agoLine 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. See https://github.com/robertdavidgraham/masscan https://github.com/robertdavidgraham/masscan
- ryanlol 10y agonmap 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.
- cryowaffle 10y agoSo 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!
- ryanl0l 10y ago>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.
- btym 10y agoThey 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 10y ago+1 for port knocking. Should be used more.
- xenophonf 10y agoI 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. :)
- est 10y ago> wouldn't a proper VPN implementation be more robust? Suddenly your whole VPN infrastructure became an attack surface.
- throwaway2048 10y agoI trust openssh a hell of a lot more than any vpn software.
- lmm 10y agoSure, 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 10y agoIf 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.
- deleted 10y ago[deleted]
- superobserver 10y agoThe real solution is to move beyond the ridiculous limitation of 65535 ports to choose from.
- homero 10y agoHow's a last digit 5 digits? Takes the last digit, if the result is above 65536, do that again
- splitbrain 10y agoLooking at the video he seems to use the first 4 digits.
- bartbes 10y agoI think they mean "remove the last digit".
- pquerna 10y agoNeat 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_ 10y agoFiltering 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 10y agofiltering 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
- suprjami 10y agoI 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 10y agoA 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 10y agoThe 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 10y agoI use recidive[1] jail to ban an IP if it tries again and again. [1] https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf#L740 https://github.com/fail2ban/fail2ban/blob/master/config/jail...
- spc476 10y agoI'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 https://github.com/spc476/syslogintr) to block for 31 days. I figure it couldn't hurt.
- ryanlol 10y agoDoesn't that seem a little overkill just for controlling logs? 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.
- Faaak 10y agoCool, 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.
- jamiesonbecker 10y agoCool 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 10y ago"Cloud SSH Keys". Absolutely not.
- jamiesonbecker 10y ago> "Cloud SSH Keys". > > Absolutely not. ... better avoid that whole cloud thing in general then! :)
- ph4te 10y agoI 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!
- CipherC 10y agoInteresting project. Support port range would be more kind since you won't want all the ports to be on firewall whiltelist.
- pandog 10y agoI 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 10y agoIANA 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
- u123u4 10y agoWhat 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 10y agoNit: 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.
- basemi 10y agoNice! 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_to_rate-limit_incoming_connections https://debian-administration.org/article/187/Using_iptables... [2] http://www.shorewall.net/4.6/manpages/shorewall-rules.html http://www.shorewall.net/4.6/manpages/shorewall-rules.html