Tag Archives: security
The Case of the Disappearing Firewall
I was configuring a firewall on a FreeBSD server and setting ssh to be in-house only. The firewall was previously incomplete, so it didn’t surprise me at the start that is was disabled — but it would haunt me later.
I added the following rule for ssh.
pass in on $ext_if proto tcp from 192.0.2.0/24 to any port ssh
And then enabled it with these commands.
pfctl -f /etc/pf.conf pfctl -e
Then under testing, I found out that I could always connect from my local machine, I didn’t have to be logged in on the customer’s network.
After a few false starts, and lots of reading to be absolutely sure my ssh rule was indeed correct (it is) I found the following in the root’s crontab.
*/2 * * * * /sbin/pfctl -d
Every two minutes, it’s disabling the firewall. And surely enough, after removing that crontab entry, the firewall worked as it should.
Final Words
The moral of the story is this. Always, always, test what shouldn’t work when setting up firewalls and other security sensitive configurations. Many, if not most, security vulnerabilities comes from people failing to test for the right error messages when configuring security.
Contact
If you need professional help with FreeBSD, you can write to johann@myrkraverk.com.
Follow me on Gab: @myrkraverk and/or Twitter: @myrkraverk.
Mitigating Linux TCP Vulnerabilities with UFW
On June 17, 2019, Netflix released a security bulletin about vulnerabilities in the Linux and FreeBSD kernels. Here we will only discuss the vulnerabilities affecting the Linux kernel and how to apply the mitigations with ufw.
The vulnerabilities discussed are: CVE-2019-11477, CVE-2019-11478 and CVE-2019-11479.
Netflix mentions patches and a choice of mitigations. Here we discuss only type of mitigation.
In the Netflix bulletin, we have mentions of sysctl and iptables. And fortunately, ufw does take care if this for us, albeit in a non-obvious way. The ufw config files are kept in /etc/ufw and that’s where we find before.rules and sysctl.conf.
So we edit sysctl.conf first, and make sure tcp_sack is set to zero.
## Setting this to zero to mitigate CVE-2019-11477, CVE-2019-11478. net/ipv4/tcp_sack=0
Additionally, we can explicitly set the tcp_mtu_probing to zero, but that’s probably not necessary.
## Setting this to zero to mitigate CVE-2019-11479. net/ipv4/tcp_mtu_probing=0
Then, we edit before.rules and add a firewall rule to drop small MSS packets, right after we accept everything on the loopback.
# allow all on loopback -A ufw-before-input -i lo -j ACCEPT -A ufw-before-output -o lo -j ACCEPT ## Mitigate CVE-2019-11479. -A ufw-before-input -p tcp -m tcpmss --mss 1:500 -j DROP
Finally, we reload the ufw to enable the new settings.
ufw reload
Disclaimer. I hope I got everything right, and these mitigations actually do work. In the event I misunderstood the Netflix recommendations and/or misapplied anything, I waive all responsibility. You are after all responsible for your own system.
Remember to Delete the Root Password from Your History File
Ok, so you accidentally type in the root password before using su -.
$ ThisIsMyRootPassword
Now you have to remember to delete it from your history file. This is somewhat non-obvious, because the history file is typically saved on successful exit.
So if you immediately do something like this.
$ tail -2 ~/.bash_history ssh somehost su -
There’s nothing suspicious in the history file.
So, log out, then log back in. Typically that means closing your ssh session, or terminal tab, and open a new session.
Now you see the password in the history file.
$ tail -2 ~/.bash_history su - ThisIsMyRootPassword
So fire up an editor and delete the line.