some hardening example for PVE on public IP

[escoreal]

Hello, I made a half paranoid (but easy to implement ) configuration for PVE on public IP.

disable NFS:

#vi "/etc/default/nfs-common"
NEED_STATD=no

#update-rc.d rpcbind disable

disable IPv6:

#vi /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset ipv6.disable=1 quiet"

#vi /etc/postfix/main.cf
inet_protocols = ipv4

fail2ban

#aptitude install fail2ban

basic firewall rules

 #vi /etc/network/if-up.d/firewall

#!/bin/bash

# local
iptables -C INPUT -i lo -j ACCEPT 2> /dev/null || iptables -A INPUT -i lo -j ACCEPT

# established
iptables -C INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 2> /dev/null || iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# icmp
iptables -C INPUT -p icmp --icmp-type echo-request -j ACCEPT 2> /dev/null || iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# ssh
iptables -C INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT 2> /dev/null || iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# block
iptables -C INPUT -j DROP 2> /dev/null || iptables -A INPUT -j DROP

access to server with ssh root login

cat .bash_profile |tail -n5
#############################################################################
#firewall exclude
iptables -C INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT 2> /dev/null || iptables -I INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT
#############################################################################

cat .bash_logout
########################################################
# delete firewall exclude
test $(netstat -an|grep ":22 " | grep ${SSH_CLIENT%% *} | wc -l) -le 1 && iptables -D INPUT -s ${SSH_CLIENT%% *}/32 -j ACCEPT
########################################################

conclusion

With this configuration you only have SSH with brute force protection (fail2ban) running public. To administer your server you need an open SSH root session.
Don't disable NFS or IPv6 if you need it.

tips for more paranoid configuration:
- disable password login for SSH
- use VPN
- use port knocking
- change SSH port
- extend firewall rules

esco

 

[sumsum]

Thank you, for sharing.
for all servers i'm running, I change the SSH port from default 22 to a higher Port. Example 35535. okay - its "security through obscurity", but it keeps the script kiddies away

Tom

 

[furioussnail]

Here is how security through obscurity goes down the drain: nmap -sV <hostname/ip>
By the way, running SSH on an unprivileged port is a bad idea. When you run it on privileged port you know that it was started by root. Otherwise you are not sure who started it.

 

[Alessandro 123]

Here is how security through obscurity goes down the drain: nmap -sV <hostname/ip>

He wrote "skipt-kiddies" for a reason: script kiddies are unable to use nmap to detect the real ssh port. They run the first script found on the net, nothing more.

I was heavy hitted by ssh bruteforce, 24/7. After changing ssh port from 22 to anything else, this kind of attack stopped immediatly.

Anyway, I think PVE should set some security settings automatically on fresh install, something like disabling NFS server if not required, using fail2ban with at least some default rules and so on. Security is never too much.

 

[furioussnail]

I am sure script-kiddies are different from one another with varying level of skills. Also, there aren't only script kiddies on the net.
Why not to restrict access to SSH through the firewall? That would be a much better approach.
Usually the best approach is to provide a system as vanilla as possible but to provide good documentation also. I will try to come up with something and I will post when I will have time. But I don't promise.
fail2ban isn't always the best approach...

 

[Alessandro 123]

Because sometimes you need to access to SSH from multiple connections.

 

[furioussnail]

You can use port knocking then. But a better approach is to use a VPS as an access point and even better in combination with a VPN. And access should be allowed only from the VPN or the VPS. At least that seems more reasonable the moment you start to develop an infrastructure.

 

[Alessandro 123]

Is not always possible and you'll add multiple point of failure. If your VPS goes down for whatever reason, you are totally off from your net.

As wrote, by changing the ssh port i've stopped any brute force attack immediatly. Yes, there are also other approch but this is a simple and effective solution.

 

[furioussnail]

Well, I just proposed a more secure approach. It is easier to filter traffic through a single server rather than doing it on every node. At least for the case when you have an infrastructure of a couple of nodes.
Mostly I wanted to emphasize why running a privileged process on an unprivileged port is a bad idea. But it isn't the end of the world. Just my two cents.

 

[guletz]

As wrote, by changing the ssh port i've stopped any brute force attack immediatly. Yes, there are also other approch but this is a simple and effective solution.

Hi,

A better solution is to leave ssh to run on port 22. But you can create a iptables rules, who can redirect any input to port X(X> 1024) to port 22/ssh(localhost). And of course port 22 is not open from the Internet/WAN.

 

[guletz]

A better idea, is to put a dedicated router(you can use some cheap hw devices) in front of your Proxmox cluster/nodes. And on this router you can put all you need for a good firewall(including some black-lists, brut-force, and so on).
And maybe an IDS/HIDS could be usefull All of this depends on what value is in your data/services.