Ah PEAP season!  Sorry, this post isn’t about the marshmallow Easter goodies, though.  It’s about Protected Extensible Authentication Protocol (PEAP).

PEAP is an EAP method commonly used to secure wireless networks.  In a nutshell PEAP authenticates users in two phases.  In the first phase, a TLS tunnel is built between client and server and in the second phase authentication takes place in the tunnel.

One main thing that sets PEAP apart from other common EAP methods is that it only requires a server certificate to create the TLS tunnel, whereas other methods require client and server certs (EAP-TLS), or no certs (EAP-FAST).

Recently I was pondering what good it does for PEAP to only require a server certificate and not a client certificate.  It seemed to me that the problem with wireless security isn’t, “I’m the client, do I know the server?” but rather, “I’m the server, do I know the client?” in which case a client cert would be more useful.  Isn’t just using a server certificate a waste of time?

I posed this question to our resident wireless expert and Friend of the Blog, Ben.  As always, he had a good answer.  Ben acknowledged that requiring just a server certificate doesn’t solve the client problem I posed, but it does still allow a tunnel to be built.  This tunnel protects against specific attacks like Man-In-The-Middle and Replay attacks by protecting the authentication exchange.  Thus, even though using only a server certificate doesn’t help to know if the client is who he says he is, it still provides some useful protections.  Thanks Ben!

Yes!  PEAP could be on the test!  See Wireless Security in VII. Cisco Security General in the Written blueprint.

(photo: psilver)

I recently needed to search through some ACS logs and the really unusable windows explorer search function just wasn’t doing the job. This left me wishing that my windows server would magically change into a unix box so I could use grep or xargs. I tried a few different DOS commands and with a little help from google I was able to do the following:
c:\> type * | find "My Search Test"
This worked great. I was able to search through all the files and find exactly what I was searching for. I think type only works on text friendly docs but it worked great for my purposes. The asterisk was used because I had about 200 files I wanted to look through. When a match was found, the filename and entry was printed to the screen.

One of the great things about the ASAs Modular Policy Framework is that you can categorize different traffic flows and decide what actions you want to take on those flows such as applying a inspect, policing or applying an action to a pattern match in a packet using regex.

In this case the goal is to apply a particular inspect to some flows but deny the inspect for others. Lets say I have 3 servers, 2 of the servers send and receive email traffic on tcp port 25, the third server sends and receives email traffic on tcp port 43. If the ESMTP inspect is applied, one of the servers cannot effectively send/receive email to another site because the vendor is using unsupported methods that do not comply with the ESMTP RFC. The ASA sees this flow and drops the traffic. Since we know this flow can be trusted and we don’t want to just remove the ESMTP inspect for the server that needs it, we will need a way to bypass inspection for this particular server. We also need to setup the inspect to not only look at traffic on tcp 25 but also inspect traffic on tcp 43 for the second mail server. We don’t want to apply the inspect to all flows because that may disrupt other traffic. So here is what we do.

1. Define access-lists for the flows we want and do not want inspected

Server 1: 192.168.20.3
Server 2: 192.168.20.4
Server 3: 192.168.20.5

ciscoasa(config)# access-list inspect_smtp deny tcp any host 192.168.20.4 eq 25
ciscoasa(config)# access-list inspect_smtp deny tcp host 192.168.20.4 any eq 25
ciscoasa(config)# access-list inspect_smtp permit tcp any any eq 25
ciscoasa(config)# access-list inspect_smtp permit tcp any host 192.168.20.5 eq 43
ciscoasa(config)# access-list inspect_smtp permit tcp host 192.168.20.5 any eq 43

As you can see we have an access-list that has 2 deny statements for server 2. This traffic will not be inspected for both sending and receiving on tcp port 25. We then define that we want port 25 inspected for SMTP for all other flows and we also define that we want to inspect traffic to and from server 3 on tcp port 43.
…click here to read more