Monday, August 17, 2015

OnionSalt Update and Support for Critical Stack Intel Client

Comments on Facebook
I got inspired at the Bro conference to dust off OnionSalt and start adding some features. Currently it is in my dev branch. There are a couple of things to talk about before you start putting this code into your environment. Let's rap about some roadmap stuff real quick.

The Dedicated Master Skeleton


You will see in the release notes the talk about dedicated master support skeleton. The plan here is to give the option to not run OnionSalt on an actual sensor if you don't want to. This has been something that has been requested from several folks due to security reasons. They want to give people ability to modify rules but not give them full access to their actual sensors etc.

To accomplish this you will now see a new pillar called sensors. You will name your sls file the name of you sensor so that it will match the pillar correctly. This is where you will store all unique values specific to each sensor. For this example we will be using the Critical Stack API key.  In the future you will be able to use this file to tune your individual sensors right from this file. For our example our sensor name is pwntsauced so the sls file would be like this:

Filename: pwntsauced.sls

File Contents:

############################################################
##                                                        ##
##        Template File for Unique Sensor Variables       ##
##                                                        ##
############################################################

sensorstuff:
    hostname: pwntsauced
    cskey: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

You will also need to comment out a section in the pillar/top.sls so that we match the pillar correctly.


#######################
##                   ##
##  Pillar top.sls   ## 
##                   ##
#######################

# Pull the hostname grain
{% set hostn = salt['grains.get']('host', '') %}

# You shouldn't have to mess with this.

base:
  '*':
    - users
    - sensors.{{ hostn }}

By using the grain, we don't have to modify the top.sls every time we add a sensor. If you have each sensor spelled out directly just add the - sensors.pwntsauced to the section for that sensor. You won't need the grain at that point.

So this code will lay the foundation for managing unique values on each of your sensors within your grid. Look for more to come on this as I find time.

Enable Critical Stack Intel Client Support


Now that we have completed the first part of this its now time to enable the Critical Stack Intel Client on our sensors. For this example we are assuming each sensor has a unique API key. To enable this to work you will see a couple of things added to the salt/sensor/init.sls file. The first section is the creation of the /etc/state directory which we will use for drop files to enable state tracking. (yea it is sorta janky but it works) You will see the new code look like this:

# Create the state directory
statedir:
  file.directory:
    - name: /etc/state

This will create the directory for us to use. Next lets create a folder under salt/sensor called scripts. You will see from the dev repo the actual script that we use to do install of the client called cstackinstall.sh:

###
## Script for Critical Stack Intel Client install
##

# Check for the drop....
if [ ! -f /etc/state/cstack.txt ]; then
curl https://packagecloud.io/install/repositories/criticalstack/critical-stack-intel/script.deb.sh | bash
apt-get install critical-stack-intel
critical-stack-intel api {{ salt['pillar.get']('sensorstuff:cskey', '') }}
touch /etc/state/cstack.txt
fi

Now from the script we can put together what we did in the first section of this post where we pull the unique value for this sensor. You see it in here as sensorstuff:cskey. This will pull the unique value and insert it into the script that runs.

Let's enable this script to run on all of our sensors. Uncomment the following code from the sensor/init.sls file.

## Enable Critical Stack Intel Client ##

csinstall:
  cmd.script:
    - source: salt://sensor/scripts/cstackinstall.sh
    - shell: /bin/bash
    - template: jinja

## End Critical Stack Intel Client

This will run the script to make sure the client gets installed. I will be adding more features as I get time like ensuring the CS service is running etc but I wanted to get the skeleton out there for people to test. This code needs more testing so please submit pull requests if you find something wrong and fix it.

Smooth out

Important Links:

Critical Stack:
https://intel.criticalstack.com/

OnionSalt DEV repo:
https://github.com/TOoSmOotH/onionsalt/tree/dev

 

Sunday, December 28, 2014

Geekempire's BadIP List

Comments on Facebook
I have automated a list of bad IP's.  These IP's have performed malicious activities against our servers. The list rotates daily. Feel free to download and use these IP's in your snort, bro, firewall, wallpaper, or any place you feel fit. We make no warranty to our list. Use at your own risk.

The list is available for download.
http://badiplist.geekempire.com/files/geekempire_badiplist.current

Sunday, December 21, 2014

Website Hosting Services Shutdown

Comments on Facebook
After over 10 years in the Web Hosting Business, Geekempire Hosting is shutting down its web hosting services. All currently hosted sites will be able to use the hosting system until the end of its hosting plan. We are going to keep the domain business going, and have no plans of shutting down our reseller services. EmpireDNS (http://www.empiredns.com) is the new site for managing domain names, DNS, and ssl certificates.

Further news and communication will be posted on the Geekempire Hosting website: http://www.geekempirehosting.com

Sunday, September 14, 2014

OnionSalt Saltstack Cheat Sheet

Comments on Facebook
I was asked by a couple of folks about some handy dandy salt commands that would help with a Security Onion deployment with Onionsalt at BSides Augusta and the Security Onion Conference. So being true to my word here are a few good things to know when writing your own salt scripts. Also feel free to fork and contribute to my repo on github HERE.

Let's start with some basics.

createadirectoy:
  file.directory:
    - name: /opt/somedir

Createdirectory is the name of the task we are performing. We are saying make sure you have the directory /opt/somedir

managedfile:
  file.manage:
    - name: /opt/somedir/somefile.sh
    - source: salt://files/somefile.sh

We are saying in that last example always make sure that /opt/somedir/somefile.sh matches the one we have on our salt file area.

manageddirectory:
  file.recurse:
    - name: /opt/somedir
    - source: salt://files/somedir

This says lets make sure that all the files in file/somedir are copied to /opt/somedir

runascriptatcheckin:
  cmd.script:
    - source: salt://scripts/somescript.sh
    - shell: /bin/bash
    - cwd: /root

Sometime you want to write a script that you run every time the minion checks in. I typically use this to check certain states on the box to make sure everything looks good. We are saying use bash to execute the script somescript.sh from the /root directory.

runsomecommand:
  cmd.run:
    - name: df -h

This one is if you just want to run some sort of command each time something checks in.

watchsomethingthendosomething:
  cmd.wait:
    - name: service httpd restart
    - watch:
      - file: /etc/httpd.conf
      - file: /etc/somedir

Here we are saying watch for anything changing in the httpd.conf or any file in /etc/somedir and if you see something run "service httpd restart"

These are a few easy things to use to get you started in writing your own salt scripts. Saltstack.com has a lot of documentation that can enable you to get much deeper than this.

Saturday, October 26, 2013

Back at TWC.. What a mess so far...

Comments on Facebook

So... I just got off the phone canceling my DirecTV service because I made the switch back to TWC. I did this under the auspice that I was going to simplify my setup and give me more flexibility as far as devices. That and I was going to save some money in the process. It's been an epic mess so far.

Let's address the elephant in the room.. Why am I not cutting the cord? Well I have kids who are addicted to Disney jr and my wife and I enjoy several TV shows. There are times where I would like to watch TV or shows that I have DVR'd but the kids are the owners of the remote. (Sad but true) So that led me to my current setup.

I bought a Tivo Romio and let me say the thing is pretty awesome. I am able to control the whole thing form my iPad and watch DVR'd shows or even live TV. This means I can watch whatever I want when I want. It also means when I travel I can download shows to it for the plane or even stream it from my house. Although I have not tried those last 2 features yet I will give it a try soon.

So enter Time Warner. My original install date was October the 15th I believe. I bought a Roku so the kids could watch Netflix and use the TWC app for their stuff. I got the Tivo unpacked and cleared some room so the guy could get to my equipment. Turns out the cable outside running under the street was cut. They woudl need to have some contractor dudes come out and run a new cable. They showed up on Thursday October 24th. These guys were very polite and did a great job. Lucky for them there was conduit under the street and it only took a few minutes.

Time Warner sent the truck back out yesterday and they hooked everything up. The cable card seemed to work nicely and the 50Mbit internets seemed ok as well. I didn't really have time to play with stuff because I was working which was a big mistake. After the tech leaves I start having weird connectivity issues. I don't get any ICMP packet loss but my sessions keep timing out. So the kids are downstairs streaming and my VPN keeps dropping and I keep dropping from IRC.

When I finally get a minute to go mess with the Tivo I switch it to a HD local station. Looks good so I go over to AMCHD and it says it is not authorized. So I call them up and they try and send something to my card to make it do something.. nothing happens still locked out. I call them up and they say they are sending the tech back out here. It is a "All Day" appointment and they will call before he shows up. Next thing I do is fire up my TWC app on my roku to test it out. It tells me I am not on my home network right now which means I can't stream jackola. So I call them about that and they make me do a bunch of stuff to which I tell them I am clearly getting a TWC IP and I provide it to them. Of course the person on the other end of the phone is following some stupid script wasting their time and mine. Finally I get it could take from 24 to 72 hours to work or something like that. I figure when tech dude gets here he can check that out as well.

At about 7PM last night I have yet to hear anything. At this point I am sorta pissed and call them up. They basically give me the run around and tell me there is still a chance they might show and if they don't call back tomorrow. So I called them today because you know they never showed up and now they are coming out Monday. Now I remember why I hate cable companies. This has been nothing but fail so far. I am guessing that dude never checked the signal strength coming form the street so if I had to guess that would be it. Cable internets and TV was working fine last time I had it and the only new thing in the mix is that new cable they ran.

Now I am stuck until Monday to see what happens.. I am monitoring the drops and I already know they will say its your pfsense box. I switch over to DSL and everything works fine. so I already took out that factor. It sucks that there is a monopoly on this crap because you are forced to take whatever they give you. Once this saga is over I will definitely be getting some credits to my account.

Saturday, July 13, 2013

Virtual Security Onion via Ubuntu, KVM & Openvswitch port mirror

Comments on Facebook
I've had a desire to play with KVM and openvswitch for a while.  I've been curious about how capable openvswitch's port mirroring functionality might be (could I mirror one source to multiple destinations for instance). This combined with some recent hardware purchases and the annoyance of booting into windows to manage my ESXi setup at home provided me the motivation this weekend to finally get the ball rolling on redoing the home network altogether with migrating to KVM as the first step.  So I took a new AMD 8 core cpu box with 24 megarams and blew on Ubuntu 13.04 - just because.  This box will host my pfSense firewall that sits between the big bad intertubes and my home network as well as the Security Onion sensor guest to watch traffic that passes through both the inside and outside interfaces.  Here's a crappy diagram. Ignore the FreeNAS junk or check out Smooth's earlier post.



Here's some notes on what I did.  Cobbled together from various blogs and documentation:

1.) I chose the "this machine will be a virtual host" or whatever during the initial install.  Update, install some more stuffs and reboot:


