pete > courses > Crash Course in System Security (CSCI 1005), Winter 2025 > Day 11

New(ish) Tools

• scapy (official documentation)
• netcat (in the "gnu-netcat" package)
• tcpdump

Note: when running scapy, if you get an error about pkg_resources, install the python-setuptools package.

Exercises

Observe DHCP

Start up Wireshark, listen on your machine’s external interface (ie, wlp-whatever), and set the filter for udp. Now, in a terminal, run this command to restart the dhcpcd process (which is what sends DHCP requests and processes DHCP responses):

$ sudo systemctl restart dhcpcd@enp0s3

Observe the sequence of packets in Wireshark. Note the encapsulation. Note the various pieces of information contained in the DHCP response.

Implement ICMP traceroute using Scapy

Because of the way Scapy accesses the network hardware, you’ll need to run your script with superuser privilege (ie, using sudo). This is not busy-work: the intention is for you to implement something you know using a new tool that has much wider uses. We’ll expand on our use of Scapy shortly.

Basic communication

Find another person to work with. Both using netcat, one set up a TCP listener and the other attempt to connect. Observe the packets flowing in Wireshark or tcpdump. Send data, watch the data fly past. Use input redirection on the sender and output redirection on the receiver to send a binary (ie, non-text) file.

Less-basic communication

With one party still using netcat, implement the other side using Scapy. Start by performing the TCP 3-way handshake according to the rules of the protocol (you can use the built-in Scapy functionality for this). Once you’ve got that working, start playing around: cause the contents of the headers to deviate in some small way, observe this deviation in Wireshark, observe the response sent by the target.

Part of the problem with using scapy to inject traffic directly onto the network is that the kernel on your machine has no idea what to do with any responses, and might itself respond… inconveniently (ie, with a RST packet, which the remote machine will interpret to mean that no such connection exists). To get around that, you can instruct the Linux kernel to decline to process any packets received from a particular host:

$ sudo iptables -A INPUT --source <ip address> -j DROP

I think this is a better solution than one which suppressed all outgoing TCP packets with the RST flag set, as sometimes these are useful/necessary.

The kernel will forget about this particular configuration upon reboot, or you can actively remove it with this command:

$ sudo iptables -D INPUT --source <ip address> -j DROP

To verify that this worked, run this command and make sure there are no rules listed under the INPUT chain:

$ sudo iptables -nvL