Archive for the ‘linux’ tag
A Quick Intro to Google’s Capirca
Yeled left a comment earlier this week asking if I’d seen Google’s Capirca. I’d heard of it and checked out some presentation slides on it, but I’d never actually tried it out, so, in keeping with the script, I downloaded it to see what it could do. Remember, now, that I’ve been playing with it for about 2 hours now, so I’m no expert on its use.
Capirca is a Python-based solution that Google came up with to automate ACL creation on their many thousands of routers around the world. You can’t blame them for wanting to automate it, either. How many times do you think they ran into problems with typos or keying errors from their network guys across those devices?
Capirca is configured similarly to Snort. The concept is that you define objects like hosts, networks, groups, and services, then you define policies based on those objects. You run the app against your definitions, and it pukes out ACLs for you. It can do Cisco ACLs, Juniper ACLs, or IPTables rules, so that may come in handy, but I only care about the Cisco stuff right now.
Like I said, I haven’t messed with it before, but I got it working with very little frustration. From the root of the application (~/capirca-1.0 in my case), I edited def/NETWORK.net and added some custom objects to it to mess around. I added my home networks, my public IP address at home, and some of the work networks that I would use to access home services. Here’s what I added to the sample file.
...SNIP...
GUESTS = 10.0.2.0/24
USERS = 10.84.8.0/24
HOMENETS = GUESTS
USERS
WORKNETS = 192.0.2.0/24
MYPUBLICIP = 192.0.2.1
...SNIP...
Now I can use those objects to define some rules for the ACL. The rules are defined in the policies/ directory and are a little more complicated than the objects, but it’s not that hard. There are two types of entries in the policy files – headers and terms. Headers define the beginning of a new ACL and define what the platform (Cisco, Juniper, IPTables) you’re using and the name of the list. The terms sections define the details of the ACL like source, destination, protocol, port, and action. Here’s the policy file (that I called home.pol) that I added to simulate letting my work IPs get to SSH on my public IP, everybody get to HTTP on the same, and deny everything else.
header {
comment:: "F0/0 Inbound"
target:: cisco F00IN
}
term permit-ssh-services {
destination-address:: MYPUBLICIP
protocol:: tcp
destination-port:: SSH
source-address:: WORKNETS
action:: accept
}
term permit-http-services {
destination-address:: MYPUBLICIP
protocol:: tcp
destination-port:: HTTP
action:: accept
}
term default-deny {
action:: deny
}
That creates a new Cisco ACL called F00IN (for F0/0 inbound) that allows our interesting traffic and denies everything else. Now that the policy is configured, all I had to do was run the executable and see what happens. In the root directory of the application, there’s a Python file called aclgen.py that you run. Since we put all our definitions and policies in the default location, all I had to do is run that with no arguments. The output told me to look in filters/home.acl for my new ACL. That’s where I found this.
no ip access-list extended F00IN ip access-list extended F00IN remark F0/0 Inbound remark permit-ssh-services permit 6 192.0.2.0 0.0.0.255 host 192.0.2.1 eq 22 remark permit-http-services permit 6 any host 192.0.2.1 eq 80 remark default-deny deny ip any any
Looks fine to me. I pasted this into a lab router, and it worked like a champ. I think I’ll put some more time into Capirca to see if I can find a use for it at work.
Send any misspelled Battlestar Galactica references questions my way.
Director’s Commentary: I need to get a better mic if I want to keep doing this.
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
An Interesting Problem with Multiple DCs on a Stick
We talked about running multiple data centers on a stick back in August, which is where you have multiple logical pairs of client and server VLANs on a single CSM for different tiers or functions. The big point of the article was that you had to do some fancy forwarding to get a server-initiated connection from one server VLAN to appear out the appropriate client VLAN. Well, we ran into an interesting issue with the given solution.
Let’s set up a scenario. Check the diagram for an overview. We have many pairs of client and server VLANs each with a firewall interface as the gateway into the DCOAS. Let’s just focus on just one, though — client VLAN 101 and server VLAN 102. In VLAN 101 is ServerA (not pictured) with an IP of 1.1.101.45; in VLAN 102 is our web farm that needs to connect to ServerA to drop off some data. We add a static route on ServerA pointing traffic for 1.1.102.0/24 back through the CSM.
When you try to connect from the web farm, though, it just times out. Why is that?
Remember that weird forwarding vserver that we had to use to get traffic to come out of the right client VLAN? Well, that’s stabbing you in the eye right now. When the web server initiates a connection, it sends traffic to the server VLAN IP of the CSM. The forwarding vserver grabs the new connection and load balances it to its only RIP, which is the IP of the firewall. What happens when any good firewall accepts traffic destined on an interface destined for a host out of the same interface? It drops the packet, and, eventually, the server times out.
What’s the fix, then? There are a few that come to mind. The first may be to just move ServerA to another network segment. Another may be to change the process around a bit by having ServerA pull the data instead of it being pushed since client-initiated connections will work like a champ.
A really outrageous one would be to set up another forwarding vserver that has only ServerA as it’s serverfarm. You would then add a static route in the web servers pointing to ServerA through that VIP, which would foward it over.
On the CSM, you’d do something like this.
serverfarm SERVERA-SF no nat server no nat client real 1.1.101.45 <--- ServerA inservice vserver SERVERA-VS virtual 1.1.102.5 any vlan 102 serverfarm SERVERA-SF inservice
On the server, you would add a static route to ServerA through 1.1.102.5. If you’re using some brand of Linux, you’d do this.
route add 1.1.101.45 gw 1.1.102.5
Don’t forget the static route on ServerA.
Send any Peeps questions my way.
VLANs on Linux
My home network has a Linux box running IPTables as it’s center point, and, since there are four networks, it has 4 NICs and 4 cables into the switch. I kept running into problems with the NICs (they would reorder depending on what flavor of Linux was installed), so I wanted to consolidate the NICs down to 2 — one for the Internet link and one for the LAN segments with 802.1q tagging.
Disclosure: I have only labbed this stuff out, and it seems to work, but I have yet to implement it. Use at your own risk in the wild.
Configuring VLAN tagging on Linux is pretty simple, actually. One way to do it is to use the vconfig command to add and remove VLANs from interfaces. As a demonstration, say you want to run VLANs 20 and 30 on eth0. You would just do something like this. Note that the interface you mention here has to be in an UP state, so do an ifconfig eth0 up if you need to get it into a good state.
vconfig add eth0 20
vconfig add eth0 30
Now, whenever eth0 comes up, you’ll have the interfaces eth0.20 and eth0.30. You can give them IP addresses through the command line with ifconfig.
ifconfig eth0.20 192.168.20.1 netmask 255.255.255.0 up
ifconfig eth0.30 192.168.30.1 netmask 255.255.255.0 up
I didn’t expect them to do so, but the IP addresses actually stay across network restarts; as long on the physical interface comes up, the VLANs come up with IPs and everything. Speaking of network restarts, the “downfall” with using vconfig is that VLAN interfaces don’t show as coming up or going down during network restarts; I don’t like that at all.
Another way to configure the VLANs is through the old-fashioned network-scripts directory. Copy your interface config (ifcfg-eth0) to the same name but with the VLAN extension (ifcfg-eth0.20) and edit it. Change the device field appropriately along with the IP address subnet mask info. For the final touch, at the end of the file, add this line.
VLAN=yes
Personally, this is the way I would do it. It lets you change configurations through the configuration files just like physical interfaces instead of trusting the configuration that resides out in the ether that is the Linux kernel. Also, when you restart network, the interface itself actually goes up and down, so you can see what’s going on with it. If you need some help with this, check out Redhat’s manual on it. Let me know if you’re still having problems with it.
Remember to set the box’s switch port to a matching 802.1q trunk. You’ve seen that before, but here’s a refresher, assuming the Linux box is plugged into f0/1 on the switch.
int f0/1
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
To check the status of your VLANs, look in /proc/net/vlan. You’ll see the config file, which lists all your VLANs. You’ll also see a device file (like eth0.20) with the statistics for that VLAN device (interface).
Let’s talk security, though. First of all, I could argue that a Linux box shouldn’t be participating in any trunking at all. There will be exceptions, but, in my experience, a Linux box (read: server) should only be on one network at a time and shouldn’t straddle networks. Do you really trust the Linux guys to keep their boxes from doing bad things on more than one network? I don’t. Heh.
If, however, you need to use VLANs on a Linux box, you’ll need to make sure you have only the proper VLANs running across this port (like we did with the CSM VLAN). If a box were to be compromised, the bad guy could simply start adding VLANs to the server and suddenly get around your routers and firewalls. Awesome, right? Make sure you put in the switchport trunked allowed vlan x directive so the server only has access to those VLANs.
As always, send me any four-leaf clovers questions you have.
P.S.: For the record, since I haven’t tried this in the field yet, I can’t tell you how well it works with IPTables, but, from what I’ve been reading, it should work fine. Good luck.
For the record, I’ve got this working at my house connected to a Cisco Catalyst 2950 trunk port. I’m happy to report that it works like a champ with IPTables and everything.
Unix Epoch + 1234567890 = Next Friday
I’m kind of an obsessive-compulsive when it comes to numbers (1, 2, 3, 4, 5…), so I’m fairly excited about next Friday (..6, 7, 8, 9, 10…) when Epoch time reaches 1234567890 at 18:31:30 on 13 February(…11, 12, 13, 14, 15…). I’m sure my ADD will kick in (Oh, look. A squirrel!) right before, but I’ll try to remember to run to a Linux box and type date +%s (…16, 17, 18, 19, 20! Made it!).
Leap Second
Did anyone notice (or care about) the leap second? I did neither. Here’s some cool output from Kevin Oberman on the NANOG list, though.
bash-2.05b# date
Thu Jan 1 00:59:58 CET 2009
bash-2.05b# date
Thu Jan 1 00:59:59 CET 2009
bash-2.05b# date
Thu Jan 1 00:59:60 CET 2009
bash-2.05b# date
Thu Jan 1 01:00:00 CET 2009
bash-2.05b# date
Thu Jan 1 01:00:01 CET 2009
bash-2.05b#
Free and Awesome Network Tools
We all have limited budgets these days. Long gone are the days of unlimited resources and uncontrollable expansion of the network, so it’s important that any network dude or dudette pay attention to the open-source world. Below is a list of stuff I use at the office and at home to monitor, trend, and alert the network. All this stuff is free and runs on Linux to save even more cash.
- Cacti – This is a system for trending pretty much anything. If it has an SNMP value, Cacti can trend it. It’s also really flexible, allowing multiple displays of data and even a mechanism to get values from scripts you write. At the office, we use it to monitor utilization of the circuit and Ethernet ports, CPU and memory of the gear, and the number of connections on the load-balancer. At home, I use it to watch utilization and track the number of connections to the wireless networks.
- Nagios – This is a monitoring and alerting system for all sorts of stuff. It watches hosts and applications for availability and response time, then alerts based on threshold. This is one of the most complicated apps to configure, but, once it’s up, it rocks. I use it at home to monitor all the network gear and systems for response times. I also use it to monitor the web servers and restart them if they’re down.
- Apache – You know what Apache is. You use it already. About 71% of webservers on the Internet are Apache.
- Squid – A caching proxy server by the same guys who do Apache. It can be configured for both inbound and outbound application acceleration. It’s great to put in front of a CMS like Drupal or Joomla. It has a mess of built-in functions that can look for bad requests, do redirects, or completely rewrite requests. At work, it fronts our application and CMS servers so users don’t have access directly to them. At home, it runs on the firewall to serve pages to the Internet. The real webserver actually sits on a box behind the firewall for security.
- Subversion – This is a version control system. Subverions lets you create repositories, check out the contents, edit them, and check them back in. This is good for keeping track of configuration files or scripts you write. We use it at work to track configuration files for Apache, NTP, yum, etc. At home, I use it to keep track of my scripts and Perl module.
- Rancid – This is configuration management for Cisco (and other network) devices. It gets configs from devices and checks them for changes. It’s got built-in alerting and is easy to set up. I use it at home to keep track of the configs on the switches and access points.
- nfsen/nfdump – These are [tag]netflow[/tag] tools. Nfdump is a suite for collecting the data, while nfsen is for displaying the information. Check out netflow if you’ve never worked with it…it’s pretty cool.
- Dyanmips/dynagen – These apps let you run virtual Cisco routers on a machine. You can set up full network deployments for testing and configuration experimentation. It takes a good bit of resources, but it’s well worth it for the functionality. I use it all the time at work to test or tweak configs. I also use it to simulate certification labs.
A Simple BGP Lab with Dynamips/Dynagen
I assume you take every word I say to heart and that you’ve been using Dynamips/Dynagen for a few days now, right? Good. That’s a start, but let’s break down a simple lab to make sure everyone’s on the same page. I run my labs on Linux most of the time, so you’ll see my commands for that platform. You’re a smart one, so you can figure out what to do on Windows. :)
First of all, everyone download the lab file. This is a very simple lab that I created to do some experimentation with BGP. I modified it a bit to save resources for the general public, though; it’s a lot easier to run 2 2651XMs than 2 7206s, right? Let’s go through the lines.
autostart = False
[localhost]
Yes, that means don’t start up the routers when you fire up dynagen. The second line is the dynamips server you want to use. This will always be localhost unless you’re leveraging another box to use as the emulator. That’s an advanced topic that I’m not going to cover right now, though.
[[2651XM]]
image = /home/jac/labs/images/c2600-adventerprisek9-mz.124-17.img
ram = 96
These lines define the parameters for any 2651Xm that we’ll be using. The image file is the actual IOS image to use. I can’t provide an IOS file for you, so you’ll have to download one yourself and change this line to where you put the file. Guess what the “ram” line is. Wow…you’re a genius if you said it was the amount of RAM to give each 2651XM. :)
[[ROUTER R1]]
s0/0 = R2 s0/0
f0/0 = LAN 1
model = 2651XM[[ROUTER R2]]
f0/0 = LAN 2
model = 2651XM
Here’s the meat of the lab. We’re creating 2 2651XMs, called R1 and R2, that each have s0/0 and f0/0 interfaces.
The 2651XM has 2 FastEthernets, so, when you fire up the lab, the routers will have those interfaces, but we don’t care about f0/1 in the scope of this lab. We’ll just ignore it for now. The “LAN” keyword in the f0/0 lines tell how you want the FastEthernets cabled up. We’re trying to do BGP here, so the FastEthernet interfaces are connected to different network (R1 to LAN 1 and R2 to LAN 2).
Notice that, in the R1 configuration, we say that R1′s s0/0 is connected to R2′s s0/0. This lets the routers talk across the serial interfaces in the virtual world. In our lab, this is the link that we’re going to run BGP over to share the paths to the f0/0 interfaces. Very simple setup.
So, let’s fire this guy up. First, make sure you’ve started your dynamips server. I run mine in a screen session to get it out of the way, but it’s your choice. Run “dynamips -H 7200″ to get going and listening on port 7200. When that’s up and running, you simply run dynagen against your lab file with a “dynagen bgp.net”.
If everything is right, you’ll be see the “=>” prompt. Remember that we set autostart to false, so we have to start up our routers. You can type “start R1″ and “start R2″ to get them going, but it can be easier to do a “start /all”. You may run into problems with CPU or memory if you do that, though, so be careful.
If you do a “list” at the dynagen prompt, you should see both of the routers in a “running” state. That’s good, but now what? Time to get on the console. If you’re running your lab on your workstation (the box that’s attached to the keyboard you’re typing on), you can do a “console /all” to bring up all the consoles at once. If you’re doing the lab remotely, you’ll have to telnet to the right port to get a console. That info’s in the last column of the “list” command.
Now comes the configuration, so get to it. Configure these guys to share their routes on the f0/0 interface via BGP. Experiment a little. Experiment a lot. You’re not going to break anything, but remember to save the configuration when you’re done. You can reuse the lab later.
—–
If you’re lazy, you can use the configs that I used for this lab. They’re very, very simple, but they work.
Finding Hosts on Layer 2
Most firewalls should block [tag]ICMP[/tag] requests to them, so how do you know that your router or server has layer-2 connectivity to one? It’s pretty elementary, actually, but I’ve found that not a lot of people know this trick. If you ping the firewall, it will receive the ICMP packet and drop it per the rulebase. In this process, though, the firewall has to answer [tag]ARP[/tag] requests, which will be stored in the router or server’s ARP table. If you see it in there, you have connectivity.
On [tag]IOS[/tag]:
show arp
On [tag]Linux[/tag]:
/sbin/arp -an
This won’t help you if you’re not on the same network as the firewall, but it’s very helpful — especially if the firewall group is separate from the group you’re in. These commands have saved me a lot of time by not having to get a bunch of people on the phone to sniff packets as I generate them only to find that the firewall isn’t talking to my router.
Using a Linux Box as a File Server
Ever heard of Samba? You should.
Samba is an open-source project “that provides seamless file and print services to SMB/CIFS clients.” That’s from the project’s website, but what the hell does it mean? In a nutshell, it’s an open-source application that lets non-Windows machines share files and printers with Windows machines. In most cases, people use Samba to share files on a Linux box in a really simple setup. I’ve read about several cases, though, where superhuman admins have used Samba machines to set up a Windows domain. I’m talking full-scale domain login, domain machine registration, and everything. I tried that once and all my Windows machines stopped working. It sucked.
I’m going to be lazy again and not tell you how to configure it. Or am I smart and efficient and saving it for another article? Either way, I wanted to talk about what Samba can get you. Samba lets you provide a way to store files on a network share. If you set up a share for everyone to use, everyone can edit an address spreadsheet or view a home inventory sheet. You can set up Samba to share your home directories to every machine on the network. Everything’s on the same machine. Think about that for a second. If everyone’s files are on the same box, it’s easy as pie to back everything up, and, since everything’s on the network, you can have access to your stuff from everywhere.
I use Samba for file sharing. Home directories for me and the wife are shared out to local drives on our laptops. If I log in to hers and I see my home drive. I also took some time and put in a Highpoint Tech 1740 with a set of 4 300G SATA drives attached to it (hot-swappable and full fault-tolerant, by the way). These guys are put into a RAID5 array to provide about 900G of space to the operating system. I used Logical Volume Manager to split this beast up into a bunch of different volumes — images, music, videos, and a share. Samba shares all these guys out, and our machines have each of these mapped to a drive. When the wife has new images to share, she just drops them on the images drive. When I finish a new video, I drop them in the videos drive.
Samba works well and is easy to set up. Give it a try. It doesn’t really scale very well, though, so using it in an enterprise may cause problems. There’s a whole new article brewing in there about file locking and sharing, but I won’t go there yet.
—-
Remember that I mentioned backing stuff up if everything’s on the same box? It’s not related to Samba technically, but I wrote a quick and dirty bash script that takes a list of directories and tars them all up to a 400G external drive I have attached to the file server. If I didn’t implement Samba, I’d really have no easy way to back it all up in one fell swoop.
Port Knocking
A few months ago, a friend of mine told me about the concept of port knocking, where you send packets to a server on certain ports to authenticate access to the box. A daemon running on your server detects the sequence of packets that you send and runs a script (usually IPtables commands), waits a certain amount of time, then runs another script (usually to take the IPtables commands out). This seems like a good way to get access to your home firewall from anywhere without having to open up access to the whole Internet.
To set it up, you have to install knock, which is the daemon that listens to the port knocking. Just use yum or apt-get to install it and you’ll wind up with the configuration file in /etc/knockd.conf. This is where you set up one or more knock sequences to do what you want. I won’t go into the internals of how it works or how you should set it up but I will go into a few examples.
I use port knocking on my home network to protect administrative access to everything on the network. I wrote a custom IPtables script that, when activated, open access from my IP on the wireless network to SSH (TCP/22) on my firewall, file server, access point, and switch. After 30 seconds, another script runs, and those rules are removed. Here’s an example of a config file that opens up SSH when you hit ports 1234, 5678, 9876, and 5432. After 30 seconds, it kills the rule.
[options]
logfile = /var/log/knockd.log[openssh]
sequence = 1234, 5678, 9876, 5432
seq_timeout = 5
tcpflags = syn
start_command = -A INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT
cmd_timeout = 30
stop_command = -D INPUT -s %IP% -d 192.168.1.1 –dport 22 -j ACCEPT
So, how do you generate these packets? On my CentOS boxes, you get the knock command which is the port knocking client. On Windows, I use KnockKnock. I have no clue about Macs, but there are lots and lots of clients out there, so just look around and I’m sure you’ll find one.