Press March 2019

press@lists.ipfire.org

1 participants
3 discussions

Introducing IPFire's new Intrusion Prevention System
by Michael Tremer 26 Mar '19

26 Mar '19

https://blog.ipfire.org/post/introducing-ipfire-s-new-intrusion-prevention-… With the next IPFire release, we are going to release huge changes to our Intrusion Detection System. Those bring packet analysis that IPFire does to a new level and we are very excited to tell you more about it in this announcement! A lesson in history Snort [1] has been the de-factor Intrusion Detection System (IDS) for years. It started out a long time ago as a Host Intrusion Detection System and over time, features for analysing passing traffic have been added, too. Within its means, it was working perfectly inside of IPFire. During its lifetime, radical redesign never happened. It is only able to run on one processor core at a time and has some other limitations which make it slow and difficult to use. Suricata [2] is the new kid on the block. Having been around for years now, too, and being started to overcome the shortcomings of Snort, it has a much more modern design and great new features. All in all, it is much better than Snort and therefore the IPFire developers have decided to migrate to it. Actions instead of listening One of the biggest changes we are now introducing is that the IDS will no longer just listen to traffic by default. Snort used to analyse a copy of every packet on the network. While it has been scanning it, it was passed on into the network. Any alarms that were raised had to be processed from a log file and potentially created iptables rules that blocked the host where the malicious packet came from. That leaves a tiny chance to an attacker to talk to a host on the network he wants to attack. Suricata takes the packet, analyses it first, and when it has passed all checks, it is being sent onward. Therefore, it is very easy for Suricata to be an Intrusion Prevention System, too. If the packet has failed the tests, it is just being dropped and alert is logged - leaving no chance to even send a single packet to the internal network. Because of that, we have renamed it on the IPFire Web UI and call it "Intrusion Prevention System". After all, that is what we all want: Preventing attacks, not just finding out about them and doing nothing. When we have found an attacker, we want to do something against it. Alternatively, Suricata can operate in a "monitoring only" mode which is helpful for testing rulesets and which is what will automatically be enabled when you have been a user of Snort before. Performance & Automatic Rule Updates Since suricata is holding on to every packet until it is declared safe, this adds some delay to forwarding the packet. In reality this is not noticeable as long as the hardware is powerful enough. In the last Core Update we have already shipped a couple of performance tuning changes that allow suricata to process more data. To make maximum use of your hardware, it uses all processor cores at the same time and analyses packets concurrently - unlike Snort which could only use one processor core at the same time. Rules will also now automatically be updated daily or weekly. Having the latest ruleset allows to detect latest attack vectors and malicious traffic efficiently. The work has been spearheaded by Stefan Schantl, but many days of work of the whole team has gone into this project over the last six months. Although on the surface this looks like small changes, this makes IPFire a much more powerful firewall. Instead of filtering packets by IP address and port - which is highly important though - the new IPS can now look deep into the packets and detect malicious traffic easily. Spyware, malware, viruses as well as SQL injection attacks on web servers and so on are now stopped. With our performance improvements and on top of the IPFire OS, this runs well in large networks where highest security is required. To support us doing this, please donate [3]. This is still not ready for prime-time, yet. We have run many tests, but of course any extra feedback that we can get on throughput, ease of use, or finding any bugs that we might have overlooked is helpful. Help us testing Suricata is available in the latest nightly builds [4]. To get in touch with the developers, sign up to our development mailing list [5] and report any bugs that you find to our bugtracker [6]. [1] https://www.snort.org/ [2] https://www.suricata-ids.org/ [3] https://www.ipfire.org/donate [4] https://wiki.ipfire.org/devel/nightly-builds [5] https://lists.ipfire.org/mailman/listinfo/development [6] https://bugzilla.ipfire.org/

1 0

IPFire 2.21 - Core Update 128 released
by Michael Tremer 13 Mar '19

13 Mar '19

https://blog.ipfire.org/post/ipfire-2-21-core-update-128-released This is the official release announcement for IPFire 2.21 - Core Update 128; another maintenance update with a brand new kernel, introducing TLS 1.3 throughout the whole system and of course a whole package of bug fixes and other improvements. Thanks to everyone who has contributed to this Core Update with either sending in patches, testing, reporting bugs and many many other things. I am quite happy to see the team grow! Thank you very much as well to all of you who have supported our Donations Challenge [1] so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate! Kernel Update The Linux kernel, the core of the IPFire operating system, has been updated to the latest release of the 4.14 branch. We have added some extra patches to improve hardware support and fix some security vulnerabilities. LEDs of PCengines' APU boards are now supported on newer versions of the mainboard and on those boards, the serial console is always enabled. On x86-based systems, we now support up to 64 processors. OpenSSL 1.1.1 & TLS 1.3 We have also updated the main TLS/SSL library to OpenSSL in version 1.1.1. This adds support for TLS 1.3 and of course brings various other improvements with it. On browsers that support it, the IPFire web user interface is now available over TLS 1.3 and any outgoing SSL connection from the firewall supports it, too. We ensure that those connections only use secure and performant ciphers to make connections as fast as they can be. We have also updated the list of trusted Certificate Authorities (CAs). We have removed any previous versions of OpenSSL from the system which will soon be end-of-life. If you have anything custom that you have compiled yourself on your system, please be aware of that and note that you might potentially rebuild your custom software. Add-ons provided by the IPFire Project now support TLS 1.3 as well. If you are running a custom configuration for postfix or haproxy make sure that TLS 1.3 is not excluded from the supported TLS protocols. Performance Tuning The system is now configured to be able to route more packets. During some benchmarks and testing we have discovered that IPFire does not always use the full performance of the hardware underneath it. While most system probably won't benefit much from these improvements, some systems with very fast processor cores will see a 5-10% increase in bandwidth from and to the firewall as well as routed through it. That comes at the cost of very slight increase of power consumption, but we figured that that is a price worth paying not only provide you a secure firewall, but also a fast one. Misc. • A change of the firewall policy might potentially be backwards-incompatible, but we saw no other way to improve the security of the system: Previously, systems on the ORANGE network were always allowed to connect to the Internet on RED. This was carried over from the very beginning of IPFire when the firewall user interface was way more basic and rules to change this behaviour could not be configured at all. Now, it makes a lot more sense to not have this default which was also not well-known and allow users to create rules to either allow or deny traffic like this. • The kdig utility is now available on command line which supports DNS lookups via TLS • Updated packages: apache 2.4.38, apr 1.6.5, curl 7.64.0, dhcpcd 7.1.1, ghostscript 9.26, logrotate 3.15, openssl 7.9p1, postfix 3.3.2, strongswan 5.7.2, tzdata 2018i Add-ons • powertop has been updated to version 2.10 • tor has been updated to version 0.3.5.7 • sendEmail has been fixed by Rob. The script had a wrong file ownership. [1] https://blog.ipfire.org/post/donations-challenge

1 0

Pre-release announcement for IPFire 2.21 - Core Update 128
by Michael Tremer 07 Mar '19

07 Mar '19

Hello editors, this is a pre-announcement email to all editors out there who write about IPFire. We would like to let you know, that we are planning to release the next IPFire release, IPFire 2.21 Core Update 128 next Wednesday, March 14 between 10:00 and 14:00 UTC. We are sending you this announcement to give you some time to prepare a news article about this new release of IPFire to help us make IPFire better-known and of course to make our existing users aware of this exciting new update being ready to be installed. We are very grateful for your support for our project! The changelog can be found here: https://blog.ipfire.org/post/ipfire-2-21-core-update-128-is-ready-for-testi… In this release, we updated the our Linux kernel and have upgraded to OpenSSL 1.1.1 in order to introduce support for TLS 1.3 throughout the whole system. Furthermore we have tuned the throughput of the system on powerful hardware. Please get in touch if you have any further questions. We will send you the final announcement when the update is officially released. Thank you very much for supporting our project! Best regards, -Michael

1 0

2024

2023

2022

2021

2020

2019

2018

Press March 2019