Suricata false postives?
-
Well I seem to be having problems with the logs at the moment as you can see from these posts.
https://forum.pfsense.org/index.php?topic=101692.0And as you can see from this post, theres messages appearing in the console but not in the logs.
https://forum.pfsense.org/index.php?topic=101408.0So with these problems its probably best to get a copy all messages out of the fw for any post mortem analysis.
As it happens I've had to reinstall pfsense from scratch again this morning as reseting the system logs and rebooting the fw didnt sort the problem of the disappearing system logs, along with other oddities.
With regard to whether this is absolutely useless duplicate shit, thats a matter of opinion, I guess you cant spot the significance and thus importance of logging data, its how you find anomalies with the system, for when systems get hacked.
-
The choice of exactly what is logged where is handled by the Suricata binary. I think rule syntax errors always go to the Suricata log. You can find it under the LOGS VIEW tab and then selecting the Suricata.log file to view.
-
I know those SC_ERR_INVALID_SIGNATURE messages appear in Services, Suricata, Logs View Tab, Suricata.log, they are the same ones replicated in the system log when you tick the option, Services, Suricata, Global Settings, General Settings section, Log to System Log.
As I cant find the 800 odd snort VRT rules as cited by yourself which dont work with suricata, I've been trying to track this down.
I do see info messages saying
18374 rules successfully loaded, 13 rules failed
but no mention of the 26 messages with SC_ERR_INVALID_SIGNATURE.
So you see there are some inconsistency in whats being said and what is being seen on the ground, and I'm trying to establish what is actually going on.
Likewise in this thread https://forum.pfsense.org/index.php?topic=101682.0
Vane makes the statement Suricata is an Intrusion Detection System (IDS) not an Intrusion Protection System (IPS), you stateThe design simply triggers off any alert and the source and/or destination IP address is inserted into the snort2c table. Because the blocking mechanism depends on libpcap and getting copies of packets for inspection by Suricata or Snort, there is no real support for DROP or REJECT. In other words, there is no inline mode available and thus those rule operations make no sense on pfSense at the moment.
Can I also make a suggestion that the description for the Suricata package description is an accurate representation of its current capabilities.
Currently the Package manager states
High Performance Network IDS, IPS and Security Monitoring engine by OISF
which is misleading to pfsense users looking for an IDS where the functionality doesnt exist in PFSense.
In the long term its not good for business for pfsense in general to claim its got every bell and whistle under the sun, when much of the functionality is yet to be implemented, or is implemented incorrectly so that holes exist in the firewall leaving many users systems vulnerable.
And if you cant provide the link to the request in the Suricata redmine, just say so instead of avoiding the question.
You guys have now been called out, lets see how you respond as your business future depends on it, because this is not the only thing wrong with pfsense!
-
Dude - you realize this package is maintained by a volunteer maintainer for free? WTF is that business you are talking about? WTF is wrong with you? The only "business" here for bmeeks is spending tons of his free time on the project.
You take absolute non-issue and start attacking the volunteer maintainer who's damn one heck of a good job when maintaining these complex Snort/Suricata monsters for users?
You don't like it? You say not good enough? How much did you pay for this? Ah, right - $0. So, if you don't like it and it ain't good enough for you, may I suggest that you move your fucking ass and produce some work to make it better!
Incredible. Is your head overheating from too much tinfoil applied?
:( >:( >:(
-
You obviously dont value the time volunteers as you like to call them, spend time testing the aforementioned output by volunteers and then you have the audacity to shoot the volunteer messenger down in flames.
Dude, you need to re evaluate yourself.
Criticism is constructive feedback, if you hadn't worked it out!
-
That incoherent blurb you produced above has nothing to do with constructive criticism. You've already been told what's the "issue" here, but apparently you are just too dumb to understand it, yet apparently "qualified" enough to advise people about their business. Just piss off, really.
-
Go back to school if you dont understand English, at least then you might be able to learn something.
All I'm asking for is links to the requests in Suricata's Redmine so I can look over these 800 Snort VRT rules which are syntactically incompatible.
You see, here https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Known_issues it states known issues, one being
Signature language support
Suricata supports Snort's signature language. We've focused on Snort version 2.9.x, which is not fully complete yet. ET/ETpro is fully supported, VRT support is steadily improving.
But as the wiki has not been updated since 2.0.3 and Suricata is now 2.0.9 stable and beta 2.1.beta4 with all references to "snort vrt" found in redmine being closed, that doesnt tie in with the pfsense Suricata 2.1.7 version shown in the package manager so I'm still trying to find out what these 800 odd incompatible snort vrt rules are, hence the request for a link.
Instead of wasting so much time getting defensive and abusive why don't you just answer the question by providing a link?
-
If you want to see those ~800 rules incompatible with Suricata to "look over them", then simply go to the damned GUI, enable all categories and all rules and look at the log. Why should I provide you with some links when you behave like an idiot?!
-
But that only gives my 70 odd errors in total now which is not the 800 odd originally cited, I'd already looked at that before.
But heres another problem if you think you are so clever, only the suricata.log messages for the last interface appears in the system log. So a user has no way of knowing if a problem exists on any other interface.
Or should I quote here? https://forum.pfsense.org/index.php?topic=101668.msg567130#msg567130
-
Yeah, so what? How the heck does it matter how many of them are incompatible? They simply are incompatible, noone counts them, except for apparently you because you have no better things to do than harassing maintainers with crap, this ain't any bug but well known Suricata limitation with Snort rules. Move on and perhaps try to produce something useful, like submitting patches upstream to make those rules compatible.
Besides, your testing skills miserably suck, with a short look at the log noise (which you'd like to flood syslog with!!!) shows
3/11/2015 -- 00:47:02 - <info>-- 3 rule files processed. 15947 rules successfully loaded, 1632 rules failed</info>
At minimum, please stop suggesting that everyone's general syslog should be flooded with crap such as:
3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY GIF file magic detected"; flow:to_server,established; file_data; content:"GIF8"; depth:4; fast_pattern; content:"a"; within:1; distance:1; flowbits:set,file.gif; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23647; rev:5;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 850 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY RealNetworks Real Media file magic detected"; flow:to_server,established; file_data; content:".RMF"; depth:4; flowbits:set,file.realplayer; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23645; rev:6;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 853 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY MPEG sys stream file magic detected"; flow:to_server,established; file_data; content:"|00 00 01 BA|"; depth:4; flowbits:set,file.mpeg; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23640; rev:8;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 856 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY MPEG video stream file magic detected"; flow:to_server,established; file_data; content:"|00 00 01 B3|"; depth:4; flowbits:set,file.mpeg; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23639; rev:8;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 859 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY Adobe LZMA compressed Flash file magic detected"; flow:to_server,established; file_data; content:"ZWS"; depth:3; flowbits:set,file.swf; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:35458; rev:1;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1750 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY M4A file magic detected"; flow:to_server,established; file_data; content:"ftypM4A"; depth:7; offset:4; flowbits:set,file.mp4; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:35433; rev:2;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1762 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"FILE-IDENTIFY JPEG file upload detected"; flow:to_server,established; file_data; content:"|FF D8 FF E1|"; depth:4; flowbits:set,file.jpeg; flowbits:noalert; metadata:service http; classtype:misc-activity; sid:35852; rev:1;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1768 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http.</error></error></error></error></error></error></error></error></error></error></error></error></error></error>
FFS. Ktnxbye. >:(