Security Incidents mailing list archives

RE: Packets from 255.255.255.255(80) (was: Packet from port 80 wi th spoofed microsoft.com ip)


From: "Fitzgerald, John" <John.Fitzgerald () petro-canada com>
Date: Wed, 5 Feb 2003 09:44:38 -0000


I think the original post was related to a router on the customer side of
the link ... although in either case, the addition of ACL as far as the ISP
is concerned is an additional administrative burden.

I wouldn't expect the ISP to provide this service for nothing - some ISPs
will provide a firewalled service. You can combine this firewalled service
with your own firewall to provide the layered security without having to
purchase and manage an additional filtering router.

Hopefully what you achieve (most suitable for a small shop) is  the
two-brain rule (where at least two people are involved in a firewall change
... one to make the change on the in-house firewall and a different person
to make the change at the ISP), hopefully, proper change control is required
by the ISP (so there's an audit of any changes made).

Even in some larger organisations you can often find that the perimeter
security is purely in the hands of one person - they can mistakenly or
maliciously open holes in the security. 

The benefit of having an additional in-house packet filter in a smaller
organisation is tempered by the fact that this is likely to be managed by
the same person (who may not be particularly expert in this area.)

I've never heard of an ISP installing the firewall at their end of the link
but this would be a clear benefit as the unwanted traffic would never get to
use up precious customer bandwidth.

Obviously there will be concerns at placing trust in a third party (although
the customer does maintain their own firewall and, hopefully, some form of
IDS ... or at least they monitor the firewall logs.) But it's not uncommon
(particularly in larger organisations) for the whole infrastructure to be
outsourced, including any security equipment.

As I mention above, there may be benefits in using an ISP if they have
significant firewall expertise (this depends on their size and the number of
customers using the firewall service)... and as inferred in the response
from Valdis - if the service can stop errant traffic using your bandwidth
even better! 

Going back to the ISP supplied/managed router at the customer site ...
although I wouldn't expect the ISP to provide customer supplied ACL (at no
extra cost) I think it's reasonable to expect the ISP to install ACL to
prevent the router itself being attacked.

John

-----Original Message-----
From: Valdis.Kletnieks () vt edu [mailto:Valdis.Kletnieks () vt edu]
Sent: 03 February 2003 19:05
To: Joel Tyson
Cc: Incidents Mailing List
Subject: Re: Packets from 255.255.255.255(80) (was: Packet from port 80
with spoofed microsoft.com ip) 


On Mon, 03 Feb 2003 10:40:02 EST, Joel Tyson <jtyson () pa eplus com>  said:

The best way to handle these types of packets would be to route them to a
null0 interface.  This way the packets will be dropped without icmp
response.
Typically all ISP should have these ACL's configured on their border
routers;
but they don't.  

There's not much financial incentive for many ISPs to filter - when you're
billing based on traffic volume, you don't really want all those probes to
go away.  So what if 20% of the traffic is probes?  That's 20% more income
for the provider, and many providers are in a financial crunch - that 20%
may be all that's keeping them afloat.  As long as they don't get burned by
an SQL worm that takes out their infrastructure too, why should the filter?

/Valdis (who is having a more-cynical-than-usual day)

            ***********************
This email communication is intended as a private communication for the sole use of the primary addressee and those 
individuals listed for copies in the original message. The information contained in this email is private and 
confidential and if you are not an intended recipient you are hereby notified that copying, forwarding or other 
dissemination or distribution of this communication by any means is prohibited.  If you are not specifically authorized 
to receive this email and if you believe that you received it in error please notify the original sender immediately.  
We honour similar requests relating to the privacy of email communications.

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


Current thread: