New Platforms

New Suricata Ruleset coming up next week!

Posted on by
Reply

 

We’re excited to have our first ruleset fork within Suricata next week. Since Suricata does have significant uptake on the current pre 1.3 release, and is on a number of commercial products, we’re going to fork here to prevent any compatibility issues.

 

The coming fork will support the 1.3 release of Suricata. The changelog there will let you know about some of the things we’re most excited about. And note that many of it’s new features aren’t ruleset related, such as greatly improved AF_Packet performance. As noted in Eric Leblond’s blog post, a tuned Suricata install using AF_Packet Suricata can EASILY do near 10gig on a commodity $5,000 server with an Intel NIC. Not a stripped down ruleset either! Suricata 1.4Beta has even more tweaks to get this speed, so try it out if you’d like to see something amazing!

 

We’ll plan to push the 1.3+ Suricata version tuesday next week. This won’t affect you if you’re running suricata under 1.3. Download links will respect exact versions and put you in the right place, but we’ll add a set of links to get Suricata-current automatically. More details Monday there, but don’t fear, no existing links will break. We’ll just be adding a new path.

 

The primary new features we’ll be taking advantage of in the new fork will be:

 

file_data

More file_data use. Performance was poor pre 1.2 Suricata. That’s resolved and we’re moving forward!

 

http_user_agent

We love this one. Just the actual user-agent string in a buffer. We can do depth, within and all within that buffer. No more jumping around to find the UA, or matching on “User-Agent|3a|” junk. This will be a major performance gain for Suricata considering how many rules use UA as a match.

 

More information next week as we prepare to push this fork. As always ideas and concerns are welcome on the list or directly at ten.staerhtgnigremenull@staerht.

 

>Suricata 1.0.4 Available!

Posted on by
Reply

>

The OISF development team is proud to announce Suricata 1.0.4, the fourth maintenance release for Suricata 1.0, the Open Source Intrusion Detection and Prevention engine.
Get the new release here:
http://www.openinfosecfoundation.org/download/suricata-1.0.4.tar.gz
Fixes
- LibHTP updated to 0.2.6
- Large number of (potential) issues fixed after a source code scan with Coverity generously contributed by RedHat.
- Large number of (potential) issues fixed after source code scans with the Clang static analyzer.
Because of these fixes upgrading is highly recommended. The fixes are also included in the current git master and the soon to be released 1.1beta3.
Known issues & missing features
As always, we are doing our best to make you aware of continuing development and items within the engine that are not yet complete or optimal.  With this in mind, please notice the list we have included of known items we are working on.
See http://redmine.openinfosecfoundation.org/projects/suricata/issues
for an up to date list and to report new issues. See
http://redmine.openinfosecfoundation.org/projects/suricata/wiki/Known_issues
for a discussion and time line for the major issues.
Cheers,
Victor Julien

Suricata and Snorby Prebuilt Install

Posted on by
Reply

From Philip Bailey at Smooth-Sec, a Suricata and Snorby prebuilt tool. If you’ve been looking to try out Suricata, here’s a great way to test quickly!


——–


Today I’m pleased to announce the release of Smooth-Sec, the ready to go IDS/IPS linux distribution.

Smooth-Sec is a ready to-go  IDS/IPS (Intrusion Detection/Prevention System) linux distribution based on the multi threaded Suricata IDS/IPS engine and Snorby, the top notch web application for network security monitoring. Smooth-Sec is built on Ubuntu 10.04 LTS using the TurnKey Core base as development platform. Functionality is the key point that allow to deploy a complete  IDS/IPS System up and running out of the box within a few minutes, even for security beginners with minimal Linux experience.

This project is not intended in any way to compete with Snorby and his team. Is my wish to maintain the cooperation that we had in the past months with the  the exciting work on SnorbySPA. It is also my wish to cooperate with the Suricata team in the next developments.

website http://bailey.st/blog/smooth-sec/

Regards,

Phillip

>Suricata and Snorby Prebuilt Install

Posted on by
Reply

>From Philip Bailey at Smooth-Sec, a Suricata and Snorby prebuilt tool. If you’ve been looking to try out Suricata, here’s a great way to test quickly!


——–


Today I’m pleased to announce the release of Smooth-Sec, the ready to go IDS/IPS linux distribution.

