Who rated this post

Note that filtering it with grep potentially presents a lot of load to the firewall. It's going through the extra debug code for every single drop, then you're discarding 99.9% of the drops with the grep.

Also, the output is buffered, so you won't see output into the file immediately. Instead, a chunk of output will accumulate for a while, then once enough is collected, it will all be handed to grep at once. On a firewall which isn't dropping much, this could result in 10+ drops all showing up at once.

I would do this like so:

fw ctl debug 0
fw ctl debug -buf 32000
fw ctl debug -m fw + drop
fw ctl debug -F "0,0,0,0,0" -F "0,0,0,0,0" ...
# Replace 0,0,0,0,0 with a filter, like used for fw monitor.
# Be sure to filter for both directions in case a reply is dropped.
nohup fw ctl kdebug -T -f 2>&1 >/var/log/<ticket number>_drop.txt &

The '-T' adds timestamps to the debug output.

Might take a little trial and error. The -F filter may need to be applied along with one of the commands. nohup allows the process it runs to survive a SIGHUP, which is the signal a closing shell sends to processes it is running. Normal output will go to /var/log/<ticket number>_drop.txt, and errors will go to nohup.out in the directory where you ran the command.

The ticket number is important so you can tell what exactly that file is for when you look at the system again in six months. To kill the command once you have the data you want, you would use:

ps -ef | grep "kdebug" | grep -v "grep" | awk '{print $2}' | xargs -L 1 kill;fw ctl debug 0

As for how to watch this and send an email when a drop is added, I would have to think about it for a while.