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
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.
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.
If you need professional help with FreeBSD, you can write to firstname.lastname@example.org.
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
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
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
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.
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.
Ok, so you accidentally type in the root password before using su -.
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.