7

Has anybody tried that approach already? I'm really considering it: Instead of relying on network based IDS etc., every packet must use encryption which was initiated by a certificate issued by my own CA.

  • Every client gets a unique client certificate
  • Every server gets a unique server certificate
  • Every service additionally requires to login.

Both SSL and SSH would be ok. Access to the internet would be done via an SSL tunnel to the gateway.

Is it feasible? Does it create practical problems? How could it be done and enforced? What do you think?

More details

My goal is to simplify the LAN's security concept - I'm not yet sure, if that's a crazy idea! But I feel, that securing a HTTPS or SSH server from internet threats (if using mutual authentication) is sometimes easier than monitoring everything that can happen in the wild world of a LAN.

On a non-encrypted LAN, I feel it's really hard to be a good step ahead of a potential attacker, because of threats like:

  • Low level attacks like ARP spoofing, Port stealing, ...
  • WLAN access (e.g. every developer will be allowed to access the SVN server from the (W)LAN - I don't think it will be through a VPN...)

=> For simplicity, isn't it easier to make the assumption, that there is always an attacker in the LAN?

=> Could I end up simplifying a (small company's) LAN security concept by treating it like a WAN? Or would I rather complicate it?

IPSec and alternatives

IPSec sounds very promising, but I'd be interested in alternatives to IPSec, too - Using SSL/SSH individually per service and creating an Stunnel to the Gateway? Using Kerberos maybe? ... What are the advantages of IPSec or the others?

If you can help me with getting a better grasp on IPSec, please see my follow-up question specifically on IPSec.

Community
  • 1
Chris Lercher
  • 3,982
  • 9
  • 34
  • 41
  • 6
    There is a standard scheme for this: IPSEC.. is that what you mean? A lot of VPN's use it over TLS, but LAN's implement it easily.. windows computers can be enabled and enforced to use it with GPO's.. makes troubleshooting a bit harder, but its not that difficult.. – Grizly Apr 07 '10 at 23:14
  • @Grizly: I'm not 100% sure! Maybe it can be done with IPSEC (?) It's important for me to authenticate both client and server via a certificate, and additionally make sure, that the client is logged in to the service (in cases where laptops are stolen etc.) – Chris Lercher Apr 07 '10 at 23:29

6 Answers6

8

IPSec is the standard for this. It comes in different forms and there is a lot of vocabulary to it.

I recommend this guide to IPSec to get you started.

Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • @Kyle: Definitely looks like a good read, and I will read it tomorrow in the morning! Do you use IPSec in your LAN(s)? Why/why not? – Chris Lercher Apr 08 '10 at 00:18
  • I only use it for WAN tunnels over the Internet myself, so you will have to wait for someone who has experience deploying it on entire LAN. It would provide extra security, but would come with a complexity cost for my environment. I generally rely on ssh and ssl to provide the network level security where needed. I would guess you won't find IPSec deployed on LANs in small/medium companies too often unless they deal in a buisness that requires very high security, I could be wrong though. I would guess this because updates, troubleshooting, backup etc probably take up the admin's time. – Kyle Brandt Apr 08 '10 at 00:41
  • 2
    We had this discussion at my work last year. It boiled down to 'physical security trumps all'. If you've got access to the packets (LAN), you've got access to stealing the whole server (in our case); so no point in putting a padlock on a 3' fence. – Chris S Apr 08 '10 at 01:56
  • 4
    IPSec is probably what he wants, but for the sake of accuracy I feel the need to point out that it doesn't encrypt "absolutely everything" in the context of a LAN. It only encrypts IP-based protocols. It's not uncommon to see non-IP protocols on LANs even today. ARP, STP, CDP, 802.1X, PPPoE, AoE, and legacy protocol stacks in some dark corners of the enterprise (Novell IPX, AppleTalk, NetBEUI, DECnet, etc.) – Spiff Apr 08 '10 at 07:43
6

I use IPsec here for everything. The reasoning is that most attacks are made by insiders anyway - the bad side/good side thinking is flawed. (If anyone makes off with the servers they can have fun trying to break the full-disk encryption, so no problem there, either.)

It's also fun to use telnet, NIS, NFS and FTP without any worries - feels like the good old days! :-)

Teddy
  • 5,134
  • 1
  • 22
  • 27
  • 1
    @Teddy: Good to hear, that you're already using it! Do you know, how it's implemented? If yes, I'd like to invite you to my follow-up question: http://serverfault.com/questions/130637/ipsec-for-lan-traffic-basic-considerations :-)) – Chris Lercher Apr 08 '10 at 18:20
  • @chris_l: I have written an answer now: http://serverfault.com/questions/130637/ipsec-for-lan-traffic-basic-considerations/130692#130692 – Teddy Apr 08 '10 at 20:12
  • Your PDF presentation you linked to over there (http://www.fukt.bsnet.se/lectures/2007-02-15_IPsec/) also answered a big part of this question here. Thanks! – Chris Lercher Apr 09 '10 at 17:25
1

Do you have a threat model where unfettered access to your LAN infrastructure is expected? If so, yes, deploying IPSEC to all end-points is probably what you want.

However, in most threat models there's enough perimeter security that you can essentially ignore the LAN infrastructure as a cheap access method.

The picture changes if you have WiFi installed, you'd need something between the WiFi network(s) and the wired network(s) to ensure that you don't have any information leakage via that route.

Vatine
  • 5,390
  • 23
  • 24
  • @Vatine: You guessed correctly: WiFi access :-) – Chris Lercher Apr 08 '10 at 11:18
  • Well, with wifi, there's still things you can do to keep it within a secured perimeter, but I guess covering the building in conductive foil can be more expensive than rolling out IPSEC. – Vatine Apr 09 '10 at 09:25
1

On the windows side what you are looking for is Domain and Server isolation. You can play with it using this labcast

My default windows implementation plan for a new install has this included. In windows it's not hard to set up and offers lots of extra security (and there's really no "extra" administration you might need a few more security groups).

NAP doesn't require IPsec (or even the PKI - that's only if you want to run native mode). SCCM is an additional product- nothing extra is required for domain and server isolation. NAP is primarily designed for send "health" information about a client and if that client doesn't pass your "health" check then it is deferred to only communicate with a remediation server(s). Health is defined as patch requirements AV settings, security settings etc. You certainly can use SCCM to set up IPSEC, but it's not a requirement.

