Saturday, November 11, 2017

Syslog relay with Scapy

I needed to point some syslog data at a new Security Thing that was being evaluated.

Reconfiguring the actual logging sources to know about the new box would have been a hassle for a quick test. Reconfiguring the Real Log Server (an rsyslog box) to relay the logs wasn't an option because the source IP in the syslog packets wouldn't have been correct.

A few lines of python running on the existing rsyslog box did the trick:

 #!/usr/bin/env python2.7  
 from scapy.all import *  
 def pkt_callback(pkt):  
   del pkt[Ether].src  
   del pkt[Ether].dst  
   del pkt[IP].chksum  
   del pkt[UDP].chksum  
   pkt[IP].dst = ''  
 sniff(iface='eth0', filter='udp port 514', prn=pkt_callback, store=0)  

This script has scapy collecting frames matching udp port 514 (libpcap filter) from interface eth0. Each matching packet is handed off to the pkt_callback function. It clears fields which need to be recalculated, changes the destination IP (to the address of the new Security Thing) and puts the packets back onto the wire.

The source IP on these forged packets is unchanged, so the Security Thing thinks it's getting the original logs from real servers/routers/switches/PDUs/weather stations/printers/etc... around the environment.

I'd expected to need to filter out the packets that scapy is sending (don't listen to and re-send your own noise), but that doesn't seem to have been necessary.


  1. hi Chris, nice quick scapy hack! For longer term we do a fair bit of fwd'ing at our syslog aggregation point before to a whole lot of other consumers e.g. a feed to SIEM and splunk etc... but we're still on syslog-ng I haven't yet pushed myself to learn/move to rsyslog. I would think rsyslog could fwd and spoof the original source ip too.

    OK it seems an rsyslog module called omudpspoof does it, maybe installing modules is service impacting though(?)

    p.s. great content across the blog. Always appreciate the quality of your analysis and info