Firewalls in service provider environments

Christopher Morrow morrowc.lists at gmail.com
Tue Feb 7 22:59:47 UTC 2012


On Tue, Feb 7, 2012 at 4:42 PM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
>
>
>> -----Original Message-----
>> From: Matthew Reath [mailto:matt at mattreath.com]
>> Sent: 07 February 2012 21:34
>> To: nanog at nanog.org
>> Subject: Firewalls in service provider environments
>>
>> All,
>>
>> Looking for some recommendations on firewall placement in service
>> provider
>> environments.  I'm of the school of thought that in my SP network I do
>> as
>> little firewalling/packet filtering as possible. As in none,
>
> I had a vendor actually suggest that that ALL my customer traffic should traverse a firewall. I asked why and they said "Ahhh it the internet, must have firewall". I suppose this must have been a great firewall.

'of china'! ha! hahaha.... anyway.

> So yes I would agree with you, firewall nothing for your customers unless they are paying you for a specific service. Filtering known bad ports, well, what's a known bad port? Bad for one person may be quite important for another. Whilst filtering port 25 outbound may help prevent some bots from emanating spam, it certainly does a lot to annoy other people.
>

I think for a purely SP network, transit-provider core links sort of
thing, why filter anything at all? why filter anything that's not
destined to your own equipment? You can't possibly know what some
customer (or set of customers) are going to do with their traffic, so
you can't possibly filter it sanely/safely.

for a consumer ISP, provided your TOS says it's ok, why not filter
some common problems:
  tcp/25
  ... not much else really... and REALLY you just want to send tcp/25
-> 587 on your mail-relays (or redirect to internal use addresses on
the relays).

If customers (in either case) want to pay you for 'security services'
then rock some filters on their CPE, with the option to move that
upstream to your PE if you have to (too much crap on customer link).

-chris




More information about the NANOG mailing list