By
convention, use the audits folder to hold current fuzz data.We have also set the logging
level to 5 in order to see more output during the process.
At this point, the process_monitor.py script is up and running and ready to attach to a
process.
Monitoring the Network Traffic
After the fuzzing session is over, we would like to inspect network traffic and quickly
find the malicious packets that caused a particular fault. Sulley makes this easy by providing
the network_monitor.py script.
We will launch the network_monitor.py script from within the virtual machine as
follows:
{common host-guest path to sulley}>mkdir audits\niprint_lpr_515
{common host-guest path to sulley}>python network_monitor.py -d 1 -f "src or dst
port 515" -??“log_path audits\niprint_lpr_515 -l 5
[02:00.27] Network Monitor PED-RPC server initialized:
[02:00.27] device: \Device\NPF_{F581AFA3-D42D-4F5D-8BEA-55FC45BD8FEC}
[02:00.27] filter: src or dst port 515
[02:00.27] log path: audits\niprint_lpr_515
[02:00.27] log_level: 5
[02:00.27] Awaiting requests...
Noticewe have started sniffing on interface [1].We assigned a pcap storage directory and
a Berkley Packet Filter (BPF) of ???src or dst port 515??? since we are using the LPR protocol.
Pages:
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794