Bug #1473
closedeve-json and tls logs aren't consistently writing to file when browsing bad certificate websites
Description
we're using https://www.ssllabs.com/ssltest/ recent worst websites to test suricata v2.0.8. after each restart suricata detects the tls protocol correctly and writes the entry to the log. however, subsequent websites don't produce any entries in either log. we're are connected to a vpn server running nfqueue. we uses barnyard2 for reporting. here is our kernel and iptables info: 2.6.32-504.16.2.el6.x86_64 and iptables v1.4.7.
Updated by Peter Manev over 9 years ago
off note - a bit old kernel - but that is just me.
How exactly are you doing the tests - can you please provide a bit more detail of your set up?
(if you are using a browser - sometimes browser cache comes into play)
Updated by Complex Integrations over 9 years ago
we're aware of the dated kernel. tried kernel ml but that was worse. anyway, running tests thru browser.
Updated by Peter Manev over 9 years ago
Try doing the tests through a tool - aka wget for example. I have seen a good few cases/set up where browser cache interferes.
Updated by Complex Integrations over 9 years ago
forgot the details. 4 custom build vpn clients, one for each major device (Android, iOS, Mac and Windows), connect to the Softether VPN server over openvpn or l2tp/ipsec. on a side note, softether taps the eth0 card creating a virtual tunnel, but we've noticed suricata doesn't care running NFQ. the tap allows the DHCP server to hand out class B IP addresses to each client. we need it so we can track the user base. we then use suricata to protect the device's vpn connection from the following: compromised IPs, malware, black listed SSLs, and self signed certificates. we have the first three working.
we use eve-json to match cn to issuer name. if a match cert the cert is self signed, so create a live rule swap for subsequent traffic. thx for fixing the memory leak btw. what's happening during our tests is suricata gets a full restart, records the first few TLS transmissions. after that nada. we thought it might be rule based but we set up a rule to look for tls.version:1.2. still no logs.
we can send you our yaml and fw rules, but maybe you can check it out for yourself. fire up a suricata session. browse to any of the really bad sites in the ssllabs.com link. see if you can get suricata to generate logs.
suruicata does it's job. we're just taking it in a different direction. if this is a dead end we'll start looking at luajit running openssl queries against the bad ip address. our users rarely visit self signed sites, so we think it can handle it.
Updated by Complex Integrations over 9 years ago
we'll check out wget. thx for your help.
Updated by Peter Manev over 9 years ago
This is an interesting and useful scenario/set up I think.
Please feel free to share a pcap or your yaml (privately) should you consider.
Try wget and see how it goes - if this is of no help - then we should dig deeper I think.
Updated by Complex Integrations over 9 years ago
we tested wget. it works. wgets logs every entry in eve-json. fyi, we sent you a private email.
Updated by Andreas Herz about 8 years ago
- Assignee set to OISF Dev
- Target version set to TBD
Updated by Victor Julien about 7 years ago
Not sure what to do here. Any updates from anyone?
Updated by Andreas Herz over 6 years ago
- Status changed from New to Closed
Hi, we're closing this issue since there have been no further responses.
If you think this bug is still relevant, try to test it again with the
most recent version of suricata and reopen the issue. If you want to
improve the bug report please take a look at
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Reporting_Bugs