Tag Archives: freebsd
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.
When Dtrace Fails – Spectacularly
So, I’ve been spending some time looking at Dtrace today. At first, I created a proof of concept on OS X, and then went on to try it in production on FreeBSD.
No such luck. After several hours of trying to figure out what the heck was going wrong, I tried the following experiment, on OS X.
% uname -a
Darwin foo 14.5.0 Darwin Kernel Version 14.5.0: Tue Sep 1 21:23:09 PDT 2015; root:xnu-2782.50.1~1/RELEASE_X86_64 x86_64
% cat hello.c
#include <stdio.h>
int main(int argc, char *argv[]) {
printf( "Hello\n" );
return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 9224 has exited
CPU ID FUNCTION:NAME
0 67470 main:entry 0x7fff583c1c20
And then again on FreeBSD.
% uname -a
FreeBSD bar 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
% cat hello.c
#include <stdio.h>
int main(int argc, char *argv[]) {
printf( "Hello\n" );
return 0;
}
% dtrace -n 'pid$target::main:entry{printf("%#p\n",uregs[R_RBP]);}' -c ./hello
dtrace: description 'pid$target::main:entry' matched 1 probe
Hello
dtrace: pid 84313 has exited
CPU ID FUNCTION:NAME
2 54008 main:entry 0
As you can see, the printed value of the %rbp register is zero on FreeBSD. In my experiments, trying to read that register always yields zero. Similarly, I do not trust it for other registers.
This seems to be a bug in FreeBSD’s Dtrace. At the time of this writing, I have not tried it on recent Illumos.