using IPSEC to restrict wired access to our network

[Brazen]

I found this article: http://www.onlamp.com/pub/a/bsd/2004/10/21/wifi_ipsec.html?page=1

I've been looking for a way to restrict access to anyone just plugging some random computer into our network and using our internet, or trying to hack our servers, or whatever.

This details linux use, and I would like to do this with Windows workstations and server, in addition to linux servers and gateway. Has anyone here done this and can help me out, or does anyone know where I can get some good information and starting out with this. (I have googled, but can't find any "good" info except the above article, and I did search the forum )

I'm thinking this would be better for us than using EAP (specifically, I was going to use EAP-TLS).

 

[Brazen]

Well, I found info on using Windows with IPSEC security here from Microsoft itself. Particularly usefull was the "Using IPsec for Network Protection: Part 2 of 2" section that presents a scenario of using Group Policy in Active Directory to authenticate the machine and allow traffice encrypted with IPSEC, but deny all other traffic. I want to use linux machines too, though so I may have to check out the group policy and see if it can be set to use PSK instead of Active Directory authentication. It would be nice though if there is anyone who has done this and can chime in on there experiences, I'm usually not very good at being the one to "pave the way."

 

[spidey07]

Why not 802.1x?

 

[Rilex]

802.1x isn't a substitute for IPSec, both should be used together given your switch supports it. Why do you want to use PSK? PSK is a (relative) security risk to using AD.

 

[spidey07]

Originally posted by: Rilex
802.1x isn't a substitute for IPSec, both should be used together given your switch supports it. Why do you want to use PSK? PSK is a (relative) security risk to using AD.

lol

 

[Rilex]

spidey, are you suggesting that a stolen PSK is more secure than using AD for authorization?

 

[Brazen]

I don't want to use 802.1x because not all our switches support it. And this method using IPSec just seems easier to manage if you ask me.

I want to use PSK because I have linux machines that I also want to secure with IPSec. I'm sure there is a way to attach a linux machine to the domain and use AD authentication, but I would rather just use PSK.

Who knows, maybe I will end up using both 802.1x and IPSec, but 802.1x will have to wait till we get all our switches replaced that don't support it.

 

[spidey07]

Originally posted by: Rilex
spidey, are you suggesting that a stolen PSK is more secure than using AD for authorization?

I'm suggesting keep it simple to meet needs. Lots of times people come up with ungoddly complic@ted solutions to very simple problem.

 

[Madwand1]

The one time I tried software IPSec, the performance hit (on gigabit) was, well, enough to make it the only time I tried IPSec...

 

[Rilex]

spidey, PSK requires extra work over using AD (which is default in Windows' IPSec).

 

[Brazen]

Originally posted by: Madwand1
The one time I tried software IPSec, the performance hit (on gigabit) was, well, enough to make it the only time I tried IPSec...

Hmm, I figured the performance hit would be similar to 802.1x...

 

[spidey07]

802.1x isn't encryption, just authentication

hence no performance hit.

using IPsec on your internal network is just a really, really, really bad idea IMHO.

You're trying to pound a square peg into a round hole. You want to stop unauthrorized users from just "plugging in". This is what 802.1x is used for. The IPsec route is not a network centric approach, more server centric. As such I can still just plug in and do whatever I want.

 

[Brazen]

Originally posted by: spidey07
802.1x isn't encryption, just authentication

hence no performance hit.

using IPsec on your internal network is just a really, really, really bad idea IMHO.

You're trying to pound a square peg into a round hole. You want to stop unauthrorized users from just "plugging in". This is what 802.1x is used for. The IPsec route is not a network centric approach, more server centric. As such I can still just plug in and do whatever I want.

If we use a linux gateway that requires IPSec and all our servers and workstations require IPSec, then they wouldn't be able to plug in and access anything, not even the net. Thanks for the comments, though, I will mull over them.

 

[spidey07]

I'm just tellin ya you're heading down the wrong path is all. You're making it out to be WAY more complicated than it needs to be.

then again I was always one to not reinvent the wheel when there is a perfectly good wheel already. You might be better off highering a security/network professional to do this for you.

 

[Woodie]

i'm w/ spidey. Internal encryption is going to be a PITA, and it will NOT scale well. Unless you use something designed for it, like 802.1x.

I'm in the process of trying to encrypt all our VOIP traffic...and that's going to be a PITA, and for only 3,500 handsets.

 

[spidey07]

Originally posted by: Woodie
i'm w/ spidey. Internal encryption is going to be a PITA, and it will NOT scale well. Unless you use something designed for it, like 802.1x.

I'm in the process of trying to encrypt all our VOIP traffic...and that's going to be a PITA, and for only 3,500 handsets.

ugg. Doesn't sound fun.

Isn't there a standard way of encrypting this traffic? You'd think there would be something built-in to the protocol.

 

[Brazen]

From what I've found lately, IPSec is the standard way of encrypting traffic.

 

[Woodie]

Spidey
So far, I'm only in to the Cisco devices (Avaya next)...because the CIO had is (Cisco) VOIP conversation recorded and played back to him.

It's pretty ugly, uses SCEP protocol (proprietary Cisco certificate proxy thingy) to request certs on behalf of the handsets, and submit those to the MS PKI we already have in place. The doc appears to have been written in a proprietary language as well. We pushed it back, and are waiting for Cisco to provide us someone who's actually installed it to figure out how/where to make it work.

It doesn't help that the Call Manager servers can't belong to the domain. Telecom software engineers, trying to write software to run under a Windows OS. They should just stick to writing IOS-based software instead.

For the actual encryption methodologies, while IPSec is important, SSL is equally important. TLS is starting to make headway with us on several fronts, but again I suspect we're a little further out in front than the mainstream.

 

[spidey07]

woodie,

do post b@ck with your findings.

IPtel is still so new.

I've done plenty of cisco voip @s well @s integr@ting with @v@y@. messy stuff. very messy.