Smooth-Sec is a ready to-go  IDS/IPS (Intrusion Detection/Prevention System) linux distribution based on the multi threaded Suricata IDS/IPS engine and Snorby, the top notch web application for network security monitoring. Smooth-Sec is built on Ubuntu 10.04 LTS using the TurnKey Core base as development platform. Functionality is the key point that allow to deploy a complete  IDS/IPS System up and running out of the box within a few minutes, even for security beginners with minimal Linux experience.

This project is not intended in any way to compete with Snorby and his team. Is my wish to maintain the cooperation that we had in the past months with the  the exciting work on SnorbySPA. It is also my wish to cooperate with the Suricata team in the next developments.

website http://bailey.st/blog/smooth-sec/

Regards,

Phillip

>Enhancing Coverage with Suricata

Posted on by
2

>At Emerging Threats and Emerging Threats Pro we put up the best coverage we can using the tools possible. Those tools at the moment include Snort from 2.4.0 to current, Suricata all versions and firewall rulesets for IPF, IPFW, pfsense, smoothwall, Cisco, you name it we cover it.

On the IDS engine side we now have an opportunity to expand coverage. Especially with malware, Suricata can do some new things that we just couldn’t do before. We’re moving forward with expanding the Suricata ruleset into taking full advantage of its capabilities. We won’t be removing any functionality from other engines, but we will be doing things with the Suricata ruleset that others just can’t do.

For example, Suricata can recognize protocols like HTTP while it’s reassembling traffic and then apply to relevant rules ONLY to traffic that is HTTP. So this rule (condensed for brevity):

Snort 2.8.6+ version:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”ET USER_AGENTS Suspicious User Agent (MyIE/1.0)”; flow:established,to_server; content:”User-Agent|3a| MyIE/”; http_header; sid:2009991; rev:6;)

A simple rule, and applied to $HTTP_PORTS only. it relies on the http preprocessor to pull the request apart so we can better match and avoid evasions. It’s a good rule, but ONLY if the traffic is on a port that’s in HTTP_PORTS and ONLY if we have the http_inspect preprocessor running and parsing all traffic on that port. 

Suricata Version:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:”ET USER_AGENTS Suspicious User Agent (MyIE/1.0)”; flow:established,to_server; content:”|0d 0a|User-Agent|3a| MyIE/”; classtype:trojan-activity; sid:2009991; rev:6;)

The Suricata version can be applied to ALL ports, and this is important, take this example we hit in the sandnet just this morning:
GET /hosts.txt HTTP/1.1
User-Agent: MyIE/1.0
Host: ad.xxxxx.info:72
Cache-Control: no-cache
Nice normal request, but it was on port 72. If we were not running Suricata we would not have caught this. Suricata got it without breaking a sweat!

The bad guys know we have had limitations in the past parsing and effectively handling anything on off normal service ports. HTTP especially. The Suricata rule catches this easily. It’s recognized as HTTP at reassembly, put through the htp-lib parser for normalization to avoid evasions, and the rule hits without issue. The biggest deal here.. NO PERFORMANCE DEGRADE! We can watch for HTTP on all ports without killing our sensor. In fact, we can do it with less load because we aren’t applying HTTP rules to non-HTTP traffic on our defined HTTP ports. 

Another example, I love this rule:

Snort 2.8.6+ version:
alert tcp $HOME_NET any -> $EXTERNAL_NET [81:8079,8081:65535] (msg:”ET POLICY HTTP GET on unusual Port Possibly Hostile”; flow:established,to_server; content:”GET “; nocase; depth:4; classtype:policy-violation; sid:2006408; rev:8;)

This rule is spectacular for catching trojans and APT threats using HTTP on off ports. But if you turn it on using any version of Snort you’d better have some serious hardware, or a VERY slow traffic flow. It’s just not feasible to apply to every packet, and we have to have a gaping hole in the port ranges just to keep it even mildly stable (ignoring 0-79). 
Here’s the Suricata version:
alert tcp $HOME_NET any -> $EXTERNAL_NET !$HTTP_PORTS (msg:”ET POLICY HTTP GET on unusual Port Possibly Hostile”; flow:established,to_server; content:”GET”; nocase; http_method; classtype:policy-violation; sid:2006408; rev:9;)
And similar versions for other HTTP methods. No performance hit, no misses, and no gaping holes in port coverage. 
So, the point of my post here is to make sure you’re aware that going forward we’re changing the Suricata rules to start taking advantage of new capabilities like this, and if you’re not using Suricata you’re going to be missing a lot of things you’ll wish you hadn’t! Suricata is stable, hitting 10gig easily, and is our official primary engine. We’re not taking any coverage away from other tools, you’ll have the same you always did there. If you want more you need to start looking at Suricata!
Matt

