3 ms·

> There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. The point is that if a vulnerability gets disc

by philh 15y ago

> There's this person you are thinking of who is actually vulnerable to something an SSH scanner is looking for. The point is that if a vulnerability gets discovered in future, he doesn't want to be on a list of "servers that are now vulnerable". When he hears about the exploit, he'll fix it. But if the bad guys hear about it first, not being on that list is useful obscurity. > If you think I'm full of it on this topic, just say so. You're probably not full of it, but it's hard to extract much value from your comments.

tptacek 15y ago
Once every ~4-6 years or so someone will find a vulnerability in OpenSSH. When that happens, the list of vulnerable servers is "everyone running SSH". Maybe there's some attacker that is keeping a database of every SSH server on the Internet, but I doubt it. I don't think it's hard to extract value from my comments. I think you don't want the value that's in my comment, because that value is "you are spending time and energy doing something that isn't providing the security benefit you think it is", and that's not fun to hear.
- epistasis 15y ago
  You don't think an attacker would hold on to the results of scanning for SSH servers? They just scan for days then throw it all away? I had absolutely no idea what you were trying to say with your first reply to me. It's only by digging through lots of your other replies that I got the hint that it may be an attempt at sarcasm, but I'm still not sure. You are not supporting your assertions, or even making your assertions clear.
  - tptacek 15y ago
    Yes. They scan for days and throw away all the results that aren't "machine I can log into".
- pmylund 15y ago
  If a company with a large and complex web property, e.g. Microsoft.com or Google.com, asked you if it mattered whether they allow DNS AXFR, what would your answer be?
  - tptacek 15y ago
    Nobody enables AXFR. AXFR isn't a default. I wouldn't advise someone to override that default. If one of my clients then asked me, "because I don't enable AXFR, is wide-open-dev-machine.customer.com safer?", I would say "no, it is not".
    - pmylund 15y ago
      So you agree that disabling AXFR, if AXFR is enabled, is a good idea? Could you explain why you think wide-open-dev-machine.customer.com is NOT safer without AXFR (assuming it blocks robots, and the web server only serves the site for "wide-open-dev-machine.customer.com")? I'm just trying to understand how it could not be considered beneficial in any way, however much (which is what you're claiming).
      - tptacek 15y ago
        I don't have to think about this much because nobody has AXFR enabled. If you had AXFR enabled, I would in fact tell you to turn it off. It isn't an operational win (unlike SSH on port 22), so what possible reason could there be for enabling it? wide-open-dev-machine isn't safer because there's a whole variety of ways to learn about it without AXFR. For what it's worth, I would not flag a customer for running SSH on port 22; I would certainly flag a customer for having port 22 exposed where it didn't need to be; for most SaaS/ASP-type companies, I'd flag them for having more than one SSH port exposed, and I'd recommend that they invest in a VPN instead of exposed SSH.
        pmylund 15y ago
        I think there are far more nameservers allowing AXFR than you think. Write a little app that attempts a zone transfer for the top 1000 of the Alexa list (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and see for yourself. (Note to anyone reading: Please don't try this before you've checked if it's legal in your state/country or not.) Could you explain how you would learn about wide-open-dev-machine as simply as by using AXFR in your scenario (you aren't on the network, so no *casting). Edit: "so what possible reason could there be for enabling it?" is eerily similar to my message :)
