Dude. Awesome blog.
Ok my brother, I'm back with great news. It is as easy as everyone in this thread has said it was. Honestly, it wasn't the set up that I was concerned with. My question was more concerned with any additional security considerations I may have to deploy before setting Tailscale up as an exit node and thus using it as a traditional VPN.
First, I am going to assume you already have Tailscale deployed on your server & laptop or desktop. That's going to make it a lot easier....hurr hurr.
So fire up your terminal and point it at your server. You can run sudo tailscale status to check the current status of Tailscale. After which you will need to issue this command: tailscale up --advertise-exit-node. This does what it says and tells Tailscale to use the current server as an exit node.
Having done that, in the Tailscale console online click the [Machines] tab. Click the [...] option at the far right of your server listing and select [Edit Route Settings]. This brings up a dialogue box. Check [Use As Exit Node].
Assuming a Windows laptop/desktop, click the Tailscale tray icon. You should see your server listed under [Recommended]. Choose that one.
You should now be connected to the server exit node. Check your IP Check your speed. Not too shabby. Conduct a DNS Leak Check
There you go. Jack's a doughnut, Bob's your uncle. To put your server back, use sudo tailscale up --advertise-exit-node=false
Somebody fact check me. LOL
How about I do the set up first, take my normal notes as I do, and then report back to you. That way I'll have a firmer grip on what needs to be done.
Nah, it's good. I do have a knack for asking silly, basic questions. I certainly don't have the networking prowess and certifications that some of the group here has, and I just want to be cautious, perhaps overly cautious when implementing what I have proposed. I know what an overlay vpn does, and I know what a traditional vpn like say, PIA, does. I just want to proceed with caution because the end use has serious implications if improperly deployed. At the very least I want to make myself confidant that I have covered all bases.
I'm sorry...I'm just asking all the stupid questions up front.
I run a hybrid: 3 VPS and a rack in the closet. I don't get hung up about labels. I leave that to others who obsess about that sort of stuff.
sugar_in_your_tea @sh.itjust.works
It's nice to be commented by someone famous.
Open up the window, let some air into this room I think I'm almost chokin' from the smell of stale perfume And that cigarette you're smokin' 'bout scare me half to death Open up the window, sucker, let me catch my breath
I have tried on numerous occasions to get freedns.afraid.org to work for me. I would be interested in how you got it going when you do get it all worked out.
I worry that having to maintain a VPS myself is tedious and risky
I have three VPS, and a rack in the closet. As far as maintenance is concerned, once you get everything set up and secured, there's not a whole lot to 'maintain', imho. I check logs, make sure all the baddies are at bay and all my good stuff is secured. I leverage technology to help me. I get a summary in the morning telling me all services are up. I do that with n8n, but you certainly could put together something more than my basic n8n flow. I use Docker containers a lot, so I have dockerbot to check that all services are up and running. Dockerbot allows me to stop/start/restart containers. I use UptimeKuma to also keep track of services and send me updates, and I use the iOS app for UptimeKuma which has a handy widget.
Once a month I run sudo apt update / sudo apt full-upgrade to make sure everything is updated. NBD there if you do it regularly and don't skip a lot of updates/upgrades. Backups happen every night using the 3,2,1 method and backed up to an offsite facility. I have a bot that at regular intervals during the day, issue sudo lsof -nP -iTCP -sTCP:ESTABLISHED and several other commands to the servers and reports back.
All of this may sound like a lot, but really once you get everything grooving, it's jippity jippity. I do business with:
- Contabo
- Ethernet Services
- LuxVPS
One thing I've learned through the years is that one man's dream VPS service, is another man's nightmare VPS service. Making recommendations is kind of hit and miss for this reason.
Picked up the story a while back. See, it would not do me good to have this happen to me. If I were forced to rename it, it would be the most deliberate, yet creative, slur against the other product.
+1 for Crowdsec
OP, here is what I do. It might seem overboard, and my way doesn't make it the best, or the most right, but it seems to work for me:
- Fail2ban
- UFW
- Reverse Proxy
- IPtraf (monitor)
- Lynis (Audit)
- OpenVas (Audit)
- Nessus (Audit)
- Non standard SSH port
- CrowdSec + Appsec
- No root logins
- SSH keys
- Tailscale
- RKHunter
The auditing packages, like Lynis, will scour your server, and make suggestions as to how to further harden your server. Crowdsec is very handy in that it covers a lot of 'stuff'. It's not the only WAF around. There is Wazuh, Bunkerweb, etc. Lots of other great comments here with great suggestions. I tend to go overboard on security because I do not like mopping up the mess after a breach.
ETA: just looked up one of your attackers:
218.92.0.201 was found in our database! This IP was reported 64,044 times. Confidence of Abuse is 100%: ISP CHINANET jiangsu province network Usage Type Fixed Line ISP ASN AS4134 Domain Name chinatelecom.cn Country China City Shanghai, Shanghai
busy little cunts.
My two cents: Using a nonstandard ssh port is good for dumping bots. True, you can easily do a port scan against a server and easily find all open ports nbd. But most off-the-shelf bots are looking for standard ports to penetrate. I know that when I format and reinstall the test server, as soon as I change the ssh port, bot noise goes down significantly. So, for a simple config edit and about 2 minutes of time, it seems worth the effort. It's just one layer tho. And yes, it goes without saying to pick a port other than 22, 222, 2222, etc.
Sometimes I'll throw something on the test server just to see how it works and maybe gain a little knowledge along the way.
I saw that Docker Compose Maker in the wild. I could see how that would be very handy for those just getting started in the SelfHosting arena.
I'm not sure if this will help you out since I'm really not sure what your problems are other than getting the reverse proxy to work. So, I'll give you what I've found to work and if it's not what you were looking for then you can just skip over what I"m yammering on about.
The process:
Spin up a container, let's say it's Dozzle and it needs port 1124. Container deployed, so lets put it in reverse proxy:
Issue command together:
sudo nano /etc/caddy/Caddyfile sudo systemctl restart caddy
Enter the following in the Caddyfile:
dozzle.myverycooldomain.duckdns.org:443 {
reverse_proxy localhost:1124
}
Press ctrl x, press y, press enter, and the Caddy server restarts if you indeed issued the commands together. Now go to dozzle.myverycooldomain.duckdns.org for test run.
I've seen it done as such:
sudo ufw deny out 1:19/tcp sudo ufw deny out 1:19/udp sudo ufw deny out 22:52/tcp sudo ufw deny out 22:52/udp sudo ufw deny out 54:79/tcp sudo ufw deny out 54:79/udp sudo ufw deny out 81:122/tcp sudo ufw deny out 81:122/udp sudo ufw deny out 124:442/tcp sudo ufw deny out 124:442/udp sudo ufw deny out 444:65535/tcp sudo ufw deny out 444:65535/udp
But your way seems a bit more elegant
My new strategy is to block EVERY port
Wow! All 65535 +/-, in and out? That's one way to skin a cat.
- Fail2ban
- UFW
- Reverse Proxy
- IPtraf (monitor)
- Lynis (Audit)
- OpenVas (Audit)
- Nessus (Audit)
- Non standard SSH port
- CrowdSec + Appsec
- No root logins
- SSH keys
- Tailscale
- RKHunter
This is a very important point actually. A back up is worthless unless it has been tested.