Daniel Senie <dts@senie.com> wrote:
While implementing these measures may not directly benefit your network, doing so may thwart an attack against someone else's net. Tomorrow, the roles could be reversed. As with many areas of managing the Internet, cooperation is key.
Yep. Actually, tier-1 ISPs can write the requirement for reverse-path source IP address verification on customer access circuits into their peering agreements. An enforcement can take a form of penalties per verified incident of forged source address attack originating in peer's network. (The adversarial IP perfix filtering was needed to institute such prefix-reduction policies as aggregation and address allocation out of ISP blocks. I remember that purely voluntary efforts were pretty much derailed by negligience of some ISPs (why AS 174 comes to the mind? :) I do not expect reverse path filtering to be any different in terms of deployment problems.) --vadim
On Tue, 8 Feb 2000, Vadim Antonov wrote:
Yep. Actually, tier-1 ISPs can write the requirement for reverse-path source IP address verification on customer access circuits into their peering agreements. An enforcement can take a form of penalties per verified incident of forged source address attack originating in peer's network.
The best penalty of all - simply pulling customer's plug till they fix their network, with a repeat offense resulting in permanent disconnection. -Dan
I think Sun could help here with adding something to their sales agreement that could result in people configuring their Sun boxes to be good net citizens. Dan Hollis wrote:
On Tue, 8 Feb 2000, Vadim Antonov wrote:
Yep. Actually, tier-1 ISPs can write the requirement for reverse-path source IP address verification on customer access circuits into their peering agreements. An enforcement can take a form of penalties per verified incident of forged source address attack originating in peer's network.
The best penalty of all - simply pulling customer's plug till they fix their network, with a repeat offense resulting in permanent disconnection.
-Dan
-- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh
It's not a matter of being good netizens. It's a matter of writing non-exploitable code so attack software like trinoo and tribe don't end up on your systems due to buffer-overflows in rpc or other services. No amount of sales agreements is going to fix that as long as human beings write code. -- Joseph W. Shaw - jshaw@insync.net Computer Security Consultant and Programmer Free UNIX advocate - "I hack, therefore I am." On Tue, 8 Feb 2000, Henry R. Linneweh wrote:
I think Sun could help here with adding something to their sales agreement that could result in people configuring their Sun boxes to be good net citizens.
It's a matter of writing non-exploitable code so attack software like trinoo and tribe don't end up on your systems due to buffer-overflows in rpc or other services.
I put the emphasis back on the server admins. Security patches were readily available on the Sun site. Ignoring applicable security patches for months is likely to get you hacked and abused on todays net. Combine that with outgoing spoofed IP filters and we are beginning to make effective countermeasures. Yes, I will acknowledge the strong tendency to avoid touching a production server, but scheduled upgrade outages are vastly superior to hitting the front page as a trinoo source. Unfortunately all three above point to a need for improvement in the good netizen department. -bryan (as a server admin, this is where i say mea culpa)
It's a matter of writing non-exploitable code so attack software like trinoo and tribe don't end up on your systems due to buffer-overflows in rpc or other services.
I put the emphasis back on the server admins. Security patches were readily available on the Sun site. Ignoring applicable security patches for months is likely to get you hacked and abused on todays net.
Yes.. and new patches appear each and every week. Do YOU want to schedule reboots for 80 some servers on a weekly basis? *IF* you get approval for such frequent reboots, you still have the problem of the administrative nightmare. Especially if you've made custom modifications to the systems and have to be carefull exactly which patches you apply instead of doing a blanket install. Now, from the other end of this, this is no excuse not to keep your servers up to date. You may just end up checking it, say, monthly instead of weekly. ---------------------------------------------------------------------- Wayne Bouchard [Immagine Your ] web@typo.org [Company Name Here] Network Engineer ----------------------------------------------------------------------
participants (6)
-
Bryan Bradsby -
Dan Hollis -
Henry R. Linneweh -
Joe Shaw -
Vadim Antonov -
Wayne Bouchard