- philh 15y ago
  > When that happens, the list of vulnerable servers is "everyone running SSH". Agreed, but in between "bad guys discover vulnerability" and "he fixes vulnerability", can't he reduce the chance that he will be attacked by having SSH on a different port? It won't stop someone who's targeting him, but it might keep him off the radar of someone who's just looking for easy targets. From another post: > "32,000" sounds like a large number on a message board, but write an evented port scanner† and see how big that number really is. So is your claim that anyone looking for vulnerable SSH servers will scan every port they can on a given IP, rather than just looking at port 22 and moving on? > I don't think it's hard to extract value from my comments. With respect, you are not the best judge of this. (I personally don't administer a server; if anything, I want you to be correct because that will save me effort if I ever do.) When I read your posts, I learn your opinion, but I often can't work out why you hold that opinion. Possibly you just write your posts under assumptions that seem obvious to you, but not to others.
  - tptacek 15y ago
    One assumption I may have that needs to be stated: OpenSSH vulnerabilities are infrequent, bordering on rare. The discovery of a remote auth bypass or remote code exec flaw in OpenSSH is a big deal; a "drop everything and block all access to port 22" deal. Another assumption: the gap between the rumor of an OpenSSH remote and the time it hits "people so dumb as to burn the exploit on a scanner" is large; probably weeks, possibly months. Another assumption: anyone running OpenSSH has turned off the dumb stuff, like password authentication. If you are using passwords to log into SSH servers, you have problems port numbers can't fix. The only attacker SSH-on-port-51122 defends against is the one so far back in line for SSH exploits that she'll stick it on the business end of an Internet-wide scanner. That vulnerability is worth many tens of thousands of dollars. Nobody that has it in the window between announce and "public downloadable exploit" is scanning with it. Finally, you really should only have one machine exposed to SSH, if that. If you have to manage 50 servers, set up 1 bastion server and relay through it.

by philh 15y ago

tptacek 15y ago

Once every ~4-6 years or so someone will find a vulnerability in OpenSSH. When that happens, the list of vulnerable servers is "everyone running SSH". Maybe there's some attacker that is keeping a database of every SSH server on the Internet, but I doubt it. I don't think it's hard to extract value from my comments. I think you don't want the value that's in my comment, because that value is "you are spending time and energy doing something that isn't providing the security benefit you think it is", and that's not fun to hear.

epistasis 15y ago
You don't think an attacker would hold on to the results of scanning for SSH servers? They just scan for days then throw it all away? I had absolutely no idea what you were trying to say with your first reply to me. It's only by digging through lots of your other replies that I got the hint that it may be an attempt at sarcasm, but I'm still not sure. You are not supporting your assertions, or even making your assertions clear.
- tptacek 15y ago
  Yes. They scan for days and throw away all the results that aren't "machine I can log into".
pmylund 15y ago
If a company with a large and complex web property, e.g. Microsoft.com or Google.com, asked you if it mattered whether they allow DNS AXFR, what would your answer be?
- tptacek 15y ago
  Nobody enables AXFR. AXFR isn't a default. I wouldn't advise someone to override that default. If one of my clients then asked me, "because I don't enable AXFR, is wide-open-dev-machine.customer.com safer?", I would say "no, it is not".
  - pmylund 15y ago
    So you agree that disabling AXFR, if AXFR is enabled, is a good idea? Could you explain why you think wide-open-dev-machine.customer.com is NOT safer without AXFR (assuming it blocks robots, and the web server only serves the site for "wide-open-dev-machine.customer.com")? I'm just trying to understand how it could not be considered beneficial in any way, however much (which is what you're claiming).
    - tptacek 15y ago
      I don't have to think about this much because nobody has AXFR enabled. If you had AXFR enabled, I would in fact tell you to turn it off. It isn't an operational win (unlike SSH on port 22), so what possible reason could there be for enabling it? wide-open-dev-machine isn't safer because there's a whole variety of ways to learn about it without AXFR. For what it's worth, I would not flag a customer for running SSH on port 22; I would certainly flag a customer for having port 22 exposed where it didn't need to be; for most SaaS/ASP-type companies, I'd flag them for having more than one SSH port exposed, and I'd recommend that they invest in a VPN instead of exposed SSH.
      - pmylund 15y ago
        I think there are far more nameservers allowing AXFR than you think. Write a little app that attempts a zone transfer for the top 1000 of the Alexa list (http://s3.amazonaws.com/alexa-static/top-1m.csv.zip http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) and see for yourself. (Note to anyone reading: Please don't try this before you've checked if it's legal in your state/country or not.) Could you explain how you would learn about wide-open-dev-machine as simply as by using AXFR in your scenario (you aren't on the network, so no *casting). Edit: "so what possible reason could there be for enabling it?" is eerily similar to my message :)
philh 15y ago
> When that happens, the list of vulnerable servers is "everyone running SSH". Agreed, but in between "bad guys discover vulnerability" and "he fixes vulnerability", can't he reduce the chance that he will be attacked by having SSH on a different port? It won't stop someone who's targeting him, but it might keep him off the radar of someone who's just looking for easy targets. From another post: > "32,000" sounds like a large number on a message board, but write an evented port scanner† and see how big that number really is. So is your claim that anyone looking for vulnerable SSH servers will scan every port they can on a given IP, rather than just looking at port 22 and moving on? > I don't think it's hard to extract value from my comments. With respect, you are not the best judge of this. (I personally don't administer a server; if anything, I want you to be correct because that will save me effort if I ever do.) When I read your posts, I learn your opinion, but I often can't work out why you hold that opinion. Possibly you just write your posts under assumptions that seem obvious to you, but not to others.
- tptacek 15y ago
  One assumption I may have that needs to be stated: OpenSSH vulnerabilities are infrequent, bordering on rare. The discovery of a remote auth bypass or remote code exec flaw in OpenSSH is a big deal; a "drop everything and block all access to port 22" deal. Another assumption: the gap between the rumor of an OpenSSH remote and the time it hits "people so dumb as to burn the exploit on a scanner" is large; probably weeks, possibly months. Another assumption: anyone running OpenSSH has turned off the dumb stuff, like password authentication. If you are using passwords to log into SSH servers, you have problems port numbers can't fix. The only attacker SSH-on-port-51122 defends against is the one so far back in line for SSH exploits that she'll stick it on the business end of an Internet-wide scanner. That vulnerability is worth many tens of thousands of dollars. Nobody that has it in the window between announce and "public downloadable exploit" is scanning with it. Finally, you really should only have one machine exposed to SSH, if that. If you have to manage 50 servers, set up 1 bastion server and relay through it.