In this example, I'm replaying SSH traffic which was captured earlier in the day and is now being replayed.
The objective of this post is just to show that yes the traffic would go to the destination.
Let's first configure the IP address of the eth0 interface and give it a default route. There is really no need for the default route as the source and destination are on the same subnet. I just put it there as it is something I typically do. .
Let's verify the interface configuration
While we are attempting to connect to the host at 192.168.0.3, we will also run tcpdump in the background. This allows us write the traffic to a file and then we can replay later.
Now let's try to connect via SSH to the host at 192.168.0.3. Note the date and time.
These connections have all failed.
Now let's replay this traffic.
Let's see how many packets were captured via tcpdump.
Looks like we got 76 packets. If we compare this with the number of packets replayed via tcpreplay, we will see that the 76 matches the number of packets attempted and the 76 which were successful.
Here we have the packets which were sent via tcpreplay
Here we have what iptables saw
Let's compare the two images to see if we can detect this as replayed traffic.
Source Port 35935: The same in the original pcap and in the iptables log.
Destination Ports 22: The same in the original pcap and in the iptables log.
Sequence numbers: Remain the same across both the pcap and the iptables.log
Acknowledge numbers: Remain the same across both the pcap and the iptables.log
Flags: The flags are the same
Point to note is that while the traffic is replayed to the host, the application layer did not pick this traffic up and attempt create a SSH session.
So from the above, hopefully if anyone else had a similar questions about replaying of the traffic this post may help to clear it up.
Additional Readings:
http://tcpreplay.synfin.net/wiki/usage
http://tcpreplay.synfin.net/wiki/manual
http://tcpreplay.synfin.net/tcpreplay.html
No comments:
Post a Comment