apt-get install openvswitch-datapath-source openvswitch-common openvswitch-switch virt-manager

2.) Modify /etc/network/interfaces:

# The INSIDE Physical Interface
auto eth0
iface eth0 inet manual
up ifconfig $IFACE 0.0.0.0 up

down ifconfig $IFACE down
post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#
# Management interface for hypervisor
auto br0
iface br0 inet static
 address 10.101.1.5
 gateway 10.101.1.1
 netmask 255.255.255.0
 broadcast 10.101.1.255
post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done

# The OUTSIDE Physical Interface
auto eth1
iface eth1 inet manual
up ifconfig $IFACE 0.0.0.0 up

down ifconfig $IFACE down
post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#

3.) Modify /etc/init/failsafe.conf timeouts to 1

$PLYMOUTH message --text="Waiting for network configuration..." || :
sleep 1

$PLYMOUTH message --text="Waiting up to 60 more seconds for network configuration..." || :
sleep 1
$PLYMOUTH message --text="Booting system without full network configuration..." || :
# give user 1 second to see this message since plymouth will go
# away as soon as failsafe starts.
sleep 1

4.) Create openvswitch bridges and add ports.  Br0 is my home network, Br1 the internet side.

ovs-vsctl add-br br0 
ovs-vsctl add-port br0 eth0
ovs-vsctl add-br br1
ovs-vsctl add-port br1 eth1

5.) Reboot and check openvswitch is running/configured with these commands:

service openvswitch-switch status
ovs-vsctl show
ovs-vsctl list bridge

6.) Create pfSense and Security Onion VMs. Note that virt-manager doesn't currently support creating the network types needed.  I just created the guests using the default network and then edited each virtual machine's interface settings via virsh (sudo virsh edit <name of VM>.  Here is a sample of what my interface settings look like for my Security Onion sensor:

    <interface type='bridge'>
      <mac address='52:54:00:ec:ac:6f'/>
      <source bridge='br0'/>
      <virtualport type='openvswitch'>
        <parameters interfaceid='e9e255c6-84ca-2f76-991a-543547638960'/>
      </virtualport>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

After firing up your VM you'll notice new interfaces on your host that correspond to interfaces on your guest.  For instance I have vnet0 that corresponds to the management interface of my sensor while vnet1 and vnet2 are my inside and outside monitoring interfaces respectfully Keep track of these for your port mirror setup.

7.) Create port mirrors.  Here's my inside port mirror config, all one line:


ovs-vsctl -- set Bridge br0 mirrors=@m -- --id=@eth0 get Port eth0 -- --id=@vnet1 get Port vnet1 -- --id=@m create Mirror name=mymirror select-dst-port=@eth0 select-src-port=@eth0 output-port=@vnet1

A few things to note here.  You can remove your port mirror config like this:

ovs-vsctl clear bridge br0 mirrors

You can also add a script to /etc/libvirt/hooks if you so wish.  I modified this dude's script so that it worked for me.

Also, it turns out that you can indeed mirror traffic from one source port to multiple destinations.  Might be handy for dev/testing NSM sensors.  Here's what I tested, all one line:


ovs-vsctl -- set Bridge br0 mirrors=@m,@n -- --id=@eth0 get Port eth0 -- --id=@vnet3 get Port vnet3 -- --id=@vnet5 get Port vnet5 -- --id=@m create Mirror name=mymirror select-dst-port=@eth0 select-src-port=@eth0 output-port=@vnet3 -- --id=@n create Mirror name=secondmirror select-dst-port=@eth0 select-src-port=@eth0 output-port=@vnet5

8.) tcpdump on your Security Onion monitoring interfaces, you should see traffic. Now you can run through your Security Onion setup and rock some NSM.


Helpful links:
Virtio pfSense stuff: http://doc.pfsense.org/index.php/VirtIO_Driver_Support