I'm not disagreeing with you. I have no experience in the ISP portion of
the field. My entire point was to make sure that you have written policies
to follow. Also, any "out of the ordinary" change you directed to make to
the firewall should be in writing.
Tim Kramer
Myllym�ki Sakari wrote:
> That sound nice and good, but consider scenario like this:
>
> CompanyA uses ISP-A and ISP-B as a backup. CompanyA's IP series 'belongs' to
> ISPA's 'inside' - right? Now CompanyA's connection to ISPA is down and their
> vital connection to say Branch office is routed through ISPB, so it will
> come through ISPB's net to ISPA's net. Since Branch office link to ISPA is
> up, the route is still advertised from there. The backup link might also be
> an ISDN that comes up only when needed.
>
> It is of course nice for the ISP if its customers cannot easily change
> provider, but not so nice for the customer, if they cannot have backup
> links.
>
> Now I know there are many more problems with this scheme, like that the
> routing for the return packets. NAT might be answer, but it brings it's own
> problems. My point is only, that it is not so simple as you make it sound.
>
> Sakari
> > -----Original Message-----
> > From: Bennett Todd [SMTP:[EMAIL PROTECTED]]
> > Sent: Saturday, September 25, 1999 8:41 PM
> > To: Tim Kramer
> > Cc: Michael Cunningham; [EMAIL PROTECTED]
> > Subject: Re: security policy examples
> >
> > 1999-09-24-16:17:48 Tim Kramer:
> > > I can only image one case where an ISP would need a firewall: to protect
> > its
> > > internal network where the billing records and logs are kept. (I'm
> > probably
> > > wrong as I've never worked that side of the house.) (Why have a firewall
> > if
> > > the security policy is "no restrictions"?)
> >
> > There ought to be a firewall any place there's an administrative border.
> > At
> > the connection between the internet and an ISP, they should have a box
> > that
> > enforces a couple of rules:
> >
> > - don't allow packets through in either direction to or from the RFC
> > 1918 address blocks 192.168/16, 172.16/12, and 10/8.
> > - don't allow incoming packets with source addresses that are
> > supposed
> > to be inside the firewall, and don't allow outbound packets with
> > source addresses that aren't inside the firewall.
> >
> > In addition a border firewall gives you valuable logging, and the ability
> > to
> > shut down many denial-of-service attacks once they're detected and
> > diagnosed.
> >
> > > Politics will always conflict with security when use of your network is
> > > involved.
> >
> > I think these conflicts, and how they are resolved, are the test of the
> > security policy. A good security policy is strengthened by such
> > challenges,
> > since it ends up either educating the user about the organization's needs,
> > or
> > else being revised to better meet them.
> >
> > -Bennett
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]