handling tzsp traffic from Mikrotik RB2011 router

[markd...@gmail.com]

Hi

I am just trialing Security Onion and have no option but to use tzsp traffic stream from a Mikrotik RB2011 router but can find no info on how to do that with SO.

there is an article here for using trafr with Suricata to do this -
http://robert.penz.name/849/howto-setup-a-mikrotik-routeros-with-suricata-as-ids/

is there any way I could get this method working with Security Onion?

thanks
M

[markd...@gmail.com]

I managed to get something but it is not working yet.
I have installed trafr and tested it working to get traffic from Mikrotik router via packet sniffer ok.

I run into problems at the line where I have to try to integrate trafr with suricata as per the link in previous comment which says use...

trafr -s | suricata -c /etc/suricata/suricata.yaml -r -

the only thing I could get to work was by changing the above line to the one below but it creates some log file that is only partially readable and certainly cannot see any of the data sent from the Mikrotik in Sguil when I run it to check.

trafr -s | suricata -c /etc/nsm/testonion-eth1/suricata.yaml --pfring=eth1 -l /var/log/ --runmode autofp

I am not really sure what that line does but when looking for the error I got with -r the suggestion was to put --runmode autofp.

[markd...@gmail.com]

got it working using this:

sudo trafr -s | sudo suricata -c /etc/nsm/testonion-eth1/suricata.yaml --pfring=eth1 -l /nsm/sensor_data/testonion-eth1

so I can now see Mikrotik traffic from the RB2011 that is sent using the packet sniffer option on the router, and using the line above trafr strips the tszp data and Security Onion can read it.

the next problem is how to add that into the startup and stop the original version in a way that wont be overwritten on upgrade or leave multiple processes running but I will log that as a seperate issue.

[markd...@gmail.com]

actually I think I spoke too soon I dont think it is working.

I am recieving input from Mikrotik router via packet sniffer, but I dont think trafr is successfully removing tszp maybe.

can anyone confirm if the logs in :
/nsm/sensor_data/testonion-eth1/dailylogs/2017-04-04/snort.log.xxxxxxxx

should be full of weird symbols or should they be readable.

when I tail -f them, it is rapidly going past, so suggests it is getting the packets ok, but they are not readable and sguil and ELSA are not showing any data from todays date.

trafr is running and my process is listed but maybe this method doesnt work as I had hoped.

[Doug Burks]

Hi markdkberry,

I have no experience with Mikrotik or trafir, but have you considered
the following ideas?

First, does trafr support sending traffic to an ethernet interface
like eth1? If so, that's the best way to feed Suricata (and all of
our other sniffing processes) without having to rewrite config files
and startup scripts.

If trafr doesn't support sending traffic to an ethernet interface,
then perhaps you could pipe the trafr output into tcpreplay reading
from stdin to then send the traffic to your ethernet interface
configured for sniffing.

Hope that helps!

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[markd...@gmail.com]

I have now had some success using tcpreplay on a SELKS test server using tzsp2pcap to strip the tzsp from the Mikrotik packet sniffed traffic then bash pipe it to a dummy Eth10 interface. This worked up to a point. I have run into some traffic issues when using 'All interfaces' and had to sniff only the relevant interfaces and send that from MTik, I also hit memory issues but that maybe unrelated and it was all v fiddly to get working with installing tzsp2pcap to work with screen and tcpreplay

if anyone wants to give it a go with tzsp2pcap I used the following two articles to base my build on. I will be posting more details to Mtik forums when I am certain my adaptation worked. (The second needs translating from indonesian)

https://bl0gg.ruberg.no/2015/10/streaming-pcap-to-a-dummy-interface/
http://budi.khoirudin.com/2016/12/mikrotik-selks-attacker-telolet-attacker.html

I hope to get back to testing it on SOnion but to be honest until you have ELK up on it I will probably wait, the upshot of working with SEKLS was more appealing for the client than the current SOnion with pretty charts etc... even though your build is more thorough with Bro and ELSA , client romanticism counts for a lot as we know.

I think trafr could work but would need tcpreplay as suggested but I also think this may cause some memory / process issues along the way. again until I can confirm more about what I did get working, hard to say.

[markd...@gmail.com]

just saw you have a beta-test ELK version available, so will maybe try and get tzsp2pcap & tcpreplay up on that and let you know how it goes in test setting.

[Doug Burks]

On Fri, Apr 7, 2017 at 12:42 AM, <markd...@gmail.com> wrote:
> just saw you have a beta-test ELK version available, so will maybe try and get tzsp2pcap & tcpreplay up on that and let you know how it goes in test setting.

I wouldn't call it "beta-test", as it is "pre-alpha", but please do
test and let us know how it goes!


--
Doug Burks

[markd...@gmail.com]

ok here is where I have got to. (I noticed ELSA isnt working but I think that is intended)

I installed the eval copy of SOnion with ELK as per your website,( btw you may want to look at Evebox it is also a great front end for alerts, may only be suricata though its a very smooth gui to work with - https://github.com/jasonish/evebox )

I ran into problems getting pcap to compile when trying to make tzsp2pcap so had to give up on that ( if anyone knows a fix to locate the libcap-dev folder when installed, I would love to know it.)

so I went back to trafr and tcpreplay, and eventually got it to work , kind of, using the below line in a ssh shell but it doesnt seem to be being read properly by snort in the ELK eval version.

trafr -s | tcpreplay --topspeed -i eth1 -

tested trafr working by itself works good. ran it to a pcap dump file and confirmed via wireshark that when I visit testmyids.com it is being sniffed and arriving.

but when I run the command above, I see traffic arriving at eth1 ok, but no alerts occur in SOnion, when I visit testmyids.com it doesnt flag, so not sure what is not working nor quite how to confirm what SO is seeing.

Is this because ELK and Eval is limited in some way, or do I need to adjust Snort settings? when I run the trafr & tcpreplay process, I get a warning message that the snaplen is 4096 bytes and it may be truncated but I dont believe it is since it shows up fine in pcap file test.

any thoughts?

[markd...@gmail.com]

rechecked a few things to make sure Ididnt miss something,

the home_net setting is set as 192.168.88.0/24 in the snort.conf under /etc/nsm/interfacename/ and in the /opt/bro/etc/network.cfgs but no data is making it to the Squil or Squert alert windows from those networks except broadcast alerts. even when seeing it arrive at the eth1 interface using ifconfig.

I wondered if the trafr is properly stripping the tzsp and checked the wireshark pcap test file again. I noticed tzsp is listed as a field still on each packet, but normally if tzsp is in place in a packet you need to use expression filter in wireshark to see the packets, the fact I dont need to do that suggests it is correct. have shared a screenshot of the pcap in wireshark in case I am missing something.

[Doug Burks]

Have you checked the Bro logs in /nsm/bro/logs/current/ to see if Bro
is properly decoding the traffic?