Snort is a software package which monitors a network for suspicious traffic and provides advanced warning of an attack. Snort can also be useful in security failure mode analysis, where it can provide a log of network wide events over a pririod of time. Snort is open source software under the GPL License which means it is free to distribute provided the source is made available.
This article is intended for network administrators and requires an intermediate functional knowledge of server administration and networking skills in a Linux environment.
======ToC======
1. Introduction
2. Installation
3. Implementation
4. Monitoring
5. Informative Resources
===============
1. Introduction
The trouble with managing a network of any size is that we only know about a breach of security after it happens. Most servers have logging but so much is being logged that its impractical to keep up with it. Yet there are many vulnerabilities which manipulate the logs or the signs of the intrusion are so cryptic it blends in with the every day noise of doing business.
Firewalls and Anti-virus only detect a small portion of network security issues. Enter the next piece of the puzzle: The Intrusion Detection System. An IDS sits at the top level network and checks the network traffic for patterns of known attacks then logs them and it can be configured to provide advanced warning of an attack in progress.
SNORT is an IDS and is free open source software (free as in beer) which can be configured to fit almost any IDS role. SNORT is not the end-all be-all security technology, it is just another security tool to be used in conjunction with other tools and practices to keep your network safer.
Like all pattern recognition based security, it must be updated regularly to be able to detect new threats.
Most security vendors are moving towards a Unified Threat Management System, which pulls firewall, vpn, IDS, Antivirus/mal-ware into one centrally maintained appliance available by subscription.
2. Installation
For this example we will be using Ubuntu Linux Server Edition on a computer with 2 or more network adapters. Since snort will be performing a great deal of logging, the more space you make available, the better off it will be.
$sudo apt-get install snort
The package manager will download all of the dependencies and install them for you.
It will then ask you for the network range you will be monitoring. (ex. 192.168.1.0/24 )
Snort will begin logging traffic it sees in /var/log/snort/alert .
Syslog is the system log daemon which manages the various reports and logs which are produced by the services currently running on your machine. Should you need to report the information to a central server or log management database (like Cisco MARS) you can create a cusom local log by:
1. Edit snort.conf and add in output "alert_syslog: LOG_LOCAL4 LOG_ALERT"
2. Edit syslog.conf "local4.alert ww.xx.yy.zz" (Where ww.xx.yy.zz is the ip address or DNS name of your logging server.)
3. Restart Snort and syslogd
3. Implementation
Most networks use a switched network which means traffic not destined for your port on the switch doesn't go there. An intelligent switch can be configured to copy all traffic to your port in addition to its intended destination. This is the ideal solution in that if we are using Gigabyte Ethernet the only other option to sniff traffic is an active bridge or hardware Ethernet tap between the top level switch and the rest of the network. Gigabyte Ethernet uses all of the pairs of a cable for receiving and transmitting so creating a passive tap between it and another host would significantly change the electrical properties of the cable and cause significant degradation of signal. 10/100 Ethernet however only uses two pairs to transmit and receive so its possible to create a passive Ethernet tap where the sending and receiving pairs would be read by a nic on your sniffing machine. This is where the specification for two or more nic's comes in because you have to use one nic to read the transmit pair and one nic to read the receive pair.
4. Monitoring
The information from the Snort sensor is normally captured in a logfile on that sensor. We configured it to send the log information to a central syslog server. Snort also has plug-ins for MySql and Postgres SQL so the information can be accessed from a database, and also allows for the use of a web-front end. SnortCenter ,SAM and ACID are examples of a web based snort data viewer.
There are also stand-alone applications such as Razorback which can display Snort logs. Snort also has a iptables firewall plugin called Snortsam which can modify the firewall settings on the fly if prevention functionality is needed.
5. Informative Resources
Cisco Systems, Inc. "Device Configuration Guide for Cisco Security MARS, Release 6.x ." (Accessed May 2009)
http://www.cisco.com/en/US/docs/security/security_management/cs-mars/6.0/device/configuration/guide/chSnort.html (September 2008)
Danyliw, Roman "Analysis Console for Intrusion Databases." (Accessed May 2009)
http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html (Last Update 3/9/2003)
Freiberg, Sam "Snort Alert Monitor." (Accessed May 2009)
http://projects.darkaslight.com/projects/show/sam
InterSect Alliance. "RazorBack: The SNORT GUI for displaying events." (Accessed May, 2009)
http://www.intersectalliance.com/projects/RazorBack/index.html
Knobbe, Frank "SnortSam." (Accessed May 2009)
http://www.snortsam.net/
The SNORT Team. "Snort - the de facto standard for intrusion detection/prevention." (Accessed May 2009)
http://www.snort.org
See Also:
2009-05-07
Introduction to Snort IDS
2009-05-01
Securing Php Web Applications
PHP is a popular server side scripting language, it's as simple or as complex as you want to make it. It is typically used along with Linux, Apache Web server and MySQL RDBMS. In most web applications the script acts on user provided information and returns processed data. To this end there are a number of simple steps you can take to help make your web application less vulnerable to exploitation by an unfriendly party.
This article is intended for beginning to intermediate web application programmers.
=======ToC=========
1. Introduction
2. Methods of input
3. Input data validation
4. Trusted processing
5. Database queries
6. Raising the bar
7. Informative resources
===================
1. Introduction
PHP is a HTML pre-processor, meaning that it reads a file before it is sent to the user and if it contains PHP script, it processes it and returns the document and the processed results to the user. There are many other technologies which do the same thing each with their benefits and flaws. The importance here is not to proclaim the benefits of PHP over the others but to show some good ideas of how to protect your applications from un-friendlies.
2. Methods of input
In PHP we can get information externally from the webserver itself ($_SERVER), Cookies ($_COOKIE), Get variables ($_GET), Post Variables ($_POST) . In addition PHP can internally connect to just about anything.
Example:
So when Joe, our end user goes to your website to check this weeks Fantasy Football scores on your website, he will login (sending login information using POST variables) to a script which then reads the login information and decides whether he can login. Then it returns a page with the result of his attempt and then either takes him to the next page or back to the login prompt. Once he is logged in, PHP sets a Cookie with a unique random session id. Every time a browser returns that cookie to a page, it knows that this session is good and belongs to Joe. Then Joe sorts his results page sending some criteria via a Get variable which is used to control a query to the sports database.
The important thing to know is that Joe can control everything he sends to the server. He can see the cookie contents, post data and get variables. Lets say that Joe wants to check a friends team score. The site allows Joe to sort his scores using GET variables. Joe just places in an escape character and appends some SQL to view his friends score.
3. Input data validation
Think of a web application like a game of D&D, if you are out on the desert plains with a 12th level Barbarian named Ogar, whats keeping the player from making Ogar go left when the DM expects the player to go right? There is no reason Ogar the barbarian can't sit down and whittle a set of dice, mark up a parchment with character stats and then play Cube farms & Bosses.
You have a nice HTML page which provides for the intended actions of the user but everything in the browser or on the computer is out of your control. Java script, plug ins, input, cookies and URLs are not controllable and therefore cannot be fully trusted.
The key is limiting the users choices, and abstracting their decisions. If your scripts inputs expect a phone number, then the input should only be numbers or else its invalid. If there is only search methods A,B or C then if the input isn't A,B or C then it has to be invalid. Simply filtering out known bad data such as embedded javascript isn't 100% effective, if the data type is contaminated it cannot be trusted.
The quality of the data you take in is important, the other part of this is abstraction of the users decisions. If a persons available choices are A,B and C, and internally you identify A, B and C as actions and everything else as false input then that is more effective than allowing user input directly control your data.
4. Trusted processing
Assuming that you have done your due diligence and secured your server, it is more trustworthy of a computing platform than your clients workstation. A clients workstation could be infected with mal-ware, it could have a malfunctioning or obsolete browser or the user could intentionally manipulate the http variables to trick the application. Input validation cannot be done using JavaScript alone, trusting JavaScript or any other plug in to obfuscate your applications process just isn't a good idea. Client side scripting is good for enhancing the presentation and for providing a means to communicate information effectively to the user but it should not be relied upon to process information.
5. Database queries
Filtering valid data is just one step, the other step is on your data sources such as MySQL, Postgres, Oracle ... most modern Databases allow you to do a prepared statement which auto-magically binds input into a SQL string. Because its binding data directly to a variable the chances that a user's escape string can hijack the SQL query is greatly diminished. By limiting the users input to only data and not to the program execution process you greatly reduce the possibility of your script becoming compromised.
For example:
"http://example.com/mypage.php?display=select * from mydatabase.mytable where user=Joe order by date;"
Including SQL in a user accessible variable is a really really bad idea. Even if it is on a link that Joe wont see and Java script is used to obscure the URL. Joe controls the machine so any obfuscation used will never be effective. What is stopping Joe from substituting "select 'joe' as user password as score, currdate() as date from mysql.users where username=root;"?
6. Raising the bar
There are alot of "Magic Bullet" solutions to web application security. Application firewalls monitor information going both to and the web application. SQL application firewalls filter out suspicious SQL commands going to your RDBMS server. For most developers, these solutions are
either too expensive or too complex to implement for individual web applications. Here are some PHP security plug ins and tools to help raise the bar on the cheap.
When you use this or any other security plug-in, it is vital that you evaluate your applications baseline performance to know what is normal behavior. For instance PHPBB2, a popular PHP bulletin board application display a large list of forums. And mysteriously the settings would not save. I was using Suhosin and this was caused because the number of variables being posted was above Suhosin's default limit and the script was aborting before it could save the changes.
On the server side there is Green SQL, which is a MySQL sanitizer/proxy. Then there is mod_security which hardens Apache and turns it into an application firewall. mod_chroot is similar in the basic functionality of mod-security except it just chroots Apache transparently to the user. Then there are web application security scanners such as the ones included in Nesssus.
Wapiti checks for cross-site scripting (XSS), injection and other common issues. OWASP's WebScarab is a good utility for testing user access to http variables on the client side and intercepting the raw http conversation between the client and the server.
7. Informative resources
Breach Security "Mod Security home page". (Accessed April 2009)
http://www.modsecurity.org
Dawes, Rogan "OWASP WebScarab Project" (Accessed April 2009)
http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Esser, Stefan "Hardened PHP Project" (Accessed April 2009)
http://www.hardened-php.net/suhosin/
Freitag, Pete "20 ways to Secure your Apache Configuration" (Accessed April 2009)
http://www.petefreitag.com/item/505.cfm (Posted Dec 5, 2005)
Green SQLProject "Green SQL home page". (Accessed April 2009)
http://www.greensql.net
Hobbit "mod_chroot" (Accessed April 2009)
http://core.segfault.pl/~hobbit/mod_chroot/
OWASP Foundation. "Main Page" (Accessed April 2009)
http://www.owasp.org/index.php/Main_Page
Tenable network security inc. "Nessus Product Page" (Accessed April 2009)
http://www.nessus.org/nessus/
The Apache Foundation. "Apache HTTP Server Project". (Accessed April 2009)
http://httpd.apache.org/
The PHP Group. "PHP: Hypertext Preprocessor". (Accessed April 2009)
http://www.php.net/
Surribas, Nicolas "Wapiti Web application vulnerability scanner / security auditor" (Accessed April 2009)
http://wapiti.sourceforge.net/
See also:
Ax0n's OAMP (Apache, Mysql, PHP on OpenBSD) Article:
http://www.h-i-r.net/2008/12/sysadmin-sunday-amp-on-openbsd-44.html
Asmodian X's Name based hosting mini-howto:
http://www.h-i-r.net/2008/10/sysadmin-sunday-apache-name-based.html
Asmodian X's Workbench - Suhosin :
http://www.h-i-r.net/2008/12/asmodians-workbench-suhosin-hardened.html
2009-04-01
Now and Then: Anatomy of a buffer overflow
Today, Kevin Poulsen posted "How A Buffer Overflow Works" on Threat Level. It includes a simplistic flash animation that kind of helps one grasp what's going on with a buffer overflow... although I'd hesitate to call it "kid-friendly".
In the hacking culture, exploiting buffer overflow vulnerabilities was known as "Smashing The Stack", as stack-based overflow exploits were (and likely still are) the most common buffer overflow vulnerability and among the easiest to exploit.
Kevin's article and the accompanying animation reminded me of a piece of work that is both antique (as far as computer history is concerned) and relevant. Phrack 49 was published in 1996, and it included an article by Elias Levy (under the handle of Aleph One) entitled "Smashing The Stack For Fun And Profit"
It's practically required reading for people dealing with application security; It's just as useful for developers as it is for penetration testers and security researchers. Seriously, go give it a read. It's a long one. All the while, keep in mind that it was released nearly 13 years ago. That even puts my own work into perspective. Phrack 49 was released just as I was myself trying to rally the writers who put together the very first bits of content that got HiR off the ground in its original eZine format.
Damn, I feel old now.
Posts
