Server & Data Security

[JWW]

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?

 

[fabian]

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?

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

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?

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.

 

[JWW]

Thank you for the response.

If you do not know what OSSEC (or it's more professional fork, WAZUH) 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
WAZUH

ProxMox Firewall currently integrates with Suricata (only a NIDS), yet would do far better integrating with OSSEC / WAZUH (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.

 

[JWW]

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

Inasmuch, it would be good if ProxMox investigated OSSEC / WAZUH 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.

 

[JWW]

Is ProxMox willing to investigate OSSEC / WAZUH for either direct integration "within" ProxMox Firewall or indirect integration "after" ProxMox Firewall?

 

[fabian]

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.

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.

 

[fabian]

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?

 

[JWW]

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/WAZUH".

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/WAZUH 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.

 

[tom]

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.

 

[JWW]

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

 

[JWW]

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.

 

[JWW]

We have found that OSSEC / WAZUH works well as an active response HIDS processed after ProxMox Firewall rules.

We are opting for Hardware RAID10 control of storage devices and hence neither ZFS nor CephFS are appropriate for either the nodes or cluster storage spaces' file system.

 

[mfgamma]

Dear JWW

incredible to have such an attitude towards Proxmox staff.

Moreover I hope you are not linked in any way to WAZUH

 

[DerDanilo]

Over and over again the internet is a weird place with people placing themself above others just because they think they are something better.
Just by reading what @JWW wrote they seem to lack basic knowledge about several things surrounding this subject.

@JWW Please leave the community with this attitude, as you are only focused on your own goals and finding a solution to your problem. As well you do not speak for the community as you are not even a part of it (New member).
With this behavior you do nothing than damaging yourself.

Another question: If you are a professional why hide behind a username? Please don't say that you are a professional while insulting others with every post you write.

Thank you.

 

[JWW]

The "attitude" came from Fabian, who behaved in an incredulously rude, pathetically juvenile and audaciously arrogant, erroneously misassuming, unintelligent and unprofessional manner.

No, we do not represent WAZUH, we were simply asking if Proxmox Staff happened to know whether OSSEC (or the WAZUH fork) conflicts with Proxmox Firewall and to confirm whether inter-nodal data relay is encrypted or not and how it could elsewise be encrypted.

Suricata is a decent NIDS yet OSSEC (or the WAZUH fork) is a superior HIDS.

If you prefer to keep your ports open as a lurid homosexual's anus to be hacked by viral infections and risk client data, that is your irresponsible and idiotic staggering stupidity.

And if you are such anally retarded imbeciles as to think such queries are an attempt of rivalry between an Open Source HIDS and an Open Source Virtualization & Cluster Management Package & Web UI, then perhaps you need to quit the cocaine and anus snorting habit and pull your thumb out of your NAMBLA Soy Boy's bum.

Worse could and ought be said of "dunny boy blow dryer".

The basic lack of knowledge is stuck to your sphincterlingual sycophantism.

Pull your tongue out of Fabian's Wulf Focke derriere port when you are done salivating for his candida infected atrazine and glyphosate laced corn syrup coated soy grits.

 

[guletz]

Hi to all

I do not want to inflame this topic, I only want to try some tehnicaly responses, so be kindly with me

I am a old ossec user, and from my point of view is a good security addition. For guys who did not used some thoughts:
- can be used for linux/win guests/hosts
- have a many good rules to detect some attacks, custom rules are possible
- can be run so you can block bad traffic that match a ossec rule (each rule have a ponder like 1-15)
- you can block traffic using iptables, null route (or even use a custum block roule if I remember), or send a mail
- is using a server/agent architecture with encryption communication, logs are signed
- also it is a third-party app where you can see many info for any agent(php) and reports
- the most important is the fact that ossec have a very very very low false positive detection events
- no kernel modules is need it, is not depend what linux distribution you have (I used from centos 5.x and debian 6.x)

So it is possible to integrate ossec with any iptables rules (like fail2ban). I do it for years....

I think (in my own opinion ) that ossec is very useful in a PMX cluster (for vm and for hosts).

Starting from next year, I want to use active response (bloking bad traffic) but without firewall / iptables because iptables is not multi-host aware. It is a waste of resurces to block the same IP on many different hosts, and your ossec iptables rules can be very big.

So insted of iptables I want to use null route using ospf(my network is ospf aware). In this case if one ip is black-listed on only one host/guest/device, then this ip black-listed on any host/guest/device.

Like I said, be kindly with me, my english is very bad ... but my intention was to help others about this good tool, and maybe some other user will try to investigate ossec.

Suricata it can not identify any unknown attack, but ossec can do this in some situation (file system integrity). Hids is not the same with nids, but both can be better ... then each of them.


PS. It was Christmas, so all of us must try to be good guys these days

 

[JWW]

Thank you for your input "guletz".

Your words were eloquent with genuine intent.

Matthew 5:9