4 ms·

Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'? It doesn't seem terribly unsafe to me, especially

Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'? It doesn't seem terribly unsafe to me, especially if you're serving static pages.

koito17 2y ago
In my experience, most of the noise on my web server are bots with spoofed iPhone or Google Chrome user-agents. I see three kinds of traffic patterns. 1. bogus /wp-login.php requests, or endpoints of presumably insecure wordpress plugins. These bots are pretty dumb and do it non-stop, even if the server constantly responds with a 404 2. testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh . Even if your web server clearly communicates that it's not Apache, the bots still insist on testing Apache vulnerabilities. They also occasionally test vulnerabilities that exist in ancient Nginx versions. 3. less common, but bots that exist to scrape something from the internet. I remember two years ago seeing a bot whose sole purpose was to document as many registered, valid domain names as possible (I found out about this since they linked a website explaining who they were in their user-agent string) Overall, I would say the background noise of HTTP servers is tame compared to what you see for SMTP servers and, to some extent, SSH servers. I happen to also self-host e-mail; logs record failed login attempts about every second. They always pick a username like "admin" or "adm". There's also people who try using your SMTP server as a relay for spam.
- aadhavans 2y ago
  Gotcha, thanks for the detailed response. I've seen the WordPress login attempts in my own web server logs, and that seems to be corroborated in your comment.
- fpoling 2y ago
  For me the biggest source of noise in logs for a small site is the referrer spam. At some point like 12 years ago I enabled webalizer stats with a public link to the stats page. Soon I had to deal with massive amount of bot requests with http referrer pointing to porn and farmacy ads. That has not stopped after the public link was removed and the stats has started to use a public spam database. And the spam is still there after 12 years.
  - tombrossman 2y ago
    Matomo (self-hosted analytics, used to be called Piwik) maintain a list of referrer spam domains. I use it as a filter list with GoAccess and haven't seen referrer spam for a long time. Worth a look. https://github.com/matomo-org/referrer-spam-list https://github.com/matomo-org/referrer-spam-list
- hyperman1 2y ago
  I've added a /wp-login.php and friends that firewall-blocks the IP of the requester for a week. It greatly cuts down the bot noise.
  - immibis 2y ago
    My competing site can have <img src="https://yourdomain/wp-login.php https://yourdomain/wp-login.php"> and customers won't be able to view your site after that. Thanks for the free customers!
    - sweetjuly 2y ago
      Yep :) The real trick is to not be vulnerable to known issues, and then mitigate post-compromise like crazy on the off chance you get patch gapped or (very unlikely) zero dayed. Blocking IP addresses is extremely silly, especially in an IPv6 world where attacker can easily get access to gigantic numbers of addresses in hard to identify ways (there's no source of truth for what IPv6 range corresponds to one blockable "customer". Some get /56s, others get /48s, etc.). It's security theater which may well just break your service for real users.
  - Beijinger 2y ago
    Can you post the script? Obviously I assume you don't run wp. I think wordfence does something similiar.
    - DEADMINCE 2y ago
      It's probably just an nginx fail2ban jail or something that looks for the wp pattern.
- DEADMINCE 2y ago
  > testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh . Are they really recent vulns though?
chipdart 2y ago
> Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'? These are the ports usually employed to serve HTTP and HTTPS traffic, which mean public-facing servers. Having a server listening to those ports is the precondition to have web servers running specific types of services, some of which have known vulnerabilities that can be and are exploited.
ValtteriL 2y ago
Ports can't be hacked but the application listening on them can ;) You can have vulnerabilities on the server software and its configuration even if you are serving only static content. This should be unlikely if you use up-to-date battle-tested software like nginx without making crazy config changes. If you serve dynamic content, that may also have vulnerabilities that hackers can exploit.
ozim 2y ago
99.9999% of issues on 80/443 are apps run on the server not webserver itself. It is applications that you run on web server that are exploited. So serving static pages is safest thing you can do.
e12e 2y ago
https://arstechnica.com/security/2024/06/thousands-of-servers-infected-with-ransomware-via-critical-php-vulnerability/ https://arstechnica.com/security/2024/06/thousands-of-server...

Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'? It doesn't seem terribly unsafe to me, especially if you're serving static pages.

koito17 2y ago

In my experience, most of the noise on my web server are bots with spoofed iPhone or Google Chrome user-agents. I see three kinds of traffic patterns. 1. bogus /wp-login.php requests, or endpoints of presumably insecure wordpress plugins. These bots are pretty dumb and do it non-stop, even if the server constantly responds with a 404 2. testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh . Even if your web server clearly communicates that it's not Apache, the bots still insist on testing Apache vulnerabilities. They also occasionally test vulnerabilities that exist in ancient Nginx versions. 3. less common, but bots that exist to scrape something from the internet. I remember two years ago seeing a bot whose sole purpose was to document as many registered, valid domain names as possible (I found out about this since they linked a website explaining who they were in their user-agent string) Overall, I would say the background noise of HTTP servers is tame compared to what you see for SMTP servers and, to some extent, SSH servers. I happen to also self-host e-mail; logs record failed login attempts about every second. They always pick a username like "admin" or "adm". There's also people who try using your SMTP server as a relay for spam.

aadhavans 2y ago
Gotcha, thanks for the detailed response. I've seen the WordPress login attempts in my own web server logs, and that seems to be corroborated in your comment.
fpoling 2y ago
For me the biggest source of noise in logs for a small site is the referrer spam. At some point like 12 years ago I enabled webalizer stats with a public link to the stats page. Soon I had to deal with massive amount of bot requests with http referrer pointing to porn and farmacy ads. That has not stopped after the public link was removed and the stats has started to use a public spam database. And the spam is still there after 12 years.
- tombrossman 2y ago
  Matomo (self-hosted analytics, used to be called Piwik) maintain a list of referrer spam domains. I use it as a filter list with GoAccess and haven't seen referrer spam for a long time. Worth a look. https://github.com/matomo-org/referrer-spam-list https://github.com/matomo-org/referrer-spam-list
hyperman1 2y ago
I've added a /wp-login.php and friends that firewall-blocks the IP of the requester for a week. It greatly cuts down the bot noise.
- immibis 2y ago
  My competing site can have <img src="https://yourdomain/wp-login.php https://yourdomain/wp-login.php"> and customers won't be able to view your site after that. Thanks for the free customers!
  - sweetjuly 2y ago
    Yep :) The real trick is to not be vulnerable to known issues, and then mitigate post-compromise like crazy on the off chance you get patch gapped or (very unlikely) zero dayed. Blocking IP addresses is extremely silly, especially in an IPv6 world where attacker can easily get access to gigantic numbers of addresses in hard to identify ways (there's no source of truth for what IPv6 range corresponds to one blockable "customer". Some get /56s, others get /48s, etc.). It's security theater which may well just break your service for real users.
- Beijinger 2y ago
  Can you post the script? Obviously I assume you don't run wp. I think wordfence does something similiar.
  - DEADMINCE 2y ago
    It's probably just an nginx fail2ban jail or something that looks for the wp pattern.
DEADMINCE 2y ago
> testing recent Apache vulnerabilities by POST-ing to something like /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh . Are they really recent vulns though?

chipdart 2y ago

> Out of curiosity, what are the ramifications of exposing ports 80 and 443? Can these ports even be 'hacked'? These are the ports usually employed to serve HTTP and HTTPS traffic, which mean public-facing servers. Having a server listening to those ports is the precondition to have web servers running specific types of services, some of which have known vulnerabilities that can be and are exploited.

ValtteriL 2y ago

Ports can't be hacked but the application listening on them can ;) You can have vulnerabilities on the server software and its configuration even if you are serving only static content. This should be unlikely if you use up-to-date battle-tested software like nginx without making crazy config changes. If you serve dynamic content, that may also have vulnerabilities that hackers can exploit.

ozim 2y ago

99.9999% of issues on 80/443 are apps run on the server not webserver itself. It is applications that you run on web server that are exploited. So serving static pages is safest thing you can do.

e12e 2y ago

https://arstechnica.com/security/2024/06/thousands-of-servers-infected-with-ransomware-via-critical-php-vulnerability/ https://arstechnica.com/security/2024/06/thousands-of-server...