15 ms·

As sad as it makes me, blocking large parts of the world that you don't expect to connect from via a list of CIDR blocks is an incredibly effective way to secur

As sad as it makes me, blocking large parts of the world that you don't expect to connect from via a list of CIDR blocks is an incredibly effective way to secure anything and reduce logspam. I personally use nft blackhole [1], which I can recommend for its ease of use. [1] https://github.com/tomasz-c/nft-blackhole https://github.com/tomasz-c/nft-blackhole

traceroute66 5y ago
Absolutely pointless for two major reasons: 1) Many attackers "hide" behind cloud services. So whatcha gonna do when your primary attack vector is AWS EC2 instances ? Block AWS CIDR ranges ? 2) With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries.
- uniqueuid 5y ago
  Looking at my case, I wouldn't call this pointles, since it removed > 95% of login attempts. Sure, IP address block fragmentation will remove some value, but you'd still kill a lot of juicy compromisable home IP addresses in those countries. Regarding cloud providers - well, I hope they have some automated systems to clamp down, since it's against their own interest to serve as vectors.
  - traceroute66 5y ago
    > since it removed > 95% of login attempts If you use certificate authentication and disable password authentication then you've killed off 100% of unauthorised attempts right off the bat. There really isn't much need to do more than that, its the world's easiest security fix.
    - uniqueuid 5y ago
      Sure, I don't think we actually disagree too much. Leaving password auth on is simply negligent. That said, blocking all countries that you don't expect to talk to is the world's second easiest security fix, and protects other processes you might have running, and other unknown vectors that might be worse, such as heartbleed.
      - traceroute66 5y ago
        > That said, blocking all countries that you don't expect to talk to All fun and games until you find yourself on travelling in Asia and you need to connect back home and forgot you blocked half the world. As for "other processes", we're talking about SSH on this thread. If you've got other processes then that falls into on-host/upstream filtering via firewall area of security. Regarding "unknown vectors", as I said, patching, no amount of IP blocking will help you with that. If you really want to talk about "world's second easiest security fix" for SSH, that would be running a super-hardened bastion host and using SSH ProxyJump.
        kijin 5y ago
        > All fun and games until you find yourself on travelling in Asia Leave a cheap droplet running somewhere, whitelist its IP, and SSH through it. I'm in Asia and I do exactly that with my U.S.-based servers. Actually, I've blocked all of the rest of the world as well, except the proxy droplet. It's like a global bastion host. There's no legitimate reason for anyone else on this planet to try and SSH into those boxes.
      - Enginerrrd 5y ago
        >Leaving password auth on is simply negligent I know this is an oft-repeated trope, but I disagree. If you are whitelisting users for ssh and use secure passwords, you're really quite safe. Whereas if you lose access to your device with ssh keys, you're locked out with no hope of getting back in. In what sense is it "negligent"? I feel like this is just an example of people constantly repeating popular advice without really considering it, like happened with bad password expiration policies. Like, I get that an ssh key probably has more entropy, but there is such a thing as good enough. My ssh password for my server is mixed case with numbers, and 20+ characters. Good luck cracking it.
        anjbe 5y ago
        I’ve seen a compromised machine whose sshd had been replaced with a trojan that saved all passwords entered into it. Some investigation revealed that sshd modification to be part of a standard script kiddie toolkit. Are you 100% sure that every machine you log into remotely with your very strong password isn’t logging that password? That’s one advantage of keys.
    - Damogran6 5y ago
      When this topic (always) comes up, somebody points out that moving the ports isn't security...but it kinda is, because if you suddenly see an uptick in logging, you know someone cares enough to FIND your port, and then POINT SOMETHING AT the port, and in the meantime it reduces heat and power and disk wear.
      - yellowapple 5y ago
        > and in the meantime it reduces heat and power and disk wear. If drive-by SSH attempts - even a large number of them - are enough to have a noticeable impact on heat/power/wear, then you should probably consider, you know, not putting hardware from 1997 on the Internet. Really doesn't take that much energy on hardware built during the current century to reject an authentication attempt and log it.
        Damogran6 5y ago
        Call it a feng shui thing.
      - anjbe 5y ago
        > it reduces heat and power and disk wear. Measurably?
      - JimDabell 5y ago
        Moving the port reduces security. Port 22 is a privileged port. Standard users can’t listen on port 22. If you move the port to 2222 or wherever, then if an attacker with local access can get sshd to crash, they can run their own sshd instead. If you left the port as the default, they wouldn’t be able to do that without chaining it with a privilege escalation attack. But because you changed the port, you disabled this security feature and it could become a privilege escalation attack.
        throwaway2048 5y ago
        Its pretty trivial to disable the ability of users to listen on certain ports higher than 1024 with a firewall config.
    - gjs278 5y ago
  - angry_octet 5y ago
    When will people realise that removing login attempts is meaningless security theatre? It's like when some CIO or politican says "we've been attacking 29 Million times today". This is why companies pay for https://www.greynoise.io/ https://www.greynoise.io/ so they don't need to worry about meaningless stuff.
    - throwaway2048 5y ago
      Its not about stopping brainless botnets from actually logging in with root:toor 9 million times, its about removing clutter from your logs so you can more easily tell when something actually dangerous is happening.
  - JimDabell 5y ago
    > it removed > 95% of login attempts. This is the wrong number to look at. The relevant number is the login attempts that would have otherwise been successful. And if you’ve disabled passwords, that will be 0.
    - beagle3 5y ago
      If failed login attempts go from 0 to 1000 in a single day, that’s very interesting and likely means you are being specifically targeted. You’d notice that if your ssh port is, say, 7731. With exactly the same targeting, on port 22, you will see a rise from 100,000 to 101,000 which will likely not notice, despite it being as dangerous. Changing the port does not make a targeted attack any more or less likely, or any more or less successful. But it does make it much more visible - and that’s useful for security as well. A fault in your reasoning assumes that you know exactly what the attacker does - a credential attack; indeed this is the most common. However, maybe they are trying to exploit a zero day timing attack, requiring multiple attempts? Or some reconnaissance that lets them figure out valid usernames? The different port won’t stop these of course, but will make the attempts stand out - which may allow you to stop them if noticed in time, or at least understand them in retrospect.
- R0b0t1 5y ago
  > Block AWS CIDR ranges? Since I don't log in from there, yes sure? And if I'm hosting on AWS I can proxy through an AWS resident host. Same with any other cloud provider.
  - throwawayboise 5y ago
    Yep. It has been a long time since I ever needed to provide a wide-open SSH service. By far the normal case is to allow login from one or a handful of IP addresses, or maybe a /24. Do this and your SSH log noise drops to zero.
    - bombcar 5y ago
      It’s amusing that the people who howl loudly that blocking foreign IP ranges is an absolute failure have zero problems with blocking all IPs but a certain few. I’ve yet to determine where the tipping point is.
- urda 5y ago
  > Absolutely pointless My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.
  - awsthro00945 5y ago
    "My logs and firewall are less cluttered" is not at all the correct metric to measure the security of your box. IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker. You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.
    - nyolfen 5y ago
      my understanding is that spoofing only works for sessionless protocols or situations -- eg a single udp packet or a series of packets that do not rely on any kind of response, since the response (like a tcp ack, or a dh handshake) is routed to the spoofed address. this would not apply to ssh. what contexts are you thinking of?
      - ianhawes 5y ago
        Yeah, the parent comment is not accurate. IP spoofing is only possible if you control the entire L4 stack.
        5y ago
- _jal 5y ago
  > Block AWS CIDR ranges ? I do, actually. There is zero reason for anyone to use EC2 instances to contact my personal public machines. > With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries. And there will continue to be tracking of who is using which blocks, so there should be no reason for error rates to creep up too much. You need to think about the specifics of your situation, not just blindly follow "best practices". For my personal public machines, I do know, with a high degree of specificity, who should be doing what, and from where. I exploit that to place limits on who can talk to them, and it provides a lot of benefit. If you're running a large public service, you're in starting from a very different stance. For my $dayjob, there are good reasons why customers might contact us from a country where we don't yet offer service, so we can't wall them off. But we do occasionally use geoblocking more selectively when we're under attack.

traceroute66 5y ago

Absolutely pointless for two major reasons: 1) Many attackers "hide" behind cloud services. So whatcha gonna do when your primary attack vector is AWS EC2 instances ? Block AWS CIDR ranges ? 2) With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries.

uniqueuid 5y ago
Looking at my case, I wouldn't call this pointles, since it removed > 95% of login attempts. Sure, IP address block fragmentation will remove some value, but you'd still kill a lot of juicy compromisable home IP addresses in those countries. Regarding cloud providers - well, I hope they have some automated systems to clamp down, since it's against their own interest to serve as vectors.
- traceroute66 5y ago
  > since it removed > 95% of login attempts If you use certificate authentication and disable password authentication then you've killed off 100% of unauthorised attempts right off the bat. There really isn't much need to do more than that, its the world's easiest security fix.
  - uniqueuid 5y ago
    Sure, I don't think we actually disagree too much. Leaving password auth on is simply negligent. That said, blocking all countries that you don't expect to talk to is the world's second easiest security fix, and protects other processes you might have running, and other unknown vectors that might be worse, such as heartbleed.
    - traceroute66 5y ago
      > That said, blocking all countries that you don't expect to talk to All fun and games until you find yourself on travelling in Asia and you need to connect back home and forgot you blocked half the world. As for "other processes", we're talking about SSH on this thread. If you've got other processes then that falls into on-host/upstream filtering via firewall area of security. Regarding "unknown vectors", as I said, patching, no amount of IP blocking will help you with that. If you really want to talk about "world's second easiest security fix" for SSH, that would be running a super-hardened bastion host and using SSH ProxyJump.
      - kijin 5y ago
        > All fun and games until you find yourself on travelling in Asia Leave a cheap droplet running somewhere, whitelist its IP, and SSH through it. I'm in Asia and I do exactly that with my U.S.-based servers. Actually, I've blocked all of the rest of the world as well, except the proxy droplet. It's like a global bastion host. There's no legitimate reason for anyone else on this planet to try and SSH into those boxes.
    - Enginerrrd 5y ago
      >Leaving password auth on is simply negligent I know this is an oft-repeated trope, but I disagree. If you are whitelisting users for ssh and use secure passwords, you're really quite safe. Whereas if you lose access to your device with ssh keys, you're locked out with no hope of getting back in. In what sense is it "negligent"? I feel like this is just an example of people constantly repeating popular advice without really considering it, like happened with bad password expiration policies. Like, I get that an ssh key probably has more entropy, but there is such a thing as good enough. My ssh password for my server is mixed case with numbers, and 20+ characters. Good luck cracking it.
      - anjbe 5y ago
        I’ve seen a compromised machine whose sshd had been replaced with a trojan that saved all passwords entered into it. Some investigation revealed that sshd modification to be part of a standard script kiddie toolkit. Are you 100% sure that every machine you log into remotely with your very strong password isn’t logging that password? That’s one advantage of keys.
  - Damogran6 5y ago
    When this topic (always) comes up, somebody points out that moving the ports isn't security...but it kinda is, because if you suddenly see an uptick in logging, you know someone cares enough to FIND your port, and then POINT SOMETHING AT the port, and in the meantime it reduces heat and power and disk wear.
    - yellowapple 5y ago
      > and in the meantime it reduces heat and power and disk wear. If drive-by SSH attempts - even a large number of them - are enough to have a noticeable impact on heat/power/wear, then you should probably consider, you know, not putting hardware from 1997 on the Internet. Really doesn't take that much energy on hardware built during the current century to reject an authentication attempt and log it.
      - Damogran6 5y ago
        Call it a feng shui thing.
    - anjbe 5y ago
      > it reduces heat and power and disk wear. Measurably?
    - JimDabell 5y ago
      Moving the port reduces security. Port 22 is a privileged port. Standard users can’t listen on port 22. If you move the port to 2222 or wherever, then if an attacker with local access can get sshd to crash, they can run their own sshd instead. If you left the port as the default, they wouldn’t be able to do that without chaining it with a privilege escalation attack. But because you changed the port, you disabled this security feature and it could become a privilege escalation attack.
      - throwaway2048 5y ago
        Its pretty trivial to disable the ability of users to listen on certain ports higher than 1024 with a firewall config.
  - gjs278 5y ago
- angry_octet 5y ago
  When will people realise that removing login attempts is meaningless security theatre? It's like when some CIO or politican says "we've been attacking 29 Million times today". This is why companies pay for https://www.greynoise.io/ https://www.greynoise.io/ so they don't need to worry about meaningless stuff.
  - throwaway2048 5y ago
    Its not about stopping brainless botnets from actually logging in with root:toor 9 million times, its about removing clutter from your logs so you can more easily tell when something actually dangerous is happening.
- JimDabell 5y ago
  > it removed > 95% of login attempts. This is the wrong number to look at. The relevant number is the login attempts that would have otherwise been successful. And if you’ve disabled passwords, that will be 0.
  - beagle3 5y ago
    If failed login attempts go from 0 to 1000 in a single day, that’s very interesting and likely means you are being specifically targeted. You’d notice that if your ssh port is, say, 7731. With exactly the same targeting, on port 22, you will see a rise from 100,000 to 101,000 which will likely not notice, despite it being as dangerous. Changing the port does not make a targeted attack any more or less likely, or any more or less successful. But it does make it much more visible - and that’s useful for security as well. A fault in your reasoning assumes that you know exactly what the attacker does - a credential attack; indeed this is the most common. However, maybe they are trying to exploit a zero day timing attack, requiring multiple attempts? Or some reconnaissance that lets them figure out valid usernames? The different port won’t stop these of course, but will make the attempts stand out - which may allow you to stop them if noticed in time, or at least understand them in retrospect.
R0b0t1 5y ago
> Block AWS CIDR ranges? Since I don't log in from there, yes sure? And if I'm hosting on AWS I can proxy through an AWS resident host. Same with any other cloud provider.
- throwawayboise 5y ago
  Yep. It has been a long time since I ever needed to provide a wide-open SSH service. By far the normal case is to allow login from one or a handful of IP addresses, or maybe a /24. Do this and your SSH log noise drops to zero.
  - bombcar 5y ago
    It’s amusing that the people who howl loudly that blocking foreign IP ranges is an absolute failure have zero problems with blocking all IPs but a certain few. I’ve yet to determine where the tipping point is.
urda 5y ago
> Absolutely pointless My logs and firewall greatly disagree. Please avoid comments on HN like this where it boxes solutions into a "my way or the highway" result, when it has been demonstrated to you here it's not "Absolutely pointless". Security is the layering of multiple solutions and defenses to protect your assets, there is no magic bullet or single solution.
- awsthro00945 5y ago
  "My logs and firewall are less cluttered" is not at all the correct metric to measure the security of your box. IP address spoofing is a thing. Blocking CIDR ranges might protect you from low-effort, drive-by botnets that constantly scan the entire internet (which all should be completely mitigated by using certificate based auth anyway), but blocking based on IP address is absolutely not an effective control against a determined hacker. You must consider your threat model. For your personal instance that you host hobby things on, you probably won't be targeted via IP spoofing. For any type of company, you should not be relying on CIDR blocking as part of your security layers. CIDR blocking is only effective at reducing the clutter of your logs, which is a convenience, not a security control. The real security control is using proper auth methods, which are so easy to do at this point that it's ridiculous for even a hobbyist to not do them.
  - nyolfen 5y ago
    my understanding is that spoofing only works for sessionless protocols or situations -- eg a single udp packet or a series of packets that do not rely on any kind of response, since the response (like a tcp ack, or a dh handshake) is routed to the spoofed address. this would not apply to ssh. what contexts are you thinking of?
    - ianhawes 5y ago
      Yeah, the parent comment is not accurate. IP spoofing is only possible if you control the entire L4 stack.
      - 5y ago
_jal 5y ago
> Block AWS CIDR ranges ? I do, actually. There is zero reason for anyone to use EC2 instances to contact my personal public machines. > With IPv4 exhaustion increasing numbers of people will be using IPv4 allocations across geographic boundaries. And there will continue to be tracking of who is using which blocks, so there should be no reason for error rates to creep up too much. You need to think about the specifics of your situation, not just blindly follow "best practices". For my personal public machines, I do know, with a high degree of specificity, who should be doing what, and from where. I exploit that to place limits on who can talk to them, and it provides a lot of benefit. If you're running a large public service, you're in starting from a very different stance. For my $dayjob, there are good reasons why customers might contact us from a country where we don't yet offer service, so we can't wall them off. But we do occasionally use geoblocking more selectively when we're under attack.