Wednesday, June 30, 2010

Do you need to do a bunch of things to network devices? This only works if you have a stable password instead of some kind of two factor authentication like an RSA token, but if that describes your circumstance, then check out expect, available at http://www.nist.gov/mel/msid/expect.cfm. It's a scripting language for automating stuff. So, for instance, you can write a script to log into routers, modify access lists, change passwords, whatever.

I first used it back in the mid 1990's when I worked in a place that had a training room. The access lists on the routers were different depending on whether the training class was external users or internal users, and we didn't want the external users being able to get to the internal network resources. The solution was to have an expect script that fired off at the end of every day and force the router to have the more secure access list. That way, if the acls had been changed during the day to allow for external users, it would be sure to be set back the way we wanted it.

Sunday, June 27, 2010

Wednesday, June 23, 2010

How NAC works. Because I am lazy and it is late, I am cribbing from a paper I wrote earlier this week:

The core functionality of NAC involves three parts: the supplicant, the authenticator, and some kind of authentication server. The supplicant is an edge host device that wants to access network resources over the local LAN. The authenticator is the network device -- usually a network switch -- that can provide that access if and only if the supplicant is correctly authenticated. The authenticator requests some kind of authentication credentials from the supplicant to determine what action to take based on the response from the authentication server. The authentication server is, unsurprisingly, a server that validates the credentials provided and informs the authenticator whether the supplicant is or is not allowed to access the LAN; they authentication server may also provide additional information to the authenticator about the user after a successful authentication. Until the negotiation is complete and a supplicant is correctly authenticated by the authenticator, the supplicant has no access to the the actual data network on the switch. Physical layer connectivity is provided, but an unauthenticated port is not part of any LAN or VLAN.

A switch acting as an authenticator will operate as a normal switch until a live network host is connected to a port configured for 802.1x. The link state change triggers the 802.1x authentication process. In normal non-802.1x operation, the switch would add the newly live switchport to the correct VLAN. For an 802.1x port, the switch is not added to a VLAN but instead placed in an unauthenticated state, which allows only 802.1x protocol traffic. The authenticator switch sends initiator datagrams that serve to request credentials. A correctly configured supplicant machine will have an operating system that is configured to listen for these packets and collect the authentication credentials from the user. They are often some kind of user/password authentication pair linked with the specific user of the supplicant machine, but may include certificates associated with the machine itself rather than the user.

The supplicant host machine and the authenticator network device exchange authentication credential information. This will include the kind of authentication, based around the Extensible Authentication Protocol originally developed for the PPP authentication, as well as the authentication credintials themselves. Communication from the authenticator switch and the authentication server is usually handled via the RADIUS authentication protocol. RADIUS allows for additional information to be exchanged besides a simple yes/no verification, so that configuration data specific to the user or a user group can be communicated back to the authenticator. The authentication server evaluates the credentials and replies to the authenticator switch to affirm or deny the access. If the authentiation server affirms the credentials, the authenticator switch will place the port onto a pre-configured VLAN or network segment. At that point, the supplicant machine can continue normal procedures for connection to the network and issue DHCP or BOOTP packets if needed, or begin normal connectivity if its network interface is already correctly configured.

And this is an interesting quote that caught my attention:You have to bring your expertise to a place where it’s magical, and show them stuff that’s bleeding edge to them, but normal to us. As Arthur C. Clarke said: “Any sufficiently advanced technology is indistinguishable from magic.﻿” What you do isn’t magic in your circle, so you have to go somewhere where it is. (from http://inoveryourhead.net/how-to-get-paid-for-what-you-do-for-free/)

Tuesday, June 15, 2010

I've been poking around to see who is still using FTP on a network. The tcpdump command is

bash-3.00$ sudo tcpdump -i nge1 -nS 'tcp[13] & 2 != 0' and 'port ftp'

FTP can be a bit twitchy to troubleshoot. It's an old protocol -- dating back to 1971 and RFC 114.

Originally, it was pretty straightforward: there are two ports in use, the control port (tcp/21) and the data port (tcp/20). The client connects to the control port and they have a lovely chat until time comes for the actual file to transfer. Then, the server opens a connection *from* its tcp/20 port to a port specified by the remote client. Which is why firewalls freak it out -- it involved an inbound connection.

PASV mode, or 'passive ftp', avoids some of this by letting both sides negotiate a high (above 1023) port, the server opens that port for connection and the client makes the connection to that port.

All of which makes it a fracking pain to troubleshoot from a network point of view.

Wednesday, June 9, 2010

I'm in the midst of writing a paper, so it's an extra-short blog post today, but I did want to keep to my schedule.

Here's a couple of interesting links: A presentation from NANOG 40 about extra-high bandwidth network stuff and the pros and cons of 40G and 100G technology.

and brocade has some crazy cloud network switch fabric going on. I'm curious if (or maybe just when) this kind of tech will trickle down to a more moderately-sized enterprise level rather than very large scale data center type networks.

I'm interested to see what's worked for encouraging more women to get involved in open source development. I think the dreamwidth idea for having a "#dw-kindergarten" IRC channel set up to help newbies without snarking them all to hell and back. I like the idea of bypassing the "you must be this tall to ride this ride" kind of mentality. I know I've certainly been nervous about asking for help from some communities because of the inevitable trolls who snark at folks. So, it's good to see successful alternatives.

Wednesday, June 2, 2010

I read this back shortly after it went up after NANOG 47, and I came across the URL again the other day. It's a fascinating look at the shift in the Internet behavior over the past couple of years. Two of the big shifts are the transition from money coming from connectivity to money coming from content (inc advertising), and the huge spike in cable internet due to things like the comcast "triple play" deal

A few things that stuck with me about it:In 2007, thousands of ASNs contributed 50% of content.In 2009, 150 ASNs contribute 50% of all Internet traffic.