Allow SSH Observatory user to specify a custom port

[claudijd]

This is done via the api with a port specification in the scan request POST request...

More details here => https://github.com/mozilla/ssh_scan_api/wiki/ssh_scan-Web-API

[floatingatoll]

Please consider prohibiting this on the public website, same as HTTP Observatory prohibits the public website from other than the default web port, cc @April.

On Mon, Jun 19, 2017 at 1:40 PM, Jonathan Claudius <notifications@github.com

wrote:

This is done via the api with a port specification in the scan request POST request...

More details here => https://github.com/mozilla/ ssh_scan_api/wiki/ssh_scan-Web-API

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/http-observatory-website/issues/119, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDOM459tPZAnEx11BqunvJtGTlYeoks5sFtzBgaJpZM4N-wzp .

[claudijd]

Related to https://github.com/mozilla/ssh_scan_api/issues/81

[april]

I agree with @floatingatoll. My command line tools allow scanning of custom ports and that is my concession to this request. I personally don't want our systems connecting to arbitrary systems on arbitrary ports anywhere on the internet.

[albocc]

@april Don't get me wrong, I can understand your concern, but the website already allows to connect to arbitrary systems, so the packets already hit the machine. There is no real difference between systems that provide their SSH service on the default port and those who provide it on a custom port. People who would abuse vulnerable systems don't need the observatory to do harm to a system. And if there is a non-SSH-service that is sensitive to SSH traffic, there are bigger issues.

In fact, it's a common advice for admins to run their SSH service on a custom port, so a lot (maybe even most?) people won't benefit of this service.

[floatingatoll]

Right now, the numbers of ports scanned by a Mozilla IP associated with the Observatory website is "3", IIRC. 1 protocol per port.

Allowing unusual / custom ports raises this to "65535"; saying that there is "no real difference" is not only false literally but mathematically false (65535 - 3 = 65532), though we typically think of port numbers as integers.

Skilled attackers do, in fact, seek out and take advantage of services that offer port scans of custom ports.

Please take care when reassuring people to take your stance in the future; your recommendation is dangerous and could result in the termination of accounts and/or service if implemented by someone else someday.

Admins who run SSH on its own port can use the command-line scanner tools provided to perform scans on any port they desire — as we do at work frequently today! — but those scans will originate from their IP, as intended.

On Tue, Jun 20, 2017 at 01:35 albocc notifications@github.com wrote:

@april https://github.com/april Don't get me wrong, I can understand your concern, but the website already allows to connect to arbitrary systems, so the packets already hit the machine. There is no real difference between systems that provide their SSH service on the default port and those who provide it on a custom port. People who would abuse vulnerable systems don't need the observatory to do harm to a system. And if there is a non-SSH-service that is sensitive to SSH traffic, there are bigger issues.

In fact, it's a common advice for admins to run their SSH service on a custom port, so a lot (maybe even most?) people won't benefit of this service.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/mozilla/http-observatory-website/issues/119#issuecomment-309684073, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDMxJCCX7VHtRcV5WkzxpfPlcZfvRks5sF4RagaJpZM4N-wzp .

[albocc]

[...] is not only false literally but mathematically false [...]

If you read my post again, you will see that I didn't say that there is no difference in number of ports, but that I said that there is no difference in the service that can be provided either on standard ports or custom ports. So don't argue that there is a "mathematical" difference when that wasn't even my point.

The IP is already being used for scans and admins won't blacklist just three ports from an IP, but most definitely the whole IP, if they decide they want to block scans from the observatory. If you run a server without any firewall in place, then your server is already exposed to much bigger risks, than people using a website to perform an SSH scan once every five minutes at maximum.

Allowing unusual / custom ports raises this to "65535"

According to RFC6335, you shouldn't use the full range of the TCP port spectrum. The port numbers 0-49151 are considered assignable and therefore it would be enough to allow those.

Skilled attackers do, in fact, seek out and take advantage of services that offer port scans of custom ports.

While I don't see how a port scanning website would be any better than performing a port scan through your own machine via VPNs or other proxies, how is this related to the functionality that the Mozilla observatory provides? Do you think someone will use the observatory to probe every port?

In addition to that, from my understanding of the Mozilla observatory, you can download the software that is running on the back-end of the web-ui onto your own machine. Why would an attacker use a rate-limited website to aid his attack, when he could just as well use that tool set via a VPN/Proxy/etc. and do the same scan?

your recommendation is dangerous and could result in the termination of accounts and/or service if implemented by someone else someday.

I still don't understand what makes opening up an SSH scan to more ports any more or less problematic than just offering it on the default port. After all, there are other services that provide similar functionality that do offer custom ports: https://www.htbridge.com/ssl/

[...] but those scans will originate from their IP, as intended.

And what if they want to test their security from outside of their own network?

[april]

While I don't see how a port scanning website would be any better than performing a port scan through your own machine via VPNs or other proxies, how is this related to the functionality that the Mozilla observatory provides? Do you think someone will use the observatory to probe every port?

Yes, people use all sorts of systems for reconnaissance and the combined traffic of the HTTP Observatory + TLS Observatory + SSH Observatory is not insignificant.

In addition to that, from my understanding of the Mozilla observatory, you can download the software that is running on the back-end of the web-ui onto your own machine. Why would an attacker use a rate-limited website to aid his attack, when he could just as well use that tool set via a VPN/Proxy/etc. and do the same scan?

Absolutely, you're exactly right. They totally can and that's why we provide the software as open and free for anyone to use.

I still don't understand what makes opening up an SSH scan to more ports any more or less problematic than just offering it on the default port. After all, there are other services that provide similar functionality that do offer custom ports: https://www.htbridge.com/ssl/

Mozilla is not HT-Bridge. Having our networks blacklisted could result in people not being able to access our software or having our AWS accounts suspended.

And what if they want to test their security from outside of their own network?

Scan from their house or spend the $2/mo to have a VPS in a random datacenter? That's what I do.

[floatingatoll]

There's no absolute law or restriction or rule that we could simply quote and adhere to in this scenario. I'm doing my best to bring a bit of levity and a lot of explanation of the thinking and judgement calls that went into this in the past evaluations, for HTTP and HTTPS scanning. Those same judgement calls also covered things not frequently requested, but just as useful as custom ports, like not permitting arbitrary URL paths - you only scan the root / site, not anything /path - and no query args, and no POST, and no custom HTTP headers.

Technically, we could do this. Technically, we could install protections. Practically, we chose not to, and the web has, regardless, benefited. It's permissible to decline to pursue a technical capability to the fullest extent possible. Open source very seriously permits exactly what you wish here: you can scan anything, anywhere, using any combination of options you want. But that's not a capability we wish to offer through the public service website, even though the tool permits it.

If they want to test their security from outside their own network, they will need to acquire a space to run the tool outside their network, or choose instead to run their service on standard ports, at the root of the site, if they wish to use the public scanner. If neither option is palatable, they can read the scanner's code, study how it scores websites, and implement the listed score bonuses themselves through direct inspection of HTTP headers. I've had to do this at work (at Mozilla) before, so I guarantee it's a technically sound solution, given effort and time.

If I can assure you on one point, I would ask simply that you trust that we aren't just blindly refusing to do this, without having argued about it at length ourselves as well. It would be no good to have decided this unthinkingly, and I guarantee you, there's been a lot of thought.

ps. Your point about 49151 is pretty awesome, I had no idea they'd requested we stop using 49152+, correction cheerfully accepted and actually brought a bit of a smile to my day.

On Tue, Jun 20, 2017 at 7:11 AM, albocc notifications@github.com wrote:

[...] is not only false literally but mathematically false [...]

If you read my post again, you will see that I didn't say that there is no difference in number of ports, but that I said that there is no difference in the service that can be provided either on standard ports or custom ports. So don't argue that there is a "mathematical" difference when that wasn't even my point.

The IP is already being used for scans and admins won't blacklist just three ports from an IP, but most definitely the whole IP, if they decide they want to block scans from the observatory. If you run a server without any firewall in place, then your server is already exposed to much bigger risks, than people using a website to perform an SSH scan once every five minutes at maximum.

Allowing unusual / custom ports raises this to "65535"

According to RFC6335, you shouldn't use the full range of the TCP port spectrum. The port numbers 0-49151 are considered assignable and therefore it would be enough to allow those.

Skilled attackers do, in fact, seek out and take advantage of services that offer port scans of custom ports.

While I don't see how a port scanning website would be any better than performing a port scan through your own machine via VPNs or other proxies, how is this related to the functionality that the Mozilla observatory provides? Do you think someone will use the observatory to probe every port?

In addition to that, from my understanding of the Mozilla observatory, you can download the software that is running on the back-end of the web-ui onto your own machine. Why would an attacker use a rate-limited website to aid his attack, when he could just as well use that tool set via a VPN/Proxy/etc. and do the same scan?

your recommendation is dangerous and could result in the termination of accounts and/or service if implemented by someone else someday.

I still don't understand what makes opening up an SSH scan to more ports any more or less problematic than just offering it on the default port. After all, there are other service that provide similar functionality that do offer custom ports: https://www.htbridge.com/ssl/

[...] but those scans will originate from their IP, as intended.

And what if they want to test their security from outside of their own network?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/http-observatory-website/issues/119#issuecomment-309767783, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDEEzDkifSaF9lg7SmdKobDRKmmP0ks5sF9MsgaJpZM4N-wzp .

[albocc]

@floatingatoll Reading your post made me realize that I was thinking of the wrong target audience for the website this whole time. I guess my experience of people changing the default port of SSH quite commonly, lead me to believe that the default port of SSH is not that common anymore and people wouldn't have much use out of a website like the observatory, but I guess there is still a place for some people.

I guess people who have the expertise to change the default port, should have enough knowledge of how to install the tool-set on their systems and test it via a remote network of some sort. Following the basic security principle of restricting a service, if it's not necessary to keep it open, I guess it's fine to sacrifice the convenience benefit of performing a scan through the website for advanced users in favor of keeping it simple, even though I can't fully agree with the security concerns @april mentioned. But since Mozilla has a more significant reputation to lose, I can understand the motives.

I had no idea they'd requested we stop using 49152+

Those ports are still okay to be used but only for dynamic purposes like source ports on the client side.

[claudijd]

ssh_scan_api is now config restricted to port 22 only (previously it allowed any port). For users who wish to scan custom ports for SSH, you will have two options...

1. Scan with the ssh_scan command-line tool (available as src, gem, docker deployment) via https://github.com/mozilla/ssh_scan
2. Setup up your own API instance and add the custom ports you desire to scan via https://github.com/mozilla/ssh_scan_api (available as src and docker deployment)

Thanks all for the lively feedback and thoughtful discourse on this!