+1 for public keys ONLY in SSH (ChallengeResponseAuthentication no, PasswordAuthentication no, UsePAM yes)
Before firewalling ss -plntss -plnu
Generally if you're offering a publicly accessible service, e.g. webserver nameserver etc. you open up those ports in your firewall, then the firewall is left protecting you from access to all the 'other' ports.
But really you shouldn't have 'other' services publicly accessible in the first place. Use ss -plntss -plnu (or netstat or similar) see what's listeneing on the public (or global) IP, and make sure you actually need those that are running. Disable those you don't (save memory too), and for those you do need, see if you can change the bind interface(s) to the loopback or any VPN interfaces only, via their respective configs.
I'm sure many have Trump-ian levels of confidence in their firewalling skills, but mistakes do happen, firewalls do fail to initialise on boot, best to fail safe and leave the minimum attack surface.
Reduce OS attack surface, e.g. install Alpine. Close all ports with iptables, open only to IPs whitelisted in "KNOWN-IP" chain (automatically updated). At-rest partition encryption with dynamic key fetch on boot. Run inter-VPS traffic through private cloud. Containerize.
@Ouji said:
The point of moving SSH to a custom port is more related to keeping the logs clean, as security through obscurity is not regarded as very good, no?
No. I mean yes. I mean correct. A custom port is going to be found by port scanners eventually. I used f2b for years but in the end discontinued it for a few reasons. First, it is a bit of a memory hog on a super low-end VPS. Second, it loses the chains if you don't restart it after restarting iptables, which is a human error issue (I didn't always remember to do it). Third, I found it is more effective to whitelist allowed ssh IPs.
@cochon said: But really you shouldn't have 'other' services publicly accessible in the first place.
This is true. Typically I do my own minimal Alpine install from scratch and don't need to worry about switching anything off. For CentOS my setup script strips out any packages which are not in a whitelist.
@tetech said:
Typically I do my own minimal Alpine install from scratch ...
i love love Alpine. Do you have some instructions how to build alpine.virt? i am interested to build this with iSCSI very much respect and appreciation. Thanks
@tetech said:
Typically I do my own minimal Alpine install from scratch ...
i love love Alpine. Do you have some instructions how to build alpine.virt? i am interested to build this with iSCSI very much respect and appreciation. Thanks
I think you are more advanced than me because I am not sure what alpine.virt does. I do everything inside a lowend KVM VPS and hot convert it to Alpine.
@tetech if you look at the downloads there is a Virtual kernel. It is very small about 150MB after install. Its great for kvm's that don't require additional kernel packages. Yes, you can install docker, k3s etc ... but you'll need the full standard addition if you plan to use for example iSCSI.
do you have time to try and build the virtual kernel + iSCSI packages? i can offer $15 for a script or detail instructions how to build and output .iso file and maybe @AnthonySmith can provide the same if he see this can be a potential write up in wiki?
@tetech said:
Typically I do my own minimal Alpine install from scratch ...
i love love Alpine. Do you have some instructions how to build alpine.virt? i am interested to build this with iSCSI very much respect and appreciation. Thanks
I think you are more advanced than me because I am not sure what alpine.virt does. I do everything inside a lowend KVM VPS and hot convert it to Alpine.
@tetech said:
Typically I do my own minimal Alpine install from scratch ...
i love love Alpine. Do you have some instructions how to build alpine.virt? i am interested to build this with iSCSI very much respect and appreciation. Thanks
I think you are more advanced than me because I am not sure what alpine.virt does. I do everything inside a lowend KVM VPS and hot convert it to Alpine.
How to "hot convert it to Alpine"?
Get apk-tools-static, mount spare partiton (e.g. swap), run apk.static to install alpine-base onto it, reboot to partition, reformat old partition and repeat process. Never had it fail yet. although Joyent images can be challenging.
@tetech said: Third, I found it is more effective to whitelist allowed ssh IPs.
That's my approach now. I am also experimenting with Wireguard, Zerotier and Tailscale for that. Just upgraded to OpenSSH8.3 so I can use my U2F key on my SSH keys.
@beagle said:
I'm assuming most people create an additional user to admin their servers.
What's your view on setting this user as passwordless for sudo?
Not an expert on security, but I prefer to have ssh login through keys only. The user itself can sudo through its password. This is like having two separate passwords. An attacker might get access to the ssh key, but then the password is still required. The user has nothing going on in the home folder.
@beagle said:
Only open the ports needed on the firewall
Create admin/sudo user
Custom SSH port
Keys only authentication
Disable root login
Setup Fail2ban
This except fail2ban, unless you're hosting Wordpress or similar (and in that case i'd suggest changing wp-admin into wp-my-admin)
i change the ssh port first. And then i deactivate the password login. Then i setup SSH Keys for more comfort and security. And then i block some Countries (Spam).
Have a nice day
@beagle said:
What's your view on setting this user as passwordless for sudo?
For specific commands in sudoers maybe, for any command, like on a LiveCD NO. It requires too much self discipline in never leaving yourself logged in or a PC session unlocked.
@beagle said:
What's your view on setting this user as passwordless for sudo?
For specific commands in sudoers maybe, for any command, like on a LiveCD NO. It requires too much self discipline in never leaving yourself logged in or a PC session unlocked.
I always type exit in a session if I'm leaving, but I get where you come from.
I've a little bash script to setup my VPS, but it is missing the fail2ban install. The script usually setups a new user, adds a SSH key to authorized_keys, change the timezone and disables root login and pwd auth. It also installs UFW. I just forked from someone else and changed some stuff for me.
Currently I'm experimenting with U2F for 2FA and Krypton for 2FA as well. Just got my first yubikey, I'm gonna try U2F with resident keys to see how it goes.
I'm not good at it, but could someone explain why people install and setup UFW or any other firewall? What does it give? I mean if all the ports are open, how someone could hurt if he doesn't know the password of the VPS and don't know the keys? Let imagine I have no UFW, I have opened all the ports. How could someone harm me let's say using 25, 4140 and 4540 ports. For example?
@Anon said:
I'm not good at it, but could someone explain why people install and setup UFW or any other firewall?
You're always careful to lock your flat door when you go out, but one day you forget. It's comforting to know that the flat complex has a main door with a keypad entry keeping random people out from discovering your door is actually unlocked today.
Minimize the attack surface as much as possible. If Exim is listening on port 25 and has a CVE, or you haven't updated it in a while and your old version has a CVE, your VPS will be pwned within days, or sometimes within minutes.
tcp/4140 is assigned to Cedros fraud detection; does anyone actually use that?
Another weak analogy :
you know that sound your flat key makes, as it scrapes across all your door surfaces as you stumble around in the dark hallway, trying to find the keyhole. Imagine doing it without the audio feedback : Packet DROP in a nutshell.
Like it was said, you never know when something you are hosting has a vulnerability. Sometimes the CVE takes a while to appear and all that time you would be vulnerable.
@Anon said:
I'm not good at it, but could someone explain why people install and setup UFW or any other firewall? What does it give? I mean if all the ports are open, how someone could hurt if he doesn't know the password of the VPS and don't know the keys? Let imagine I have no UFW, I have opened all the ports. How could someone harm me let's say using 25, 4140 and 4540 ports. For example?
You need to be sure that there are no applications listening on the ports. If you are no good at sysadmin stuff, I rather you setup a firewall. If something you need isn't working, you open the required port. Other stuff is automatically banned from receiving requests, including things that you may not be aware of.
Comments
firewall.
poweroff when not in use.
Custom SSH port
Firewall
Put TSA lock on server
I bench YABS 24/7/365 unless it's a leap year.
Limit access to sensitive areas to local IP range only
• Temporary Disposable Email ↔ Shared Hosting Deals •
Only open the ports needed on the firewall
Create admin/sudo user
Custom SSH port
Keys only authentication
Disable root login
Setup Fail2ban
+1 for public keys ONLY in SSH (ChallengeResponseAuthentication no, PasswordAuthentication no, UsePAM yes)
Before firewalling
ss -plntss -plnuGenerally if you're offering a publicly accessible service, e.g. webserver nameserver etc. you open up those ports in your firewall, then the firewall is left protecting you from access to all the 'other' ports.
But really you shouldn't have 'other' services publicly accessible in the first place. Use
ss -plntss -plnu(or netstat or similar) see what's listeneing on the public (or global) IP, and make sure you actually need those that are running. Disable those you don't (save memory too), and for those you do need, see if you can change the bind interface(s) to the loopback or any VPN interfaces only, via their respective configs.I'm sure many have Trump-ian levels of confidence in their firewalling skills, but mistakes do happen, firewalls do fail to initialise on boot, best to fail safe and leave the minimum attack surface.
Reduce OS attack surface, e.g. install Alpine. Close all ports with iptables, open only to IPs whitelisted in "KNOWN-IP" chain (automatically updated). At-rest partition encryption with dynamic key fetch on boot. Run inter-VPS traffic through private cloud. Containerize.
The point of moving SSH to a custom port is more related to keeping the logs clean, as security through obscurity is not regarded as very good, no?
No. I mean yes. I mean correct. A custom port is going to be found by port scanners eventually. I used f2b for years but in the end discontinued it for a few reasons. First, it is a bit of a memory hog on a super low-end VPS. Second, it loses the chains if you don't restart it after restarting iptables, which is a human error issue (I didn't always remember to do it). Third, I found it is more effective to whitelist allowed ssh IPs.
This is true. Typically I do my own minimal Alpine install from scratch and don't need to worry about switching anything off. For CentOS my setup script strips out any packages which are not in a whitelist.
i love love Alpine. Do you have some instructions how to build alpine.virt? i am interested to build this with iSCSI very much respect and appreciation. Thanks
I think you are more advanced than me because I am not sure what alpine.virt does. I do everything inside a lowend KVM VPS and hot convert it to Alpine.
@tetech if you look at the downloads there is a Virtual kernel. It is very small about 150MB after install. Its great for kvm's that don't require additional kernel packages. Yes, you can install docker, k3s etc ... but you'll need the full standard addition if you plan to use for example iSCSI.
do you have time to try and build the virtual kernel + iSCSI packages? i can offer $15 for a script or detail instructions how to build and output .iso file
and maybe @AnthonySmith can provide the same if he see this can be a potential write up in wiki?
what you think?
How to "hot convert it to Alpine"?
my offer is open to anyone if tetech declines.
No time in the near future, so others please take it!
Get apk-tools-static, mount spare partiton (e.g. swap), run apk.static to install alpine-base onto it, reboot to partition, reformat old partition and repeat process. Never had it fail yet. although Joyent images can be challenging.
That's my approach now. I am also experimenting with Wireguard, Zerotier and Tailscale for that. Just upgraded to OpenSSH8.3 so I can use my U2F key on my SSH keys.
I'm assuming most people create an additional user to admin their servers.
What's your view on setting this user as passwordless for sudo?
ed25519 keys, fail2ban, ufw and different port of SSH
Not an expert on security, but I prefer to have ssh login through keys only. The user itself can sudo through its password. This is like having two separate passwords. An attacker might get access to the ssh key, but then the password is still required. The user has nothing going on in the home folder.
This except fail2ban, unless you're hosting Wordpress or similar (and in that case i'd suggest changing wp-admin into wp-my-admin)
i change the ssh port first. And then i deactivate the password login. Then i setup SSH Keys for more comfort and security. And then i block some Countries (Spam).
Have a nice day
Greetings from 🇩🇪 North Rhine-Westphalia, Xenic.
For specific commands in sudoers maybe, for any command, like on a LiveCD NO. It requires too much self discipline in never leaving yourself logged in or a PC session unlocked.
I always type exit in a session if I'm leaving, but I get where you come from.
I've a little bash script to setup my VPS, but it is missing the fail2ban install. The script usually setups a new user, adds a SSH key to authorized_keys, change the timezone and disables root login and pwd auth. It also installs UFW. I just forked from someone else and changed some stuff for me.
Currently I'm experimenting with U2F for 2FA and Krypton for 2FA as well. Just got my first yubikey, I'm gonna try U2F with resident keys to see how it goes.
I'm not good at it, but could someone explain why people install and setup UFW or any other firewall? What does it give? I mean if all the ports are open, how someone could hurt if he doesn't know the password of the VPS and don't know the keys? Let imagine I have no UFW, I have opened all the ports. How could someone harm me let's say using 25, 4140 and 4540 ports. For example?
You're always careful to lock your flat door when you go out, but one day you forget. It's comforting to know that the flat complex has a main door with a keypad entry keeping random people out from discovering your door is actually unlocked today.
Minimize the attack surface as much as possible. If Exim is listening on port 25 and has a CVE, or you haven't updated it in a while and your old version has a CVE, your VPS will be pwned within days, or sometimes within minutes.
tcp/4140 is assigned to Cedros fraud detection; does anyone actually use that?
Another weak analogy :
you know that sound your flat key makes, as it scrapes across all your door surfaces as you stumble around in the dark hallway, trying to find the keyhole. Imagine doing it without the audio feedback : Packet DROP in a nutshell.
Like it was said, you never know when something you are hosting has a vulnerability. Sometimes the CVE takes a while to appear and all that time you would be vulnerable.
I only allow ssh from allowed ip addresses via iptables
I have a script that reverse looks up my dynamic ip
You need to be sure that there are no applications listening on the ports. If you are no good at sysadmin stuff, I rather you setup a firewall. If something you need isn't working, you open the required port. Other stuff is automatically banned from receiving requests, including things that you may not be aware of.
Deals and Reviews: LowEndBoxes Review | Avoid dodgy providers with The LEBRE Whitelist | Free hosting (with conditions): Evolution-Host, NanoKVM, FreeMach, ServedEZ | Get expert copyediting and copywriting help at The Write Flow