5 ms·

You should not be afraid to change the port number either. As a sysadmin, I have heard all the tales of no security through obscurity, which honestly I don't th

You should not be afraid to change the port number either. As a sysadmin, I have heard all the tales of no security through obscurity, which honestly I don't think is nearly as steadfast a law as people pretend, but thats another discussion. Changing ports isn't about security, it's about log fatique. Less hits on different ports, less things to stop and investigate. Even better, port knocking on non-standard port.

webwanderings 10y ago
What's better - Fail2ban or change port?
- TallGuyShort 10y ago
  Why not both? Changing the port is so trivially easy and just moves you out of the way of the majority of low-sophistication automated scans.
  - teddyh 10y ago
    (I repeat my comment from 3 years ago¹:) 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. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312
    - TallGuyShort 10y ago
      Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
      - teddyh 10y ago
        Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451
- arca_vorago 10y ago
  Why not both? Really, first thing is to be on top of your pure iptables config. Even better, is to realize iptables is being deprecated and it's time to learn nftables. No, don't use nice little gui's or menus that abstract the data entry away for you, you need to understand how the firewall actually works. Then port change, SSH hardening in general (key + pass, google pam auth module, etc), then fail2ban, denyhosts, sshguard, tallow, etc. And all that doesn't matter if you don't see any alerts. Need a hids (I like OSSEC) and a good logging system for syslog etc alerts. Number one issue I see with servers (besides badly secured in the first place), is a bunch of logs no one ever actually looked at.
- developer2 10y ago
  If I understand correctly, fail2ban has no effect if you disable the use of passwords. If you force the use of ssh keys, fail2ban becomes completely superfluous. That leaves port change, which is better than nothing. But even better than that is proper firewalling with whitelisted IPs.
- grogenaut 10y ago
  Why is your ssh even open to the Internet?
  - derefr 10y ago
    Why shouldn't it be? Tunnelling connections through an SSH jump-box is no more or less secure than tunnelling through IPSec VPN.
    - grogenaut 10y ago
      It depends on how that jump box is configured, audited, etc. Do you know that your users aren't leaving their keys on laptops that don't have drive encryption, don't have passwords on the keys, etc? Are you forcing 2fa? A lot of these other solutions offer many more deeper enforced protections with better auditing than just an ssh jump box. I'm also not really a fan of leaving things with a shell connection on the net, again part of configuration. If you can root the ssh server, you could likely root a vpn box. Also, I guess, I'm sorry, you're not allowed to ask questions on HN anymore. Thanks for the drive by down vote.
