15 ms·

It’s an useless anecdote because SSH bruteforce attempts are not a threat and cost you nothing.

elmo2you 6y ago
> It’s an useless anecdote because SSH bruteforce attempts are not a threat and cost you nothing. I can say from personal experience that this anecdote is both accurate (20 years ago and up till today) and meaningful. No idea where you get this notion that brute force attack are no threat or without cost. They certainly do pose a security risk (takes only one insufficiently trained employee/intern for a potential breach) and they certainly come at a cost (way beyond dirty just logs).
- fmajid 6y ago
  Botnets and fast networking stacks like DPDK have made port scanning the entire Internet a much more viable proposition than 20 years ago. Depending on your sshd settings you can be effectively locked out of your machine by a brute-force attack. Running on IPv6 and/or having a secondary sshd instance that only accepts connections from whitelisted IPs is cheap insurance.
  - mercer 6y ago
    That doesn't invalidate the observation (which I share) that these attempts are almost 0 when using a different port. It reduces logspam and if I start getting lots of brute force attempts on my non-standard port, this is useful and meaningful information (someone cares enough to do this).
  - elmo2you 6y ago
    > Botnets and fast networking stacks like DPDK have made port scanning the entire Internet a much more viable proposition than 20 years ago True indeed, yet even today I have seen little evidence of scanning beyond standard ports (pretty much the same as in the past). Criminals are opportunistic by default and tend to go for low hanging fruit (standard ports, with standard server config). I certainly did see in increase on standard ports. Even while full range scanning has become more feasible, I have not seen much evidence of its use.
- iso1631 6y ago
  > takes only one insufficiently trained employee/intern for a potential breach How? If they've leaked their key, why do you assume the port hasn't leaked too? On the other hand if they haven't leaked their key how would they get in? Or are you allowing password authentication like it's 1999?
  - elmo2you 6y ago
    > Or are you allowing password authentication like it's 1999? That is assuming you have such authority or technical means. If you're maintaining systems for a company, there's a good change that the product vendor simply won't allow fucking around with their system like that (ergo: yes, in practice you are indeed stuck with your 1999 authentication). I'm not saying that it is good security (that's why layers security is often paramount), but it is situation I've encountered more than a few times. Great for you, if you are GOD on all the systems you work with. Even then, your client/employer might simply tell you to stuff your objections and accept the bad authentication policy, because to them the risks are simply not worth the business disruption. I totally agree that is a flawed argument. But decisions usually aren't always (if ever) called on valid arguments. Good for you, if you are in a position where you never had to deal with such real life situations.
    - deckard1 6y ago
      Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth? I'm a software engineer, so if my company gets hacked via ssh that's really not my problem. Worrying about such things would make me a busybody. But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work. They will get hacked and you will be the guy that gets blamed.
      - elmo2you 6y ago
        > Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth? First, you'll have to separate two things here. One is the technical ability to control sshd, the second whether a company will allow you to tinker with the auth policy (whether that is password login, password login with only strong passwords, or rsa/ecdsa key access only). The latter has nothing to do with control and only with what decision makers allow you to do (that sometimes is a large product vendor, not allowing anything beyond what they ship). If you work in a place where you have full control over the systems you work on, great for you. I can ensure you that it is not the norm (unless we're talking about hobby projects or projects with exclusive personal ownership). As for the technical aspect, keep in mind that changing the public facing ssh port might not even be done on the host itself, but e.g. in port forwarding table in a router/firewall. This might not even always happen because it's technically impossible to do it on the box itself. I'm pretty certain that tinkering with a box is regularly discouraged (especially if it is managed by some orchestration or vendor specific control/update tool), while effectively the same can be done by changing a router/firewall. There's a lot more things to be said about that, but please take it from me that hacking around in a systems you have not build yourself isn't always a bright idea (and it happens to be a very common situation). > But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work. That's an interesting theory, but frankly not how I think the real world (usually) works. As a system admin you are there to solve problems for a client or employer. You can (and should) of course always warn for potential dangers, but refusing work or quitting a job/assingment because you're not getting full control over a system .. good luck with that. It is simply not an acceptable position in many situation. You must be in really high demand if you want to pull stunts like those and still have any work after a while. Maybe it works different in software engineering land, but I highly doubt it. When was the last time you quit a job, because you preferred a different library or framework over the one your superiors/client dictated? Please don't get me wrong. On a personal level I'm very principled about what I choose to work on or with (and what I refuse to take part of). But at the end of the day we are professionals, here to solve problems. If we can and a client/employers is willing to accept the risks of an imperfect solution that fits in their requirements, it ultimately is their call and responsibility. All within reason, of course.
