5 ms·

It seems that once again, running services on non-standard ports where possible might have payed off. Off to patching. Or rather, wait for eventual patches. B

by roeme 12y ago

It seems that once again, running services on non-standard ports where possible might have payed off. Off to patching. Or rather, wait for eventual patches. But you know what interests me the most about the whole thing? Theo de Raadts reaction. You know, after bashing OpenSSL heavily. And hinting at a SSH hole in FreeBSD, known to him but deliberately undisclosed. Judging from the announcement's tested systems, it might be the exact hole he referred to. "...many more" sounds like they'd like to claim more successfully exploited platforms, but can't since they do something different, and the de facto reference implementation of OpenSSH on OpenBSD is suspiciously absent.

akerl_ 12y ago
I'm curious how running services on non-standard ports has an impact on anything like this. This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.
- marksamman 12y ago
  It helps against a masscan on the standard port. If the attacker is specifically targeting you or has the resources to masscan every port, then I agree that it's useless.
  - akerl_ 12y ago
    https://zmap.io/ https://zmap.io/ / https://github.com/zmap/zmap https://github.com/zmap/zmap It's pretty crazy to think about, but a portscan of the IPv4 space isn't that hard to do in practice: "On a typical desktop computer with a gigabit Ethernet connection, ZMap is capable scanning the entire public IPv4 address space in under 45 minutes."
    - marksamman 12y ago
      It isn't clear whether that is on a specific port or every port. The documentation[1] makes it look like it's on a specific port since it requires a target port to run. If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. Thanks for sharing, I had not heard about ZMap before. [1] https://zmap.io/documentation.html https://zmap.io/documentation.html EDIT: The research paper says that it's on a particular port, from page 3: "The architecture allows sending and receiving components to run asynchronously and enables a single source machine to comprehensively scan every host in the public IPv4 address space for a particular open TCP port in under 45 mins using a 1 Gbps Ethernet link."
      - akerl_ 12y ago
        Indeed, but if you consider that plenty of cheap servers with larger links exist, and attackers aren't limited to using one... Essentially, you'd run this across a botnet so that rather than focusing all the traffic at one target, you retrieve the massive amount of data much faster than your single system could.
      - phil21 12y ago
        > If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. You're not? I am. Or would be if this wasn't known info yet. Think about it for a bit - you can narrow down your search area quite a bit by excluding huge swaths of the Internet such as consumer ISPs. Focus on the target-rich environments like EC2 space, hosting providers, enterprises, etc. You also can not scan any unassigned v4 space (admittedly getting smaller), multicast addresses, RFC1918, etc. The usable pool of v4 is actually quite a bit smaller than 32 bits, and the interesting parts are even less. I would be surprised if you couldn't come up with a list of interesting space to scan that you couldn't do within 15 minutes per port. You aren't using this tool to pwn Joe nerd who runs a Linux NAT box off his cable modem. From there, you just need a few hundred compromised servers (not difficult this day in age) and you can probably scan the entirety of "rich" space on all ports rather quickly via a distributed manner. The only downside is such scans tend to generate complaints, so you'll need to balance your loss of compromised hosts with the expected payoff.
- fleitz 12y ago
  It doesn't. If anything change the line SSH emits and how it identifies itself. You want the automated tools to send the wrong exploits. If you can make your OpenBSD machine look like a Windows server running a commercial SSH server you're going to deflect a lot of attacks / attract the wrong kind of attacks. The proper way to do something like this is generally three fold: 1) Trusted host (OpenBSD?) that runs only SSHD, and only allows users to run ssh from the shell. Log the fuck out of this server, and likely port mirror and record raw packet logs. Since no one should be talking to this machine except for SSH simply drop everything from those IPs when you recieve something other than SSH. 2) Ensure all other servers only accept SSH connections from the trusted host. 3) Restrict unconditional access to the trusted host to a list of trusted IPs, turn off all unused SSH options, you probably don't need that many if all it is doing is proxying connections to other hosts. Now that you have a list of trusted IPs you can be very aggressive in firewalling malicious connections from non-trusted IPs. (It's nice to have some way to getting back into your infrastructure when you're on vacation, etc) Generally the best thing for security is a default deny rule. Chances are your database server doesn't really need to connect to the internet. Chances are your webservers only require inbound connections on ports 80 and 443, and only make outbound connections to your database & log server. Fuckery with port numbers is generally a waste of time. The best thing for an attacker to do is extensive slow scanning in advance, then when an exploit comes out it's a quick lookup in a DB for likely vulnerable systems.
neoCrimeLabs 12y ago
What interests me is Theo de Raadt's reaction hearing about someone running a OpenSSH on a non-standard port paying off against a potential exploit.

by roeme 12y ago

akerl_ 12y ago

I'm curious how running services on non-standard ports has an impact on anything like this. This specific threat appears to be a hoax, but even if it wasn't, an attacker just portscans you and then targets your SSH service. Moving the port doesn't even buy you a few minutes.

marksamman 12y ago
It helps against a masscan on the standard port. If the attacker is specifically targeting you or has the resources to masscan every port, then I agree that it's useless.
- akerl_ 12y ago
  https://zmap.io/ https://zmap.io/ / https://github.com/zmap/zmap https://github.com/zmap/zmap It's pretty crazy to think about, but a portscan of the IPv4 space isn't that hard to do in practice: "On a typical desktop computer with a gigabit Ethernet connection, ZMap is capable scanning the entire public IPv4 address space in under 45 minutes."
  - marksamman 12y ago
    It isn't clear whether that is on a specific port or every port. The documentation[1] makes it look like it's on a specific port since it requires a target port to run. If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. Thanks for sharing, I had not heard about ZMap before. [1] https://zmap.io/documentation.html https://zmap.io/documentation.html EDIT: The research paper says that it's on a particular port, from page 3: "The architecture allows sending and receiving components to run asynchronously and enables a single source machine to comprehensively scan every host in the public IPv4 address space for a particular open TCP port in under 45 mins using a 1 Gbps Ethernet link."
    - akerl_ 12y ago
      Indeed, but if you consider that plenty of cheap servers with larger links exist, and attackers aren't limited to using one... Essentially, you'd run this across a botnet so that rather than focusing all the traffic at one target, you retrieve the massive amount of data much faster than your single system could.
    - phil21 12y ago
      > If it's on a specific port, you might want to multiply 45 minutes with 65535, if not I'm impressed. You're not? I am. Or would be if this wasn't known info yet. Think about it for a bit - you can narrow down your search area quite a bit by excluding huge swaths of the Internet such as consumer ISPs. Focus on the target-rich environments like EC2 space, hosting providers, enterprises, etc. You also can not scan any unassigned v4 space (admittedly getting smaller), multicast addresses, RFC1918, etc. The usable pool of v4 is actually quite a bit smaller than 32 bits, and the interesting parts are even less. I would be surprised if you couldn't come up with a list of interesting space to scan that you couldn't do within 15 minutes per port. You aren't using this tool to pwn Joe nerd who runs a Linux NAT box off his cable modem. From there, you just need a few hundred compromised servers (not difficult this day in age) and you can probably scan the entirety of "rich" space on all ports rather quickly via a distributed manner. The only downside is such scans tend to generate complaints, so you'll need to balance your loss of compromised hosts with the expected payoff.
fleitz 12y ago
It doesn't. If anything change the line SSH emits and how it identifies itself. You want the automated tools to send the wrong exploits. If you can make your OpenBSD machine look like a Windows server running a commercial SSH server you're going to deflect a lot of attacks / attract the wrong kind of attacks. The proper way to do something like this is generally three fold: 1) Trusted host (OpenBSD?) that runs only SSHD, and only allows users to run ssh from the shell. Log the fuck out of this server, and likely port mirror and record raw packet logs. Since no one should be talking to this machine except for SSH simply drop everything from those IPs when you recieve something other than SSH. 2) Ensure all other servers only accept SSH connections from the trusted host. 3) Restrict unconditional access to the trusted host to a list of trusted IPs, turn off all unused SSH options, you probably don't need that many if all it is doing is proxying connections to other hosts. Now that you have a list of trusted IPs you can be very aggressive in firewalling malicious connections from non-trusted IPs. (It's nice to have some way to getting back into your infrastructure when you're on vacation, etc) Generally the best thing for security is a default deny rule. Chances are your database server doesn't really need to connect to the internet. Chances are your webservers only require inbound connections on ports 80 and 443, and only make outbound connections to your database & log server. Fuckery with port numbers is generally a waste of time. The best thing for an attacker to do is extensive slow scanning in advance, then when an exploit comes out it's a quick lookup in a DB for likely vulnerable systems.

neoCrimeLabs 12y ago

What interests me is Theo de Raadt's reaction hearing about someone running a OpenSSH on a non-standard port paying off against a potential exploit.