- NANOG - lists.nanog.org

Re: Cisco, Anti-virus Vendors Team on Network Security
by Brandon Butterworth 18 Nov '03

18 Nov '03

Duh. Make that the OS that can use it seem to be more usually wormed/virused than the OS that can't

1 0

Re: Cisco, Anti-virus Vendors Team on Network Security
by Brandon Butterworth 18 Nov '03

18 Nov '03

> Cisco has licensed its Cisco > Trust Agent technology to Network Associates, Symantec and Trend Micro so > > Currently the Cisco NAC software only works with Cisco network equipment > and Microsoft Windows NT, XP and 2000 operating systems. > > Without the secret handshake Mac OS, Linux, Solaris and other operating > systems will not be able to connect to a Cisco Self-Defending Network > which limits its usefullness for ISPs. Sounds of limited use anyway, the OS that can use it seem to be more usually wormed/virused that the OS than can't (regardless of the add on security products). brandon

1 0

uRPF-based Blackhole Routing System Overview
by Robert A. Hayden 18 Nov '03

18 Nov '03

I posted earlier mentioning that I was using uRPF to facilitate a blackhole routing system on our campus. I went off to lunch and came back to 38 private emails from people asking how I'm doing it. Rather than respond individually, I figured I'd post an informal synopsis here. First, I'm a network engineer at the University of Wisconsin Madison (I read NANOG from my personal email account). We have a large ethernet-based network that runs primarily on Cisco 6500s for core routing and switching, and 3550/3750 switches for edge aggregation. 802.1q is used for layer 2 networking, with each department network getting a unique .1q VLAN ID. uRPF was designed primarily to block spoofed IPs. However, you can trick it into blocking non-spoofed IPs by making the routing table think the IP address should legitimately be located somewhere else. So, the first step is to turn on strict uRPF checking on to the interface. We use the following as an example interface setup on an MSFC2 running 12.1.(19)E1: interface Vlan645 description Department of Nuclear Basketweaving LAN ip address 192.168.1.0 255.255.255.0 secondary ip address 10.0.0.1 255.255.255.0 ip verify unicast source reachable-via rx allow-self-ping ... end Second, we set up a small router and make sure it speaks OSPF with the rest of our backbone mesh. Any size router will do since it doesn't need to handle a lot of traffic. Heck, grab an old 2501 out of your suplus closet. Make sure that this router is set up to redistribute static routes. We use a 3550-12 switch because we forward certain traffic into a server for analysis so we wanted something with a little horsepower to handle it. In most cases, anything small will work. Now, let's pretend that the IP address of 192.168.1.100 is Nachi compromised and we want to blackhole it. That is, we want to make sure that it neither receives nor sends traffic beyond its router interface. On the blackhole router I can enter: ip route 192.168.1.100 255.255.255.255 null 0 OSPF will inject this /32 route into the backbone mesh. Back on the actual interface, uRPF will see in the routing table that the route belongs "somewhere else" and conclude that it must spoofed and dump it. In addition, traffic destined TO that IP address will follow the most-specific route and end up in the BH router. As soon as the nachi virus is removed, I do: no ip route 192.168.1.100 255.255.255.255 null 0 on the blackhole router and in a few seconds traffic to and from that IP flows properly because the /32 is no longer seen by the router interface. Note that if you don't use uRPF on that interface, or if you use loose-source uRPF, than this system won't work for outgoing traffic, only for packets destined TO the BHed IP address. Now, we also have a web-based front end we custom developed. It takes the IP address we want to manipulate and executes the 'ip route' command on the router by proxy. It also saves additional information into a historical database about who entered/removed the IP, any Clarify tracking case associated with it (our internal ticketing system), and any other relevant information. For notification, it checks against our WHOIS-based customer tracking database that associates people records with the vlan number, and send them a notification that the IP was blackholed, and then reminders every few days until the IP is removed. Unfortunately, this was also all custom developed. As a whole, the system works REALLY well and we can sugically remove IPs from the backbone without having to kill entire subnets, and then just as easily enable them again. One final note. This system is pretty useless for modem pools, VPN concentrators, and many DHCP implementations. The dynamic IP nature of these setups means you will just kill legitimate traffic next time someone gets the IP. You can attempt to correlate your detection with the time they were handed out, of course, in the hopes you find them. - Robert Network Guy @ UW Madison

5 4

C&W Euro NOC contact
by Thomas Kernen 18 Nov '03

18 Nov '03

If someone from the C&W European NOC can contact me offline I would appreciate it. I have an issue that can't be escalated because the person that answers the phone in Munich doesn't seem to understand what on earth I'm talking about. Thx Thomas

1 0

Search for a better solution
by Wesley Vaux 18 Nov '03

18 Nov '03

All, In my never ending search for a better technology I recently requested information about the GFI Security suite, I would like to thank all who replied. My next suite of products I am exploring and request your feedback is the ISS suite of tools to include SiteProtector and Preventia series devices for IDS, IP(prevention)S, Firewall/VPN,Anit-virus,and Content Filtering. If anyone uses/used these devices please reply to me offlist with your thoughts on these products. I appriciate all of your patience with me in exploring these solutions. Thanks you in advance, Wes Vaux, CCNA, CCDA Network Security Engineer, 9000 Regency Pkwy Ste 500 Cary, NC 27511 t 919.463.6782 f 919.463.1290 Global Knowledge Experts Teaching Experts http://www.globalknowledge.com <blocked::http://www.globalknowledge.com/>

1 0

need a contact at Prodigy/Ameritech
by Mark Jeftovic 18 Nov '03

18 Nov '03

If anyone at Prodigy/Ameritech in here can you contact me offlist or let us know what the listing critereon is for your BL? host mx1-clevoh.clevoh.ameritech.net[66.73.20.19] said: 553 5.3.0 DNSBL:To request removal of,[216.220.40.247], send and E-mail to abuse(a)prodigy.net (fwd) Our mail forwarding clients on your system are being affected by this. -mark -- Mark Jeftovic <markjr(a)easydns.com> Co-founder, easyDNS Technologies Inc. ph. +1-(416)-535-8672 ext 225 fx. +1-(416)-535-0237

2 1

Inter layer communication in edge routers
by sandoche balakrishnan 18 Nov '03

18 Nov '03

Bonjour, I am a Masters student focusing on cross layer simulation in edge routers. I would like to have pointers on papers which talks about cross layer interactions among layers which could help to optimise the system performace as a whole. Thanks, Cordialement, Sandoche Balakrichenan. _________________________________________________________________ BharatMatrimony.com. http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 India's premium matrimonial website.

1 0

New IPv4 blocks allocated to RIPE NCC
by leo vegoda 18 Nov '03

18 Nov '03

Dear Colleagues, The RIPE NCC received the IPv4 address ranges 83.0.0.0/8 and 84.0.0.0/8 from the IANA in November 2003. We will begin allocating from these ranges in the near future. On 24 October 2003 there was a formal proposal to the RIPE Address Policy Working Group to lower the minimum allocation size from /20 to /21. For the text of this proposal please see: <http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00189.html> It is likely that there will be formal consensus on this proposal in the near future. Consequently, the minimum allocation size for these blocks has been set at /21. Nonetheless, the RIPE NCC will not make /21 allocations from these blocks until after there is formal consensus to do so. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

IETF Area Director position
by Geoff Huston 18 Nov '03

18 Nov '03

I'm posting this on behalf of Rich Draves, the chair of the IETF Nominations Committee. Please direct any followup questions to Rich at richdr(a)microsoft.com Thanks, Geoff Huston ---------------------------------------------------- Last week Randy Bush resigned from his position as Operations & Management Area Director for the IETF. This creates a mid-term vacancy that the IETF NomCom needs to fill. Randy's replacement will have a one-year term. Please submit nominations for Randy's O&M Area Director position to nomcom(a)ietf.org. The deadline for these nominations is noon (Pacific Time) on December 1. Any member of the IETF community may nominate any member of the IETF community for any open position. Self-nominations are permitted. Please also send the NomCom your feedback on the past performance of the incumbents, feedback on potential nominees, or your thoughts on what the NomCom should keep in mind when considering candidates. All input to the nomcom will be kept strictly confidential. Thanks, Rich

1 0

New IANA IPv4 allocations and bogon updates: 83/8 and 84/8
by Rob Thomas 18 Nov '03

18 Nov '03

Hi, team. [ Apologies to those who have received this post in other fora. ] The numerous Team Cymru bogon projects have been updated to reflect the following IANA allocations on November 15, 2003: 83/8 Nov 03 RIPE NCC 84/8 Nov 03 RIPE NCC IANA allocations change over time, so please check regularly to ensure you have the latest filters if you are not using the bogon BGP feed(s). We do announce updates to the bogon projects to the FIRST community, as well as on lists such as NANOG, isp-routing, isp-security, isp-bgp, cisco-nsp, and bogon-announce. We can not stress this point strongly enough - these allocations change. If you do not adjust your filters, you will be unable to access perhaps large portions of the Internet. Worse yet, you may end up blocking access for people who transit through you. Please do not blindly apply any filters or blocks to your network without carefully considering the ramifications of doing so. As a point of reference, the master Bogon Reference Page can be found here: http://www.cymru.com/Bogons/index.html A quick summary of the documents and projects that have been updated include the following: HTTP The Bogon List The Text Bogon List, Unaggregated The Text Bogon List, Aggregated Secure BIND Template Secure IOS Template (Cisco) Secure BGP Template (Cisco) Secure JUNOS Template (Juniper) Secure JUNOS BGP Template (Juniper) Ingress Prefix Filter Templates, Loose and Strict (Cisco) Ingress Prefix Filter Template, Loose (Juniper) Ingress Prefix Filter Template, Strict (Juniper) BGP Bogon route-server * RADb fltr-unallocated fltr-martian fltr-bogons DNS Bogon (bogons.cymru.com) zone Monitoring Bogon prefix monitoring * All of the bogon peers have received the appropriate BGP prefix updates. Please feel free to contact Team Cymru with any comments, questions, or concerns. Thanks! Rob, for Team Cymru. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

1 0