- Test - lists.nanog.org

Re: Telco's write best practices for packet switching networks
by Steven M. Bellovin 08 Mar '02

08 Mar '02

In message <Pine.GSO.4.33.0203061459240.3098-100000(a)rampart.argfrp.us.uu.net>, "Christopher L. Morrow" writes: > >On Wed, 6 Mar 2002, Ron da Silva wrote: > >> >> On Wed, Mar 06, 2002 at 09:41:55AM -0500, Steven M. Bellovin wrote: >> > >> > In message <gu9ofi1rcwe.fsf(a)rampart.argfrp.us.uu.net>, Eric Brandwine writ >es: >> > >> > > >> > >Firewalls are good things for general purpose networks. When you've >> > >got a bunch of clueless employees, all using Windows shares, NFS, and >> > >all sorts of nasty protocols, a firewall is best practice. Rather >> > >than educate every single one of them as to the security implications >> > >of their actions, just insulate them, and do what you can behind the >> > >firewall. >> > > >> > >When you've got a deployed server, run by clueful people, dedicated to >> > >a single task, firewalls are not the way to go. You've got a DNS >> > >server. What are you going to do with a firewall? Permit tcp/53 and >> > >udp/53 from the appropriate net blocks. Where's the protection? Turn >> > >off unneeded services, chose a resilient and flame tested daemon, and >> > >watch the patchlist for it. >> > >> > Precisely. You *may* need a packet filter to block things like SNMP >> > (to name a recent case in point), but a general-purpose firewall is >> > generally the wrong solution for appliance computers. > >There is no need to drop traffic for things that aren't listening. Eric's >point was you deploy your fancy-dan mail server with ONLY 22 and 25 >listening, you know that's all that's listening and your >daily/hourly/weekly/monthly automated audits tell you this continually and >alert when there are problems/deviations. So, why filter anything in this >case? It's wasted bandwidth/processing power. > I was agreeing with Eric's point. I've been saying this for years. My comment about the packet filter was to deal with services that are needed for some internal purposes, but for some reason can't protect themselves. Right now, that's snmp -- you may have snmpd running on your mail server, but given the recent CERT advisory you need to keep the bad guys away from it. (Yes, you should install fixed code -- but given how many components were affected by that advisory, it's quite obvious that no one has had time to test the fixes properly.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

5 8

black hat .cn networks
by Dan Hollis 08 Mar '02

08 Mar '02

http://wired.com/news/politics/0,1283,43437,00.html Time to drop AS4134. -Dan

16 17

Equinix Exchange Point
by Guy.Ram＠usa.telekom.de 08 Mar '02

08 Mar '02

Quick poll to see who's at or planning to be at the Equinix Asburn exchange point. thanks, -guy

7 8

Frame Relay Aggregation Experience
by Tim McKee 08 Mar '02

08 Mar '02

With the quantity of equipment vendors that have bitten the dust over the lat year, I would like to update my database of who still exists and what products they have in the small and medium size frame aggregation product (for remote ILEC colo deployment) with ATM IMA and DS3 delivery. Also small ATM switches with IMA, DS3 and OC3c concentration capabilities. I would appreciate any real operational comments regarding this type of equipment. I will gladly summarize the information and comments and place it online for general access by the NANOG community. Thanks in advance, Tim McKee

1 0

Equinix Exchange Point
by Louisa_Coughlan＠rcn.net 07 Mar '02

07 Mar '02

RCN will be there in about a week. -lou

1 0

Re: Telco's write best practices for packet switching networks
by JC Dill 07 Mar '02

07 Mar '02

On 04:37 PM 3/7/2002 -0500, Sean Donelan wrote: >My comment was originally prompted by the meeting minutes which >reported on the survey data showing that 100% of carriers are implementing >firewalls in their gateways. The 100% is what caught my eye. Is that "100% of carriers report implementing firewalls in 100% of their gateways" or "100% of carriers report implementing firewalls in at least one gateway"? I suspect that it's closer to the later than the former, and that it includes firewalls located at gateways on the *customer* side of the circuit (managed IP services, including managing customer routers and firewalls). jc

1 0

Re: Telco's write best practices for packet switching networks
by Steven M. Bellovin 07 Mar '02

07 Mar '02

In message <Pine.GSO.4.40.0203071618090.25551-100000(a)clifden.donelan.com>, Sean Donelan writes: > >My comment was originally prompted by the meeting minutes which >reported on the survey data showing that 100% of carriers are implementing >firewalls in their gateways. The 100% is what caught my eye. As the >topic comes up in various places, large ISPs repeatedly say they are >unable to implement filters or packet screening on their high-speed >links such as at peering points. So the self-reported 100% implementation >of screening and filtering firewalls at gateways didn't seem to jive >with my understanding of the limitations faced by large ISPs. Yup. > >Firewalls can be a useful tool in the security engineer's toolbox. But >they get misused a lot. I don't believe security engineers are better >programmers. If there was a class of programmers in the world that didn't >make mistakes, I would hire them to write the applications. When the >firewall is more complex than the application server it is "protecting" >which is likely to have more mistakes? > Yes and no. I don't think that security programmers are any better than application programmers. But they might be trained differently. For example, I suspect that most application programmers have never heard of format string vulnerabilities. I would hope that most security professionals have. But you're absolutely right about the complexity of many of today's firewalls -- I've been complaining about that for years. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

216.119.248.0/21
by David Barak 07 Mar '02

07 Mar '02

What's ARIN got to do with it? route: 216.119.248.0/21 descr: Nuvox Communications origin: AS16994 notify: bgp(a)nuvox.net mnt-by: MAINT-AS11456 changed: dfh(a)nuvox.net 20020130 source: RADB -David Barak "Quis custodes ipsos custodiet?" - Juvenal ========= JD Falk wrote: Has ARIN begun assigning from 216 (but not updating whois), or is AS16994 playing silly buggers here? (Apparently this network was sending spam.) route-views.oregon-ix.net>sh ip bgp 216.119.251.98 BGP routing table entry for 216.119.248.0/21, version 1338771 Paths: (53 available, best #14) Advertised to non peer-group peers: 64.166.72.140 3333 9057 3549 11456 11456 16994 __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/

4 3

SNMP Advisory Updates
by CERT(R) Coordination Center 07 Mar '02

07 Mar '02

