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.
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.
https://github.com/ajgon/self-hosted-mailserver/blob/master/...
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!
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.
https://forum.hestiacp.com/t/t-online-curious-story-about-th...
They may even check if your domain has an "imprint". I kid you not. I use my own domains too, but I piggyback with infomaniak.com
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.
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."
This describes it pretty well.
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.
Selfhost does not imply residential IP.
Yes and yes (if DMARC/DKIM/SPF configured correctly).
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.
. 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?)
…and more thrilling possibilities!
Embrace key auth. Future you will thank you.
So in practice you'll probably also use something like fail2ban, firewall rules that only allow connections from certain IP blocks, things like that.
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.
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.
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.
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.
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.
It doesn't seem terribly unsafe to me, especially if you're serving static pages.
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.
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.
Obviously I assume you don't run wp. I think wordfence does something similiar.
Are they really recent vulns though?
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.
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.
It is applications that you run on web server that are exploited.
So serving static pages is safest thing you can do.
Isn't this hypothetical risk mitigated or outright eliminated by using stateless apps and periodically redeploying them in the spirit of cattle?
As you're periodically doing clean redeployments, that's not a concern isn't it?
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.
Public facing like serving some static webpages or blog, text content. Yeah do it.