>Daily Update Summary 21/12/2010

Posted on by
Reply

>

Lots of new good things for today’s release:
1. Dynamic rules now have a Suricata optimized version. You’ll find these in a <name>.suricata.rules file in the suricata tarballs. Since suricata does IP matching much differently we don’t have to split into tcp/udp rules, and don’t need to check flags. These will be VERY efficient in Suricata.
2. We now have a snort-edge link to the current ruleset. This will help with some automated downloaders.
3. We had a few instances where depth/within were used when the other should have been. Still works, but Snort 2.9.0.3 now enforces this. We’re glad it does now, and cleaned up the rules that were violating style there. 
Details of the changes today:

[+++]          Added rules:          [+++]

 2012078 – ET POLICY Stunnel Encrypted Tunnel Connection Outbound (policy.rules)
 2012079 – ET POLICY Stunnel Encrypted Tunnel Connection Outbound 2 (policy.rules)
 2012080 – ET POLICY Stunnel Encrypted Tunnel Connection Outbound (policy.rules)
By Mike Iacovacci to detect outbound tunnels. Should be reliable and interesting.

 2012081 – ET CURRENT_EVENTS Possible Bozvanovna Zeus Campaign Config File URL (current_events.rules)
 2012082 – ET CURRENT_EVENTS Possible Bozvanovna Zeus Campaign Binary File URL (current_events.rules)
 2012083 – ET CURRENT_EVENTS Possible Bozvanovna Zeus Campaign SSL Certificate (current_events.rules)
