Server & Data Security

Discussion in 'Proxmox VE: Networking and Firewall' started by JWW, Dec 6, 2018.

  1. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    We are about to build a Cluster with PVE yet have a few queries regarding server and data security.

    Server Security

    Does ProxMox Firewall conflict with OSSEC?

    If ProxMox Firewall and OSSEC do not conflict, then what one processes first?

    And whether they conflict or not, would it be better to disable ProxMox Firewall and run the OSSEC in Active Response Mode with it's default rules on both the host server/s and server cluster?

    Data Security


    Is data relay between a server cluster's nodes encrypted?

    If so, how is it encrypted?

    If not, how can we encrypt it?

    eg: forced SSL on host servers, CephFS or ZFS encryption on the server cluster?
     
  2. fabian

    fabian Proxmox Staff Member
    Staff Member

    Joined:
    Jan 7, 2016
    Messages:
    3,129
    Likes Received:
    478
    I don't know what OSSEC is or how it works. you can use other firewall management tools if you want, whether they get in the way of pve-firewall or not depends on what exactly they do ;)

    not sure what "data relay" is referring to here. the cluster communication for syncing /etc/pve (pmxcfs) uses authenticated and encrypted corosync. forwarding of API requests from one node to another uses TLS with pinned certificates (see man pveproxy). some operations are tunneled via SSH, unless you explicitly opt out (e.g. migration of guests). Ceph is only authenticated, not encrypted - but you probably want to use a separate internal network for Ceph for performance reasons anyway.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    Thank you for the response.

    If you do not know what OSSEC (or it's more professional fork, WAHUZ) is, then maybe you should find out. It is a Host Intrusion Detection System superior to yet inclusive of a Network Intrusion Detection System with "Payment Card Industry Data Security Standard" compliant community "intrusion detection" and "intrusion response" rules that are regularly updated yet can be custom edited.

    Search for:
    OSSEC
    WAHUZ

    ProxMox Firewall currently integrates with Suricata (only a NIDS), yet would do far better integrating with OSSEC / WAHUZ (a far superior HIDS).

    Regarding data relay between cluster nodes (what your software specific jargon terms "syncing"); we verified through the PVE Admin Guide that data relay between cluster nodes is automatically encrypted with PVE issued TSL (i.e. SSL v4) Certificate Authority by default or LetsEncrypt ACME issued TSL (i.e. SSL v4) Certificate Authority by configuration.

    In addition to that, we understand that ZFS can be established during PVE installation as a host server's "root file system".

    We are wondering whether a cluster's file system can be set as ZFS also.

    And we are wondering if the root file system and/or a cluster's file system can be ZFS Encrypted.
     
    #3 JWW, Dec 8, 2018 at 10:14
    Last edited: Dec 9, 2018 at 07:28
  4. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    "ProxMox Firewall currently integrates with Suricata (only a NIDS), yet would do far better integrating with OSSEC / WAHUZ (a far superior HIDS)."

    Inasmuch, it would be good if ProxMox investigated OSSEC / WAHUZ for either direct integration "within" ProxMox Firewall or indirect integration "after" ProxMox Firewall.

    It would be of superb benefit to ProxMox VE user's system security.
     
    #4 JWW, Dec 8, 2018 at 10:36
    Last edited: Dec 9, 2018 at 07:29
  5. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    Is ProxMox willing to investigate OSSEC / WAHUZ for either direct integration "within" ProxMox Firewall or indirect integration "after" ProxMox Firewall?
     
  6. fabian

    fabian Proxmox Staff Member
    Staff Member

    Joined:
    Jan 7, 2016
    Messages:
    3,129
    Likes Received:
    478
    I suggest you read up on PVE and its architecture ;) syncing the cluster file system is not done via TLS, but via corosync like I said. API proxying between nodes happens via TLS. there is only one cluster file system for /etc/pve (pmxcfs), "setting it to ZFS" does not make sense. you can encrypt any storage manually either by that storage's tooling if available, or manually (e.g. by layering dmcrypt underneath it).

    we are not planning on doing any integration for external firewall or intrusion detection system currently. but if the patches are sane and not too intrusive, feel free to contribute something yourself (PVE is open source software after all ;)). in case you require bigger changes, it's best to discuss your approach up front to avoid unnecessary work.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. fabian

    fabian Proxmox Staff Member
    Staff Member

    Joined:
    Jan 7, 2016
    Messages:
    3,129
    Likes Received:
    478
    the suricata integration is just that our firewall rules are generated in a way to allow suricata to hook into it - maybe you can already re-use this to allow your IDS to hook into the packet flow in the same way?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    Would you mind ditching your obnoxious attitude?

    You are not anywhere near as intelligent as you misassume yourself to be; as evidenced by your lazy lack of grammar, inability to recognise and comprehend generic terms that include more than one specific jargon title and failure to understand simple, logical queries or the circumstantially related reasons for them.

    Obnoxious attitude aside, thank you for "trying" to assist our query despite your elsewise rude and arrogant manner.

    We already stated:

    "we verified through the PVE Admin Guide that data relay between cluster nodes is automatically encrypted with PVE issued TSL (i.e. SSL v4) Certificate Authority by default or LetsEncrypt ACME issued TSL (i.e. SSL v4) Certificate Authority by configuration."

    As you twice stated, that relates to data relay between cluster nodes in the form of API Requests.

    And as you twice stated, data relay between cluster nodes in the form of "syncing" is done by corosync; which you initially remarked involves encryption of data relayed between cluster nodes.

    That thoroughly answered the first Data Security query.

    Though we ought notify you that the PVE Admin Guide makes no reference to "corosync" involving data encryption, nor do general sources of information about the methods involved in "corosync", HENCE WHY WE ORIGINALLY ASKED THE DATA SECURITY QUERY:

    "Is data relay between a server cluster's nodes encrypted?"

    If you read the PVE Admin Guide, as you suggest, you will find that during PVE installation you can choose the root file system, including the option of ZFS.

    If you keep reading the PVE Admin Guide, as you suggest, you will find that a server cluster's file system can be configured to CephFS.

    As you ought know, if you read the PVE Admin Guide and are familiar with PVE and it's architecture, the root file system of a host server and the file system of a server cluster are two unique storage regions. The root file system of a host server is unique to the storage devices networked with a single physical server and the file system of a server cluster is distributed across the storage devices networked with one or more host servers.

    We were asking if ZFS was feasible as a server cluster file system concurrent to ZFS as the host server file system/s.

    We asked that because ZFS is superior to CephFS (provided adequate RAM per physical server) and, despite details of ZFS as a root file system for a host server, because the PVE Admin Guide provides no detail about implementing and configuring ZFS as the file system for a server cluster. The only emphasised implementation and configuration detail given in the PVE Admin Guide for server cluster file systems is for CephFS.

    And we were asking if host server root file systems and/or server cluster file systems can be ZFS Encrypted (the optional encryption facility of ZFS).

    We asked that with regards to providing data security against physical access to storage devices and because there was no reference to the capacity of PVE to handle ZFS Encryption on either host server root file systems and/or server cluster file systems.

    Returning to the query about third-party IDS compatability, the potential for OSSEC functions and rules to compatibly operate AFTER ProxMox Firewall functions and rules is EXACTLY WHY WE ORIGINALLY ASKED THE DATA SECURITY QUERY:

    "Does ProxMox Firewall conflict with OSSEC?

    If ProxMox Firewall and OSSEC do not conflict, then what one processes first?"


    Integration is another generic term you fail to comprehend yet feel the need to audaciously and erroneously "educate" us about.

    Contrary to your misassumption, "integration" is not limited to only mean "merger of separate computer programming scripts' function processes into a singular computer programming script".

    Aside from far broader context potentials, the given context can include exactly the compatibility and order of process we originally enquired about, as is the case with existing "integration with Suricata" that we concurrently mentioned when advising ProxMox to investigate the potential of "integration with OSSEC/WAHUZ".

    As obviously evidenced by our written words, we are aware of Suricata as a compatible IDS that processes subsequent to ProxMox Firewall processing and have considered implementing it.

    Moreso, in considering it, it was obviously evidenced that we would prefer to implement OSSEC/WAHUZ because:

    "It is a Host Intrusion Detection System superior to yet inclusive of a Network Intrusion Detection System with "Payment Card Industry Data Security Standard" compliant community "intrusion detection" and "intrusion response" rules that are regularly updated yet can be custom edited."

    In that OSSEC/WAHUZ is a HOST IDS whereas Suricata is a NETWORK IDS, it is "potentially" far more appropriate for ProxMox Virtual Environments that involve both Host Servers, Server Clusters and Virtual Machines

    Yet compatibility and the possibilities of integration need be investigated and the ProxMox Team are the most appropriate party to investigate it.

    ProxMox and ProxMox users might like to thank us for offering that suggestion.

    Also, when you hopefully mature to be an adult man, you might like to offer us your gratitude for helping you to overcome your current tendency towards erroneous arrogance and an obnoxious attitude.

    ;)

    Merry Christmas.
     
    #8 JWW, Dec 11, 2018 at 21:35
    Last edited: Dec 12, 2018 at 00:00
  9. tom

    tom Proxmox Staff Member
    Staff Member

    Joined:
    Aug 29, 2006
    Messages:
    13,159
    Likes Received:
    352
    It looks like I do not like your posting style.

    People try to answer your questions as best as possible in this community but now I have my real doubts that you get further answers.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    "Obnoxious attitude aside, thank you for "trying" to assist our query despite your elsewise rude and arrogant manner."
     
  11. JWW

    JWW New Member

    Joined:
    Dec 6, 2018
    Messages:
    7
    Likes Received:
    0
    We were referring to "Fabian", not "Tom" or "ProxMox Staff" in general.

    In general, thank you ProxMox for providing a good server cluster management platform and a forum for staff and user support.

    Kindly quit the derogatory attitudes towards users' queries though.

    Again, we did you a couple of favours in the process of our queries to you.

    Whereas we thanked you, you are yet to even recognise our favours to you let alone express your gratitude.

    Grow up.
     
    #11 JWW, Dec 11, 2018 at 21:53
    Last edited: Dec 12, 2018 at 00:02
  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