Re: Nahhh, we don't need to secure the *internal* network....
I think that we could probably come up with thousands of different ways to compromise the security of an internal network. What about actually securing it? One of the easiest things that I have seen done was impliment an IPSec-based LAN. The setup was simple. From the outside in: router - firewall - FreeS/WAN gateway - encrypted traffic to LAN. Each machine on the LAN had it's own keypair that was registered with the gateway, so when a desktop was fired up, it would authenticate itself to the gateway, and it was then free to communicate with anyone. Anyone that was able to sniff the traffic just got encrypted streams. If you could get a system onto the network, it would be useless unless the gateway was compromised to accept a bogus key. C-Ya, Kenny On Thu, 2002-08-01 at 22:32, Tom Buskey wrote: I'd think an old 386 would be alot less noticable and more disposable. Heck, how about a floppy based system? Go up to an existing machine already running on a friday afternoon and boot. If it's a floppy, have it erase itself after it boots. It'd probably run undetected until monday morning. Kenneth E. Lussier said: So, basically, be suspicious if anyone brings in a gaming console and sets it up in the breakroom. My favorite quote form this was: Most organizations focus on the perimeter, said Davis. Once you get through the outside, there's a soft chewy center. Not a bad read. A little light on the details, and you can't really dance to it, so I'd give it a 7.3 ;-) C-Ya, Kenny On Thu, 2002-08-01 at 13:20, [EMAIL PROTECTED] wrote: We're behind a firewall. We're safe! http://online.securityfocus.com/news/558 Think again! (not that we haven't said *that* before either ;) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- --- Tom Buskey * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
On 2 Aug 2002, Kenneth E. Lussier wrote: From the outside in: router - firewall - FreeS/WAN gateway - encrypted traffic to LAN. Each machine on the LAN had it's own keypair that was registered with the gateway, so when a desktop was fired up, it would authenticate itself to the gateway, and it was then free to communicate with anyone. Anyone that was able to sniff the traffic just got encrypted streams. If you could get a system onto the network, it would be useless unless the gateway was compromised to accept a bogus key. Very cool idea... I like it alot. Did you actually implement it? Any idea what the overhead was like? I imagine that your FreeS/WAN gateway would need some decent horsepower - otherwise you'd have scaling issues as your user base grows, right? For smaller networks, or maybe large networks segmented into smaller ones, this could be a nice setup. I guess one question is - the FreeS/WAN gateway solution still gives someone a connection in, correct? They can get on the network the same way (put a box in physically, have it phone home, connect) they just can't talk to anyone else. This solves the one problem, however, it doesn't solve the problem where you have a client that can't run something that talks to your FreeS/WAN gateway. Printservers, specialized boxes, etc.. Or do I misunderstand how you'd use it? -- If you must play, decide on three things at the start: the rules of the game, the stakes, and the quitting time. * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
Ben Boulanger said: On 2 Aug 2002, Kenneth E. Lussier wrote: From the outside in: router - firewall - FreeS/WAN gateway - encrypted traffic to LAN. Each machine on the LAN had it's own keypair that was registered with the gateway, so when a desktop was fired up, it would authenticate itself to the gateway, and it was then free to communicate with anyone. Anyone that was able to sniff the traffic just got encrypted streams. If you could get a system onto the network, it would be useless unless the gateway was compromised to accept a bogus key. This is a good way to secure an 802.11b network too. Very cool idea... I like it alot. Did you actually implement it? Any idea what the overhead was like? I imagine that your FreeS/WAN gateway would need some decent horsepower - otherwise you'd have scaling issues as your user base grows, right? For smaller networks, or maybe large networks segmented into smaller ones, this could be a nice setup. I guess one question is - the FreeS/WAN gateway solution still gives someone a connection in, correct? They can get on the network the same way (put a box in physically, have it phone home, connect) they just can't talk to anyone else. This solves the one problem, however, it doesn't solve the problem where you have a client that can't run something that talks to your FreeS/WAN gateway. Printservers, specialized boxes, etc.. You could put them on an unsecured private network. Throw a firewall in front of the the unsecured network with key pairs too. Well, I guess someone could hack that network, but you could probably do something allowing only certain MAC addresses. The author of LPRng described how to do this with printers. He had to print stock certificates or something like that. Postscript is a programming language. You can hid a key at random on the printer in RAM or on an attached hard drive. So he implemented RSA in postscript. Some of these specialized boxes have Java. There's an SSH in Java. I've looked at implementing private firewalls on servers. eg; a backup server running on an insecure net. With ipfilter, iptables, and windows 2k or XP it's not hard. There's always the DOD approach: put the network cables in conduit that has a vibration alarm on it. Use 10base2, token ring, or FDDI; something that detects a break and stops passing traffic if a splice is made. -- --- Tom Buskey * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
On Fri, 2 Aug 2002, Tom Buskey wrote: There's always the DOD approach: put the network cables in conduit that has a vibration alarm on it. Use 10base2, token ring, or FDDI; something that detects a break and stops passing traffic if a splice is made. 1) Unless I'm mistaken (something I'll readily concede if it's the case -- my time with Token Ring Hell^H^H^H^H^H^H^H^H^H United Parcel Service was many moons ago), you could just splice the TR cable, plug it into a MAU, and go from there. You wouldn't even drop packets if your ring was an actual ring, though you might notice a couple beacons. 2) All of this is well and good, but IMHO, encrypting the workplace would -not- solve even a portion of the big problem. People who have access would still have access, and could just as easily e-mail files to the outside. Combine that with social engineering, and the damn keyboard capture devices I've seen that plug right into the PS/2 port (Hell: PC Magazine even wrote two up last issue), and it's *DAMN* hard to prevent someone who's determined from getting to stuff, and a whole lot easier than it would be to sniff an unencrypted packet-switched network. Don't mis-understand my point: encryption -is- good. But hiring trustworthy employees, expiring passwords, and enforcing good file-permission security (so people don't have access to things they don't need access to) are probably more relevant. That, and throwing away Outlook. ;-) $.02, -Ken * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
In a message dated: 02 Aug 2002 08:38:52 EDT Kenneth E. Lussier said: I think that we could probably come up with thousands of different ways to compromise the security of an internal network. What about actually securing it? One of the easiest things that I have seen done was impliment an IPSec-based LAN. The setup was simple. From the outside in: router - firewall - FreeS/WAN gateway - encrypted traffic to LAN. Each machine on the LAN had it's own keypair that was registered with the gateway, so when a desktop was fired up, it would authenticate itself to the gateway, and it was then free to communicate with anyone. Anyone that was able to sniff the traffic just got encrypted streams. If you could get a system onto the network, it would be useless unless the gateway was compromised to accept a bogus key. In theory, this is a great idea. However, keep in mind that: Security = 1/productivity In many corporate situations, especially engineering environments, the implementation of a VPN would get in the way of development. For instance, my current environment is co-located between the US and Belgium. The folks in Belgium require direct access to our lab here, and vice-versa. Additionally, both groups require direct access to central corporate servers. A lot of what's going on requires high performance connectivity with as little latency introduced as possible. Placing a VPN client on some of these systems would automatically get in the way of a lot of the testing that is done. As a result, there aren't even virus scanners on a lot of the systems in the labs. And, since the labs need direct access to corporate servers, the labs often become breeding grounds for virii. A proposal was made to VPN off all the labs, which would prevent a virus from escaping since the virus couldn't authenticate with the VPN, however, it was determined that there are no VPN servers at this time which will not slow down a GigE connection, which is required for a lot of the stuff going on here. (of course, since we only have a 2MB connection to Belgium, I don't see why the GigE thingy is a requirement for *our* situation :) Also, as Ben pointed out, just because all the traffic between hosts is now encrypted, that doesn't prevent someone from using a box to internally probe your network looking for ways out. Once you're in, you're in, and if you can use that internal system to create a conduit you can get into from the outside, all bets are off! -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
On Fri, 2002-08-02 at 12:11, Ken Ambrose wrote: 1) Unless I'm mistaken (something I'll readily concede if it's the case -- my time with Token Ring Hell^H^H^H^H^H^H^H^H^H United Parcel Service was many moons ago), you could just splice the TR cable, plug it into a MAU, and go from there. You wouldn't even drop packets if your ring was an actual ring, though you might notice a couple beacons. Having also served my time in UPS hell, and having delt with their warped view of how to run a network, I can honestly say that they are an exception. They purposely did away with some of the security features built into TR for various reasons. 2) All of this is well and good, but IMHO, encrypting the workplace would -not- solve even a portion of the big problem. People who have access would still have access, and could just as easily e-mail files to the outside. Combine that with social engineering, and the damn keyboard capture devices I've seen that plug right into the PS/2 port (Hell: PC Magazine even wrote two up last issue), and it's *DAMN* hard to prevent someone who's determined from getting to stuff, and a whole lot easier than it would be to sniff an unencrypted packet-switched network. Don't mis-understand my point: encryption -is- good. But hiring trustworthy employees, expiring passwords, and enforcing good file-permission security (so people don't have access to things they don't need access to) are probably more relevant. I never meant to imply that this would solve all security problems. It's not even close. My point was that there are ways of securing a network against the type of attack that was described in the article where someone plants a box on your network. If someone has access to a system that is *SUPPOSED* to be on the network, then your network is theirs. I whole-heartedly agree that password aging, file-permissions, etc. are extremely important. As I, and many others, have said many times before, security comes in layers upon layers. There is no silver bullet that will solve all security problems. As I have said many times, also, there is no such thing as secure, only varying degrees of risk. It is all about what you are willing to do to protect data, what the data you are protecting is worth, and to what lengths someone will go to to get that data. My example was only one small part of an over all plan, not by any means, a solution for all security problems. That, and throwing away Outlook. ;-) Well, that goes without saying, now doesn't it ;-) C-Ya, Kenny -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
On Fri, 2002-08-02 at 12:13, [EMAIL PROTECTED] wrote: In theory, this is a great idea. However, keep in mind that: Security = 1/productivity In many corporate situations, especially engineering environments, the implementation of a VPN would get in the way of development. There are some good performance studies for FreeS/WAN and other implimentations at http://www.freeswan.org/freeswan_trees/freeswan-1.95/doc/performance.html I'm not saying that there is *no* overhead, just that in a LAN environment it is not a major factor. But again, it all comes down to: What is the company willing to do to protect their data. For instance, my current environment is co-located between the US and Belgium. The folks in Belgium require direct access to our lab here, and vice-versa. Additionally, both groups require direct access to central corporate servers. A lot of what's going on requires high performance connectivity with as little latency introduced as possible. Placing a VPN client on some of these systems would automatically get in the way of a lot of the testing that is done. You don't need to put a VPN client on the systems in a case like this. You put a gateway at each end, and authenticate/encrypt/route on the gateway. The users at either end most likely wouldn't even notice. As a result, there aren't even virus scanners on a lot of the systems in the labs. And, since the labs need direct access to corporate servers, the labs often become breeding grounds for virii. You can get network virus scanners for routers now I don't pretend to know anything about their usefulness, though. A proposal was made to VPN off all the labs, which would prevent a virus from escaping since the virus couldn't authenticate with the VPN, however, it was determined that there are no VPN servers at this time which will not slow down a GigE connection, which is required for a lot of the stuff going on here. (of course, since we only have a 2MB connection to Belgium, I don't see why the GigE thingy is a requirement for *our* situation :) If you require GigE, but only have a 2MB connection, then security isn't the problem... *MATH* is!! ;-) Also, as Ben pointed out, just because all the traffic between hosts is now encrypted, that doesn't prevent someone from using a box to internally probe your network looking for ways out. Once you're in, you're in, and if you can use that internal system to create a conduit you can get into from the outside, all bets are off! In the scenario that I proposed, the traffic between hosts isn't just encrypted, it is also authenticated through a central gateway. If you put a box on the network, it will hit that gateway and stop, since there is no way out without authenticating. C-Ya, Kenny -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
In a message dated: 02 Aug 2002 12:39:34 EDT Kenneth E. Lussier said: I'm not saying that there is *no* overhead, just that in a LAN environment it is not a major factor. Whether or not it's a factor depends upon what type of delay is introduced vs. what is acceptable, and the definitions of 'factor', 'major', and 'acceptable'. Oh, and we probably need to agree upon what the definition of 'is' is just to be clear ;) But again, it all comes down to: What is the company willing to do to protect their data. True. And in this particular instance, we can derive that from the required use of: Win2K, Outlook, and Exchange :) For instance, my current environment is co-located between the US and Belgium. The folks in Belgium require direct access to our lab here, and vice-versa. Additionally, both groups require direct access to central corporate servers. A lot of what's going on requires high performance connectivity with as little latency introduced as possible. Placing a VPN client on some of these systems would automatically get in the way of a lot of the testing that is done. You don't need to put a VPN client on the systems in a case like this. You put a gateway at each end, and authenticate/encrypt/route on the gateway. The users at either end most likely wouldn't even notice. What would prevent a virus from spreading between the 2 locations then? Since the tunnel is authenticated at the gateway level, it's nothing more than a router for all intents and purposes, right? What was proposed was not setting things up as you suggest, but essentially setting up a firewall that each client/person would need to authenticate against in order to access the non-lab corporate WAN. So, not only would the users know, but performance *would* be impacted at the client level, since they would require VPN client sw installed on them. You can get network virus scanners for routers now I don't pretend to know anything about their usefulness, though. Yeah, I heard they stop all incoming SPAM as well. Hey, do know anyone that needs a bridge? I have a nice one right between Queens and Brooklyn I'm looking to sell ;) Or, if you prefer, I another on in the San Fran/Bay area! (of course, since we only have a 2MB connection to Belgium, I don't see why the GigE thingy is a requirement for *our* situation :) If you require GigE, but only have a 2MB connection, then security isn't the problem... *MATH* is!! ;-) Well, keep in mind, we're not the only one's this proposal would affect. Though the limiting connection between here and Belgium is only 2MB, the Massachusetts buildings are all connected by OC48 trunks divided into multiple OC3 connections. So there well may be some other group which has a GigE connection requirement between multiple buildings on this side of the puddle :) In the scenario that I proposed, the traffic between hosts isn't just encrypted, it is also authenticated through a central gateway. If you put a box on the network, it will hit that gateway and stop, since there is no way out without authenticating. Oh, okay. Either I missed that part of the explanation, or just didn't understand correctly what you were proposing. That does make a lot of sense, and would be a nice configuration. Hmmm, maybe I'll play with that one of these days when I finish playing with FAI :) -- Seeya, Paul -- It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right! * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
So, basically, be suspicious if anyone brings in a gaming console and sets it up in the breakroom. My favorite quote form this was: Most organizations focus on the perimeter, said Davis. Once you get through the outside, there's a soft chewy center. Not a bad read. A little light on the details, and you can't really dance to it, so I'd give it a 7.3 ;-) C-Ya, Kenny On Thu, 2002-08-01 at 13:20, [EMAIL PROTECTED] wrote: We're behind a firewall. We're safe! http://online.securityfocus.com/news/558 Think again! (not that we haven't said *that* before either ;) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
Re: Nahhh, we don't need to secure the *internal* network....
I'd think an old 386 would be alot less noticable and more disposable. Heck, how about a floppy based system? Go up to an existing machine already running on a friday afternoon and boot. If it's a floppy, have it erase itself after it boots. It'd probably run undetected until monday morning. Kenneth E. Lussier said: So, basically, be suspicious if anyone brings in a gaming console and sets it up in the breakroom. My favorite quote form this was: Most organizations focus on the perimeter, said Davis. Once you get through the outside, there's a soft chewy center. Not a bad read. A little light on the details, and you can't really dance to it, so I'd give it a 7.3 ;-) C-Ya, Kenny On Thu, 2002-08-01 at 13:20, [EMAIL PROTECTED] wrote: We're behind a firewall. We're safe! http://online.securityfocus.com/news/558 Think again! (not that we haven't said *that* before either ;) -- Seeya, Paul * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- Tact is just *not* saying true stuff -- Cordelia Chase Kenneth E. Lussier Sr. Systems Administrator Zuken, USA PGP KeyID CB254DD0 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xCB254DD0 * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. * -- --- Tom Buskey * To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *
