Re: Transport Mode IPSEC
On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? You might read up on ethernet switching technology a bit before answering that. I'm sorry to be the one to make this remark but it's you who needs to read a bit to learn (a) how to sniff traffic off most Ethernet switches from D-Link to Cisco; (b) what other security risks unprotected NFSv3 shares pose. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
On Wed, 17 Jan 2007, Ted Mittelstaedt wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? That implies trust of the switch, trust against arp-cache poisoning, and the like. The idea of ipsec is not trusting the wire. With NIS/NFS known for being this inherently secure, would it get me a better answer if I said with only a single router between them? -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
Quoting Ted Mittelstaedt [EMAIL PROTECTED]: Most people don't wear 2 condoms, you know. Then you're not having wild enough sex -grin- :) -- C ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
On 1/18/07, Dan Mahoney, System Admin [EMAIL PROTECTED] wrote: Hey all, I see the handbook has a nice howto on tunnel mode ipsec. I just want to protect my NFS/NIS traffic between two hosts on a switch (neither NAT'd) -- is there a reference as to transport-mode ipsec anywhere, or has anyone done it that can outline it? I would imagine it would be drastically simpler than tunnel mode, but I'm not sure where it would break off. It's not that simple. The difficulty is in key exchange, and it stays. I can show you how to implement it with static keys: = 192.168.17.1:/etc/ipsec.conf flush ; spdflush ; add 192.168.17.69 192.168.17.1 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; add 192.168.17.1 192.168.17.69 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; spdadd 192.168.17.69 192.168.17.1 any -P in ipsec ah/transport//require ; spdadd 192.168.17.1 192.168.17.69 any -P out ipsec ah/transport//require ; = 192.168.17.69:/etc/ipsec.conf flush ; spdflush ; add 192.168.17.69 192.168.17.1 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; add 192.168.17.1 192.168.17.69 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; spdadd 192.168.17.69 192.168.17.1 any -P out ipsec ah/transport//require ; spdadd 192.168.17.1 192.168.17.69 any -P in ipsec ah/transport//require ; Then add ipsec_enable=YES to rc.conf(5) on both hosts and run /etc/rc.d/ipsec start. That should set up authenticated relationship between the two hosts. See setkey(8) for encryption and other options. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
On Thu, 18 Jan 2007, Andrew Pantyukhin wrote: On 1/18/07, Dan Mahoney, System Admin [EMAIL PROTECTED] wrote: It's not that simple. The difficulty is in key exchange, and it stays. I can show you how to implement it with static keys: As I read through the article (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html)...I get the distinct impression the howto actually is somewhat adaptable -- one just needs to ignore everything it says about tunnels, and the GIF device. I'd still install raccoon, still do everything like that -- the change comes in the lines in /etc/ipsec.conf spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; which would be I think modified to your lines below. I'm not sure if you still need the additional policy definition (between the slashes). Perhaps you can clarify for me? I'm liking doing things with raccoon only because it allows you to use those nice non-static keys. -Dan = 192.168.17.1:/etc/ipsec.conf flush ; spdflush ; add 192.168.17.69 192.168.17.1 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; add 192.168.17.1 192.168.17.69 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; spdadd 192.168.17.69 192.168.17.1 any -P in ipsec ah/transport//require ; spdadd 192.168.17.1 192.168.17.69 any -P out ipsec ah/transport//require ; = 192.168.17.69:/etc/ipsec.conf flush ; spdflush ; add 192.168.17.69 192.168.17.1 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; add 192.168.17.1 192.168.17.69 ah 4567 -A hmac-sha2-512 Y38mKV6jWhmouiumhyiPXIbG6p8aSTBQ2peMedMwmh1tasd5yM9mjH8aVSsnWrLy ; spdadd 192.168.17.69 192.168.17.1 any -P out ipsec ah/transport//require ; spdadd 192.168.17.1 192.168.17.69 any -P in ipsec ah/transport//require ; Then add ipsec_enable=YES to rc.conf(5) on both hosts and run /etc/rc.d/ipsec start. That should set up authenticated relationship between the two hosts. See setkey(8) for encryption and other options. -- Don't try to out-wierd me. I get stranger things than you free with my breakfast cereal. -Button seen at I-CON XVII (and subsequently purchased) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
You don't trust your own switch? Your making a common mistake here. Your confusing application security with environment security. If an environment is insecure you cannot make it secure by mucking with the application. (ie: hiding it in a tunnel) for example you cited arp cache poisoning on an ethernet network. running ipsec will not protect against this. If your ethernet environment is insecure (ie: your using unmanaged switches) and it's got hostiles on it, you can run all the ipsec you want, an attacker can DoS your NFS server with an arp cache poison, no problem. Or, assume the MAC of your default gateway and knock all users offline. If you correct the environment security, then the application is protected. For example, you put in a decent managed switch, you setup rate-limiting on it, you setup MAC/IP address filters, and your now secure on your local LAN. Basically, what your trying to do - use ipsec to encrypt nfs on a local lan - is unnecessary, adds overhead, and what you want to have happen is better done by other mechanisms. If your running NFS over a WAN connection where ipsec encryption would have some validity, well, NFS isn't a good protocol for such a connection. Copying a file is going to be slow. WANs are unreliable and you don't want your NFS mounts vanishing without being umounted. sftp would be a much better choice I think. NFS isn't inherently insecure unless it's improperly deployed. I would consider deploying NFS on a hostile ethernet network that is not secured, to be an improper deployment and I think any security professional would agree. This discussion is like when Microsoft made packet signing mandatory in SMB in Windows XP. They said this will enhance the security of SMB No it didn't. SMB packets in Real Life are almost always on a local LAN, and most of those are switched. All that did is break connecitons to UNIX Samba servers (which was probably the real reason they did it) Ted - Original Message - From: Dan Mahoney, System Admin [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 18, 2007 12:06 AM Subject: Re: Transport Mode IPSEC On Wed, 17 Jan 2007, Ted Mittelstaedt wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? That implies trust of the switch, trust against arp-cache poisoning, and the like. The idea of ipsec is not trusting the wire. With NIS/NFS known for being this inherently secure, would it get me a better answer if I said with only a single router between them? -Dan -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
- Original Message - From: Andrew Pantyukhin [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: Dan Mahoney, System Admin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 18, 2007 12:25 AM Subject: Re: Transport Mode IPSEC On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? You might read up on ethernet switching technology a bit before answering that. I'm sorry to be the one to make this remark but it's you who needs to read a bit to learn (a) how to sniff traffic off most Ethernet switches from D-Link to Cisco; (b) what other security risks unprotected NFSv3 shares pose. Yeah, sure I've heard that one before. Why don't you go ahead and elaborate one of your favorite theoretical attacks out of one of those books that proves that an attacker can sniff most switches so I can have the fun of knocking it down by real-world hardware implementations that you can actually buy and use right now. Don't be a fool. Ethernet switch manufacturers aren't stupid and have read the same stuff your citing. They combat them 2 ways. The first is used on the expensive switches and it's called filtering and allows switch manufacturer salespeople to have something to dog and pony. The second is used on the cheapo switches and it's called using a wussy CPU on the switch so that the second you try attacking the switch with one of your fancy attacks to sniff it, the switch just rolls over and dies, passing so few packets that every connection through it looses tremendous numbers of packets, and hell breaks loose as all users start screaming. been there, done that. Those work just dandy in the lab and in your CCIE class with 3 hosts setup for the purpose of demonstrating the attacks. But try it on a production network some day and the side-effects will kill you. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
On 1/18/07, Dan Mahoney, System Admin [EMAIL PROTECTED] wrote: On Thu, 18 Jan 2007, Andrew Pantyukhin wrote: On 1/18/07, Dan Mahoney, System Admin [EMAIL PROTECTED] wrote: It's not that simple. The difficulty is in key exchange, and it stays. I can show you how to implement it with static keys: As I read through the article (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html)...I get the distinct impression the howto actually is somewhat adaptable -- one just needs to ignore everything it says about tunnels, and the GIF device. I'd still install raccoon, still do everything like that -- the change comes in the lines in /etc/ipsec.conf spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require; spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require; which would be I think modified to your lines below. I'm not sure if you still need the additional policy definition (between the slashes). Perhaps you can clarify for me? Just esp/transport//require; should do I'm liking doing things with raccoon only because it allows you to use those nice non-static keys. So do I. The problem is there's no perfect way to block non-ipsec traffic right now and there's no way to make sure raccoon won't ever croak and leave you insecure/disconnected. YMMV. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: - Original Message - From: Andrew Pantyukhin [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: Dan Mahoney, System Admin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 18, 2007 12:25 AM Subject: Re: Transport Mode IPSEC On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? You might read up on ethernet switching technology a bit before answering that. I'm sorry to be the one to make this remark but it's you who needs to read a bit to learn (a) how to sniff traffic off most Ethernet switches from D-Link to Cisco; (b) what other security risks unprotected NFSv3 shares pose. Yeah, sure I've heard that one before. Why don't you go ahead and elaborate one of your favorite theoretical attacks out of one of those books that proves that an attacker can sniff most switches so I can have the fun of knocking it down by real-world hardware implementations that you can actually buy and use right now. Don't be a fool. Ethernet switch manufacturers aren't stupid and have read the same stuff your citing. They combat them 2 ways. The first is used on the expensive switches and it's called filtering and allows switch manufacturer salespeople to have something to dog and pony. The second is used on the cheapo switches and it's called using a wussy CPU on the switch so that the second you try attacking the switch with one of your fancy attacks to sniff it, the switch just rolls over and dies, passing so few packets that every connection through it looses tremendous numbers of packets, and hell breaks loose as all users start screaming. been there, done that. Those work just dandy in the lab and in your CCIE class with 3 hosts setup for the purpose of demonstrating the attacks. But try it on a production network some day and the side-effects will kill you. Okay, I'm sorry to have sounded a bit rough before I even parsed your name :-) You don't need to throw bits of your knowledge at unsuspecting bystanders, too. ;) Most attacks I can imagine, I read/heard about or seen in the worst of my nightmares - I wouldn't be able to reproduce or describe in detail. My friend has a motto, which I happen to agree with: there's a good enough attacker for any kind of security measures, our job is to make his job as tough as possible. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Transport Mode IPSEC
- Original Message - From: Andrew Pantyukhin [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: Dan Mahoney, System Admin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 18, 2007 2:07 AM Subject: Re: Transport Mode IPSEC On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: - Original Message - From: Andrew Pantyukhin [EMAIL PROTECTED] To: Ted Mittelstaedt [EMAIL PROTECTED] Cc: Dan Mahoney, System Admin [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 18, 2007 12:25 AM Subject: Re: Transport Mode IPSEC On 1/18/07, Ted Mittelstaedt [EMAIL PROTECTED] wrote: Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? You might read up on ethernet switching technology a bit before answering that. I'm sorry to be the one to make this remark but it's you who needs to read a bit to learn (a) how to sniff traffic off most Ethernet switches from D-Link to Cisco; (b) what other security risks unprotected NFSv3 shares pose. Yeah, sure I've heard that one before. Why don't you go ahead and elaborate one of your favorite theoretical attacks out of one of those books that proves that an attacker can sniff most switches so I can have the fun of knocking it down by real-world hardware implementations that you can actually buy and use right now. Don't be a fool. Ethernet switch manufacturers aren't stupid and have read the same stuff your citing. They combat them 2 ways. The first is used on the expensive switches and it's called filtering and allows switch manufacturer salespeople to have something to dog and pony. The second is used on the cheapo switches and it's called using a wussy CPU on the switch so that the second you try attacking the switch with one of your fancy attacks to sniff it, the switch just rolls over and dies, passing so few packets that every connection through it looses tremendous numbers of packets, and hell breaks loose as all users start screaming. been there, done that. Those work just dandy in the lab and in your CCIE class with 3 hosts setup for the purpose of demonstrating the attacks. But try it on a production network some day and the side-effects will kill you. Okay, I'm sorry to have sounded a bit rough before I even parsed your name :-) You don't need to throw bits of your knowledge at unsuspecting bystanders, too. ;) OK, truce then. :-) Most attacks I can imagine, I read/heard about or seen in the worst of my nightmares - I wouldn't be able to reproduce or describe in detail. Actually they sound a lot more interesting than they are in practice. There are two general ethernet attacks out there. The first is a MAC-based, you impersonate someone's MAC and IP address (preferably a machine that happens to be switched off at the moment) to get some sort of elevated privilege on a server somewhere, or you do it while the other machine is online, in order to take it offline, or do it to the gateway in order to disrupt internet access, (usually) Quite a lot of fun things can be done with MAC and IP spoofing, and there was a lot of this in early university campus dorm networks when they were first setup. Schools screamed about it and switch vendors responded with intelligent switches that blurred the distinction between layer 1, 2 and 3 and the rule of thumb nowadays is to deploy those in networks where you have potential attackers. The best switches can notify the admin when someone is pulling one of these stunts and the admin can program in advance port lockdowns and such, so that the wanna-be college freshman that thinks he's smart gets a visit from campus security when he pulls this kind of thing. The second are in the high-speed rate family. You send out a lot of itty-bitty packets at a high rate of speed. One trick is to vary the MAC address on each packet so you overflow the switch internal mac tables and cause the switch to basically become a big hub - when that happens you run your sniffer and try to steal passwords, etc. Once more, the aforementiond intelligent switches are the way to deal with this. Both of these attacks depend on the attacker being on the local LAN, or a machine he has compromised being on the local LAN. It is, of course, true that there's a lot of cheap switches on the market and there are corporations that deploy them. However your dealing with an environment here where if an attacker gains control of a machine on the inside, he can get far more useful data from inserting a keystroke logger into the compromised operating system than bothering with running LAN attacks. Or, the attacker can try a high speed password cracker. You would not believe how insecure most corporate networks are. As an example a few months ago a customer of ours
Re: Transport Mode IPSEC
Dan, You do realize, don't you, that since both of these hosts are on a switch, and are using unicast traffic to communicate with each other, that they cannot be sniffed, don't you? You might read up on ethernet switching technology a bit before answering that. Most people don't wear 2 condoms, you know. Ted - Original Message - From: Dan Mahoney, System Admin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 17, 2007 11:28 PM Subject: Transport Mode IPSEC Hey all, I see the handbook has a nice howto on tunnel mode ipsec. I just want to protect my NFS/NIS traffic between two hosts on a switch (neither NAT'd) -- is there a reference as to transport-mode ipsec anywhere, or has anyone done it that can outline it? I would imagine it would be drastically simpler than tunnel mode, but I'm not sure where it would break off. -Dan -- A mother can be an inspiration to her little son, change his thoughts, his mind, his life, just with her gentle hum. -No Doubt, Different People, from Tragic Kingdom Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
