Constant monitoring with 'zdebug drop'

[Matlu]

Hi, Mates.

A query, the command

#fw ctl zdebug drop | grep 'Destination IP'

can be left 'running' in the background in order to 'monitor' a particular IP and know if during the day, the command 'registers' something relevant?

We do this in order to capture traffic at the exact moment, because unfortunately when we apply the command in real time everything works fine, but just when we stop testing, the connection between 1 source and 1 destination begins to fail and we have no records of those precise moments.

Is this possible?

Greetings.

[the_rock]

I let it run in my lab before for a week, never had a problem.

Andy

[Matlu]

Hey, Buddy.

I think my query was not well explained.

I want to leave ‘running’ the zdebug drop for example x 1 week.
So, if for example I connect via ssh and applied the command, it is simply not to interrupt the command with Ctrl+C?

If I close the terminal (Putty, SecureCRT, etc), I can be sure that the command is still running?

[the_rock]

Thats exactly what I did.

[Matlu]

Is it possible to send the output of the command #fw ctl zdebug drop | grep -IP DESTINATION- to a particular ‘path’ of a vsenv (For example in /var/tmp/) and tell it to save the result in a file ending in .txt extension?

[the_rock]

Yup...example

fw ctl zdebug + drop | grep 1.1.1.1 > /var/log/zdebug.txt

[Matlu]

Hi,
The #fw ctl zdebug drop
is 100% reliable for troubleshooting?
The messages that appear here for a particular IP that you are having problems with, for example related to TCP RETRANSMISSIONS, is it reliable to rely on this command or are there other testing options?

[the_rock]

Personally, I would say its reliable, yes, but you would need to use it along with other things, such as tcpdump, logs, fw monitor, etc

Andy

[Timothy_Hall]

For long-term monitoring with fw ctl zdebug + drop (the "+" ensures you see drops by SecureXL which are rather rare) I wouldn't recommend piping the full output to a grep like that.  While the overwhelming majority of packets are accepted and don't show up in the zdebug output, the commencement of a DoS attack or even port scan will cause the amount of output to increase rapidly and potentially impact the performance (or worse) of the firewall.

What I would recommend is something like this in one window:

fw ctl zdebug + drop > output.txt 

Then after a few seconds (long enough for the zdebug to fully initialize) do this in another window:

fw ctl set str simple_debug_filter_daddr_1 DESTINATION_IP

Then after hitting CNTRL+C to stop the zdebug in the first window, now run this command in the second window just in case:

fw ctl debug 0 (to ensure your filter has been unset, the zdebug being stopped should do this automatically though)

The second command will filter the output inside the debug itself and substantially reduce the chance of a DoS flooding the output.  Unfortunately you can't run that fw ctl set command before starting the zdebug as it will just get reset by the zdebug when it starts (and usually when it ends).

If anyone knows how to add/set simple_debug_filter_daddr_1 to the zdebug as part of invoking the zdebug in a single command I'd be all ears.