I think my server was hacked

[crusher11 1127]

3 hours ago, Q-Droid said:

Enable SNI (many do by default) so that IP based requests are rejected. 

What's SNI?

[sh0rty 726]

38 minutes ago, crusher11 said:

What's SNI?

Server name indication. Simple: The reverse proxy just reacts when the specified hostname, e.g. emby.yourdomain.com is called by the client. Many simple bots, vulnerability scanners and automated scripts try to connect directly to your public IP address. 

Edited yesterday at 03:50 PM by sh0rty

[Q-Droid 1002]

10 minutes ago, sh0rty said:

Server name indication. Simple: The reverse proxy just reacts when the specified hostname, e.g. emby.yourdomain.com is called by the client. Many simple bots, vulnerability scanners and automated scripts try to connect directly to your public IP address. 

This. And if your domain doesn't have a PTR record for reverse lookups then your IP is all they know and can't complete the TLS handshake to get any more info. Just don't run non-TLS services on the same IP. Most domains wouldn't need a PTR unless running an email server and if someone is then they should know enough to protect their services.

 

[crusher11 1127]

...I have no idea what any of that means, either.

[woofstream 4]

I'd really love to enable SNI, how should I get started?

[Lessaj 477]

Nginx Proxy Manager (NPM) is a pretty easy way to get started with SNI since it has a web GUI for configuration.

[woofstream 4]

Thank you! I have that setup now, new IP address from my ISP as well. I am curious though, is the login page for Nginx Proxy Manager meant to be exposed on my IP or is there more I should do?

[Lessaj 477]

I don't actually use NPM to properly answer that question but I would assume no the login page should not be exposed, only the port that is used for whatever services you have configured to run behind it - which should only be reachable via domain name (SNI) on that port, which is probably 80 and 443. Some light research indicates that port 81 is the login page, definitely don't expose that.

[woofstream 4]

Makes sense. I accidentally put a 1 where a zero should have went in my port forwarding. Port 80 isn't showing a login page anymore, thank you!

[Q-Droid 1002]

Unless you have a good reason for it you shouldn't open port 80 on the WAN side or any other port that isn't using TLS.

 

[Lessaj 477]

2 hours ago, Q-Droid said:

Unless you have a good reason for it you shouldn't open port 80 on the WAN side or any other port that isn't using TLS.

 

I think it's needed for SSL auto renewal and probably has an auto redirect but I'm not sure. I had to set up 80 for certificate renewal with acme.sh and have a 443 redirect in the vhost (using httpd).

[Q-Droid 1002]

If he's going to redirect 80 to 443 then that defeats the purpose of using SNI to prevent domain name discovery as it will be revealed in the redirect. If port 80 is used only for cert renewal then I guess it could be done in a way that doesn't reveal anything, like a dead-end page. DNS-01 is another acme challenge option and it doesn't need inbound connections to validate.

SNI is not a security feature. It's just handy when used this way to hide information and force snoopers to try harder. And if reverse lookups return the name then it's not useful in that regard.

 

 

[darkassassin07 667]

5 hours ago, Q-Droid said:

If he's going to redirect 80 to 443 then that defeats the purpose of using SNI to prevent domain name discovery as it will be revealed in the redirect.

 

That's not necessarily true; the redirect can simply tell the client to make the same request, but via https on port 443. It doesn't have to tell the client which name it should use, just 'use the same host+path, but with a different protocol+port'.

In nginx that looks like:

 

server{
    listen 80 default_server;
        location / {
        return 301 https://$host$uri;
    }
}

 

Some browsers won't automatically try https, so if you don't provide a port 80 redirect and the user doesn't explicitly type https://, the client will only try 80 and fail to connect.

[Q-Droid 1002]

16 minutes ago, darkassassin07 said:

That's not necessarily true; the redirect can simply tell the client to make the same request, but via https on port 443. It doesn't have to tell the client which name it should use, just 'use the same host+path, but with a different protocol+port'.

In nginx that looks like:

server{
    listen 80 default_server;
        location / {
        return 301 https://$host$uri;
    }
}

Cool. I was thinking about that and figured there would be a way but hadn't explored it.

Quote

Some browsers won't automatically try https, so if you don't provide a port 80 redirect and the user doesn't explicitly type https://, the client will only try 80 and fail to connect.

Isn't this unlikely these days unless the user disables auto https? And in those cases they should recognize why something failed to connect. In the end if there are ways to improve usability without having to compromise security then every bit helps.