Security Incidents mailing list archives

Re: ISP Filtering (Survey of Sorts)


From: <macdaddy () pittstate edu>
Date: Fri, 1 Jun 2001 19:59:40 -0500 (CDT)

Keith,
        In all honesty, I can't imagine any ISP or provider of any sorts
not dropping RFC1918's at all edges, unless something special is going on,
inbound and outbound.  That should be the most common practice next to
setting a root or enable password.  At an ISP I contract with, I'm
preparing to go on a massive ACL binge.  I'm dropping a whole bunch of
ports.

1-19 I/O  (there isn't any reason why a user should be using these ports)

61/62 I (there isn't any reason why someone should be query *any* of our
devices via SNMP)

111 I/O (talk about hack me please...)

135-139 I/O (no reason to allow this.  too much info can be gathered with
NO log entry on the queried box.  most are misconfigured and allow access
to way too much)

53 where possible (few client nodes should be queried for DNS.  Most of
our users are basic dialups.  Some DSL, very little business DSL or leased
line.  Those people plus our own DNS servers need to be allowed for.)

netbus/BO ports  (let's halt the problem before it starts)

I've seriously been thinking about blocking connections TO port 25 on our
client (non-business) nodes.  We'd still allow them to use any SMPT server
they want (unlike many DSL/cable providers) but we won't let them run
their own SMTP server.  I really like that idea personally.  Sure somebody
will be running Linux and want to be able to have sendmail running on
their box.  I say just configure it to relay to our SMTP server and on out
from there.  It sounds much more reasonable that what a lot of ISPs do).

I have a whole list of ports on my whiteboard at work.  All of the ports I
list are ports that 99.99% of clients would use.  They are generally ports
that can be malicious in nature (111) or just shouldn't be allowed out of
our network (135-139, 61/62).  Sure this will skew portscans outside of
our network but I don't mind.  Our admin machines will be exempt from
these rules.  The way I see it, most attacks occur on a select number of
services that few if any clients need to run.  Taking measures to limit
their exposure up front just sounds natural to me.  That's my $.02.

Justin

PS==> if anyone wants my full list, email me and I'll send it to you next
week.



--
Justin Shore                    Pittsburg State University
Network & Systems Manager       Kelce 157Q
Office of Information Systems   Pittsburg, KS 66762
Voice: (620) 235-4606           Fax: (620) 235-4545
http://www.pittstate.edu/ois/

"Time spent tightening security at your site is best spent before a
break-in occurs. Never believe that your site is too small or of too
little consequence. Start out by being wary, and you will be more prepared
when the inevitable attack happens."

  -- "Sendmail, 2nd Edition" by Bryan Costales & Eric Allman for O'Reilly

On Thu, 31 May 2001, McCammon, Keith wrote:

A few questions:

1) Does anyone know of a list of known security-conscious ISP's (for larger
corporate circuits) that are known for providing basic security services
(ingress/egress filters, RFC1918's, and client-specific filter requests) to
customers without hassle.

2) Does anyone else have an ISP that, by policy, will not filter upstream?
I've got Verizon, and I've been having some infrequent correspondence with
them regarding filtering and it has been denied all the way up the chain.
I'm getting kind of tired of seeing thousands of matches on my access-lists
against RFC1918 rules and such that I would assume should be filtered by any
semi-responsible ISP.


Current thread: