Monday, July 30, 2018

IPv6 with OPNsense and Spectrum/TWC

"I still remember back in the day installing winsock clients on windows 3.1 machines so people at my work could get internet."

Although the above statement dates me a little bit, I have been using TCP/IP for a long time. One of the most used books I have is TCP/IP Illustrated. For the longest time I have avoided adopting IPv6 for an array of factors. First being the addresses are long, second is the lack of support from a lot of things out there, and third there is a lot of basic information out there but nothing that could address my needs.

Even though there really isn't much incentive for companies to move over, I figured I would give it a shot at home. I have a complex setup that I use to keep things organized and separated at home. Right now I have my main home network VLAN, a VLAN for work, and an isolated network for incoming connections. I have plans to segment even more for kids, guests, security cameras, the whole shebang. OPNsense is at the heart of all this and I use it to run the show.

I feel as if I should run a disclaimer that I am an IPv6 noob. I understand a lot of the basics but there is a ton of room for me to improve and grow my knowledge. I learn by doing so here is what I did and the struggles I faced. Your mileage may vary based on your ISP but a lot of these concepts should relate.

Test 1 - Does IPv6 from Spectrum even work?


Enable it on your WAN interface:


Now on your LAN interface select "Track Interface" under IPv6 Configuration Type:


Go to the bottom and set the interface to WAN and a prefix of 0:


Reboot your router and log back in. Under your main dashboard you should see a v6 address assigned to your WAN and LAN interfaces. Clients should also start picking up addresses and as long as you didn't change your default v6 rules you should be able to ping ipv6.google.com.

If all you have is a single LAN and want IPv6, CONGRATS! you are done!

Meat and Taterz time


After getting to the above I needed to segment. This is where I started looking for more advanced documentation. A lot of the suggestions out there was around assigning a static IP to the LAN and using DHCPv6 to hand out addresses etc. The main issue with that was if your ISP changes your /64 then everything is broken. Or at least that is how I understood it. I was really looking for a way to keep it simple and not have to mess with anything.

Several things I read suggested requesting a larger prefix from TWC/Spectrum and then just dishing out a /64 per network. After some testing and a bunch of floundering I came up with a working solution.

Change the following settings on your WAN interface:



So now go to each interface on OPNsense that represents the networks you want to add and change the prefix number to the next number. So we set LAN to 0 and in my case I set the other to to 1 and 2.  Rinse and repeat for all of your other networks. You can have up to 256 /64s from a /56 so in theory you are looking at supporting up to that many interfaces, although I am sure you will hit some sort of limit in OPNsense before that.

Once you have done all of that its time to add a firewall rule. I don't know if this is really needed or not but I saw it in a couple of other examples so I put it in there.

Allow your networks to get out and request an IP from your ISP. Add the below policy to the WAN interface on your firewall:


Apply that and REBOOT your OPNsense box. For some reason you have to reboot for IPv6 stuff to take hold. Once it is back up your interface list should look something like this:


Big thanks to the OPNsense twitter account for getting me over the last hurdle which was the prefix stuff. Please leave comments if anything above is incorrect but this is how I got mine working. 

Wednesday, December 6, 2017

It's Back!!

It has been a long while since we have done anything here. Real life has a way of getting in the way of stuff. I was finally able to separate the Geekempire Youtube channel from my personal account so I am going to start firing up more content there as well as talking about things I have been getting a lot of questions about around security and crypto currency.

Smooth out

Monday, August 17, 2015

OnionSalt Update and Support for Critical Stack Intel Client

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

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

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

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.