Showing posts with label breach. Show all posts
Showing posts with label breach. Show all posts

2010-09-20

What I personally learned at CyberRAID

One last post from me on the inaugural CyberRAID event here in Kansas City.


Leadership
I'm not sure why I was chosen as team captain. Maybe it was because I knew more people on my team than everyone else, because I seemed more confident or because I was one of the first ones present. I wasn't nervous. I felt like I was as prepared as I was going to be. I had my plan, tools and more than half my life behind me that I've spent doing security work in some capacity or another. I thought I was ready to orchestrate a defense team, too, so I happily accepted the position of Captain at the start of the game when people told me "Go up to Dwight! Get our info!" It's not that I can't orchestrate a defense team, but I wasn't as ready as I had thought I'd be, and my plan fell apart pretty quickly.

My plan was to get people organized by what they're good at, and set them on a task. I kind of succeeded at that, but I did plenty of things wrong from the beginning. First, I was stressed but I haven't completely forgotten my manners. My requests probably sounded like a bossy demand followed by "please." Next, I didn't enforce these roles nor did I evaluate how it was going. Some roles changed without much communication. More than once, someone stepped on the toes of someone else who was already working on something. I'm thankful that there wasn't any apparent infighting on my team. Everyone remained rational.

I've lead teams on many projects in my career, but I have no formal management experience or training. I've been an IT worker in a crisis situation more times than I can count. I've never had to lead a crisis response, though. To manage people and work on technical things at the same time is a truly herculean task -- one that I feel I only barely stumbled through.

I learned a lot about myself and hardships faced by leaders in a crisis situation. I also gained a new perspective on IT workers. Among my team, I had some of the most brilliant and capable security minds I know of in the region. On the first day, we had grand ideas and the right mindset, but our implementation of them was slipshod at best. Our good communication skills were the only thing standing between what we had (which was still a good effort) and unabashed anarchy.

Things I learned about leadership and IT teams (and thus, what I need to work on myself):

#1: Technical leaders must lead first and foremost, and help second.

#2: Groups of geeks require a little bit of guidance to avoid replicating (or undoing) work.

#3: Good communication is vital, and its prerequisite is good rapport.

#4: Change management is an extension of good communication. Yeah, I went there.

On the technical side, there were so many things that I'd do different right from the start.

#5: Get visibility to the DMZ network and I'd immediately scan it from the outside while the firewall and system admins work to start locking down obvious things.

#6: Additional Virtual Machines on the DMZ. It would have been great to have a decent (and familiar) IDS on a Span Port. It might have also been fun to have a few honey pots sitting on the DMZ. Had I thought about this ahead of time, I could have totally made it happen. These are tools any one of us could have brought along for the ride in VMs.

#7: Egress filters from the start. There's no good reason not to. They make sense in the enterprise, and they make sense in the game.

Things I'm taking back to the office:

#7: Egress filters! I'm mentioning it twice. Blind SQL injection and RCE exploits are very popular, so crafty hackers and pen-testers often try to leverage these vulnerabilities to launch some process that can notify them that their exploit has worked. This might be popping an xp_cmdshell to launch ping with a special payload they can look for in return, or it may be something much more quotidian, such as a reverse_tcp or meterpreter call-back from metasploit. Again, egress filters make sense in the real world. To further this point, watch out for obscure tunneling through ICMP and DNS. Ideally the DNS server your DMZ uses should not allow recursion.

#8: We all know that despite our best efforts, a dedicated adversary will find a way in. For some reason, this exercise made it sink in a little better. It's been a while since I've worked somewhere that was breached on my watch. This further boosts my desire to learn more about modern post-breach activities both defensive (forensics, containment) and offensive (post-exploitation, pivoting). I have some serious reading and research to do!

Who else was at CyberRAID, CCDC, SANS ICE II or any other recent exercise like this? What did you get out of it?

2009-05-07

Introduction to Snort IDS

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-01-09

A call to arms: War on removable media!

According to some, 2TB SDXC memory cards will be directly responsible for data loss in the future:

Even though I am an optimist, it is hard not to see bigger (literally) breaches ahead - unless we get our act together. Time to make these cards more secure - can we get some security standards also into the new SDXC standards?
While we're blaming things:
  • Forks cause obesity
  • Guns cause murder
  • Matches cause arson
Obviously, I'm being sarcastic.

Let's think rationally for a while, and take a look at the numbers: stolen or misplaced removable media is to blame for a scant 3% of reported data loss incidents.

Data loss and breach are largely human problems. If Jim is disgruntled and wants to take the entirety of his corporation's Intellectual Property with him to his new gig, the latest, whiz-bang SDXC card won't necessarily be the break he's been waiting for, and increased capacity won't likely lead to many to bigger accidental breaches since this type of incident is responsible for such a minuscule fraction of them in the first place. It might, however, increase bandwidth abuse at work, since people can finally torrent the entirety of the Dr. Who saga and fit it all onto a cute little card that fits in their pocket.