Cobia Community Blog

Setting up a DHCP server in 20 minutes

Need a DHCP server right now?  With Cobia, you can have one up and running from a barebones system and ISO in about 20 minutes.  Maybe less, if you're not working on one or two other projects at the same time like I usually do. 

This is another in my series of how-to's, and this is probably going to be one of the easiest to implement yourself.  If you've already got a Cobia server up and running, you could literally be done with the entire process in under 5 minutes. 

Scenario:  Basic configuration of the DHCP scope and a dynamic pool. 

Description: The DHCP server on Cobia only takes a couple of minutes to set up and start running on your network. This post addreses the initial setup and configuration of a DHCP scope and dynamic pool.

Technical requirements:  Cobia server with initial setup completed.

Solution: Setting up the Cobia server to start offering DHCP services is a two step process. First, create a scope by selecting "Add a scope" from the DHCP -> Configure DHCP -> General screen. Select a unique, descriptive name for the DHCP scope and select an interface for the server to offer DHCP addresses on, then select OK twice to create the scope. To create the dynamic pool in your new scope, select the interface you created the scope in and click on 'add a dynamic pool'. Select a unique, descriptive name for the pool, designate your pool of IP addresses and subnet mask. Select OK three times to commit the changes.

Finally, stop and start the DHCP service on the system from the DHCP -> Configure DHCP server page. 

Time Required:  5 minutes

Use Case:  Configuring a DHCP scope and dynamic pool.

Use case scenarios

If you haven't already noticed, Mitchell and I are working on a number of use case scenarios for Cobia that will be posted to the blog over the upcoming weeks.  These will be step by step instructions on setting up a Cobia system on your own home or business network, starting simple and building up to more complex implementations.

These will be multi-part postings, each covering a different aspect of implementing a small business network.  The first series is based on a small office of 25 or fewer systems, and will include setting up DHCP scopes and reserving IP's for file servers and printers.  The second series will be for a larger office with 25 to 250 users and will include setting up a mail gateway and a DMZ for web accessible services, such as your web server.

One of the more interesting scenarios we'll be writing up is the use of Cobia in a multi-building campus environment.  I haven't worked much with BGP or RIP before and will be getting a lot of help from several of our engineers, meaning I get to learn an aspect of security and networking I haven't dealt with much before.  And I always enjoy learning about technologies that are new to me.

Our final writeup will be a multi-site network connected over the Internet via VPN.  There are also several related writeup such as setting up a VMware lab environment and egress filtering that will be included as time allows.

If you have a scenario you'd like to see written up or have a writeup of a situation you've created in your own environment, send me an email at cobia_at_stillsecure.com. 

Using a wireless router with Cobia

I recently moved my wireless network at home to my Cobia server.  I'd previously had it hanging off of a Linksys router connected to my DSL modem, but I didn't have nearly as much control over the firewalling functions as I'd like.  The Linksys box is a perfectly acceptable as a consumer level firewall and does what my father or grandmother might need, but doesn't give me quite the capabilities I need.  And if you're reading this blog, you need a bit more control and capabilities than a consumer router is going to give you.

Moving to my AP over to my Cobia server only took a few minutes.  Obviously, the first thing to do was set up the Cobia server.  I have a small pool of static IP addresses from my ISP, so I assigned the external interface, eth0, one of these.  If you're getting your IP from a DHCP pool provided by your ISP, you'll need to read KC's article on setting up a DHCP client on your system.  My ISP provided me with the important information such as default gateway and DNS servers, as do most ISP's.  I've found most ISP's to have a pretty good FAQ about setting up your internet access, but your mileage may vary.

The next step was to set up the internal interface for the wireless router.  I chose to use the 2.0.0.0/24 subnet, but any of the bogon networks would have worked.  I'm using it as a class C subnet because I will eventually have additional hosts in a DMZ off of the Cobia server.  If I wasn't, I'd use a /29, subnet mask, which makes the network 2.0.0.0, the Cobia firewall internal interface 2.0.0.1 the AP 2.0.0.2 and the broadcast address 2.0.0.4.  I like limiting it to the bare minimum IP address usage so no other hosts can be added to the subnet.  Not that this is too likely in your home network, but it's a good habit to stay in for when you're working on the corporate network.

After that, you need to set up SNAT'ing on the Cobia firewall, which I covered on the blog last month.  The AP needs to plug into eth1 on on the Cobia server and and one of the switched ports on the AP.  This allows you to have the AP forward any DHCP requests to the Cobia server rather than using the DHCP capabilities of the AP.  You need to plug Cobia into a switched port rather than the WAN port, because the AP won't pass DHCP requests through the WAN port.  When you initially plug your computer the AP's switched ports for configuration, it should provide you with a 192.168.0.x address.  Turn off the DHCP service on the AP and use the DHCP service on the Cobia server instead.  Your Cobia firewall's internal interface will be the default gateway and the DNS information will have been provided by your ISP.

Be sure to use the best encryption you can on the AP, at the very minimum WPA Personal.  This is what I had to use because of the built in wireless on my HP laptop won't work with WPA2.  WPA is not bulletproof, but it's a lot better than WEP.  A script kiddy could break WEP in 10-20 minutes, where as I've been told WPA takes at least a week.  WPA2 hasn't been cracked yet, to the best of my knowledge, but it's not supported by all vendors.

After that, it should just be a matter of setting up the wireless connection on your laptop or desktop.  My children's computer is in another room of the house and I didn't feel like running a cable.  More accurately, my wife wasn't willing to let me drill more holes in the floor or walls to run cables.  The wireless works great for them and I'm hoping to move the wife's computer to the wireless network and out of my office soon. 

Questions or comments?  Send an email to [email protected] or leave a comment on the blog.  Let us know if this has been helpful to you.

Blocking the Bogons with Cobia

Almost everyone in IT knows the bogons, even if they don't know them by that name.  They're the list of unassigned IP addresses that no one should be using on an external network.  The one's most people use are the 192.168.0.0, 127.0.0.0 and 10.0.0.0 addresses, but there are nearly 50 distinct class A, B & C networks that qualify as bogons.

Unless you have a good reason, you should have ingress and egress filters on your firewalls blocking all traffic to these networks.  Why?  Because there's no good reason for your firewall to be passing this traffic, since the bogons are supposed to be unused.  If there's traffic originating from one of these coming into your network, chances are very good it's going to be malicious.  The source address of the packet is most likely forged and it's an attempt to do something bad to your network.  Similarly, if your network is trying send packets to one of these networks, you either have a misconfigured host or one that's trying to connect something that doesn't exist.  So in either case, you want to block the traffic before it can do harm.

So how do you block the bogons using the Cobia firewall?  It's actually pretty easy, but it is somewhat time consuming.  Even the consolidated bogons list has 30 different networks that need rules written for them.  If you create both ingress and egress filters for all of the networks, you have to create over 60 rules.  From the firewall module, select Add Rule.  I chose to name each rule "Bogon x.x.x.x" so that I could easily identify each rule and the addresses it affects.  I also decided to turn both logging and the rule hit counter options to make troubleshooting that much easier.  After all, if you're using a bogon IP network in you're DMZ, blocking all the bogon's could cause you just a little bit of problems.

The rules themselves are simple:  Block any traffic with a source IP in the bogons list.  Using the 5.0.0.0 network as an example, select the exterior interface as the source and the internal interface.  Change the source address from 'Any source IP address' to 'IP address/netmask'.  Enter the network IP and mask in the appropriate boxes, leave the destination address as 'any' and the protocol as 'any'.  Pay attention to the subnet masks for the bogons, many of them are not standard /8 or /16 subnets.  You could change the destination address to that of your network, but it would have the same affect overall anyways.  Finally, set the action to deny, hit the 'ok' button to save the rule and continue on to the next rule.  When you have all 30 incoming rules, hit the 'ok' button a second time to commit the rules.

Creating the egress is the same, except the interfaces will be reversed with the incoming interface being your internal interface.  Other than something on your internal network, such as the previously mentioned DMZ, there's no reason our network should ever be sending traffic to a bogon network.  Having the egress filters turned on with the rule hit counter enabled could notify you of malicious traffic on your network.  Or maybe an end user who took their laptop home and reconfigured it for his or her network and is now sending out spurious traffic.  It also helps you be a good netizen.

I've included a screen shot of a finished firewal rule as well as a copy of the IPtables rules that Cobia creates to implement these rules in the extended body.  Each Cobia rule creates 3 IPtables rules: the blocking rule, the logging rule and the hit counter rule.  The logging and counter rules are almost the same, except for the fact that they write to different log files.  The IPtables rules below are created automatically by Cobia, I included them to illustrate how easy Cobia makes it to create these rules.

Please leave me a comment or send me an email if you found this useful.  If you've got a project you'd like to see me walk through with Cobia, let me know.  I'll be regularly posting how-to's such as this and could use some ideas .

Source NATing

This morning on the Cobia Forums, we had a question about the creation of a basic firewall rule configuration.  As was pointed out by Paul Crook, without any setup the Cobia firewall module allows all outbound traffic and responses, but blocks incoming traffic, because of the default Final Rule .  If your using live, assigned IP's on your internal network, the firewall should pass the traffic through automatically and work without any additional configuration. 

On the other hand, if you're like most of us, you'll be using a non-routable class B or C network, such as 192.168.x.x, on your internal network and need to do Network Address Translation or NAT. KC Berg stated that it'd be a cake walk to make the rule and I thought it was worth taking a few minutes to put together a quick screen capture of how to create this in Cobia.

From the base of the Firewall module, select 'Configure firewall', 'NAT Rules' and 'add rule' in the Source NAT section (left image).  I named the rule Cake Walk, set the Incoming interface to my private network and my outgoing interface to the public network(right image).  Hit ok twice to commit the rules and all traffic from the internal network will given an external IP address as it exits the network.

I choose a simple configuration like this to start, but I'll be creating quick Cobia walk throughs like this in answer to questions from the forum or when I do something interesting on my own network.  Let me know if there's a scenario you'd like to see us talk about.  You can drop us a line a at [email protected].

Furniture shopping and Cobia

Right now, my wife is online looking at new office furniture.  Because I'm spending a lot of my time working from home, she wants her computer out of my office and I'm not complaining.  She has a modest budget for a armoire type computer desk in the living room, the type that folds away when you're not using it.  The search has already been going on for a week, but hopefully she'll find something soon.

This will also mean redesigning portions of my network, something I'm looking forward too.  As it currently stands, my Linksys wireless router is sitting behind another Linksys router which in turn sits behind a third Linksys router that acts as my external firewall.  My DMZ between sits between the two wired router and my local network is on the same router as the wireless router.  My wife's computer is currently sitting on the local ethernet network.

When we find the piece of furniture she wants, her computer will have to move to the wireless network.  I'm building a Cobia server to act as the firewall for the wifi network, directly connected to the DSL router.  The Linksys WRT54G will attach to the Cobia firewall, which will probably also become my secondary DNS server eventually.  It'll simplify that portion of the network a lot, and hopefully clear up some of my issues with the kids wifi.  Next thing is to rate limit the wife and kids connection so I can keep all the bandwidth for myself!  Or not, if I don't want to run afoul of my wife.

I'm can't wait to reclaim the room in my office as well as cleaning up my network a little.   I think I'm going to have to reset the WRT54G because I misplaced the password, but that's a small price to pay.  I'll take notes and post a write up here.  Once we've selected the furniture, that is.

Blocking Boguns

I like revisiting the basics from time to time.  It just seems like a good idea to me to go back and make sure you've got a good foundation to work from before moving on to more complex tasks.  And by taking another look at the simple stuff from time to time, it helps me understand and remember how it relates to the more esoteric security considerations we sometimes run into.

One of the things the developers did in the Cobia firewall module was to automatically create a final firewall rule that drops all traffic.  This is the good, old, "if it's not explicitly allowed, it's denied" rule.  It's a simple rule, with not much to it, but it's one I've seen forgotten more than once.  Having it created by default means one more thing you don't have to worry about.

When I was recently in Texas at TRISC, I got to sit down and listened to Mark Loveless, aka Simple Nomad, talk about evading IPS/IDS.   One of the methods he mentioned was how hackers use 'dark' or unused IP addresses to perform reconnaissance and attacks against networks.  Some of these are addresses that have been assigned but aren't currently used, such as spare public IP addresses, but a large number of them are bogons.

What are bogons?  According to the Team Cymru Bogon Reference page, "A bogon prefix is a route that should never appear in the Internet routing table."  In other words, a bogon is an IP address no one should be using.  And since no one should ever be using IP addresses from the bogon list, there's no reason we should be allowing this traffic into or out of our networks. 

Creating an ingress and egress filters to deal with the bogon list is fairly simple but will take a few minutes to set up the first time since the list is fairly long.  Team Cymru has provided the list in several forms, and updates it regularly to remove allocated addresses and add disputed or unused ones.  While you're creating these filters, I'd suggest adding another to block inbound traffic that originates from your own subnet range; there's no reason you should ever see this type of traffic, so block it.

Blocking the bogon addresses is a simple process, but it's one we often overlook in a firewall installation.  It probably won't make a difference in your day to day networking, but if it gives someone trying to scout out your network one more hurdle to overcome, I think it's worth doing.  If you've got a good foundation to work from, then when the more complex problems come up, you've got your basis covered.