12 ms·
Why Putting SSH On Another Port is a Good Idea
- bubblesorting 13y agoBetter yet, put a firewall in front of sshd and only allow connections from your management network ;)
- cldr 13y agoOuch, camouflage on a tank is a good analogy. Nice response post. In addition to, as the author encourages, being "weary of the 'by obscurity'" argument (as I'm sure we all already are), I would also advocate being wary of it :)
- sliverstorm 13y agoSeriously, I think "wary" might be the most-misspelled word in the English language right now....
- relix 13y agoNo it isn't. Every server runs SSH, so this is more like there's a field, and you know there's a tank in the field, but you can't see it. The next thing you do then is take out your standard radar device which scans the field, and pinpoints exactly where the tank is in 3 seconds, and then you aim your tank buster at that spot and fire.
- markeganfuller 13y agoExcept unless your only target is that one tank you're not going to scan all its ports.
- serans 13y agoIn my experience most of the time "attackers"/script-kiddies just scan over a range of IPs for port 22, and if it's not open on your computer, they just move on to the next IP. That's why you get thousands of requests for port 22 and very few on say port 21. Of course, not that it would stop someone willing to spend more than a few seconds on attacking your server, but still makes the camo analogy a quite nice one in my opinion.
- maaku 13y agoOr, you put up a fake, camouflaged tank and let the enemy reveal themselves when they attack it. (Leave 22/tcp open as a honeypot, triggering an immediate iptables drop).
- djcapelis 13y ago2. Next he talks about this non-root listener issue. He claims that you shouldn’t run your SSH daemon on a non-privileged port because anyone can spin up a daemon up there. Great point, except you can still do that even if you run your main one on 22. I don't think I understand this point at all. What is it that you're trying to say? Are you sure you understood the original post's point? djc@capelis.dj:~$ nc -l -p 14 nc: bind to source :: 14 failed: Permission denied nc: bind to source 0.0.0.0 14 failed: Permission denied nc: failed to bind to any local addr/port djc@capelis.dj:~$ nc -l -p 1414 ^C See the difference? (Edit: The original blog entry has now been edited to slightly clarify the wording. But the update mostly seems like an attempt to rapidly justify the author's original point.)
- city41 13y agoPrivileged ports are why I disagree with this rebuttal. I want some assurance that when I ssh into a box, that I'm hitting a true and sanctioned sshd.
- djcapelis 13y agoTo be fair, you could get the advantages of both by running SSH on a different privileged port than 22. Many of the lower numbered even-numbered ones are good options as for historical reasons those are all mostly unassigned. (Pretty much any even number below 16 isn't used by much.) But I agree, the privileged ports point isn't something that should be brushed aside.
- GalacticDomin8r 13y ago> To be fair, you could get the advantages of both by running SSH on a different privileged port than 22. ephemeral port range are a tunable at least on FreeBSD. However tuning stuff like this is fraught with disaster consider how difficult it is to guess an ssh password vs all things that can go wrong when changing sshd's listening port. But do it if you want, I bill by the hour. galacticdominator% sysctl net.inet.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 10000 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023
- Oculus 13y agoThat was very fair response. Kudos for being able to attack the points, not the person.
- justinwr 13y agoI posted the original because I thought it was interesting. Elated to see an honest response. I love HN.
- jonbaer 13y agoI still can't understand why things like port knocking or single packet auth schemes like fwknop never really took off ...
- _mpu 13y agoBy experience, it just lets you avoid getting a shitload of brute-force attacks. So I do it.
- fletchowns 13y agoHow about: Why it doesn't matter what port you run SSH on * Because anything but the IP address of your office or VPN connection should be blocked at the firewall level for that port
- akurilin 13y agoI'm with you on that one. Setting up OpenVPN is a day worth of work at most and gives you the freedom not to have to worry about this stuff in the future.
- __david__ 13y agoWhy would I use a VPN when I have SSH? IE, why do you think that a VPN is somehow more secure than an SSH connection?
- zorbo 13y agoVPN is not mutually exclusive with using SSH. What he's saying is that people should firewall their SSH ports to only allow access from trusted IPs, and VPN's make that easier to do.
- __david__ 13y agoSo that means you can't SSH into your remote machine from an arbitrary connection? What do you do when you're traveling?
- fletchowns 13y agoYou use a VPN and then connect to SSH
- __david__ 13y agoSo then we go back to my original question. Why do you think a VPN is more secure than SSH? IE, Why is it important that your SSH port only be connected to by known IPs, but your VPN port is OK to be connected to from anywhere?
- tuzakey 13y agoIts kinda silly to move the port, a targeted attack is going to start with an portscan of you box, the attacker is going to say "oh what’s this here on port 2222?" and promptly discover that its ssh listening on a high port. Port knocking would make that discovery less likely I suppose but its still all treating a symptom of a bigger problem. So why not solve the problem with something a little more proactive like turning off password auth and go for sshkeys only. Maybe toss in something like fail2ban if you want to interrupt kiddies scanning your boxen. That said high port ssh can be nice if you're frequently on restrictive networks and getting out on port 22 is impossible. edit(spelling)
- brooksgarrett 13y agoI think you've missed the point. Ultimately, moving the port isn't securing the service but is just one more layer. It won't hold against a focused attacker but will hold against a majority of casual scanners just looking for a large number of SSH targets. The goal isn't to do keys OR move the port. The goal is to combine all the factors at your disposal to disrupt and discourage attacks.
- justinwr 13y agoI completely agree, moving the port is a must just to change up the configuration from everyone else's. Configuration items like port numbers are meant to be tweaked, especially when you can just stick a unique SSH port in your ssh_config. However, it's not hard to imagine these scanners have moved further past the days of the Morris worm and aren't just simple port scanners. Identifying what services are on what ports is a relatively easy process that doesn't remove much from the discovery phase of a bot or script kiddie. Hell, code review metasploit for a half hour and rip theirs out.
- tszming 13y agoYes, you have pointed out - a targeted attack. What if non-targeted attack like a robot scanning all port 22 in your datacenter?
- 13y ago
- programminggeek 13y agoHere is something to think about, the author is right, but if you follow many ssh setup tutorials that say to move to say port 25000, you are less likely to be port scanned than the default, but still more likely than if you had used something totally random like say port 42 or 818. By me even writing this clever hackers will start scanning those ports too, just to be sure they are hitting everyone. That being said, any port is better than the standard one and picking an unused port instead of the standard ssh port will give a reasonable 80/20 benefit for a lot of people.
- eslaught 13y agoPort scanning is generally automated (edit: and scans all ports, not just the handful you listed), so it doesn't actually matter which port you pick as long as it's not 22. Port scanners like nmap are widely available, so the time to actually figure out which port is running SSH is quite short in practice. Basically, there are two classes of people: 1. Those who use port scanners. 2. Those who do not. If you are being attacked by someone in class 1, then moving your port gives you absolutely no protection. Thus moving your port is only worth anything at all if the percentage of class 2 people is significant. However, if you also consider the probability a person in each class has of actually compromising your machine, then the security looks less convincing. Yes, it might be true that 95% of people don't bother to use a port scanner, but the most competent hackers are almost certainly going to be in the 5% that do use one.
- GhotiFish 13y agothose numbers don't look good at when you take a look at what those two classes of people are doing. ie. 1. is targeting you specifically, 2. is bot targeting everyone when presented with two options, thinking of those options as 50:50 is natural, but it's really more like 0.0000001:99.9999999
- mjhall 13y agoA bot doesn't necessarily only scan port 22 in a range - nothing stops the bot herder making it scan 1-1024 instead.
- csdreamer7 13y agoWasn't it posted on HY that modern exploit tools like metasploit scan all ports for SSH services by default now? That was my biggest reason not to bother changing the port. Is there any real reason beyond that? (I do use fail2ban to block repeated attempts.)
- dotBen 13y agoThe reason he's right is most attacks on SSH are one-dimensional. In most cases the dimension is IP range - an automated process moves from IP address to IP address examining port 22 for any common vulnerabilities. Rarely do these processes check all ports. Moving your SSH deamon to a different port prevents those automated processes from then hitting your security layer on whichever port you are running. The other dimension of attack is when an attacker is focusing on your IP address specifically. Then he probably is going to nmap your IP and discover which port(s) SSH is running on. Changing the default port for SSH doesn't help here, but this use case is far less common. Like others have said, changing port doesn't remove the need for security measures (cert-based/passwordless login, disable root, fail2ban) but it reduces any of those even being tested in the first place when most of your attempted attacks are IP-range based.
- __david__ 13y agoTurning off passwords and only using keys also mitigates the standard brute force attacks that happen. Frankly I'd much rather do that then have my server on a non-standard port.
- kenrose 13y agoActually, one thing I've found useful is keeping an sshd listening on port 443. I know, I know, sacrilege reusing the HTTPS port, right? The benefit of this is that it can allow you to tunnel through an HTTP proxy (e.g., like in a corporate environment). Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, it will transparently just transmit data between your client and the remote server, irrespective of what that content is. In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy. You can use this to tunnel ssh through an HTTP proxy. Putty supports this out of the box, but if you're using openssh, you'll need corkscrew also. You can always try to tunnel to an ssh server on port 22, but most proxies will hand you HTTP403 on any CONNECT request to a non-port 443. More info at http://daniel.haxx.se/docs/sshproxy.html http://daniel.haxx.se/docs/sshproxy.html.
- XorNot 13y agoI use sshttp for this - support for both port HTTP and HTTPS. I don't serve any webpages, but I wanted the option to also use a more aggressive SSH holepunch on the same port, and just naked SSH if I could.
- antocv 13y ago> Many HTTP proxies only allow traffic through to port 80 and port 443. The benefit of ssh on port 443 is that if the proxy is handed a CONNECT verb, Thats not how HTTPS works, there is no HTTP proxy for 443. You are in a corporate environment where nothing is let out on port 80, except through their HTTP proxy. However, port 443 is allowed out. > In fact, this behaviour is what makes HTTPS remain secure when going through an HTTP proxy. That would be a MITM against https and it doenst work that way. If you would go over the http proxy to connect to your sshd on port 443, that would be stupid as the proxy would see your connections. Its much easier and better to just connect directly without asking the proxy.
- grahamedgecombe 13y agoIt can work like this - see: http://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel http://wiki.squid-cache.org/Features/HTTPS#CONNECT_tunnel
- gmuslera 13y agoStandard or not standard port, you still should use port knocking in a way or another (or only enable it for the specific IPs that can access it ever). Internet don't even should be able to know that you have there a service that is only for you or for a very small amount of people. If a remote vulnerability is discovered in the server (happened in the past, don't rule it out for the future), you will be attacked, and it won't be a brute force attack to be blocked by fail2ban or similar. You can be scanned in any time, put in a database as "having ssh version x running in y port" and get ready for future use. And if well simple port knocking could be defeated inspecting your traffic, there are variants like fwknop that are resistant to that kind of interception or replaying.
- rsync 13y agoAgreed. Contrary to the naysayers, port knocking is an unalloyed good. Whatever your setup is, it's better if it doesn't show up in a scan at all. The "knock is a weak password" argument is silly - nobody suggests using only the knock, but rather to use the knock in addition to your existing auth scheme.
- cenhyperion 13y agoOn my personal boxes I use a combination of non-standard ports, disabling password auth (seriously, this will do more for your security than anything else), and fail2ban. Even with key authentication fail2ban still blocks several IPs a day.
- aiiane 13y agoThanks for writing up the same response I had to that article.
- sarnowski 13y agoThe "change-port" discussion for SSH is so boring :-/ OpenSSH is I guess the most secure daemon on all your servers. People should more think about to change the HTTP(S) ports of their non-public facing sites and other daemons and frameworks they use.
- quesera 13y ago> OpenSSH is I guess the most secure daemon on all your servers. Probably correct. However, sshd should be the only public facing daemon that hasn't dropped root privileges immediately after binding to its privileged port. So it should be the only daemon that can directly offer root privs to an attacker. I say "should" because it's a big world out there and people do some bizarre and indefensible things. Sometimes merely lazy things, but the net effect is the same.
- peterwwillis 13y agoIt is almost the same thing to offer non-root privs, because of the great number of patched and unpatched priv escalation holes in Linux. Almost guaranteed you will be able to get root if you get normal user privs.
- BryanB55 13y agoAnyone use Dome9? (http://dome9.com http://dome9.com) they close all of your ports and open them on demand via chrome extension or mobile app for when you want to use SSH.
- GrinningFool 13y agoSeems kind of like inetd? Except having to trust the reliability and availability of a remote provider to manage it for you?
- spc476 13y agoI run SSH on port 22, but occasionally (when I travel) I will run it on port 443. Yes, know 443 is used by HTTPS, but: 1) I don't run HTTPS on the box I SSH into 2) I might hit an overly restrictive WiFi that only allows traffic out over HTTP and HTTPS Which is another reason why you might not want to run SSH on another port. You might not be able to reach it.
- deleted 13y ago[deleted]
- quesera 13y agoIn moving sshd to an alternate port, I've noticed two things: a greatly decreased amount of log noise from dictionary attacks, and a moderately increased amount of portscans. It's reasonably clear to your average net malfeasant that any host running recognizable services is going to be running sshd. So why not do both? Put a dummy sshd on 22/tcp, deny all auth attempts, log whatever keeps you swimming in interesting data. Then run real sshd elsewhere, possibly filtered, possibly port knocked, and hopefully permitting key-based auth only.
- sorin-panca 13y agoAnd use sshguard, because the only thing you should care on a secured host is power consumption. One of my boxes went to 33% on all CPU threads during a sk attack.
- mikegirouard 13y agoI've done this in the past with some pretty good results. Though, I've dropped it because I found myself constantly locking myself out of my own machines. I can't deny, it is a cool technique though. PortSentry is a good tool to use for just this. Anytime someone came to :22 and the machine just disappears.
- swinglock 13y agoTry kippo, it's a whole bunch of fun. Redirect the port in iptables to a kippo VM to stay safe as well, but I don't think anyone's broken out of it.
- GalacticDomin8r 13y agoSo really the only problem you had with the argument is the security via obscurity? Yeah, me too. Otherwise, his point were spot on and you didn't address them directly.
- ewokhead 13y agoa: $port != 22 is enough to thwart most bots and skiddies. If you think the port number is a guarantee that you are safe or that you are communicating with a blessed ssh you are sadly mistaken. b: Uhh the port number means nothing. Host keys are there for a reason... Someone does not understand the functions of SSH. http://www.snailbook.com/ http://www.snailbook.com/ <- great book c: If you are not investigating fingerprint issues when logging in via SSH and you call yourself a sysadmin, please stop. You are going to be the reason your company ends up in the news because your shit got owned and 2,000,000 user account hashes were leaked blah blah. d: If you are not using key based auth and you have a fly by night keystore policy. Which means you have a keystore - stop. The whole keystore for SSH shit irritates me. I cannot tell you how many times I have heard sysadmins say a that a single private key is a "best practice". It is not a best practice it is a stupid practice and really prevents you from protecting unauthorized logins on other machines for the obvious reasons. Put your public keys on bitbucket.com or source management. Put your private keys on an encrypted disk in an encrypted archive if you must. This is still dumb imho because it is not needed. Leave one account (root) with console only/no ssh access that will allow for keys to be revoked/recreated when users need new keys. e: The original article http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port-than-22-is-bad-idea/ http://www.adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-... Is wrong and misguided. port knocking or knockd is an obscurity measure, precisely the kind he argues against. The linked article from the OP calls this out. f: Spinning up daemons is a big deal for non-priv users? So spinning up a remotely accessible Lisp out of emacs from a screen that is running in the background is bad? Hmm, here I thought that computers were meant to be tools for humans to get work done... Sorry, background processes are part of getting shit done. Users should be able to spin up the stuff they want to spin up in the network segments they have access to without the bureaucracy of misguided fools making the jobs of others more difficult because they think spinning up a gunicorn process or a custom daemon is worse than their unpatched kernel, apache tomcat and mysql listening on a publicly accessible address. Stateful firewalls and hosts allow/deny are there for a reason. Sorry for the snarky reply here but there are a lot of people chiming in that obviously have very little knowledge about managing *nix ops and remote access. I have pretty strong opinions about this kind of stuff. Especially the single key stupidity and not checking host fingerprints.
- mdmarra 13y agoBetter solution: require VPN connectivity and don't expose SSH on any port to the public Internet. Running services on non-standard ports will make the next admin that takes over this server want to track you down and smother you in your sleep.
- jrockway 13y agoI run my ssh server on port 443 in addition to 22, because some network connections block anything except 80 and 443, and this allows me to easily proxy through that broken network connection. (Actually, I appear to have stopped doing this. But it's something to consider if you are on weird networks on a regular basis.)
- deleted 13y ago[deleted]
- abalone 13y agoHe's overreacting a bit. Port knocking is not just an "obscurity layer". It's more akin to a PIN or weak password. The condescending opening is a tip off ("people who almost understand the topic").
- jvdh 13y agoEven so, it is still a very weak security layer that you are adding on to something that is already very secure. Does that really make it less secure? Now running SSH on a different port is an even weaker obscurity layer, but still, it still adds some security.
- teddyh 13y agoI think nobody is denying that it adds security. The question is, does the added security offset the increased complexity and associated difficulties?
- rsync 13y agoThis is, I think, the only valid argument against knocking. The standard (and always condescending) responses are that it is either a very small password and/or that an attacker can record and replay the knock from an eavesdropping position. Both of those are true, of course, but they neglect that the knock is always in addition to whatever else you are already doing to protect ssh. So I have always rejected those arguments and continue to evangelize for port knocking. BUT, the added complexity part is a valid point. I try to keep systems as bare and simple as possible and hate to add even a single unnecessary dependency package. I am happy to say that (on FreeBSD, at least) knock[1] is light, simple, and has run for thousands of days on busy production servers as well as my personal servers without even a single incident. [1] /usr/ports/security/knock
- teddyh 13y agoI used the word “complexity” not in the meaning of “the installed system is more complex for having more software in it”, but in the sense of “I don’t want to feel like I’m entering Diagon Alley just for wanting to use SSH” – i.e. complex to use, not complex to set up. But your interpretation works too – they are both valid arguments, in my opinion.
- bcoates 13y agoHe's right that "security by obscurity" isn't the entire story -- it's more like a mnemonic device for the more complex idea that: 1. In the real world, security resources aren't free. 2. Security decisions are made by users. 3. Humans will engage in risk compensation [1] 4. Setting policy doesn't change people's brains, it just tells them what to do. 5. It doesn't matter what you intend, it matters what users actually do. The upshot of this is that any security policy that is highly visible and highly inconvenient will reduce your security, and has to have a substantial benefit to justify its cost. You can say "I'll do stupid port reassignment tricks, and I'll also mandate that passwords are forbidden, and require that private keys be managed properly" but at three in the morning when the whatever is overdue and not working what you're gonna get is: I'll just do password auth with root:root, nobody ever hits port 24601 anyway. Besides, look at this page [2], using a strange port makes me invisible like the Predator and makes me four thousand times more secure! I really want to believe this so I do. Also, subverting scanners is an anti-security move, not a pro-security one. Scanners are a helpful tool to identify what the hell is running on your network. Your security efforts have to find every hole, the bad guys only have to find one. Don't put yourself at an even bigger disadvantage by making your systems harder to analyze. [1] http://en.wikipedia.org/wiki/Risk_compensation http://en.wikipedia.org/wiki/Risk_compensation [2] http://www.danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk http://www.danielmiessler.com/blog/security-and-obscurity-do...
- telephonetemp 13y agoI agree with the sentiment of your post, however, I'm not sure if for the kind of user who would put a root:root shell on port 24601 the alternative in the absence of the article [2] wouldn't be putting the same shell on port 22. The former at least has a better chance to stay uncompromised until somebody comes in to fix it. Edit: I also wonder if a passwordless root Telnet would last longer. :-)
- INTPenis 13y agoI think you're making some assumptions about people in your argument. This is really very simple, security is a multi layered thing and security by obscurity is never a good layer by itself but part of a larger "onion" it can be helpful. Bottom line, good security always takes discipline because humans are the last line of defense. There is no one button solution and anyone in security should know this so the argument shouldn't even be present about that point. Changing the SSH port towards the internet is a very pragmatic solution to spam in your logs. I know people will mention fail2ban but I'd rather not have a log parser running day and night on every internet facing server when I can just change the port and get rid of all that spam Forever. (I have yet to encounter one robot that can dynamically scan for SSH ports and use anything else than 22). Also, in my personal opinion, using a high port like 24601 is insecure because if your SSH daemon ever crashes then an unprivileged user on your system can listen on that high port and receive your precious connections. So personally I always use an alternative ssh port under 1024.
- hrjet 13y agoIs there a way to increase the privileged port range from 1024 in linux? If it's set to a high enough number, say 1024*1024, that would solve both problems (we could use a large port number for ssh and not allow non-root users to hijack the port).
- edgarvm 13y ago1024*1024=1048576 TCP port is a 16-bit value i.e. only values between 0 a 65535 are valid, it's not a wide range at all
- dmourati 13y agoAmend the title to include (if you run only one SSH daemon and you're the only one who needs to access it). Then I agree. Otherwise, hell no.
- ballard 13y agoIt's probably already been said, but it can be said enough: Security through obscurity is valid for marginally increasing the total security margin, but relying on any one practice or technique always smells like a dangerous approach. (Hence the hollistic practice of many overlapping features providing defence-in-depth.) Changing ports reduces the threat surface in limited but practical ways, however far more effective would be using secure port knocking (say fwknop with GPG and is also time-based). Secure port knocking and changing ports together would be perfectly valid. In fact, I have deployed these for openbsd jumpboxes guarding core infrastructure. So breaking in would require defeating fwknop with GPG and ssh. (If anything needs public auditing, it's GPG and SSH. VPN code also considering the logic often makes OpenSSL look simple. )
- _sabe_ 13y agoThis is a non issue. Set your iptables to start dropping packages after 3 failed login attempts.
- mlopes 13y agoSo, the guy's point is that if someone has access to your machine, then it's ok to make life easier for them to run a fake sshd?
- Sami_Lehtinen 13y agoOne question, why people always say that disabling passwords is important. AFAIK, passwords with keys is better than keys only. Now if someone gets the keys they can access the service with those keys without the passwords. Disabling passwords just makes security in one way worse. Think about chip & pin, because you have your credit card, wouldn't it be smart to disable PIN completely? Of course key ring could be encrypted, but that still allows off-line attack against it. If password is queried on-line, you can limit password attempts which you can't do in off-line situation. - Thanks
- inigoesdr 13y agoDisabling password-only authentication doesn't prevent you from using a password on your key. When you login with key-based authentication you will be prompted for the password for your key, even if password authentication is disabled, because they are two separate & unrelated processes.
- antihero 13y agoI still don't see any reason to change the port. Use only key auth. Problem solved.
- n0on3 13y agoI apologize but there is no such thing as "it is (ALWAYS|NEVER) a good idea" no matter how many blog posts people wrote about that. It just depends on which are the tradeoffs between the antithetic goals that you have when you do any kind of security hardening. Aside from that, since many already mentioned port knocking as another layer in the pile of this game, let me point out that not all port knocking (-like) implementations are that weak, look e.g. at knockknock [ http://www.thoughtcrime.org/software/knockknock/ http://www.thoughtcrime.org/software/knockknock/ ].
- mixmastamyk 13y agoI don't change the port, but use keys and instead allow a tiny, tiny subset of the the internet to talk to my servers on 22... my networks. Very little hassle, no crap in the logs. Is there a drawback I'm missing?
- dontmakemelaugh 13y agoif you have sshd on 22 you get 1000 hack attempts per day. if you move it somewhere else you probably get none the whole day. the chance to get hacked is way higher. why would you not want to lower the risk?
- msimpson 13y agoLet's start with a secure implementation for remote access: 1. SSH: Port - 22 Protocol - 2 PermitRootLogin - no StrictModes - yes MaxAuthTries - 1 PasswordAuthentication - no PermitEmptyPasswords - no ChallengeResponseAuthentication - no UsePAM - yes 2. PAM_ABL (auto-ban by account after three retires) 3. IPTables (auto-ban by IP after three retries) So in the above implementation an attacker has three attempts, max. This means the logs are quiet, yet accurately depict intrusion attempts. This also stops brute force attempts in their tracks and requires no exemptions to normal workflow. If, under the above circumstances, I were to obscure the port as well, this would serve no purpose than to completely side step script kiddie brute force attempts (as minimized as they would be in this configuration) with the horrific side effect of forcing my users to maintain (at the least) a config entry for the custom port assignment. Which, by the way, would become perpetually worse with the amount of servers and users in play. This is why obscuring the port is such a bad idea. And if you still want to obscure the port because the server, or network device, in question should only have occasional access by an extremely limited group of people, then just throw on a white list and possibly restrict access only through another server. Both provide more security than moving the port. And moreover, this article isn't even about SSH. It's about the semantics surrounding the usage of the term "security through obscurity" in the previous article. Which is hilarious to me, as both articles are full of shit. For one, the security implications of non-privileged ports is moot as the attacker already has access. And two, being less likely of a target is still being a target. Those five people who found the port in the test sample. Those are the ones who win most likely to exploit; not the thousands of script kiddies brute forcing you. Your time would be much better spent obscuring the actual version information for the service than the access point to it ... (Reposted here, as the original site went down.)
- teddyh 13y agoAs I understand his argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
- sdfjkl 13y agoI changed it because it makes FreeBSD's nightly security run output not contain thousands of lines like this: Jul 28 23:53:57 hostname sshd[1068]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55040 ssh2 Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2 Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2 Jul 28 23:53:58 hostname sshd[1076]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55155 ssh2 Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2 Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2 Jul 28 23:53:59 hostname sshd[1084]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55460 ssh2 Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2 Jul 28 23:54:00 hostname sshd[1092]: Failed keyboard-interactive/pam for root from 78.129.252.154 port 55566 ssh2
- belorn 13y agoHere is an even worse log output nightmare: Enable logging in the firewall/ids, which show all packets sent to a closed port. It's massive. Endless. Like looking into the endless void. Of course, my computer does not log packets that are just bouncing against my computer. It would distract me too much, and maybe it would do so for you to. Easier just to tell the computer to not bug you about it, and trust that the "attack" is harmless enough so to not to bother logging it at all.
- orenbarzilai 13y agowhile I agree with most of the things in this article, he states the obvious... Don't understand how this article got to the main page and it's still here after more than 11 hours.
- druiid 13y agoThere's nothing inherently good or bad about running SSH on another port. Honestly this argument is a bit silly given how easy it is to port-scan and many scripts out there will do that before actually trying anything. Essentially all you're going to do is make things annoying for your users. The really real good idea is running a VPN in front of all of your servers and never allowing SSH access to the outside world. I have two ports (at most) open on all of my servers: 80 and 443. OpenVPN takes less than an hour to setup. There's no reason not to set it up!
- virtualwhys 13y agoAgreed, VPN via physical firewall is a particularly nice solution. Sounds like you've offloaded mail, dns, etc. elsewhere if you only have at most 80 and 443 open.
- scardine 13y agoA daemon that blocks the attacker address after a number of wrong attempts is much more secure. IMHO moving SSH to another port is kind of Cargo Cult Security.
- mattln 13y agoI think he mentions port knocking precisely because he DOES understand point #1 ( the difference between security through obscurity as a layer but not your only layer), and is giving an example of using it as one such layer.
- blossoms 13y agoAfter pondering this article, I think the only reason to run SSH on a different port is to prevent zero day ssh authentication bypasses, which I don't think is a decent reason -- I'll eat my hat when this happens again.