selfhoster11 6y ago
They cause some real work because of the log noise they create. It's easier to see targeted SSH attacks if all the undirected attacks are filtered away.
- gruez 6y ago
  What would be indications of "targeted" ssh attacks, and what can you do in response?
  - sascha_sl 6y ago
    The fact that someone bothered to scan the entire range (or find your port at random) might indicate that they're specifically targeting you, and just being aware of that is an upside.
    - gruez 6y ago
      >and just being aware of that is an upside. but what can you realistically do with that knowledge?
      - BLKNSLVR 6y ago
        Infinitely more than you can do without that knowledge
        ryanlol 6y ago
        Give some examples then. Knowing that someone is targetting you shouldn’t change anything, you should be ready regardless.
        sascha_sl 6y ago
        It shouldn't, but it does. Many smaller companies driven by business people, where maybe tech is just seen as a necessity on the side need a narrative like "people are trying to get in and if they do it's going to be a disaster" to take security seriously. Then or at the point where the disaster strikes. I'm not really sure why this point was voted down below either; just because you work for someone who takes security seriously (at least to the point where it's insurance-satisfyingly safe) does not mean everyone does. Years ago I worked at a small agency and every bit of time I spent had to be justified and produce tangible/visible results. "But is anyone really going to try to hack this local business" was a question I actually had to answer, since most other employees were creatives.
icedchai 6y ago
They fill the logs with noise. That's "something." I finally set up fail2ban a while back... it works wonders.
- gruez 6y ago
  Do people even read the logs? What value does it add compared to just monitoring successful logins?
  - cedilla 6y ago
    There's a lot of value. For example, if you see failed logins against random user names like "dbadmin" or "root" it's likely just random scanning, but what if suddenly lots and lots of valid user names appear?
    - gruez 6y ago
      >but what if suddenly lots and lots of valid user names appear? then what are you going to do?
      - sokoloff 6y ago
        At a minimum, spend some of my limited time and attention on this issue rather than the 100s of other things that might be clamoring for my time.
        wbl 6y ago
        What are you going to do to solve that issue?
      - cedilla 6y ago
        Well that would highly depend on what I'm seeing. If it's a single user there might be an attack on the way against that user. If it's multiple users, there might have been a compromise of some credentials. It's definitely something you need to investigate.

> It’s an useless anecdote because SSH bruteforce attempts are not a threat and cost you nothing. I can say from personal experience that this anecdote is both accurate (20 years ago and up till today) and meaningful. No idea where you get this notion that brute force attack are no threat or without cost. They certainly do pose a security risk (takes only one insufficiently trained employee/intern for a potential breach) and they certainly come at a cost (way beyond dirty just logs).

fmajid 6y ago
Botnets and fast networking stacks like DPDK have made port scanning the entire Internet a much more viable proposition than 20 years ago. Depending on your sshd settings you can be effectively locked out of your machine by a brute-force attack. Running on IPv6 and/or having a secondary sshd instance that only accepts connections from whitelisted IPs is cheap insurance.
- mercer 6y ago
  That doesn't invalidate the observation (which I share) that these attempts are almost 0 when using a different port. It reduces logspam and if I start getting lots of brute force attempts on my non-standard port, this is useful and meaningful information (someone cares enough to do this).
- elmo2you 6y ago
  > Botnets and fast networking stacks like DPDK have made port scanning the entire Internet a much more viable proposition than 20 years ago True indeed, yet even today I have seen little evidence of scanning beyond standard ports (pretty much the same as in the past). Criminals are opportunistic by default and tend to go for low hanging fruit (standard ports, with standard server config). I certainly did see in increase on standard ports. Even while full range scanning has become more feasible, I have not seen much evidence of its use.
