FIREWALLD
After Ipfwadm (2.0.X kernels), Ipchains (2.2.X kernels) and Iptables (2.4.X/2.6.X kernels), there is now Firewalld which stands for “Dynamic Firewall”.
This new firewall evolution brings several advantages:
This new firewall evolution brings several advantages:
- no connection cut during firewall reconfiguration,
- use of temporary configuration disappearing after reload/restart,
- services with their characteritics (ports, protocoles, modules) already recorded,
- predefined zones with various levels of trust,
- D-BUS applications support,
- use of “rich rules”.
The configuration consists in putting the server network interfaces into zones with the firewall-cmd command or the firewall-config graphical application.
The built-in configuration is located under the /usr/lib/firewalld directory. The configuration that you can customize is under the /etc/firewalld directory.
It is not possible to use Firewalld and Iptables at the same time. But it is still possible to disableFirewalld and use Iptables as before.
Further information can be found on the Fedora Project website, explanations about “rich rules” included.
A Firewalld beginner’s guide is available. Also, you can look at Thomas Woerner’s video (45min) about Firewalld.
In addition, the Red Hat annual Summit (2014) provided a presentation about the Next Generation Firewall.
The built-in configuration is located under the /usr/lib/firewalld directory. The configuration that you can customize is under the /etc/firewalld directory.
It is not possible to use Firewalld and Iptables at the same time. But it is still possible to disableFirewalld and use Iptables as before.
Further information can be found on the Fedora Project website, explanations about “rich rules” included.
A Firewalld beginner’s guide is available. Also, you can look at Thomas Woerner’s video (45min) about Firewalld.
In addition, the Red Hat annual Summit (2014) provided a presentation about the Next Generation Firewall.
FSS
FSS stands for Forward Secure Sealing. It’s a new mechanism invented by Lennart Poettering’s brother (Beltram Poettering) to secure systemd journal.
As FSS is disable by default, everything starts after running the following command:
As FSS is disable by default, everything starts after running the following command:
# journalctl --setup-keys
This commands generates a key pair of “sealing key” and “verification key”. The verification key is only generated once, is not locally stored and must be recorded by you straight away. There will be no way to recreate it (a QR code is displayed to make the recording easier). Then, the sealing key will be used to sign all the messages written into the journal until a predefined delay is reached (15min by default). At this time, a new sealing key will be generated based on the previous one with no history kept.
An attacker will not be able to sign old messages, the messages showing when he broke into the system included, and will need to remove all of them. The removal of journal messages should make the discovery of any hack easier.
This mechanism doesn’t replace a centralized syslog server but offers minimal security when no such a server is available.
You can also check Lennart Poettering’s presentation on Google+.
An attacker will not be able to sign old messages, the messages showing when he broke into the system included, and will need to remove all of them. The removal of journal messages should make the discovery of any hack easier.
This mechanism doesn’t replace a centralized syslog server but offers minimal security when no such a server is available.
You can also check Lennart Poettering’s presentation on Google+.
Identity Management
There is now a better integration with Active Directory through cross‑realm Kerberos trust. This domain federation on the Kerberos level allows RHEL servers to accept the users coming fromActive Directory domains without loosing their native features in terms of POSIX attributes andSELinux capabilities.
Sources: Red Hat’s blog and Gordon Haff’s blog.
Additional information is available on the Red Hat Enterprise Linux Blog.
Sources: Red Hat’s blog and Gordon Haff’s blog.
Additional information is available on the Red Hat Enterprise Linux Blog.
SELinux
Instead of putting all the system into SELinux permissive mode in order to debug a process, it is now possible to only put this process into SELinux permissive mode. SELinux instructions are available.
In addition, you can look at Dan Walsh’s presentation.
In addition, you can look at Dan Walsh’s presentation.
Also, the HTTPD SELinux policy (Apache and Nginx follow exactly the same SELinux policy) gets a slightly different behavior by default: the httpd_unified boolean that was previouslyenabled in RHEL 6 is now disabled by default in RHEL 7. A dedicated article about this HTTPD SELinux change is available.
No comments:
Post a Comment