5 ms·

I once tried hosting a web server at home by exposing ports 80 and 443 to the Internet. Hours later I reviewed the logs, thousands of attempts to hack into my l

I once tried hosting a web server at home by exposing ports 80 and 443 to the Internet. Hours later I reviewed the logs, thousands of attempts to hack into my lil Linux server. It spooked me to say the least, so I switched to using cloudflare tunnels instead. Exposing ports on the Internet is dangerous, especially SSH. You're much safer using a proxy or gateway of some sort, or better yet a VPN if it doesn't need to be publicly accessible.

mikhmha 2y ago
Yeah this is what keeps me away from self-hosting public facing stuff. To me its like opening a new pipe into your home that is open to the whole world. And I'm too carefree to get the settings down right. So I avoid it all with complete process isolation. Don't shit where you sleep!
- sureglymop 2y ago
  But couldn't, you, within your home, separate it from everything else? I don't see how it's any more dangerous really.
  - mikhmha 2y ago
    I should clarify. When I mean self host it’s for public facing applications that generate revenue. It involves some transaction in currency?value? between the user. Once money is involved you become a target. I don’t want anything that could be traced to my physical address. I told you I’m careless, I’ll eventually slip up on installing the patches or configuring something right. Public facing like serving some static webpages or blog, text content. Yeah do it.
  - Nux 2y ago
    Obviously you need to know how and if you don't then it's always going to look very daunting.
waingake 2y ago
Is it? If you've got `PasswordAuthentication` disabled, only allow public key logins and keep your system up to date. Honest question. I self host my email ( docker-mailserver ) and host my personal website on an old laptop with a static IP. Have done for years now without issue.
- pkrotich 2y ago
  The keyword is diligently keeping your system up to date! That said you’ll still have exposure to zero day vulnerabilities and DOS attacks.
  - kristopolous 2y ago
    https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades Most distros have something like this.
    - Beijinger 2y ago
      This reminded me of: https://github.com/ajgon/self-hosted-mailserver/blob/master/docs/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers.md https://github.com/ajgon/self-hosted-mailserver/blob/master/...
  - Fabricio20 2y ago
    But an attacker with one of the biggest vulnerabilities on earth (hell, ssh noauth 0day) would very likely use it against big cloud providers and infrastructure (isps and others) and not burn it on your home server! Keeping it reasonably up to date with your distro's cycle is probably enough for most people doing this home server thing. So of course, as things always are with security this is a matter of risk assessment and understanding your attack surface, a server with only public key and maybe on a special port goes a very long way, add fail2ban on top and i'd say it's probably fine for quite a while. But that does make me think... what if... a wormable noauth 0day like that on ssh or some other popular system... how fast could it replicate itself to form the biggest botnet.. how long would it take, to take over all visible linux servers on the internet (so that your little home box ends up being a target)? I guess at that point you are limited by bandwidth, but since you can scale that with every compromised server... hope someone does the math on that one day!
INTPenis 2y ago
I noticed earlier this year while deploying a CoreOS VPS with terraform that sometimes you'd get an interesting IP that would receive incoming HTTP requests for interesting domains such as theguardian.com. I of course destroyed and re-deployed the VPS several times so the interesting IPs are lost to me, but it might be worth running a HTTP honeypot as well as an SSH one.
aadhavans 2y ago
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.
kristopolous 2y ago
I've been doing it for 25 years. It's fine.
- Hendrikto 2y ago
  ”Works for me.“ does not really answer the question. Having a 25 year history might be why your mail gets delivered, while many people trying to self-host have constant and unpredictable deliverability issues.
  - kristopolous 2y ago
    It's more an advocacy against security paranoia. You will always get automated attacks, constantly. But they're almost all doing stuff like trying to exploit a 12 year old bug in Wordpress or IIS. They're about as sophisticated as any other scammer on the net.
nurettin 2y ago
Don't worry, they are usually Russian/Chinese ips scanning for 5 year old php exploits. I've been exposing ports to the internet for decades with no issues. Always block ssh password and keep software relatively up to date. If you are very paranoid, make a vps beacon and remotely tunnel ports from your lab to it. That way you only expose the beacon.
- zelphirkalt 2y ago
  I wonder, what is the issue with authenticating by password. If you choose a password of lets say 64 random chars, shouldn't it be pretty safe? Or is there something in the password method itself, that is inherently weak?
  - cess11 2y ago
    Sure, they probably won't crack that, but there are other things to consider as well. A sshd on IPv4 port 22 that accepts password auth attracts attention, and you'll spend CPU cycles constantly checking credentials from very large database dumps that float around. In my experience it leads to more log noise too, it seems many bots will discard your IP and stop pestering it if passwords aren't accepted. So in practice you'll probably also use something like fail2ban, firewall rules that only allow connections from certain IP blocks, things like that.
  - KAMSPioneer 2y ago
    There are still advantages to public key auth. Sibling comment mentioned resource use, but also consider ease of use: are you setting a random 64-character password on every machine that has SSH server installed? Would it not be easier to generate one ed25519 keypair, apply a reasonable passphrase (and/or use disk encryption), and then you have secure auth on all your machines without a password manager? If you're _not_ setting unique 64-character passwords per server, then you should consider what happens if your super strong password is discovered -- an attacker would have access to all your boxes. Compromising a key is harder than compromising a password.
  - denton-scratch 2y ago
    > Or is there something in the password method itself, that is inherently weak? Your 64-character high-entropy password might be safe; other users on your system might baulk at memorising/typing in 64 random chars, and choose a less-secure password instead. With SSH keys, that can't happen.
chipdart 2y ago
> I once tried hosting a web server at home by exposing ports 80 and 443 to the Internet. Hours later I reviewed the logs, thousands of attempts to hack into my lil Linux server. It spooked me to say the least, so I switched to using cloudflare tunnels instead. Isn't this hypothetical risk mitigated or outright eliminated by using stateless apps and periodically redeploying them in the spirit of cattle?
- metadat 2y ago
  Depends, If they get into the stateless app and hoist that to penetrate into other stuff in your network, they might be able to install an APT.
  - chipdart 2y ago
    > (...) they might be able to install an APT. As you're periodically doing clean redeployments, that's not a concern isn't it?
    - immibis 2y ago
      Clean deployments of your entire home network?
spc476 2y ago
I checked the logs for May for one website I run---65% of failed requests were for PHP scripts (mostly Wordpress). I don't run PHP so I don't worry. The rest of the requests were bots that can't parse HTML [1] and other weird requests. I've been running a webserver, SMTP, SSH and DNS for over 25 years and only once had an issue due to an inside job [2] twenty years ago (hard to protect against those). [1] https://boston.conman.org/2019/07/09.1 https://boston.conman.org/2019/07/09.1 [2] https://boston.conman.org/2004/09/19.1 https://boston.conman.org/2004/09/19.1
JackSlateur 2y ago
Every things on the internet is doing exactly this "dangerous things", with the exact same means you have at your disposal. Exposing a service is not dangerous. It is the same thing when you go to the sub and many people ask you for money : they keep asking, but that will not lead you to your bank account. So you have log, this is not an issue, this is not something to be scared of or even cared of. Just ignore them, as they are worthless and part of the v4 internet.
DEADMINCE 2y ago
The traffic doesn't matter if you are sure your setup is secure. Key auth only for SSH, reverse proxy in front of your actual web server and use secured containers or VMs for each service. Throw in fail2an or crowdsec and that's more than enough for a little home linux server.

mikhmha 2y ago

Yeah this is what keeps me away from self-hosting public facing stuff. To me its like opening a new pipe into your home that is open to the whole world. And I'm too carefree to get the settings down right. So I avoid it all with complete process isolation. Don't shit where you sleep!

sureglymop 2y ago
But couldn't, you, within your home, separate it from everything else? I don't see how it's any more dangerous really.
- mikhmha 2y ago
  I should clarify. When I mean self host it’s for public facing applications that generate revenue. It involves some transaction in currency?value? between the user. Once money is involved you become a target. I don’t want anything that could be traced to my physical address. I told you I’m careless, I’ll eventually slip up on installing the patches or configuring something right. Public facing like serving some static webpages or blog, text content. Yeah do it.
- Nux 2y ago
  Obviously you need to know how and if you don't then it's always going to look very daunting.

waingake 2y ago

Is it? If you've got `PasswordAuthentication` disabled, only allow public key logins and keep your system up to date. Honest question. I self host my email ( docker-mailserver ) and host my personal website on an old laptop with a static IP. Have done for years now without issue.

pkrotich 2y ago
The keyword is diligently keeping your system up to date! That said you’ll still have exposure to zero day vulnerabilities and DOS attacks.
- kristopolous 2y ago
  https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades Most distros have something like this.
  - Beijinger 2y ago
    This reminded me of: https://github.com/ajgon/self-hosted-mailserver/blob/master/docs/my-first-5-minutes-on-a-server-or-essential-security-for-linux-servers.md https://github.com/ajgon/self-hosted-mailserver/blob/master/...
- Fabricio20 2y ago
  But an attacker with one of the biggest vulnerabilities on earth (hell, ssh noauth 0day) would very likely use it against big cloud providers and infrastructure (isps and others) and not burn it on your home server! Keeping it reasonably up to date with your distro's cycle is probably enough for most people doing this home server thing. So of course, as things always are with security this is a matter of risk assessment and understanding your attack surface, a server with only public key and maybe on a special port goes a very long way, add fail2ban on top and i'd say it's probably fine for quite a while. But that does make me think... what if... a wormable noauth 0day like that on ssh or some other popular system... how fast could it replicate itself to form the biggest botnet.. how long would it take, to take over all visible linux servers on the internet (so that your little home box ends up being a target)? I guess at that point you are limited by bandwidth, but since you can scale that with every compromised server... hope someone does the math on that one day!

INTPenis 2y ago

I noticed earlier this year while deploying a CoreOS VPS with terraform that sometimes you'd get an interesting IP that would receive incoming HTTP requests for interesting domains such as theguardian.com. I of course destroyed and re-deployed the VPS several times so the interesting IPs are lost to me, but it might be worth running a HTTP honeypot as well as an SSH one.

aadhavans 2y ago

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.

kristopolous 2y ago

I've been doing it for 25 years. It's fine.

Hendrikto 2y ago
”Works for me.“ does not really answer the question. Having a 25 year history might be why your mail gets delivered, while many people trying to self-host have constant and unpredictable deliverability issues.
- kristopolous 2y ago
  It's more an advocacy against security paranoia. You will always get automated attacks, constantly. But they're almost all doing stuff like trying to exploit a 12 year old bug in Wordpress or IIS. They're about as sophisticated as any other scammer on the net.

nurettin 2y ago

Don't worry, they are usually Russian/Chinese ips scanning for 5 year old php exploits. I've been exposing ports to the internet for decades with no issues. Always block ssh password and keep software relatively up to date. If you are very paranoid, make a vps beacon and remotely tunnel ports from your lab to it. That way you only expose the beacon.

zelphirkalt 2y ago
I wonder, what is the issue with authenticating by password. If you choose a password of lets say 64 random chars, shouldn't it be pretty safe? Or is there something in the password method itself, that is inherently weak?
- cess11 2y ago
  Sure, they probably won't crack that, but there are other things to consider as well. A sshd on IPv4 port 22 that accepts password auth attracts attention, and you'll spend CPU cycles constantly checking credentials from very large database dumps that float around. In my experience it leads to more log noise too, it seems many bots will discard your IP and stop pestering it if passwords aren't accepted. So in practice you'll probably also use something like fail2ban, firewall rules that only allow connections from certain IP blocks, things like that.
- KAMSPioneer 2y ago
  There are still advantages to public key auth. Sibling comment mentioned resource use, but also consider ease of use: are you setting a random 64-character password on every machine that has SSH server installed? Would it not be easier to generate one ed25519 keypair, apply a reasonable passphrase (and/or use disk encryption), and then you have secure auth on all your machines without a password manager? If you're _not_ setting unique 64-character passwords per server, then you should consider what happens if your super strong password is discovered -- an attacker would have access to all your boxes. Compromising a key is harder than compromising a password.
- denton-scratch 2y ago
  > Or is there something in the password method itself, that is inherently weak? Your 64-character high-entropy password might be safe; other users on your system might baulk at memorising/typing in 64 random chars, and choose a less-secure password instead. With SSH keys, that can't happen.

chipdart 2y ago

> I once tried hosting a web server at home by exposing ports 80 and 443 to the Internet. Hours later I reviewed the logs, thousands of attempts to hack into my lil Linux server. It spooked me to say the least, so I switched to using cloudflare tunnels instead. Isn't this hypothetical risk mitigated or outright eliminated by using stateless apps and periodically redeploying them in the spirit of cattle?

metadat 2y ago
Depends, If they get into the stateless app and hoist that to penetrate into other stuff in your network, they might be able to install an APT.
- chipdart 2y ago
  > (...) they might be able to install an APT. As you're periodically doing clean redeployments, that's not a concern isn't it?
  - immibis 2y ago
    Clean deployments of your entire home network?

spc476 2y ago

I checked the logs for May for one website I run---65% of failed requests were for PHP scripts (mostly Wordpress). I don't run PHP so I don't worry. The rest of the requests were bots that can't parse HTML [1] and other weird requests. I've been running a webserver, SMTP, SSH and DNS for over 25 years and only once had an issue due to an inside job [2] twenty years ago (hard to protect against those). [1] https://boston.conman.org/2019/07/09.1 https://boston.conman.org/2019/07/09.1 [2] https://boston.conman.org/2004/09/19.1 https://boston.conman.org/2004/09/19.1

JackSlateur 2y ago

Every things on the internet is doing exactly this "dangerous things", with the exact same means you have at your disposal. Exposing a service is not dangerous. It is the same thing when you go to the sub and many people ask you for money : they keep asking, but that will not lead you to your bank account. So you have log, this is not an issue, this is not something to be scared of or even cared of. Just ignore them, as they are worthless and part of the v4 internet.

DEADMINCE 2y ago

The traffic doesn't matter if you are sure your setup is secure. Key auth only for SSH, reverse proxy in front of your actual web server and use secured containers or VMs for each service. Throw in fail2an or crowdsec and that's more than enough for a little home linux server.