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.
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!
Ipv4 is only 4 billion addresses. It doesn't actually take very long to just try all of them. If you're running a service exposed to the internet and it has a published exploitable vulnerability, it's just a matter of time before it gets exploited. (that said, that time does give a little buffer for patching)
Yes, it's risky to accept password auth if someone sharing the box with you has a poor password. They could do things like:
. Install a spam or brute force password bot, which could get the machine kicked off its internet connection (in addition to whatever havoc it causes first)
. DoS the server by filling up the disk or using too much RAM (are quotas enforced?)
. Exploit a local vuln to get root, if such exists on that box. (Is the kernel promptly patched and the box rebooted?)
. Explore other users' directories (are permissions locked down correctly across users?)
It is, if for no other reason than you never know when some other user has a guessable password. You should switch everyone to ssh keys. It's a good excuse to learn :)
How good is your password? If it's long, with special characters, it's fine. Install fail2ban. The problem with auth keys is you can't get into the server if you don't have your laptop/phone/NFC device because you got pickpocketed/mugged?
Is this still possible? Are your emails getting delivered?
Downvoted. I don't know when the downvoter tried the last time to "host their own email". Yes, DMARC, DKIM und SPF. Good luck trying to get your email deliverd to t-online or something.
> Is this still possible? Are your emails getting delivered?
Mine are. Although it probably helps to have a static IP with a 25 year long clean history.
Are there very occasional glitches? Sure. But I've seen ISPs drop everything from GMail on the floor for no obvious reason. I've seen GMail drop GMail email before. Same for every other large email provider.
To date I haven't seen any reason strong enough to push me to switch to a centralised email host. That day may yet come of course.
I self-host my email, and have not really had problems delivering normal quantities of personal email (except a bit of pain for Microsoft to accept mail in the first place, but it can be sorted quickly) - as long as you do DMARC / DKIM / SPF.
I've never heard of t-online before or tried to send an email there to my knowledge... if one provider I've never heard of would refuse to accept my mail if I ever sent something to them, that's more of a them problem than a me problem - but it certainly isn't the norm for other providers.
> Good luck trying to get your email deliverd to t-online or something.
People who say it cannot (or should not) be done should not interrupt those who are doing it.
The dismissiveness is likely why you are downvoted, I'm guessing. The suggestion that because it's hard for you and therefore you're surprised others are doing it isn't a good look.
Self hosting email isn't that hard, and there are many solutions for all sorts of self hosting issues. That's a topic for another discussion, though.
"Self hosting email isn't that hard". Self hosting is super easy. Getting your emails delivered is hard. And I am not even talking SPAM folder here (see t-online example).
Smart comment from reddit:
"The problem with selfhosting email, unlike selfhosting services like Jellyfin or Nextcloud, is that you rely on other people's servers to play ball with you, but they often don't. Or they play for a while and then suddenly decide not to without telling you. It's unpredictable and we selfhosters don't have enough control over that."
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.
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?
> 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.
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.
The first benefit is some bots won't bother testing passwords as the SSH error message tells them the server doesn't use password auth. The second benefit is if your server is compromised it's quite easy for a rootkit to hijack SSH and steal your password when you login (and then abuse that on other servers you use it), the same is not true with a key and it is much harder for a rootkit to abuse as long as you only use the key on your local machine (there are strong protections against SSH handshake MITM attacks afaik)
> Or is there something in the password method itself, that is inherently weak?
You have to send your password/hash. With PKC, your private key never leaves your device. It can even live on a separate security key. All you ever send are signed messages, never your key.
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.
”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.
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).
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.
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.
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
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.
My competing site can have <img src="https://yourdomain/wp-login.php"> and customers won't be able to view your site after that. Thanks for the free customers!
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.
> 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.
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.
> 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?
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.
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.
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!
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.
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.