-----BEGIN PGP SIGNED MESSAGE----- Hello Folks, I've made a large number of vendor updates to the SNMP Advisory (http://www.cert.org/advisories/CA-2002-03.html) Due to the sheer number of vendors included in this Advisory, you may wish to take a look at your convenience. Thanks, Ian Ian A. Finlay CERT (R) Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA USA 15213-3890 Feb 12, 2002: Initial release Feb 12, 2002: Corrected vendor appendix formatting issues Feb 12, 2002: Added vendor statement for Inktomi Feb 12, 2002: Fixed formatting problem in "Disable stack execution" section Feb 12, 2002: Updated vendor statement for Juniper Feb 12, 2002: Fixed broken link in Juniper statement Feb 12, 2002: Updated Public Thanks section Feb 12, 2002: Updated Covalent statement Feb 12, 2002: Updated SNMP Research statement Feb 12, 2002: Updated CVE and Comtek services links Feb 13, 2002: Updated Cisco, Enterasys, FreeBSD, HP, Microsoft, Sun, and Tandberg statements, removed Tivoli statement Feb 14, 2002: Added vendor statement for Aprisma Feb 14, 2002: Added vendor statements for MG-Soft and NetScreen Feb 14, 2002: Added vendor statement for iTouch Communications Feb 14, 2002: Added vendor statement for F5 Networks Feb 14, 2002: Added vendor statement for Sierra Wireless Feb 15, 2002: Added vendor statement for MICROMUSE Feb 15, 2002: Updated HP statement Feb 16, 2002: Updated Nortel Networks statement Feb 16, 2002: Added vendor statement for Foundry Networks Feb 18, 2002: Added vendor statement for Tivoli Feb 18, 2002: Added vendor statement for Radware Feb 18, 2002: Updated Nortel Networks statement Feb 19, 2002: Updated Nortel Networks statement Feb 19, 2002: Updated F5 Networks statement Feb 19, 2002: Updated Compaq statement Feb 19, 2002: Updated IBM statement Feb 19, 2002: Added vendor statement for Dell Feb 19, 2002: Fixed bad link in Enterasys statement Feb 19, 2002: Updated IBM statement Feb 19, 2002: Added vendor statement for BMC Software Feb 20, 2002: Added vendor statement for Wind River Systems Feb 20, 2002: Added vendor statement for Concord Communications Feb 20, 2002: Added vendor statement for CommWorks Corporation (a 3Com company) Feb 20, 2002: Added vendor statement for Lexmark International Feb 20, 2002: Added vendor statement for Check Point Software Technologies Inc. Feb 20, 2002: Added vendor statement for Alcatel Feb 21, 2002: Added vendor statement for Avici Systems Inc. Feb 21, 2002: Added vendor statement for NuDesign Team Inc. Feb 21, 2002: Added vendor statement for ADTRAN, Inc. Feb 21, 2002: Updated NetScreen vendor statement Feb 21, 2002: Added vendor statement for TMP Consultoria S/C Feb 21, 2002: Added vendor statement for Xerox Feb 21, 2002: Updated Inktomi vendor statement Feb 21, 2002: Added vendor statement for nCipher Corp. Feb 21, 2002: Updated Lucent vendor statement Feb 21, 2002: Added vendor statement for Spider Software Feb 21, 2002: Added vendor statement for Riverstone Networks Feb 21, 2002: Added vendor statement for Standard Networks, Inc. Feb 21, 2002: Added vendor statement for Openwave Systems Inc. Feb 21, 2002: Added vendor statement for General DataComm Feb 22, 2002: Added vendor statement for NETWORK HARMONi, Inc. Feb 22, 2002: Updated HP vendor statement Feb 22, 2002: Updated Nortel Networks statement Feb 25, 2002: Added vendor statement for American Power Conversion Feb 25, 2002: Added vendor statement for Cambridge Broadband Ltd. Feb 25, 2002: Added vendor statement for Corsaire Limited Feb 25, 2002: Added vendor statement for SonicWALL, Inc. Feb 26, 2002: Added vendor statement for Perle Systems Feb 26, 2002: Added vendor statement for Sonus Networks Feb 26, 2002: Added vendor statement for Optical Access Feb 26, 2002: Added vendor statement for INRANGE Technologies Feb 26, 2002: Updated vendor statement for Redback Networks, Inc. Feb 26, 2002: Removed "Disable stack execution" section from Solutions Feb 26, 2002: Added vendor statement for BinTec Communications AG Feb 26, 2002: Updated vendor statement for IBM Feb 27, 2002: Updated HP vendor statement Feb 27, 2002: Added vendor statement for World Wide Packets Feb 27, 2002: Added vendor statement for Dart Communications Feb 27, 2002: Added vendor statement for Quallaby Corporation Feb 27, 2002: Updated iTouch Communications vendor statement Feb 27, 2002: Added vendor statement for CipherTrust, Inc. Feb 27, 2002: Added vendor statement for Ipswitch, Inc. Feb 27, 2002: Added vendor statement for D-Link Systems, Inc. Mar 01, 2002: Added vendor statement for iPlanet Mar 01, 2002: Updated vendor statement for Novell Mar 01, 2002: Updated vendor statement for nCipher Corp. Mar 01, 2002: Added vendor statement for Extreme Networks Mar 04, 2002: Added vendor statement for NetSilicon Mar 04, 2002: Added vendor statement for SecureWorks, Inc. Mar 04, 2002: Added vendor statement for Efficient Networks, Inc. Mar 04, 2002: Updated vendor statement for Novell Mar 04, 2002: Added vendor statement for Monfox, LLC Mar 05, 2002: Added vendor statement for Paradyne Mar 05, 2002: Added vendor statement for Trend Micro Mar 05, 2002: Updated vendor statement for Dartware, LLC Mar 05, 2002: Added vendor statement for Quick Eagle Networks Mar 05, 2002: Added vendor statement for Conectiva Mar 05, 2002: Added vendor statement for Asante Technologies, Inc. Mar 05, 2002: Added vendor statement for SolarWinds.Net, Inc. Mar 06, 2002: Updated vendor statement for Aprisma Mar 06, 2002: Updated vendor statement for Ipswitch, Inc. Mar 06, 2002: Added vendor statement for CSCare, Inc. Mar 06, 2002: Updated vendor statement for iTouch Communications Mar 06, 2002: Added vendor statement for Uptime Devices, Inc. Mar 06, 2002: Added vendor statement for Larscom Incorporated Mar 06, 2002: Added vendor statement for InterNiche Technologies, Inc. Mar 07, 2002: Added vendor statement for Network Appliance Mar 07, 2002: Updated vendor statement for Avaya Mar 07, 2002: Updated vendor statement for Xerox Mar 07, 2002: Added vendor statement for Sniffer Technologies Mar 07, 2002: Added vendor statement for Powerware Corporation Mar 07, 2002: Added vendor statement for Carrier Access Mar 07, 2002: Added vendor statement for net.com Mar 07, 2002: Added vendor statement for Oracle Corporation -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBPIfb/KCVPMXQI2HJAQGVcgQApnmr2rPkaXwxEK1KoikbQSpjlVngHNBi R4EkoyvrpWXtlNlGQWX8zLAvEWZf4mS12r8Ai/zyYLw3mIhzs48SM6d5+f07aTrh afKwbsdAocdg3lx8T5F1toBlM4GphYFaQDDYPMh6EzDko3aIbrXaEmpcOCM8CJ2F aofaejrBLb0= =m5if -----END PGP SIGNATURE-----

1 0

Contact for AS4015
by Eric Whitehill 07 Mar '02

07 Mar '02

Hey everyone: Sorry to ask this, but if someone can please contact me from AS4015? The contacts listed at Arin are no longer any good, and anyone we have talked to at Qwest doesn't seem to know anyone we can talk to about an issue we are having. Thanks, -Eric

1 0