Cacti remote code and SQL injection vulnerability

Published: 2006-12-28
Last Updated: 2006-12-29 04:30:11 UTC
by Jim Clausing (Version: 1)
0 comment(s)
Secunia has published a bulletin regarding vulnerabilities in the popular open-source network management web application, Cacti (versions <= 0.8.6i which is the current version).  The vulnerabilities include SQL injection and possible remote code execution.  There is public proof-of-concept code available.  If you run Cacti, you are urged to read the work-arounds in the bulletin until a patch/new version is released.

Secunia bullentin:
Cacti home:

Jim Clausing,  jclausing %% at %% isc dot sans dot org
0 comment(s)

What should I do with these gift cards?

Published: 2006-12-28
Last Updated: 2006-12-29 03:58:56 UTC
by Jim Clausing (Version: 1)
0 comment(s)
My kids never know what to get me for birthdays or Christmas, so they get me gift cards to <insert electronics chain here> and <insert bookstore chain here>, which frankly is fine with me.  So the question for our faithful readers is what should I use these gift cards to buy this year?  I've read 4 of the 7 books on Richard Bejtlich's  Digital Security Postgraduate School, 4 of the 7 on his Digital Security War College, and 6 of the 7 on his Digital Security Bootcamp lists, but what other ones should I look at?  How about cool new gadgets?  I've got a friend who has a USB HDTV receiver/tuner to watch over-the-air HDTV, he thinks I should look at one of those, what do you think?  I'll collect responses and post your thoughts next week.

Jim Clausing, jclausing ++ at ++ isc dot sans dot org
0 comment(s)

Port 32000 spike, got packets?

Published: 2006-12-28
Last Updated: 2006-12-29 02:20:08 UTC
by Jim Clausing (Version: 1)
0 comment(s)
We've noticed in the dshield data and from some of our users, that there was a very large spike in activity on TCP port 32000 yesterday.  While it appears that the vast majority of this traffic seems to be coming from one source IP, it also seems to have hit a large chunk of internet address space.  At this point, the spike may very well be over, but if anyone has more than just SYN packets (like had a netcat listener on that port) and can share the packets with us so we can try to figure out what application they might have been looking for, please submit via the contact page.

Jim Clausing, jclausing -- at -- isc dot sans dot org
0 comment(s)

Archiving the snort tips

Published: 2006-12-28
Last Updated: 2006-12-28 18:07:55 UTC
by Jim Clausing (Version: 2)
0 comment(s)
Joel's 'snort tips' article has now found its longterm home, here, and Joel's new handler page is here.
Keywords: snort
0 comment(s)

The Snort Top 10

Published: 2006-12-28
Last Updated: 2006-12-28 15:53:59 UTC
by Joel Esler (Version: 4)
0 comment(s)
I work with SNORT®..... constantly. It's my job to do so. I've been using Snort for many years, I teach classes on how to configure it, I teach classes on how to write Snort rules. I've been using Snort and setting up Sourcefire and Snort devices on hundreds of different networks for years on end now.

I am frequently asked questions, many of the questions are the same things over and over again, and I always see the same mistakes being made when setting it up. So, i've compiled a list of the top ten mistakes and commonly misconfigured or overlooked things when configuring everyone's favorite IDS.

None of these override the necessity to read the Snort manual, however. The manual supersedes all Snort books, because as great as these books are, they can't keep up with the fast-paced updates at which Snort is updated. So here goes...

1. The Snort.conf file.
Almost all your options are set in this file. This file should be read line by line, from top to bottom, taking the time to fully understand what each one of the configuration options are. 90% of all the questions I get can be answered by just reviewing the documentation in the snort.conf file.

2. Variables.
At the very top of the Snort.conf file there are variables to be set. The very least of which is "HOME_NET". HOME_NET should ALWAYS be configured. Depending on the placement of your IDS, your HOME_NET is loosely interpreted as "whatever the Snort box is protecting". For instance, on my network, it's The whole network is controlled by my router, and no other IP addresses should be on the network unless it has this range. If I *had* other IP's pop on my network, I would definately not want them treated as mine! Common settings for HOME_NET may be your whole internal network range, such as any RFC 1918 addresses. Depending upon the placement of your sensor (such as at your border) you many want to have your public IP address space in your HOME_NET as well. Remember that only CIDR notation is accepted within the variable notation. won't work, neither will Only will. Another big thing to note is your setting for EXTERNAL_NET. By default, EXTERNAL_NET is set to "any". "Any" includes your HOME_NET. In order to make Snort treat traffic that is NOT in your HOME_NET as EXTERNAL, you can set your EXTERNAL_NET to "!$HOME_NET". Which setting applies to you is dependent upon the placement of your sensor.

3. Frag3 preprocessor.
Snort is able to avoid many different types of evasions. One of the big ones that people think they can slip by on any IDS is through IP fragmentation, or using malicious overlapping and underlapping fragments in order to slip the payload past your IDS's, but have it reassembled correctly on the target.

Okay.. I realized I may have just thrown a big ball at you... Let's back up.

IP fragmentation is when Packet A on Network A is too big to go onto Network B. So the router on the Network A side splits Packet A into Packet A.1, A.2, A.3, and so on, so it's able to fit onto Network B. However, these smaller packets aren't put back together until they reach the final destination IP. Still with me so far right? Cool...

The problem with that is, different operating systems put fragmented packets back together in different orders depending on the type of operating system. (and you thought they were all the same!) Well, the problem with IDS's is, they have absolutely not idea what the Operating Systems are that they are protecting. Frag3 allows you to tell it. Now, without writing a book about the subject, you need to go into the docs/ directory that is enclosed with your Snort tarball and read the README on frag3. (As well as the accompanying section in the Snort manual.)

However, in order to FULLY understand what I am talking about, go read the whitepaper written by Judy Novak. (You have to register to download it) She's one of the authors of the SANS 503 IDS course, one of the designers behind frag3, and currently a Vulnerability Research Team (VRT) employee at Sourcefire.

4. HTTP Inspection preprocessor.
The most misunderstood preprocessor there is. This preprocessor analyzes, normalizes, and alerts on http traffic. The thing to remember is, it's SERVER based. It's meant to analyze traffic coming inbound to your http SERVERS. It basically has two settings, the "global default" setting, which you should set to the majority of your web servers. For instance, are most of your web servers IIS, on port 80?  Then you need to set that to the global setting.  If only some of your web servers are not IIS, or  only some of them are not on port 80,  then those need to be specified INDIVIDUALLY, by IP! Does that mean you will have to create a separate line for each of your "non-standard" web servers? Yes! That's the way it's SUPPOSED to work!

5. Portscan preprocessor.
Also very mis-understood piece of code. You need to read the README for the "sfportscan" preprocessor in the docs/ directory. There is no better explanation on how to configure this preprocessor.

6. The rest of the preprocessors, to include the new "dynamic" preprocessors.
All of the preprocessors have configuration lines. Each need to be configured to the networks you are protecting with Snort. Review the documentation for each of them extensively. All the documentation is well written, and is written with the user in mind.

7. Rules.
The Rules in Snort are key. At the bottom of the Snort.conf you will see a bunch of "include" lines. "include $RULE_PATH/web-iis.rules" for example. This line will call the rules file web-iis.rules and load it in at runtime. Alot of people ask "what is the best ruleset to run?" Well, by far the first and foremost ruleset to run the VRT ruleset available after registration here. However, does this mean that you need to run every rule in that ruleset? NO! Take a look at the categories.. pop3.rules, imap.rules, oracle.rules, web-coldfusion.rules, pop2.rules, mysql.rules.. etc... Do you run these services on your network? Do you run pop3? Do you run pop2? Do you run imap? No? Then turn the rule category off! There is no sense in running rules that have no application to your network! All you are doing is potentially creating more work for yourself through false positives, as well as making the Snort engine work harder then it needs to.

"But I hear there are other rulesets besides the VRT set!" YES! There are. There are basically two. The BleedingThreats set available at and the Community ruleset. Each of these rulesets is contributed to regularly by YOU the Snort community and each have their own pros and cons. Should you run all three rulesets? Sure! However, you need to go through each rule file, and turn on/off what you are not interested in or what does not apply to your network. For example, do you have Vertias on your network? No? Then go into exploit.rules and shut off the Veritas rules.

8. Output.
Snort can output to syslog, to pcap format (default), to a database, or lastly, to Unified. The "official" recommendation is to unified. The unified file format is the fastest output format coming out of the backend of Snort. Especially when you are trying to output to database! When Snort has to output to a database directly, it has to perform an INSERT into the db... doing so is CPU intensive. Do you want your IDS to be an IDS? Or a database insertion tool?  So use Unified! Well, the problem with unified is, you need something that reads unified file format and outputs it into the db, or tcpdump file format you want....

9. Barnyard (or FLoP)
Barnyard reads the unified file format and inserts what it finds into a db, or outputs into tcpdump file format. FLoP is another tool that also reads Snort's output (albeit in a different method) and does what you want with it. Both are excellent tools and both need to be checked out and use the one that's appropriate to you.

10. Rule updates.
However you choose to update your rules is up to you, I recommend Oinkmaster. Nice perl proggie to keep your rules up to date. Just don't forget to register on and get your oinkmaster code if you wish to download the VRT registered user set.

Notice that I didn't put a recommendation for any type of Snort log reviewing tool. BASE, Sguil, Placid, etc.. all have their merits and you will want to check out the one that is most appropriate to your situation. However, I do have one recommendation that I will make here... and it's turning into more of a "RULE" now. Do NOT use ACID. Don't get me wrong, ACID was great for it's day, however, with over 200+ bug fixes, feature implementations, and the fact that ACID hasn't been updated in.. going on 4 years now... go with BASE if all you are looking for is an Alert browser. BASE works with your existing ACID db, and is very easy to upgrade to.

So there you go. I hope this helps a bit to get you started down the correct path of tuning Snort. Don't forget to hit the mailing list archives, post to the mailing lists with any questions, look for your local Snort User Group, visit the Snort Forums, or even write into us here at the ISC (several of us use Snort constantly, not just me).. or drop into into #snort and say hello! Thanks!

Stay tuned for another article on Snort in the future.. If you have suggestions about what I should write about as far as Snort goes, feel free to write in!

/** Joel Esler **/

Sourcefire and Snort are registered trademarks of Sourcefire.
0 comment(s)


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives