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.
Sunday, September 14, 2014
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:
2.) Modify /etc/network/interfaces:
# 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
#
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
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:
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:
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
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>
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.
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:
Sunday, May 19, 2013
How do you do this without NSM?
I have had many many conversations over the past few weeks on the difference between traditional IDS and NSM and I am shocked that NSM is still a foreign concept to people. Sometimes there is a challenge to help folks realize what the real difference is. If you don't know what NSM is then read this book written by Richard Bejtlich. This is not a ploy to sell more books for Richard but a cry out to detection folks out there that you could be doing it differently.
Several years ago I stumbled upon Sguil when I was looking for a way to better manage my Snort environment. I was using Acid (yea.. I know) and I just wasn't happy with it. I was finding bad hosts with obvious signatures such as SQL Slammer and Code Red (yea.. I am dating myself) which was great but I didn't know what I was missing. I thought I was happy, management was happy I was finding these bad hosts, and for me everything was good in the world. What I didn't know is I was only scratching the surface on what could be done.
Now the landscape back then was completely different but I think back on what else I could have detected. This was before people could make money off huge botnets and most people didn't bank online. But with today's climate with all the drive bye java exploits and APT1 noise having an alert is no longer sufficient to protecting your environment.
You see IT teams think the security guys are crying wolf all the time because 1 out of the last 20 hits was a false positive. It takes more proof these days generally to get them off their seats to do something. You cannot be an effective analyst if all you do is send resources on wild goose chases. Lets choose an example that is relevant to current events. You see a host hit a drive-by site. That is all the information you have in your console. So we know this person hit a site and did the AV on the system catch the evil that was potentially pushed to the machine. You could use the aliens approach and nuke the site from orbit and re-image the machine, but chances are the IT dudes will run AV and say I got nothing that says there is anything bad on this box. Thanks for the false positive and you move on to the next one. You used all the information and your layered security approach to show you "Hey this was a blip.. maybe the evil code was taken down etc". What you don't know is this machine is WTFPWNTSAUCED.
You don't know this because the evil it downloaded was new to AV. In the NSM world once you got the alert the first thing you would do is pull the transcript of the entire session of the drive-by In that case you see the host hit the site and was directed to download a jar file. Now we know that it downloaded a jar file but what else happened? Here is where things get fun. So you could pull that jar file from the stream using wireshark and run it on a sand box and see what it does. (You know like @SecShoggoth MASTIFF) Another option is you could pull the session data from the host for 2 minutes before the incident and 2 minutes after and see that after it downloaded that jar it made connections out to other internet IP addresses in suspect countries. You could also pull the HTTP info from it to see that it then requested an exe file from a suspect looking domain. Now you can pull that from PCAP and see what it does. You run it through MASTIFF and see it starts up a process called kungfu.exe and then tries to reach out to an IRC server in the Ukraine. Or flip it around.. You see the first stage is successful by grabbing the jar file but in the second stage you see a 404 when its trying to grab its evil.
So what does NSM really give you? It gives you options. It gives you all the data you need to make an informed descision about what is the real deal vs what is just noise. As attacks become more and more behavior based there will be even further needs for this type of info. The best part of it all is the best tools out there to do this are open source. You can get started today by simply downloading Security Onion.
I did not write this to say traditional IDS is useless but to show folks that there is a difference. You may believe that your methods are awesome and I am full of crap and that is fine but I have never heard anyone complain they have too much information on an incident. I just know that having an alert for me is not enough information to make an informed decision on the state of the machines involved.
Several years ago I stumbled upon Sguil when I was looking for a way to better manage my Snort environment. I was using Acid (yea.. I know) and I just wasn't happy with it. I was finding bad hosts with obvious signatures such as SQL Slammer and Code Red (yea.. I am dating myself) which was great but I didn't know what I was missing. I thought I was happy, management was happy I was finding these bad hosts, and for me everything was good in the world. What I didn't know is I was only scratching the surface on what could be done.
Now the landscape back then was completely different but I think back on what else I could have detected. This was before people could make money off huge botnets and most people didn't bank online. But with today's climate with all the drive bye java exploits and APT1 noise having an alert is no longer sufficient to protecting your environment.
You see IT teams think the security guys are crying wolf all the time because 1 out of the last 20 hits was a false positive. It takes more proof these days generally to get them off their seats to do something. You cannot be an effective analyst if all you do is send resources on wild goose chases. Lets choose an example that is relevant to current events. You see a host hit a drive-by site. That is all the information you have in your console. So we know this person hit a site and did the AV on the system catch the evil that was potentially pushed to the machine. You could use the aliens approach and nuke the site from orbit and re-image the machine, but chances are the IT dudes will run AV and say I got nothing that says there is anything bad on this box. Thanks for the false positive and you move on to the next one. You used all the information and your layered security approach to show you "Hey this was a blip.. maybe the evil code was taken down etc". What you don't know is this machine is WTFPWNTSAUCED.
You don't know this because the evil it downloaded was new to AV. In the NSM world once you got the alert the first thing you would do is pull the transcript of the entire session of the drive-by In that case you see the host hit the site and was directed to download a jar file. Now we know that it downloaded a jar file but what else happened? Here is where things get fun. So you could pull that jar file from the stream using wireshark and run it on a sand box and see what it does. (You know like @SecShoggoth MASTIFF) Another option is you could pull the session data from the host for 2 minutes before the incident and 2 minutes after and see that after it downloaded that jar it made connections out to other internet IP addresses in suspect countries. You could also pull the HTTP info from it to see that it then requested an exe file from a suspect looking domain. Now you can pull that from PCAP and see what it does. You run it through MASTIFF and see it starts up a process called kungfu.exe and then tries to reach out to an IRC server in the Ukraine. Or flip it around.. You see the first stage is successful by grabbing the jar file but in the second stage you see a 404 when its trying to grab its evil.
So what does NSM really give you? It gives you options. It gives you all the data you need to make an informed descision about what is the real deal vs what is just noise. As attacks become more and more behavior based there will be even further needs for this type of info. The best part of it all is the best tools out there to do this are open source. You can get started today by simply downloading Security Onion.
I did not write this to say traditional IDS is useless but to show folks that there is a difference. You may believe that your methods are awesome and I am full of crap and that is fine but I have never heard anyone complain they have too much information on an incident. I just know that having an alert for me is not enough information to make an informed decision on the state of the machines involved.
Friday, April 26, 2013
Thanks for Hacking Me!!!
Dear "Hacker" from Brazil,
I wanted to thank you for hacking my Redhat box in 2000 via a vulnerability with wuftpd. At the time I was very angry with you and I felt violated. I also want to thank you for not covering your tracks very well. What pisses me off is I was doing a remote install and I had to start it all over again once you owned it. I was excited when I was about to leave for work that day since the install had just finished from running over night and I rebooted the box and tested the remote login. I was going to finish up what I was doing when I got to the office.
You see I was taken aback when I tried to connect from my shell server on the internets when I got a warning about the SSH key. In the 30 minutes between leaving my house and getting settled into work you somehow found my box and rooted it. I was unable to log into the machine because you replaced the standard ssh server with your own personal version. This was stupid because if you would have tried to hide yourself a little bit I probably would not have noticed. But I am glad your stupid because had you not done that I would not have switched to Infosec as a career.
When I looked at your shitty code with comments in portuguese I started to see what you did there. I know you were using my fast connection at the time to move mp3s around and I have to say your choice in music was horrible. After I booted that thing in single user mode and moved the code off to somewhere else I restarted that damn install. Some days I miss those boot floppy linux installs. :)
To that point I just wanted to be a network engineer because I thought that was really cool messing with routers and switches. I had just set up my first BGP router and route filters and was riding high. But that day when I booted into single user mode I was a changed man. I took that crappy code of yours and rooted myself as soon as the fresh install finished. I learned so much from your code that I started looking for other scripts to play with. I think it was 6 months later I got my first dedicated security job. (very rare at the time)
After being in this business for a long time now I talk to a lot of people who got into this line of work for the exact same reason. Something they used got wtfpwntsauced and they found a whole new world once their eyes were opened. So although I was extremely pissed at the time I want to take back that anger and formally thank you for owning me. I can't think of anything else I would rather be doing.
Smooth out
When I looked at your shitty code with comments in portuguese I started to see what you did there. I know you were using my fast connection at the time to move mp3s around and I have to say your choice in music was horrible. After I booted that thing in single user mode and moved the code off to somewhere else I restarted that damn install. Some days I miss those boot floppy linux installs. :)
To that point I just wanted to be a network engineer because I thought that was really cool messing with routers and switches. I had just set up my first BGP router and route filters and was riding high. But that day when I booted into single user mode I was a changed man. I took that crappy code of yours and rooted myself as soon as the fresh install finished. I learned so much from your code that I started looking for other scripts to play with. I think it was 6 months later I got my first dedicated security job. (very rare at the time)
After being in this business for a long time now I talk to a lot of people who got into this line of work for the exact same reason. Something they used got wtfpwntsauced and they found a whole new world once their eyes were opened. So although I was extremely pissed at the time I want to take back that anger and formally thank you for owning me. I can't think of anything else I would rather be doing.
Smooth out
Saturday, February 23, 2013
My Home Setup - FREENAS and VMWare ESXi
Throughout the years my home setup has seen many changes but the overall requirements have pretty much stayed the same. I need some test servers and a file server as well as a firewall to provide internet access and do some PAT/NAT luvin. Here is sort of an explination of the evolution of my home setups through the years.
In the early dial up/cable modem days I would have a standalone multi-homed box acting as my firewall and then multiple machines living behind that. This worked really well for a long time but it had a rather large physical footprint. I would have multiple physical machines for different things. Back in the day this wasn't a big deal because energy was cheap and I thought it was cool to have a sun box to learn on etc.
Once virtualization became something that was solid and memory prices began to drop I was able to consolidate a lot of hardware on to less physical hardware. This eventually pushed me down to a single server with lots of disk running linux and a commodity interwebs firewall/router. This worked fine for a while but there were a few things I had problems with:
Normally my home setup was something that was just pieced together with old stuff without too much thought. So I decided new hardware instead of hand me downs and also put together some basic requirements for my new home setup. (Disclaimer - My hardware is not new any more as this setup has been running for several years now but when I built it was mostly new)
- Must be able to keep network storage available while I am blowing up my OS/kernel.
- Need to isolate VMs that have no exposure to my internal network.
- Easy to spin up instances for testing stuff.
- ZFS Z-Raid.. Cause its pretty much awesome.
- Jumbo Frames NICs. (We'll get into that later)
- ESX compatible hardware.
When I took these requirements into consideration I ended up going for 2 physical boxes. I would have a FreeNAS box and an ESXi box. The FreeNAS machine would meet my ZFS needs as well as allow me to mess with stuff on my main box without having to move data around. I would simply use this same disk for the storage pools inside ESXi.
First off I won't go deep into the steps to get ESX working on a whitebox type motherboard. There are tons of articles and sites with info out there for that. In my ESX box I have 8 gigs of RAM and a quad core CPU. I ended up buying 2 intel Gigabit NICS and pulled an old 3Com 3C905B from storage. Those were the bomb back in the day and I still have a few.. I could never bring myself to pitch them. So my hoarding ways for old hardware paid off. (I still have my 2 Canopus Pure 3DII cards.. Those will always be with me.) All I have is a 8 gig USB thumb drive plugged into the back.
So why 3 NICS? My first Intel NIC is my uplink to the internal network. On the second Intel NIC is my dedicated connection to my FreeNAS box utilizing jumbo frames. (You must configure the virtual switch to use jumbo frames) My 3rd NIC the trusty old 3C905B is for connectivity to the Internet. It's only a 100meg NIC but my Interwebs is only 30mbit so it will do.
On the FreeNAS box I dropped in an Intel NIC along with the onboard Realtek. The Intel NIC would be for the jumbo frames network. I also used an 8GB USB drive for the OS as well. I also have 6 x 1TB hard drives that are in a Raid-Z config as well as 2 x 300GB that are mirrored for my iSCSI mounts for the OS.
In ESXi I created 4 virtual switches 3 of which have one of the NICs assigned. You can see ISONET has no physical adapters. This will be the network for VMs I want to expose inbound services from the Internet to.
The Kernel Port in the Storage network is important because that is how I am mounting the iSCSI mount from the FreeNAS box for my VMs.
Commodity firewall/routers are neat and all that but nothing beats pfSense. It gives me everything I need out of the box with some really cool remote access features. When you install the pfSense VM assign it 3 network cards and put one in the 3C905B switch (Internet), the internal network Intel NIC (LAN), and finally the last one in the ISONET.
When install pFSense make sure you assign the correct network cards to the "zone" they are supposed to be in. Typically you can keep the default for the WAN and LAN zones but make your ISONET ruleset look like this:
The first rule denies all traffic to the LAN Network. The second rule allows it to go everywhere else. Now you can further lock this down if you like or you could open certain services to your internal network if you really wanted to like ssh etc. Just make sure you put those above the first rule.
The early days
Enter virtualization
Once virtualization became something that was solid and memory prices began to drop I was able to consolidate a lot of hardware on to less physical hardware. This eventually pushed me down to a single server with lots of disk running linux and a commodity interwebs firewall/router. This worked fine for a while but there were a few things I had problems with:
1. Flexibility
With linux being my host OS and running VMs I was constantly trying to manage updates and reboots. This becomes a serious pain in the ass when you have to recompile kernel modules every kernel update so that vmware would continue to work. The other issue was if I wanted to play around with different base OS installs I would have to do something with my data like copy it to other machines which is a royal pain. Also your standard home based firewall can't do a lot of cool things like say a pfsense box. (OK The WRT stuff is cool)2. Security
Typically there are a few services I like to expose to the internets like SSH in case I need to log into the crib or shell access for things like irssi etc. The problem with using PAT is that if your internet facing VM gets WTFPWNTSAUCED the adversary now has a foot hold inside your internal network. This means they can try and access your systems that actually have something you care about on them.Enter my new home setup:
Normally my home setup was something that was just pieced together with old stuff without too much thought. So I decided new hardware instead of hand me downs and also put together some basic requirements for my new home setup. (Disclaimer - My hardware is not new any more as this setup has been running for several years now but when I built it was mostly new)
- Must be able to keep network storage available while I am blowing up my OS/kernel.
- Need to isolate VMs that have no exposure to my internal network.
- Easy to spin up instances for testing stuff.
- ZFS Z-Raid.. Cause its pretty much awesome.
- Jumbo Frames NICs. (We'll get into that later)
- ESX compatible hardware.
When I took these requirements into consideration I ended up going for 2 physical boxes. I would have a FreeNAS box and an ESXi box. The FreeNAS machine would meet my ZFS needs as well as allow me to mess with stuff on my main box without having to move data around. I would simply use this same disk for the storage pools inside ESXi.
First off I won't go deep into the steps to get ESX working on a whitebox type motherboard. There are tons of articles and sites with info out there for that. In my ESX box I have 8 gigs of RAM and a quad core CPU. I ended up buying 2 intel Gigabit NICS and pulled an old 3Com 3C905B from storage. Those were the bomb back in the day and I still have a few.. I could never bring myself to pitch them. So my hoarding ways for old hardware paid off. (I still have my 2 Canopus Pure 3DII cards.. Those will always be with me.) All I have is a 8 gig USB thumb drive plugged into the back.
So why 3 NICS? My first Intel NIC is my uplink to the internal network. On the second Intel NIC is my dedicated connection to my FreeNAS box utilizing jumbo frames. (You must configure the virtual switch to use jumbo frames) My 3rd NIC the trusty old 3C905B is for connectivity to the Internet. It's only a 100meg NIC but my Interwebs is only 30mbit so it will do.
On the FreeNAS box I dropped in an Intel NIC along with the onboard Realtek. The Intel NIC would be for the jumbo frames network. I also used an 8GB USB drive for the OS as well. I also have 6 x 1TB hard drives that are in a Raid-Z config as well as 2 x 300GB that are mirrored for my iSCSI mounts for the OS.
So give me some details:
In ESXi I created 4 virtual switches 3 of which have one of the NICs assigned. You can see ISONET has no physical adapters. This will be the network for VMs I want to expose inbound services from the Internet to.
The Kernel Port in the Storage network is important because that is how I am mounting the iSCSI mount from the FreeNAS box for my VMs.
FreeNAS
FreeNAS is pretty straight forward. I set up iSCSI but you can also use NFS for your ESX setup. Just be sure to change the networking for jumbo frames support:
pFSense.. The key to this setup:
Commodity firewall/routers are neat and all that but nothing beats pfSense. It gives me everything I need out of the box with some really cool remote access features. When you install the pfSense VM assign it 3 network cards and put one in the 3C905B switch (Internet), the internal network Intel NIC (LAN), and finally the last one in the ISONET.
When install pFSense make sure you assign the correct network cards to the "zone" they are supposed to be in. Typically you can keep the default for the WAN and LAN zones but make your ISONET ruleset look like this:
The first rule denies all traffic to the LAN Network. The second rule allows it to go everywhere else. Now you can further lock this down if you like or you could open certain services to your internal network if you really wanted to like ssh etc. Just make sure you put those above the first rule.
Where to go from here?
Personally I am getting ready for a hardware refresh as recent motherboards etc have way lower power usage. I know Panaman is using an E-350 for his FreeNAS box which is extremely low power. That is really the only shortcoming with my current implementation is power usage. If I was building this today I would make sure to take power consumption in mind. Although I am running 6 of the WD Green Drives I think I would get 4 x 3TB WD Red drives. They are better for home NAS use according to Western Digital. Soem other things I would like to do to improve this is add second NICs to the jumbo frame network and make them bond interfaces to get more bandwidth. Most of the time this is not a problem but if I am processing a lot of data across that link I do notice a performance hit on other VMs.
That's really it. Comment below if you have questions.
Smooth out
Subscribe to:
Posts (Atom)