iso1631 6y ago
> takes only one insufficiently trained employee/intern for a potential breach How? If they've leaked their key, why do you assume the port hasn't leaked too? On the other hand if they haven't leaked their key how would they get in? Or are you allowing password authentication like it's 1999?
- elmo2you 6y ago
  > Or are you allowing password authentication like it's 1999? That is assuming you have such authority or technical means. If you're maintaining systems for a company, there's a good change that the product vendor simply won't allow fucking around with their system like that (ergo: yes, in practice you are indeed stuck with your 1999 authentication). I'm not saying that it is good security (that's why layers security is often paramount), but it is situation I've encountered more than a few times. Great for you, if you are GOD on all the systems you work with. Even then, your client/employer might simply tell you to stuff your objections and accept the bad authentication policy, because to them the risks are simply not worth the business disruption. I totally agree that is a flawed argument. But decisions usually aren't always (if ever) called on valid arguments. Good for you, if you are in a position where you never had to deal with such real life situations.
  - deckard1 6y ago
    Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth? I'm a software engineer, so if my company gets hacked via ssh that's really not my problem. Worrying about such things would make me a busybody. But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work. They will get hacked and you will be the guy that gets blamed.
    - elmo2you 6y ago
      > Not sure what you're arguing here. You either have control over sshd or you don't. Or are you really suggesting you can change the port of sshd but aren't allowed to disable password auth? First, you'll have to separate two things here. One is the technical ability to control sshd, the second whether a company will allow you to tinker with the auth policy (whether that is password login, password login with only strong passwords, or rsa/ecdsa key access only). The latter has nothing to do with control and only with what decision makers allow you to do (that sometimes is a large product vendor, not allowing anything beyond what they ship). If you work in a place where you have full control over the systems you work on, great for you. I can ensure you that it is not the norm (unless we're talking about hobby projects or projects with exclusive personal ownership). As for the technical aspect, keep in mind that changing the public facing ssh port might not even be done on the host itself, but e.g. in port forwarding table in a router/firewall. This might not even always happen because it's technically impossible to do it on the box itself. I'm pretty certain that tinkering with a box is regularly discouraged (especially if it is managed by some orchestration or vendor specific control/update tool), while effectively the same can be done by changing a router/firewall. There's a lot more things to be said about that, but please take it from me that hacking around in a systems you have not build yourself isn't always a bright idea (and it happens to be a very common situation). > But if you're a system admin and can't properly do your job, then I would seriously start looking for a new place to work. That's an interesting theory, but frankly not how I think the real world (usually) works. As a system admin you are there to solve problems for a client or employer. You can (and should) of course always warn for potential dangers, but refusing work or quitting a job/assingment because you're not getting full control over a system .. good luck with that. It is simply not an acceptable position in many situation. You must be in really high demand if you want to pull stunts like those and still have any work after a while. Maybe it works different in software engineering land, but I highly doubt it. When was the last time you quit a job, because you preferred a different library or framework over the one your superiors/client dictated? Please don't get me wrong. On a personal level I'm very principled about what I choose to work on or with (and what I refuse to take part of). But at the end of the day we are professionals, here to solve problems. If we can and a client/employers is willing to accept the risks of an imperfect solution that fits in their requirements, it ultimately is their call and responsibility. All within reason, of course.

selfhoster11 6y ago

They cause some real work because of the log noise they create. It's easier to see targeted SSH attacks if all the undirected attacks are filtered away.

gruez 6y ago
What would be indications of "targeted" ssh attacks, and what can you do in response?
- sascha_sl 6y ago
  The fact that someone bothered to scan the entire range (or find your port at random) might indicate that they're specifically targeting you, and just being aware of that is an upside.
  - gruez 6y ago
    >and just being aware of that is an upside. but what can you realistically do with that knowledge?
    - BLKNSLVR 6y ago
      Infinitely more than you can do without that knowledge
      - ryanlol 6y ago
        Give some examples then. Knowing that someone is targetting you shouldn’t change anything, you should be ready regardless.
        sascha_sl 6y ago
        It shouldn't, but it does. Many smaller companies driven by business people, where maybe tech is just seen as a necessity on the side need a narrative like "people are trying to get in and if they do it's going to be a disaster" to take security seriously. Then or at the point where the disaster strikes. I'm not really sure why this point was voted down below either; just because you work for someone who takes security seriously (at least to the point where it's insurance-satisfyingly safe) does not mean everyone does. Years ago I worked at a small agency and every bit of time I spent had to be justified and produce tangible/visible results. "But is anyone really going to try to hack this local business" was a question I actually had to answer, since most other employees were creatives.

icedchai 6y ago

They fill the logs with noise. That's "something." I finally set up fail2ban a while back... it works wonders.

gruez 6y ago
Do people even read the logs? What value does it add compared to just monitoring successful logins?
- cedilla 6y ago
  There's a lot of value. For example, if you see failed logins against random user names like "dbadmin" or "root" it's likely just random scanning, but what if suddenly lots and lots of valid user names appear?
  - gruez 6y ago
    >but what if suddenly lots and lots of valid user names appear? then what are you going to do?
    - sokoloff 6y ago
      At a minimum, spend some of my limited time and attention on this issue rather than the 100s of other things that might be clamoring for my time.
      - wbl 6y ago
        What are you going to do to solve that issue?
    - cedilla 6y ago
      Well that would highly depend on what I'm seeing. If it's a single user there might be an attack on the way against that user. If it's multiple users, there might have been a compromise of some credentials. It's definitely something you need to investigate.