Error: Twitter did not respond. Please wait a few minutes and refresh this page.
Incoherent ramblings of an InfoSec professional
About a month ago Ryan Stillians came to me with an idea to do a local meet up for information security professionals in the area. Since I had sorta had this same idea but never got it off the ground we decided to work together to get something off the ground. This is designed to be a monthly meet up group with some additional things if we have a topic that we really want to dig into. Most meetings will take place between Iowa City and Cedar Rapids and hopefully back and forth. The desire is to create a community in the area where info sec professionals can get to know others. Hopefully this will keep the good momentum we saw from the first meeting.
First meeting was great, second meeting is tonight (12/9) where we are planning some member introductions.
Check out our meet up site http://www.meetup.com/Hawkeye-InfoSec/
or via twitter @HawkeyeInfoSec
Earlier this year Richard Bejtlich (@taosecurity) was on PDC http://pauldotcom.com/wiki/index.php/Episode327 Since that time his book as been released. The Practice of Network Security Management from NoStarch (http://nostarch.com/nsm). Richard is an individual who knows what he is talking about when it comes to NSM, having run a CIRT for the Air Force and GE and now resides as the CSO for Mandiant. Richard has also authored The Tao of Network Security Monitoring and Extrusion Detection.
This an excellent resource for beginners to NSM or people starting to do NSM in their environment and it is not intended for experienced NSM practitioners. It begins with a very good overview of what NSM is and what constitutes NSM and the sort of data that needs to be collected. Gives some good examples of how to place sensors and caveats found in large organizations with NAT and the like. Then to tie the types of devices into a tool, Richard introduces a very good set of Open Source tools like, Bro (bro.org), Snort, Squil, Snorby, ELSA etc. that are part of the Security Onion distribution created by Doug Burks (@dougburks).
The first section of the book is dedicated to in the installation of Security Onion and configuration of the tools that go along with it so that the reader could spin up their own instance and learn along with the book. If you are in anyway experienced with Linux installations you can skip most of this section, it was written so folks without much exposure can install SO. Once that is taken care of he builds on the tools contained within SO. When he can he shows multiple ways and tools to achieve the same thing, for example using tshark and the GUI version of Wireshark to analyze packets. He gives real world examples of data that tripped things like Snort to help understand the workings of the tools.
After the basics and tools are introduced it dives into using NSM to monitor a network. Areas like phases of an investigation and what data might help identify success vs attempt in an incident. He discusses incident classification which is one place I think CIRTs miss. The best part in my opinion of the whole book is in chapters 10 and 11. Once everything is introduced and a good understanding of the tools are in place Richard walks through 2 sample breech investigations and takes a step by step approach on the analysis done, data and tools used to identify the extent of a breach.
This is a very well written technical book. This is a very easy and quick read for its size, provides many examples and screen shots to give readers a good understanding of how to use the tools in the book. I would recommend this for anyone getting into the field of incident response who doesn’t have a great understanding of NSM, newcomers or perhaps less technical Managers.
-Greg Hetrick @gchetrick
Going Live on pauldotcom soon to talk SRP. Grab a beer and join in.
A few weeks ago (Episode 329 http://pauldotcom.com/wiki/index.php/Episode329#Tech_Segment:_Free_Amazon_Socks_Proxy_by_Allison) Allison gave a great segment on avoiding firewalls using port forwarding and SOCKS proxy via ssh with a server on port 443 using free Amazon AWS instance. Something struck me:
1) you could have a proxy block SSH traffic going over 443.
2) you could haven IDS detect and, if inline, block since any IDS will detect SSH over non-standard ports.
So how do we fix this problem? Encapsulate SSH traffic inside SSL of course. In comes stunnel! Stunnel creates a SSL tunnel to pass almost any traffic through it. All you need is the same AWS instance that Allison talked about with stunnel installed and a client on the other end also with stunnel.
yum or apt-get install stunnel – Both server and client (there is a macport of stunnel as well as Android and Windows installers at stunnel.org)
Server side configuration, create file stunnel.config with the contents below:
accept = <serverip>:443
connect = 127.0.0.1:22
Create Self Signed certificate.
Create a key
$ openssl genrsa 1024 > stunnel.key
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)
Generate the self signed certificate.
$ openssl req -new -key stunnel.key -x509 -days 1000 -out stunnel.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) :
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) :
Common Name (e.g. server FQDN or YOUR name) :
Email Address :
Next up create the PEM file which just contains the key and the crt contents
$ cat stunne.crt stunnel.key > stunnel.pem
Now you can start the tunnel — in Debian there is a perl wrapper for stunnel4 that is /usr/local/bin/stunnel — when I envoked stunnel this way the tunnel would not start. When I bypassed the wrapper and called stunnel4 directly it worked fine.
$ stunnel4 stunnel.config
verify with netstat that the port is running (netstat -tanp) or you can test it with an openssl command: $ openssl s_client -connect <ip>:443
Now over on the client side copy over the .pem certificate from the server and place it somewhere. Then create your client configuration file stunnelclient.config
*If you need to go through a proxy you can uncomment the “protocol” lines and fill out the information accordingly. Where protocolHost is the server you want to connect to, and connect becomes the ip and port of the proxy device. If there is no proxy present the connect line is the ip and port of the remote host to connect to.
Now fire up stunnel on the client machine
$ stunnel4 stunnelclient.config
netstat -tapn to verify it is running on the assigned local port, in this example it is 2200
Now you can simply use ssh to the localhost
$ ssh -p 2200 localhost
and you are on the remote server, all hidden in nice SSL packets. I was able to run through a web proxy on port 443 with this config and did not trip signatures on the IDS that was otherwise tripping without stunnel in the middle.
You should be able to follow Allison’s documentation for getting port forwarding working properly for full enjoyment.
Go forth and evade.