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, 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.

Saturday, October 26, 2013

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


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

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 



Saturday, June 1, 2013

Live TV on the Playstation PS3

I have two HDHOMERUN Prime cable tuners with cable cards in them. Silicondust recently updated the firmware to enable DTCP-IP support for encrypted channels to work. They have a list in their forums for DLNA devices that this should work on, and the PS3 is one of them.

All you need to do is enable DTCP-IP in the system settings of your PS3. This is where it got fun.
I kept getting an error code (8071053d) when I tried to enable it. So I did a little searching.

First thing i did was enable UPNP on my pfsense firewall and set a rule to allow my PS3 ip and a port range of 3000-6000. I also enabled UPNP on my PS3.

I then tried enable DTCP-IP again, and I still got the stupid error.
So this time, I ssh'd into my pfsense firewall and started running tcpdump on my WAN interface looking at ports 5223,3478,3479,3658

I started seeing a few IP's popping up. I then did a whois on one of the IP's and saw:
network:In-Addr-Server;I:PLAYSTATION1-HST.127.0.0.1/32

I run pfblocker on my firewall and it was telling my PS3 to screw off.
So I had to whitelist this CIDR 198.107.128.0/19

Once that was complete. I went back to my PS3 and viola ..... DTCP-IP enabled!
Now I can watch all the cable stations I subscribe to through my PS3.

HD HOMERUN PRIME showing up on the PS3:


Science Channel HD: