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.
This archive was generated by hypermail 2b30 : Sat Jun 02 2001 - 07:08:36 PDT