With Domain and server isolation I don't have the ability to check those "health"- nor is it the point. When it's set up I am encrypting the traffic and ensuring that and additionally guaranteeing that the servers and clients are only allowed to communicate with the servers and clients required for that business function (eg HR workstations are the only workstations allowed to communicate with the HR server).

Jim B
  • 23,938
  • 4
  • 35
  • 58
  • Thanks - is this different from SCCM and NAP (from the answer by GAThrawn)? I don't use Windows very much... But it almost seems, as if the thing I want to do is something that's more common in the Windows world? – Chris Lercher Apr 08 '10 at 18:05
  • See my edits above – Jim B Apr 08 '10 at 21:58
0

The security term is "protection of data in transit." Yes, there are groups that do this, and yes, in some ways it does simplify LAN security. IPSEC and IPv6 can be used to support this.

The complementary concept is "protection of data at rest," which means encrypting your disks.

mpez0
  • 1,492
  • 9
  • 9
0

Don't know what systems and infrastructure you're using but Microsoft's System Centre Config Manager (SCCM) has a Network Access Protection (NAP) component that does exactly what you're after.

It PKI encrypts all client-server traffic and puts non-authenticated machines into what is effectively a DMZ where they're unable to to talk to any server/machine/system that hasn't been specifically setup to sit in that DMZ also. It can also allow pre-check machines patch level, anti-virus, security, etc settings before allowing them onto the main LAN (obviously in this case you'd have an updates server or two sitting in the DMZ.

Step by step guides to settings this up for demo/testing are here.

GAThrawn
  • 2,424
  • 3
  • 20
  • 38