some hardening example for PVE on public IP

Dec 22, 2010
78
0
6
Hello, I made a half paranoid (but easy to implement ;) ) configuration for PVE on public IP.

disable NFS:
Code:
#vi "/etc/default/nfs-common"
NEED_STATD=no

Code:
#update-rc.d rpcbind disable

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

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

fail2ban
Code:
#aptitude install fail2ban

basic firewall rules
Code:
 #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
Code:
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

Active Member
Oct 26, 2009
161
2
38
Bern, Switzerland
www.dmd2.com
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

New Member
Sep 13, 2017
4
0
1
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.
 
Last edited:

Alessandro 123

Active Member
May 22, 2016
636
23
38
37
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

New Member
Sep 13, 2017
4
0
1
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...
 

furioussnail

New Member
Sep 13, 2017
4
0
1
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

Active Member
May 22, 2016
636
23
38
37
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

New Member
Sep 13, 2017
4
0
1
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

Famous Member
Apr 19, 2017
1,491
227
83
Brasov, Romania
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

Famous Member
Apr 19, 2017
1,491
227
83
Brasov, Romania
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.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!