By Kevin Ross. Should be interesting, but high load. These are in but disabled by default.
[///]     Modified active rules:     [///]
I won’t comment on the changes here, most are just performance, depth/within changes, etc. Removing those that are just  for updating to 2.9 http syntax for brevity.
    2180 – GPL P2P BitTorrent announce request (p2p.rules)
    3158 – GPL NETBIOS DCERPC CoGetInstanceFromFile little endian overflow attempt (netbios.rules)
 2000332 – ET P2P ed2k request part (p2p.rules)
 2000333 – ET P2P ed2k file request answer (p2p.rules)
 2000334 – ET P2P BitTorrent peer sync (p2p.rules)
 2000335 – ET P2P Overnet (Edonkey) Server Announce (p2p.rules)
 2000340 – ET P2P Kaaza Media desktop p2pnetworking.exe Activity (p2p.rules)
 2000357 – ET P2P BitTorrent Traffic (p2p.rules)
 2001296 – ET P2P eDonkey File Status (p2p.rules)
 2001297 – ET P2P eDonkey File Status Request (p2p.rules)
 2001298 – ET P2P eDonkey Server Status Request (p2p.rules)
 2001299 – ET P2P eDonkey Server Status (p2p.rules)
 2001664 – ET P2P Gnutella Connect (p2p.rules)
 2001809 – ET P2P Limewire P2P UDP Traffic (p2p.rules)
 2002673 – ET P2P MS Foldershare Login Detected (p2p.rules)
 2002681 – ET WEB_SPECIFIC_APPS Mambo Exploit (web_specific_apps.rules)
 2002761 – ET P2P Gnutella TCP Ultrapeer Traffic (p2p.rules)
 2002814 – ET P2P Direct Connect Traffic (client-server) (p2p.rules)
 2002853 – ET DOS FreeBSD NFS RPC Kernel Panic (dos.rules)
 2003323 – ET P2P Edonkey Client to Server Hello (p2p.rules)
 2003331 – ET WEB_SPECIFIC_APPS PHP Generic membreManager.php remote file include (web_specific_apps.rules)
 2003437 – ET P2P Ares over UDP (p2p.rules)
 2003464 – ET ATTACK_RESPONSE Unusual FTP Server Banner (warFTPd) (attack_response.rules)
 2003465 – ET ATTACK_RESPONSE Unusual FTP Server Banner (freeFTPd) (attack_response.rules)
 2007801 – ET P2P Gnutella TCP Traffic (p2p.rules)
 2008579 – ET SCAN Sipp SIP Stress Test Detected (scan.rules)
 2008582 – ET P2P BitTorrent DHT find_node request (p2p.rules)
 2008583 – ET P2P BitTorrent DHT nodes reply (p2p.rules)
 2008584 – ET P2P BitTorrent DHT get_peers request (p2p.rules)
 2008595 – ET P2P SoulSeek P2P Server Connection (p2p.rules)
 2008611 – ET P2P SoulSeek P2P Login Response (p2p.rules)
 2008641 – ET SCAN sipscan probe (scan.rules)
 2009535 – ET POLICY Telnet to HP JetDirect Printer With No Password Set (policy.rules)
 2009536 – ET POLICY External FTP Connection TO Local HP JetDirect Printer (policy.rules)
 2009706 – ET POLICY Nessus Vulnerability Scanner Plugins Update (policy.rules)
 2009966 – ET P2P KuGoo P2P Connection (p2p.rules)
 2009967 – ET P2P eMule KAD Network Connection Request (p2p.rules)
 2009968 – ET P2P eMule KAD Network Connection Request(2) (p2p.rules)
 2009969 – ET P2P eMule KAD Network Firewalled Request (p2p.rules)
 2009970 – ET P2P eMule Kademlia Hello Request (p2p.rules)
 2009972 – ET P2P eMule KAD Network Server Status Request (p2p.rules)
 2010139 – ET P2P Vuze BT Connection (p2p.rules)
 2010140 – ET P2P Vuze BT UDP Connection (p2p.rules)
 2010141 – ET P2P Vuze BT UDP Connection (2) (p2p.rules)
 2010142 – ET P2P Vuze BT UDP Connection (3) (p2p.rules)
 2010143 – ET P2P Vuze BT UDP Connection (4) (p2p.rules)
 2010144 – ET P2P Vuze BT UDP Connection (5) (p2p.rules)
 2800094 – ETPRO EXPLOIT Microsoft Windows Active Directory Crafted LDAP Request Buffer Overflow (exploit.rules)
 2800095 – ETPRO EXPLOIT Microsoft Windows Active Directory Crafted LDAP Request Buffer Overflow (exploit.rules)
 2800444 – ETPRO DOS IBM DB2 Database Server CONNECT Request Denial of Service (dos.rules)
 2801174 – ETPRO WEB_CLIENT Microsoft Publisher pubconv.dll Size Value Memory Corruption (web_client.rules)

[///]    Modified inactive rules:    [///]

    1699 – GPL P2P Fastrack kazaa/morpheus traffic (p2p.rules)
 2000330 – ET P2P ed2k connection to server (p2p.rules)
 2009973 – ET P2P eMule KAD Network Send Username (p2p.rules)

[---]  Disabled and modified rules:  [---]

 2800929 – ETPRO SMTP Novell GroupWise Internet Agent Content-Type Buffer Overflow (smtp.rules)

[---]         Disabled rules:        [---]

 2800936 – ETPRO FTP ProFTPD FTP Server TELNET_IAC Stack Buffer Overflow (ftp.rules)

[---]         Removed rules:         [---]

 2008596 – ET SCAN Brute Force Exploit Detector HTTP Buffer Overflow Detection (scan.rules)
 2801175 – ETPRO TROJAN Possible Worm.Win32.Qvod.a URL Request (trojan.rules)

>Emerging Threats and Support for Non-Current Versions of Snort

Posted on by
Reply

>

In recent weeks, we’ve had a number of customer inquiries about the level of support we offer for different versions of Snort.  We’ve made it a priority to always put our users first.  Because of this, we have always offered back support of Snort to version 2.4.0 and will continue to do so as long as our users need it.  
Why?  For starters, there are still a large number of businesses running older versions of Snort.  To discontinue support of those versions would not be in keeping with our commitment to our customers.  As long as our users run older versions of Snort we will continue to write rules for it.  In addition, there are inherent security risks in not supporting legacy versions of Snort.  Businesses running older versions of Snort have two options:
  1. Run an outdated ruleset.  The risks in this are obvious.  In order to keep up with the changing threat landscape an up-to-date ruleset is vital.  Running an old ruleset poses a major security risk.
  2. Manually convert current rules for the older engine.  While this seems logical in theory, in practice it introduces an additional security risk—human error.  Having an IT manager comb through an endless stream of rules to ensure they match up with older versions of Snort is inevitably going to result in security holes.  It’s unavoidable.  
Emerging Threats is providing a third option—run a current ruleset that works well on versions of Snort dating back to Snort 2.4.0.  When ET Pro launched, we did so with the intention of supporting multiple engines and we will continue to do so.  As mentioned earlier, as long as our users continue to use historical versions of Snort, we will continue to write rules.