- laumars 10y ago
  fail2ban is easily the better of those two options. However the best solution is to use SSH keys (disable password authentication) and have a small few IPs whitelisted. If password authentication is a must then hopefully you can still go for 2FA (there's a few two factor authentication plugins for PAM). But if you do that then make sure you also stick fail2ban in there as well.
drzaiusapelord 10y ago
Also its worth mentioning most hacking is fairly low effort. If you're using port knocking or non-standard ports you're avoing 99.9999999% of attacks and scans by default. As part of a comprehensive security plan I have no problem with it. I dont deploy any linux servers with ssh listening on 22 nor without fail2ban. Unfortunately, because of the vendors we use things like mandatory VPN or ssh keys only aren't in the cards.
TallGuyShort 10y ago
Security through obscurity isn't bad, it's just not enough. I concur with other reports - just running an EC2 host for a couple of day you'll see login attempts all the time on port 22. Just bots looking for low-hanging fruit. Something as simple as using port 2222 or 122 is going to avoid most of those scans and still be easy for authorized operators to remember. A targeted scan is still going to find it, but if there's some zero day and people just start scanning port 22 on all IPs, you're above much of the water. Still patch the zero-day ASAP, but the obscurity has probably bought you some time and decreased your real-world exposure to attempts.
geggam 10y ago
Why do you log failed connections ? Unless you are doing some sort of analysis where things are coming from its a waste of log space. Turn off password auth, use only keys and log only successful connections. Not exposing ssh means you will forget/not care you are running an old version and eventually this will bite you
laumars 10y ago
I'm struggling to think of any circumstances where "log fatigue" might be a thing. File sizes aren't an issue because auth logs take up such a negligible amount of space compared to the storage capacities we have at our disposal these days. But if your box is really that low capacity then stream your logs to a logging server (or push them to remote storage when you do your log rotate). Realistically you should be shipping your log files anyway. Performance isn't really an issue either as larger auth logs isn't going to make sshd perform any better or worse. There isn't really even a strong argument for the human readability impact as those logs should generally be parsed by robots instead of humans. Be it alerting systems like Nagios, reporting tools like Splunk, or firewall management services like fail2ban; in all cases you wouldn't typically be reading the auth logs in vi unless something has gone very wrong. So I say just keep sshd listening on 22 and instead ensure your system is properly hardened (IP whitelists, SSH keys, etc) with automated processes in place that monitor the logs so you don't have to. Or better yet, don't expose SSH at all.
- laumars 10y ago
  I've been down voted a few times here. Interested to know why. Any care to elaborate on which bit they disagree with please
  - IAmGraydon 10y ago
    No idea in your case, but this place is merciless when it comes to any misinformation. That means that downvotes come easy, but that's also one of the things I like about HN.
    - laumars 10y ago
      That would be fine if any the people down voting were exempt from being misinformed themselves and took the time to explain why they disagreed with the comments they were down voting. But in this case I've been hardening Linux and UNIX servers professionally for years and yet still am completely in the dark about what it was that people disagreed with in my advice. The down vote itself doesn't really bother me so much as the inability for misinformation to be corrected - be that my own error or whoever (which is why I always make a point of replying to people rather than down voting).
derefr 10y ago
(TCP and UDP) ports are for layer-4 protocol negotiation. If you want to distinguish services, you should be giving them separate names/addresses. This is what the second half of an IPv6 address (the "interface" part) is for.
influx 10y ago
The phrase security through obscurity should be applied to algorithms, but it's been co-opted by everyone who knows a little bit about security as a catch phrase applied to everything. Obviously things like passwords are security through obscurity, but the algorithm to hash the passwords should be well known.

webwanderings 10y ago

What's better - Fail2ban or change port?

TallGuyShort 10y ago
Why not both? Changing the port is so trivially easy and just moves you out of the way of the majority of low-sophistication automated scans.
- teddyh 10y ago
  (I repeat my comment from 3 years ago¹:) 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. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312
  - TallGuyShort 10y ago
    Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
    - teddyh 10y ago
      Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451
arca_vorago 10y ago
Why not both? Really, first thing is to be on top of your pure iptables config. Even better, is to realize iptables is being deprecated and it's time to learn nftables. No, don't use nice little gui's or menus that abstract the data entry away for you, you need to understand how the firewall actually works. Then port change, SSH hardening in general (key + pass, google pam auth module, etc), then fail2ban, denyhosts, sshguard, tallow, etc. And all that doesn't matter if you don't see any alerts. Need a hids (I like OSSEC) and a good logging system for syslog etc alerts. Number one issue I see with servers (besides badly secured in the first place), is a bunch of logs no one ever actually looked at.
developer2 10y ago
If I understand correctly, fail2ban has no effect if you disable the use of passwords. If you force the use of ssh keys, fail2ban becomes completely superfluous. That leaves port change, which is better than nothing. But even better than that is proper firewalling with whitelisted IPs.
grogenaut 10y ago
Why is your ssh even open to the Internet?
- derefr 10y ago
  Why shouldn't it be? Tunnelling connections through an SSH jump-box is no more or less secure than tunnelling through IPSec VPN.
  - grogenaut 10y ago
    It depends on how that jump box is configured, audited, etc. Do you know that your users aren't leaving their keys on laptops that don't have drive encryption, don't have passwords on the keys, etc? Are you forcing 2fa? A lot of these other solutions offer many more deeper enforced protections with better auditing than just an ssh jump box. I'm also not really a fan of leaving things with a shell connection on the net, again part of configuration. If you can root the ssh server, you could likely root a vpn box. Also, I guess, I'm sorry, you're not allowed to ask questions on HN anymore. Thanks for the drive by down vote.
laumars 10y ago
fail2ban is easily the better of those two options. However the best solution is to use SSH keys (disable password authentication) and have a small few IPs whitelisted. If password authentication is a must then hopefully you can still go for 2FA (there's a few two factor authentication plugins for PAM). But if you do that then make sure you also stick fail2ban in there as well.

drzaiusapelord 10y ago

Also its worth mentioning most hacking is fairly low effort. If you're using port knocking or non-standard ports you're avoing 99.9999999% of attacks and scans by default. As part of a comprehensive security plan I have no problem with it. I dont deploy any linux servers with ssh listening on 22 nor without fail2ban. Unfortunately, because of the vendors we use things like mandatory VPN or ssh keys only aren't in the cards.

TallGuyShort 10y ago

Security through obscurity isn't bad, it's just not enough. I concur with other reports - just running an EC2 host for a couple of day you'll see login attempts all the time on port 22. Just bots looking for low-hanging fruit. Something as simple as using port 2222 or 122 is going to avoid most of those scans and still be easy for authorized operators to remember. A targeted scan is still going to find it, but if there's some zero day and people just start scanning port 22 on all IPs, you're above much of the water. Still patch the zero-day ASAP, but the obscurity has probably bought you some time and decreased your real-world exposure to attempts.

geggam 10y ago

Why do you log failed connections ? Unless you are doing some sort of analysis where things are coming from its a waste of log space. Turn off password auth, use only keys and log only successful connections. Not exposing ssh means you will forget/not care you are running an old version and eventually this will bite you

laumars 10y ago

I'm struggling to think of any circumstances where "log fatigue" might be a thing. File sizes aren't an issue because auth logs take up such a negligible amount of space compared to the storage capacities we have at our disposal these days. But if your box is really that low capacity then stream your logs to a logging server (or push them to remote storage when you do your log rotate). Realistically you should be shipping your log files anyway. Performance isn't really an issue either as larger auth logs isn't going to make sshd perform any better or worse. There isn't really even a strong argument for the human readability impact as those logs should generally be parsed by robots instead of humans. Be it alerting systems like Nagios, reporting tools like Splunk, or firewall management services like fail2ban; in all cases you wouldn't typically be reading the auth logs in vi unless something has gone very wrong. So I say just keep sshd listening on 22 and instead ensure your system is properly hardened (IP whitelists, SSH keys, etc) with automated processes in place that monitor the logs so you don't have to. Or better yet, don't expose SSH at all.

laumars 10y ago
I've been down voted a few times here. Interested to know why. Any care to elaborate on which bit they disagree with please
- IAmGraydon 10y ago
  No idea in your case, but this place is merciless when it comes to any misinformation. That means that downvotes come easy, but that's also one of the things I like about HN.
  - laumars 10y ago
    That would be fine if any the people down voting were exempt from being misinformed themselves and took the time to explain why they disagreed with the comments they were down voting. But in this case I've been hardening Linux and UNIX servers professionally for years and yet still am completely in the dark about what it was that people disagreed with in my advice. The down vote itself doesn't really bother me so much as the inability for misinformation to be corrected - be that my own error or whoever (which is why I always make a point of replying to people rather than down voting).

derefr 10y ago

(TCP and UDP) ports are for layer-4 protocol negotiation. If you want to distinguish services, you should be giving them separate names/addresses. This is what the second half of an IPv6 address (the "interface" part) is for.

influx 10y ago

The phrase security through obscurity should be applied to algorithms, but it's been co-opted by everyone who knows a little bit about security as a catch phrase applied to everything. Obviously things like passwords are security through obscurity, but the algorithm to hash the passwords should be well known.