Reconfiguring the logging sources to know about the new device would have been too much of a hassle for a quick test. Reconfiguring the Real Log Server (an rsyslog box) to relay the logs wasn't viable because the source IP in the syslog packets would have reflected the syslog box instead of the origin server.
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 = '192.168.100.100'
sendp(pkt)
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.
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.
ReplyDeleteOK 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
nice post
ReplyDelete