Re: Access to the Internic Blocked
Curtis wrote:
I've said many times that if security in your network is weak enough that you need to worry about LSRR packets you need to worry about security in your network.
Not at all. LSRR is a nice tool to mount practically untraceable flooding attack (hint -- just forge source address and spread intermediate points evenly across the network). Shutting you down may be exactly what the attacker wants. (LSRR attacks against service providers are particlularly bad -- just imagine somebody flooding you at T-1 speed and bouncing packets back and forth two dozen times. Poof -- here goes the T-3 :) There are particularly nasty man-in-the-middle attacks (which defeat one-time-password login authentication, like that) if you can combine LSRR with bogus routing.
The minute someone unpacks a Sun workstation, configures an IP address and sticks it on the ethernet without installing the security patches and doing the administrative work needed to secure the machine, if you had a small hole in your security with LSRR, you now have a gaping hole in your security. If you are relying on blocking LSRR, your security is a weak as the most peerly administered machine on your network. A real bad thing if you are constantly hiring.
I never argued that blocking LSRR plugs all security holes. However it is one thing _not_ used in normal operations; and everything not used _must_ be shut down by a prudent security. And, again, there are several LSRR-based attacks.
Even so, if anywhere, where you want LSRR turned off is the border router(s) in front of the machines used for operations, network management, etc.
Obviously you want your network to be secure even if LSRR was enabled for the reason I cited above.
Security Rule #1: You're never secure. Turning LSRR off doesn't particularly hurt connectivity, and is cheap. It's a way to _improve_ security. --vadim
In message <199608230202.TAA00281@quest.quake.net>, Vadim Antonov writes:
Curtis wrote:
I've said many times that if security in your network is weak enough that you need to worry about LSRR packets you need to worry about security in your network.
Not at all. LSRR is a nice tool to mount practically untraceable flooding attack (hint -- just forge source address and spread intermediate points evenly across the network). Shutting you down may be exactly what the attacker wants.
Oh come on. Like they're not going to get caught stuffing an entire T1 with LSRR packets. Face it. You're grabbing at straws. Besides the fact that with your suggestion of traceroute using ICMP echo requests they'd just send a T1s worth of ICMP echo requests with LSRR and accomplish the same thing.
There are particularly nasty man-in-the-middle attacks (which defeat one-time-password login authentication, like that) if you can combine LSRR with bogus routing.
Who said one time passwords were secure. Kerberos mutual authentication with encrypted payload is my choice. Some people prefer SSL. AFS is nice if you can afford it. Skey just doesn't cut it. Skey is only slightly better than passwords in the clear. Besides, man in the middle is really easy if you're already on the LAN due to the guy that just unpacked his first Sun workstation. Much easier to do than LSRR with bogus routing.
I never argued that blocking LSRR plugs all security holes. However it is one thing _not_ used in normal operations; and everything not used _must_ be shut down by a prudent security. And, again, there are several LSRR-based attacks.
LSRR is just too useful for diagnosing network problems to shut down on a backbone. If you want to be secure, have your security group assume someone has already broken onto your local LAN segment. Explain how he would be prevented from any further breach and how his unusual activities would be quickly detected and dealt with. For example, we don't run certain common services so any activity on these ports is automatically logged as unusual. Packet filters and disabling LSRR where you have NM machines and other network operations machines that can't be behind firewalls are just another barrier but mostly for alarms and audits for post mortems. Curtis
Who said one time passwords were secure. Kerberos mutual authentication with encrypted payload is my choice. Some people prefer SSL. AFS is nice if you can afford it. Skey just doesn't cut it. Skey is only slightly better than passwords in the clear.
If you don't care that people see your mail or administrative docs, and if everything you do locally is skeyed, why do you feel that s/key is so useless?
Curtis
Just curious, Avi
In message <199608231318.JAA06033@netaxs.com>, Avi Freedman writes:
Who said one time passwords were secure. Kerberos mutual authentication with encrypted payload is my choice. Some people prefer SSL. AFS is nice if you can afford it. Skey just doesn't cut it. Skey is only slightly better than passwords in the clear.
If you don't care that people see your mail or administrative docs, and if everything you do locally is skeyed, why do you feel that s/key is so useless?
Curtis
Just curious,
Avi
If someone decides to be destructive you don't want to have to go around cleaning up lots of systems. You also don't want to be the place hackers launch their attacks from if you are very well connected. If you are web hosting its nice to know the content will remain intact (there is a tradeoff here between inconvenience to your customers and encryption based security). There are lots of reasons for strong security. Or are you asking what the hole is in skey? If so, we'll talk at the nanog meeting. Curtis
participants (3)
-
Avi Freedman -
Curtis Villamizar -
Vadim Antonov