Is It Best Practice To Use Proxmox Firewall or Firewall In VM?

Discussion in 'Proxmox VE: Networking and Firewall' started by mhayhurst, Jul 5, 2018.

  1. mhayhurst

    mhayhurst Member

    Joined:
    Jul 21, 2016
    Messages:
    39
    Likes Received:
    1
    Hello everyone,

    Just curious what others are doing, but is it best to use Proxmox's firewall that is available in the webgui for each VM or use the VM's firewall available within the OS (e.g. ufw, firewalld, etc...)? I'm on Proxmox 5.2-2 and most of my VM's are a Linux distro (Ubuntu, CentOS, FreeBSD) with the exception of one Windows VM if that makes a difference.
     
  2. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
    Depends on what you want. If you compare stateful packet firewall's, i'd go with PVEs choice. If you need application level firewalling, do it on the guest.

    The Proxmox VE firewall is very capable of securing your machine and cannot be influenced by a faulty VM firewall. I'd recommend to create security groups e.g. for virtual-DMZ etc. and use them to secure your machines. This is very easy and is working for any kind of guest OS.
     
    Knight likes this.
  3. mhayhurst

    mhayhurst Member

    Joined:
    Jul 21, 2016
    Messages:
    39
    Likes Received:
    1
    I want to keep devices on my LAN from accessing certain things like MySQL, Redis, etc... which have open ports but I will also have a few VM's (such as ownCloud) that will be using one of my static IP's with a direct connection to my WAN through a Linux Bridge (no LAN). I like that PVE's firewall is easily accessible from the webgui and more or less provides a central point to make changes on my VMs. You think what I'm trying to accomplish would be a good candidate for PVE's firewall?
     
  4. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
    I already said that I like the PVE integrated firewall and their ability to define and use security groups. You can create perfectly firewalled systems which allow only what you really want including disallowing outgoing connections. I recommend to use always REJECT (INPUT/OUTPUT) and only allow what you really, really need. I have a "catch-all" dmz group that I always put in the last spot that allows outgoing DNS to the servers only, incoming and outgoing ping (often used as simple uptime-check by most programs), linux packages mirror. Further, I have a security group for a webserver with only incoming http and https.
     
  5. kcallis

    kcallis New Member

    Joined:
    Apr 5, 2018
    Messages:
    19
    Likes Received:
    0
    My PVE box is connected to my pfSense box, so I have not tried to make use of the internal PVE firewall. I have been noticing that the console to my VM as well as ssh login constantly drops on a regular basis. Sometime, trying to ssh into the VM, I don't even get a login before it times out. Could that be an issue with me not setting up the PVE firewall or it something going on with my networK? The VM is being bridged to my network so not doing any NAT or anything of that nature.
     
  6. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
    Without setting up the firewall, everything is accepted (so no rules are enabled). Could be network related, but in general not pve-firewall related if disabled.
     
    kcallis likes this.
  7. kcallis

    kcallis New Member

    Joined:
    Apr 5, 2018
    Messages:
    19
    Likes Received:
    0
    Thanks for the response!
     
  8. mhayhurst

    mhayhurst Member

    Joined:
    Jul 21, 2016
    Messages:
    39
    Likes Received:
    1
    Thank you for sharing!
     
  9. Rhinox

    Rhinox Active Member

    Joined:
    Sep 28, 2016
    Messages:
    255
    Likes Received:
    33
    If you know the difference between "REJECT" and "DROP", then you also know why using "REJECT" is bad idea...
     
  10. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
  11. Rhinox

    Rhinox Active Member

    Joined:
    Sep 28, 2016
    Messages:
    255
    Likes Received:
    33
    Good, then I do not have to repeat what's there in "summary" and "update". But there are a few more things to consider, i.e. spoofed source address. Do you realise your system could be tricked by botnet to be part of drdos, sending icmp-packets (as part of your REJECT policy) to innocent victim?
     
  12. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
    This is also true for any spoofed packets that reach your system and you reply (ordinary icmp ping, webserver etc.), isn't it?
     
  13. Rhinox

    Rhinox Active Member

    Joined:
    Sep 28, 2016
    Messages:
    255
    Likes Received:
    33
    True, but only if those packets come to a few opened ports. I think the more I reduce this chance, the better...

    Moreover, I do not use icmp at all (very unsecure protocol) and udp is strictly limited to dn-replies only for my clients. Then it is much easier to deal with tcp (i.e. for web), because if source-ip (be it true or spoofed) does not answer to syn-ack reply from my server in proper manner, it gets banned (again, with "reject"). So victim can get only single packet from me...

    If you think all this is not your problem, maybe you could consider costs: every packet that goes through network-stack needs some resources (cpu, ram, bandwidth). I personally do not want to spend more resources on malformed traffic than absolutely necessary. And there are many more good reasons not to use "reject"...
     
  14. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,845
    Likes Received:
    220
    That is right.

    how do you do that?

    My main problem with DROP is that I often run into problems with guest OSs that e.g. yum update with DROP in place takes forever (waiting for timeout and process is in uninterruptible state) if you're not allowed to connect to the destination. Same for DNS. How do you deal with such situations?
     
  15. Rhinox

    Rhinox Active Member

    Joined:
    Sep 28, 2016
    Messages:
    255
    Likes Received:
    33
    As with everything, you can achieve it in many ways. For example I'm checking my firewall logs with fail2ban and if it finds pre-defined patterns, it takes care of banning IP with invalid traffic. In case of unfinished 3way handshake there is "connection died" or something like that (don't remember, and I do not have remote access to my server righ now). There are many tweaks I included, i.e. using synproxy target, filtering in mangle/prerouting instead of input/filter to speed things up and save resources, rules against port-scanning, against common attacks, rules for port-knocking, using sets, time-dependent rules, dynamic parameters, etc, etc. You can find many tricks for iptables on the net. And upcomming nftables are imho even better!

    In case something does not work, you can always use LOG before DROP (using -limit/-limit-burst with LOG is obligatory, otherwise you might ddos yourself) and check the problem in server-logs, instead of client. With properly configured iptables you can filter full 1gbit without even using all cpu/ram. With improperly configured iptables even 100mbit packet flow can bring it to knees...
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice