Snort blog comments are now disabled

As the topic of the post says, blog comments on this blog are now disabled.

Why?

99% (percentage is entirely made up, but most likely more accurate than non-accurate) of all the comments were spam.  The majority of my time moderating the comments on the blog was spent mashing the "Spam" button.

Every once in awhile a real comment would appear on the blog, and 99% of those comments were answered by me answering with "Go to the mailing lists".

So, in the interest of my sanity, and the fact that the mailing lists provide a better answer and conversational interaction than a blog comment ever could, I've disabled blog comments.

Please direct your questions to the Snort mailing lists: https://www.snort.org/community

Thanks all!

The 2017 Snort Scholarship Contest is now closed!

We are no longer accepting applications for the Snort scholarship award. We'd like to thank everyone that took the time to submit an application for consideration! 

The winners will be announced on or about May 29, 2017 here as well as our Snort Scholarship page at Snort.org.

Best of luck to all of the applicants!

New Snort Integrator System on Snort.org

As part of our efforts to enhance the customer experience and better suit the account management needs of our Integrator customers we’ve revamped our Snort Integrator system on Snort.org! 

In this new upgrade our new sub-registration process will give Integrators the ability to link active licenses to their master account via the Snort.org account portal. To accommodate the wide range of sub-user management needs, we have created options that allow our integrators to add customers manually via the Integrator Manager for smaller businesses. This can also be done through the Integrator API which allows our customers to add numerous sub-users at once, accommodating the needs of much larger businesses. This will allow our integrators to couple the user provisioning for the customer’s oinkcode directly into their own user provisioning systems for easy automation.

As a benefit, the addition of this exciting new feature allows integrators to add and suspend their specific users, as needed, without interrupting the service for their other customers. We have also provided extensive documentation and example code written in Perl that can be used with our system to easily utilize the new integrator features.  All of this documentation can be found on your Integrator Account oinkcode page, after logging into Snort.org.

As our Integrator program continues to grow, our Snort.org team is constantly striving to evolve our program. Our team aims to evolve the program in ways that will not only increase our customer satisfaction and partnerships, but prove mutually beneficial for the business management needs of our integrators. 

You can view our most current list of integrators by clicking here.

If you are interested in becoming a Snort Integrator please email snort-sub@cisco.com for more details on our program.

How can you tell if Snort is properly running when using systemd (or a standard init.d startup script)? - Guest Post by Bill Parker

This is a Guest post by Bill Parker.  Bill writes many of the installation docs on Snort.org.  Please welcome him to the Snort Blog!

---

I receive more than a few emails from end users who are having difficultly determining if snort version 2.9.x is running on their server, though the quickest way to see if it is running is by using the commands 'ps' and 'grep'.

However, in many cases, there could be an issue with the 'snort.conf' file which can be found using the '-T' option to snort (run manually) to determine which line in snort.conf is causing difficulty.

On my system when snort is NOT running, the command below returns the following:

[bill@moocow ~]$ ps auxww | grep -i "snort"

bill      1025  0.0  0.2 116388  2164 pts/0    S+   09:01   0:00 grep --color=auto -i snort

If I use systemctl to check the status of snort, I get:

[root@moocow init.d]# systemctl status snort.service <--- here="" look="" p="">* snort.service - Snort NIDS Daemon
   Loaded: loaded (/usr/lib/systemd/system/snort.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
 
Jan 23 09:10:55 moocow systemd[1]: Stopped Snort NIDS Daemon.

Which shows that snort isn't currently running on my server.

However, when snort is running, the same command produces a slightly
different output:

[bill@moocow ~]$ ps auxww | grep -i "snort" <--- here="" look="" p="">
snort     1071 41.6 39.7 748988 404492 ?       Ssl  09:11   0:37 /usr/local/bin/snort -A fast -b -d -i enp0s8 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort
bill      1090  0.0  0.2 116388  2204 pts/0    S+   09:13   0:00 grep --color=auto -i snort

Here is the output when systemctl is used instead of ps auxww | grep -i "snort":

When I start snort 2.9.8.x on Fedora 22, the output below is a partial
listing of the output that snort sends to /var/log/messages:

[root@moocow init.d]# systemctl status snort.service <--- font="" here="" look="">
* snort.service - Snort NIDS Daemon
   Loaded: loaded (/usr/lib/systemd/system/snort.service; disabled; vendor preset: disabled)
   Active: active (running) since Sun 2016-01-10 10:02:38 PST; 1min 33s ago
 Main PID: 1070 (snort)
   CGroup: /system.slice/snort.service
           `-1070 /usr/local/bin/snort -A fast -b -d -i enp0s8 -u snort -g sn...

Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_IMAP  Version 1...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SSLPP  Version ...4>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DNP3  Version 1...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SSH  Version 1....3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DNS  Version 1....4>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DCERPC2  Versio...3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_REPUTATION  Ver...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_FTPTELNET  Vers...3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SIP  Version 1....1>
Jan 10 10:03:26 moocow snort[1070]: Commencing packet processing (pid=1070)
Hint: Some lines were ellipsized, use -l to show in full.

On newer distributions of Linux, systemd has been implmented in favor of the old style init.d startup scripts, here is the README file from the /etc/init.d directory on my Fedora 22 Server system:

You are looking for the traditional init scripts in /etc/rc.d/init.d, and they are gone?

Here's an explanation on what's going on:

You are running a systemd-based OS where traditional init scripts have been replaced by native systemd services files. Service files provide very similar functionality to init scripts. To make use of service files simply invoke "systemctl", which will output a list of all currently running services (and other units). Use "systemctl list-unit-files" to get a listing of all known unit files, including stopped, disabled and masked ones. Use "systemctl start foobar.service" and "systemctl stop foobar.service" to start or stop a service, respectively. For further details, please refer to systemctl(1).

Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.

Thank you!

Further reading:
        man:systemctl(1)
        man:systemd(1)
        http://0pointer.de/blog/projects/systemd-for-admins-3.html
        http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities

Introducing the new look of the Snort.org blog!

When we were redesigning Snort.org, we noticed the blog didn't match the design and colors we had established for the site.

So we decided to refresh the look of the Snort blog as well.  We hope you enjoy the new look and feel.  Thanks so much for supporting Snort!

Reminder: Google Reader is ending it's life on July 1, here's an alternative

As may of you may know, Google Reader is EOL'ing it's product effective July 1.

Since several thousand of you are subscribed to this blog via Google Reader, I thought I'd let you know about another option that we offer that many of you also take advantage of.  Subscribing via email.

If you go to http://blog.snort.org, look over to the right in the sidebar, you'll see "Subscribe to the Snort.org blog via email".  This will allow you to keep your updates to the Snort.org blog, but instead of having to go to a third program to read the feed, it'll be delivered shortly after I click "Publish" directly to your inbox.

There are hundreds of people that do this already to the Snort blog, so it seems that it works quite well.  Give it a shot!

Google Reader's EOL announcement: http://googlereader.blogspot.com/2013/03/powering-down-google-reader.html

The Agile Security Manifesto

I may have to break out my 'old man pants' on this blog post.

Awhile back, over on the Sourcefire corporate blog, we put out what we called the "Agile Security Manifesto".  A series of 12 or so blog posts that detailed what we (Sourcefire corporate) really meant by our Agile Security message.

When I started working with Snort, this would have been around 2001, I was in the military and I believed that what I was doing, protecting networks, was my little corner of the Army sphere.  I believed that my goal was to protect everything that I could the best that I could, and so I tried to use the tools and develop the methodologies that allowed me and my team to do that.  Here it is 2012, and I still believe that.

I read the blog posts that various people at Sourcefire wrote on the corporate blog and I liked them.  Heck, even Matt Olney liked them over on the VRT blog.  Anytime you can show the VRT something we can get behind, I'm betting 99.9 times out of 100, it isn't going to be tied to marketing.  But for Matt it was different, and it's different for me too.

Internally we put these twelve blog posts into a PDF and we sent it around for people to read and to share with people.  I asked our VP of Corporate Communications if I could put it out on the Snort blog.  Not behind a Marketing signup, just out there, free for download so that people could read what is so near and dear to the core of what and who Sourcefire is.

This PDF reads like a mission statement to me.  Even if people people aren't using our products, or even if people have no intention of buying our products, this PDF inspired me and makes me want to move forward and invent the next great thing.  It makes me want to dedicate time to making sure that my customers remain secure from as many threats as we can protect them from.

Tech people hate to be marketed to, they love a solution, they love an outlook, they like to believe there is a light at the end of the tunnel.  People generally want to be believe that what they are doing is making a difference.  At least I do.

When I write detection and the next day I receive a ton of feedback via support and email asking for feedback on some rule that I just wrote and shipped and suddenly is catching some new attack strain, I see the results of my work.  The VRT thrives on this.  We love to see that what we are doing isn't just going out into the ether.  We like to see what we are doing is making a difference.

This blog post series is what we are about, what we believe, and what we are striving for, and now, it's available for download here:

http://www.sourcefire.com/agile-security/manifesto

Introducing the file-identify rule category.

This week we are introducing a new category into the VRT ruleset.  It's named "file-identify".

Instead of rehashing everything we wrote here, I'll just point you over to the post on the VRT Blog.

Please go here:  http://blog.talosintel.com/2011/11/say-hello-to-file-identify-category.html