- Test - lists.nanog.org

Maximun effective range of an excuse is... [Was: Re: Quarantine your i nfected users spreading malware]
by Fergie 21 Feb '06

21 Feb '06

QED: AT&T/SBC also does this for their DSL subscribers... - ferg -- Larry Smith <lesmith(a)ecsis.net> wrote: The problem with discussing AOL and "large provider" in the same sentence is that the complete AOL (connection, desktop, tools, etc) function are AOL controlled (walled garden) so they have the capability of doing much more in that arena that other providers. [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 21 Feb '06

21 Feb '06

----- Original Message Follows ----- From: Gadi Evron <ge(a)linuxbox.org> > Many ISP's who do care about issues such as worms, > infected users "spreading the love", etc. simply do not > have the man-power to handle all their infected users' > population. > Some who are user/broadband ISP's (not say, tier-1 and > tier-2's who would be against it: "don't be the > Internet's Firewall") are blocking ports such as 139 and > 445 for a long time now, successfully preventing many of > their users from becoming infected. This is also an > excellent first step for responding to relevant outbreaks > and halting their progress. > > Philosophy aside, it works. It stops infections. Period. > > Back to the philosophy, there are some other solutions as > well. Plus, should this even be done? Oh geez, here we go again... Search the archives and read until you're content. It's a non-thread. This horse isn't only dead, it's not even a grease spot on the road any more. :-( scott

15 28

Subject: drone armies C&C report - February/2006
by c2report＠isotf.org 21 Feb '06

21 Feb '06

Below is an automatically generated periodic public report from the ISOTF's affiliated group "DA" ("Drone Armies (botnets) research and mitigation mailing list" / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. In the past few months we did not publish this report, allowing for responsible parties to ask for regular reports from us on suspected botnet C&C activity on their networks. As you can see below, the Internet drastically changed its face positively because these reports (compared to when we started), and now a lot more so due to direct reporting. For purposes of this report we use the following terms: open the host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 4271 unique domain with port or IP with port suspect C&Cs. This list is extracted from the BBL which currently has a historical base of 7780 reported C&Cs. Of the suspect C&Cs surveyed, 685 reported as Open, 3353 reported as closed and 572 issued resets to the survey instrument. Of the C&Cs listed by domain name, 1847 are mitigated via remapping. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. ASN Responsible Party Total Open Percent_Resolved 14744 PNAP Internap Network Services 91 0 100% 10913 PNAP Internap Network Services 67 0 100% 30058 FDCSE FDCservers.net LLC 65 18 72% 25761 STAMIN-2 Staminus Communications 58 6 90% 3356 Level 3 Communications, LLC 53 0 100% 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 14779 INKT Inktomi Corporation 42 0 100% 21844 THE PLANET 41 2 95% 19318 AIC-81 Albany International Corp. 40 11 73% 13749 EVRY Everyones Internet 37 5 86% 4766 KIXS-AS-KR 35 2 94% 30315 Everyones Internet 31 12 61% 12182 PNAP Internap Network Services 31 0 100% 9318 HANARO-AS 30 9 70% 21840 SAGONE Sago Networks 30 5 83% 13790 PNAP Internap Network Services 30 0 100% 22822 LLNW Limelight Networks 29 10 66% 27595 ATRIV Atrivo 27 5 81% 12832 Lycos Europe 26 3 88% 3561 Savvis 24 1 96% Top 20 ASNes by number of active suspect C&Cs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. ASN Responsible Party Total Open Percent_Resolved 13301 UNITEDCOLO-AS Autonomous System of 52 35 33% 32748 NOZON NoZone 21 20 5% 30058 FDCSE FDCservers.net LLC 65 18 72% 174 Cogent Communications 20 16 20% 25700 SWIFTDESK VENTURE 19 13 32% 30315 Everyones Internet 31 12 61% 4134 CHINANET-BACKBONE 17 12 29% 19318 AIC-81 Albany International Corp. 40 11 73% 9121 TTNet 15 11 27% 22822 LLNW Limelight Networks 29 10 66% 8972 INTERGENIA-ASN intergenia autonomou 21 10 52% 15083 IIS-129 Infolink Information Servic 24 9 63% 30407 Velcom.com 12 9 25% 9318 HANARO-AS 30 9 70% 20115 Charter Communications 20 9 55% 23522 CIT-FOONET 14 9 36% 16265 LEASEWEB AS 15 9 40% 3269 TELECOM ITALIA 16 8 50% 8560 SCHLUND-AS 19 7 63% 19166 Alpha Red, INC 14 7 50% 33569 ALLHOSTSHOP.COM 16 6 63%

1 0

Re: Quarantine your infected users spreading malware
by Scott Weeks 20 Feb '06

20 Feb '06

> > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > > the road any more. :-( > > I quite agree, which is why I trived to cover the > philosophical part from both sides. Now, how about some > solutions that came about since our last discussion that > was nothing BUT philosophy? You can't get there from here. scott

2 1

Cisco 3550 replacement
by Jacky Lam 20 Feb '06

20 Feb '06

Hi all, I'm currently looking for a CPE that can replace the Cisco 3550 we currently deploy in our network. Key features that I'm looking for are as follows: Hierarchical QOS Traffic shaping/policing L3VPN functionality(VRF-lite) BGP OSPF dot1q some sort of spanning tree Any help would be really appreciated, Jacky

3 3

RE: MLPPP over MPLS
by Peering 20 Feb '06

20 Feb '06

I've been told by Juniper that the MTU negotiation problem was fixed in the 7.x versions. We're upgrading soon, so I hope to find out for myself. Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Brent A O'Keeffe Sent: Monday, February 20, 2006 7:57 AM To: Jon Lewis Cc: Jon R. Kibler; nanog(a)merit.net Subject: Re: MLPPP over MPLS It may also be worth noting that if the provider is running Juniper and not Cisco, there are fragmentation issues with certain versions of Juniper code. The MLPPP session cannot agree on an MTU and usually stop somewhere around 100 bytes if they do. The workaround is to implement "ppp multilink fragment disable" on the Cisco Multilink interface. Brent Jon Lewis <jlewis(a)lewis.org> Sent by: owner-nanog(a)merit.edu 02/17/2006 03:38 PM To "Jon R. Kibler" <Jon.Kibler(a)aset.com> cc nanog(a)merit.net Subject Re: MLPPP over MPLS On Fri, 17 Feb 2006, Jon R. Kibler wrote: > We have a customer that is implementing an MPLS network that will have 2 > to 6 T1 feeds at some locations that will be using MLPPP for channel > bonding. This is a telco provided network that will be customer managed. It's not clear from your message, but I'm assuming the MLPPP will be from PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case, on the customer end, it's just a MLPPP, and on your end, it's an MLPPP with an "ip vrf forwarding foo" statement. It's probably more than the average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS config work). Anyone who actually uses IOS on a regular basis (as opposed to someone who crammed for an exam and knows squat) should have no trouble with it. > The customer is being told by their router vendor that an MLPPP/MPLS > network is 'too complex' to be managed by anyone except for the router > vendor's VARs or the telco. They indicated that it would be impossible > for the customer's router vendor certified network person to come up to > speed on MLPPP/MPLS configurations and manage such a network -- that it > takes years to adequately learn how to manage that type of network > configuration. I think someone may be confusing "providing MPLS service" with "buying MPLS service". A customer buying MPLS VPN service never sees any of the MPLS tags or messes with MPLS/tag-switching commands. There is no added complexity...or at least there doesn't need to be any. > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. Virus-free, because I say it is...and I run Pine on Linux :) ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

[operational update] Fast-Flux (fast IP changing hosts)
by Gadi Evron 19 Feb '06

19 Feb '06

[X-posted] I figure it's a good idea to update the ops community on a new term called Fast-Flux.. but for that you need a bit of background. There have been three *main* new phishing tricks used over the past year.. which will bring us to what interests us... POST information in the mail message ------------------------------------ That means that the user fills his or her data in the HTML email message itself, which then sends the information to a legit-looking site. The problem with that, is how do you convince an ISP that a real (compromised) site is indeed a phishing site, if there is no phishy-looking page there, but rather a script hiding somewhere? Trojan horses ------------- This is an increasing problem. People get infected with these bots, zombies or whatever else you'd like to call them and then start sending out the phishing spam, while alternating the IP address of the phishing server. Now.. Which brings us to... Fast-Flux --------- Fast Flux is a term coined in the anti spam world to describe such Trojan horses' activity. The DNS RR leading to the phishing server keeps changing, with a new IP address (or 10) every 10 minutes to a day. Trying to keep up and eliminate these sites before they move again is frustrating and problematic, making the bottle-neck the DNS RR which needs to be nuked. At times this is even on the domain level itself, making termination/suspension of the domain critical. This has been seen before, but before this past year mostly in POC's. This is mostly known is closed communities, and needs some public light. A lot more data and test cases out there, but I figure this is enough for now.. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

1 0

NANOG36-NOTES 2006.02.14 Tools BOF Notes
by Matthew Petach 18 Feb '06

18 Feb '06

Last notes of the day... Matt 2006.02.14 Tools BOF Todd Underwood, panel moderator A number of interesting tools presented earlier today; all of them are good and interesting and solve a particular set of problems. None are in widespread use. There's a lot of possible reasons; do they solve problems you don't have, in which case they can move onto something new; or they solve a problem similar to one you have, but not quite. Or they solve a problem you can't quite implement yet. Discuss use cases, problems they're trying to solve, and give feedback, as interactively as comfortably as people can. 3 tools, OpenBGPD, IRR powertools/webtools (to get feedback and is the IRR even useful anymore?) and Flamingo as one of 2 netflow platforms. Start with Henning, active in open source software development; he'll go in more depth on openbgpd. OpenBGPD Henning Brauer henning at openbsd.org 3 process design Principle of least privilege the RDE (route decision engine) does not need any special priv at all, so it runs as __bgpd:__bgpd: chrooted to /var/empty SE needs to bind to TCP/179 parent needs to modify kernel routing table. Session Engine (SE) needs to bind to 179/tcp we have the parent open sockets see recvmsg(2) parent needsd to keep track of which fds the SE has open, so it doesn't bind() again to same ip/port the SE can drop all privs, then. SE 2 since one process handles all bgpd, need nonblocking sockets. on blocking, you call write(2), won't reurn until it's done or get errors on nonblocking, returns as soon as it can't proceed immediately So, have to handle buffer managmeent SE 3 designed an easy to use buffer API and mesg handling system. Messaging internal messaging is core comp. in reused for OpenNTPD, OPenOSPFD, and somee more. bgpd has more than 52 message types, more than OpenSSH bgpctl talks to bgpd using same imsg socket tcp md5 some very old code in kernel for tcp md5, from 4.4 BSD never worked tcp md5 is somewhat similar to ipsec, ah, so implement it within IPSec maze. Had to add pfkey interface to bgpd; committee designed API. that made IPSec that much easier; extended the API so they can request unused SPIs from kernel, don't have to be configured manually. tcp md5/ipsec when you don't have tcp md5 or ipsec in place, big tcp windows are risky stay at 16k window unless you have tcp md5 or ipsec, then you get 64K so ipsec improves performance. Joel Yagli asks how big a tcp window do you need for a BGP session at all? initial connection gets faster with 64K, but thereafter, similar. looking glass just added an optional second control socket that is restricted to the "show" operations regular bgpctl binary can be used with it cgi, yeah, that needs to be hacked in shape, but it's easy. Juniper only does static IPSec setup, so requires nasty setup. OpenBGPD is dynamic, but interoperates with Junipers. So back to looking glass, security on OpenBSD, the httpd (an apache 1.3 variant) runs in a chroot jail by default th readonly socket can be placed inside that jail bgpd_flags="-r /var/www/bgpd.rsock" in rc.conf.local put a statically linked bgpctl binary in the chroot /path/to/bgpctl -s /bgp.rsock, $ impressions from road to ipv6 most heinous checkin message yet. The lower 2 bytes of the scopeID overwrite part of the v6 address...ugly! Performance http://hasso.linux.ee/linux/openbgpd.php it's quick openBGPD 3.6 port for linux; can't communicate with kernel, no v6, no md5; 8 times faster than quagga. future plans and ideas the biggest task waits outside bgpd itself; kernel routing table. we need to make use of the radix mpath capabilities added in 2004, and add route source markers (BGP, OSPF, etc) bgpd and ospfd can blindly install their routes kernel then knows precedence hard to do, once it's done, routing will be easier. Also need multiple routing tables, with pf acting as table selector so unholy route-to can died, and associated issues vanish/ might be useful with bgpd as well. iddeas for quite radical changs, speed up packet forwarding dramatically. will have fast path where all easy cases can be handled on specialized PCI cards multiple 10GE at wire speed within 2 years. hardware exists, on way to him. for route servers, reversing filter and best path selection would be good. filter generation from RIPE DB or similar but IRR toolset sucks hairy moose balls should be solvable in perl "someone" has to code it. (maybe use IRR power tools for it instead!) [ we can fail over IP addresses already, thanks to CARP we can hve synchronized state tables on multiiple machines, gives HA firewall clusters. Would be really cool to be able to fail over TCP sessions and bgp sessions. could make for BGP hitless failover syncging BGP stuff shouldn't be too hard lots of work, not much time. Money has to come from somewhere, obviously. Unfortunately, people forget about this, just go to mirrors. Vendors don't help Never got anything for OpenSSH yet it comes down to you. yes YOU. buy our CDs, donate cash, tee-shirts, etc. or sponsor events, plane tickets, etc. Matt asks if they can be configured actively only, not binding on port 179. Currently, no. Can bind to loopbacks for the moment, or modify the code as appropriate. RAS asks if they support the lastest IETF draft for collision handling. They don't implement collision detection RFC-wise, no. And they're not active only, without passive. He also asks about comparing a RIB-in; that's been in the code for 2 weeks now, still has some bugs. Add support for passing more than one best path in case people are using this for a looking-glass. ie the VRF style hack for getting multiple views of the same route. Todd asks if they log dump output in MRT format. Short answer, yes. Many thanks to Henning! OK, over to RAS for IRR power tools. One leading question is whether the IRRs are even worthy of supporting, or are they a dead horse we've been flagellating for ten years? Todd kicks it off with question--you developed toolset because you think IRRs are a worthy effort to support, right? RAS notes that manual filters aren't a reasonable means to configure routers. Our current system is broken, something needs to change. Tool was written for internal use initially, Chris Morrow convinced him to release it for others. Not really meant as a plug for the IRRs, it's more "if you're going to use the IRRs Riverdomain, package base, if it can be a .rpm or .deb package, it would help; RAS doesn't do Linux, but others are welcome to package it up. When people go to implement this, they find a lot of cruft lurking around. Verio is the primary forcer right now for using IRRs; Level3 proxy objects are a great pain point. No motivation to remove old information out of the system. Larry Blunt with Merit; if you send email to them, they will remove old stale objects. It may take a little while, but it will get done. They're starting to check for inconsistencies so you can do bulk deletions of blocks that aren't being announced. Could they send out a monthly nag message, send that initially. They charge a yearly fee. When someone doesn't pay, companies will eventually be phased out. About 1600 maintainers, some are proactive about keeping them up to date, others are pretty minimal or are laggards. Website will show out-of-date info, but won't allow cleaning it up; next step is to allow them to clean it up via the web. They're looking to have a simple form vs complex form coming up, for those who don't have a complete understanding of BGP. Report section works across all registries. Could check to see if there's a less specific entry already with a different MAINT-ID. What about an INET-num to block any more specifics from the block from being registered. Challenge centers around the split between IP allocation and route registration. Peter Shoenmaker, works for Verio; many people mirror other databases, so there's compounded stale data. There are certain companies that have large blocks, and they'll register all the more specifics under it as well. Generating those filter lists gets ugly. RAS notes his tool auto-aggregates to least specific block possible. Samantha Billington, ISC, current maintainers of the current IRR ToolSet; would love to re-do it if there were some backing behind it. Currently trying to develop peering tools to make keeping track of peerings more easily. Randy Bush, IIJ, peers at the SIX using a perl script to generate filter lists around peval; it's a decade later, and we're still hacking more tools on top of the same broken data. It's time to do something new; doing the same thing, and expecting different outcome is definition of insanity. He says let's just give up, and change. Todd asks about SBGP/SO-BGP; they haven't caught on, and perhaps never well. But in the meantime, Randy notes it will let you build filters that are at least rigorously verifiable. And it'll be a backend only change in the future to drop in for the IRR in the future. It'll be downhill, incremental work at that point. Randy doesn't think it makes sense to continue forward at all. Let's stop for a year and redo things on better course before another ten years goes past. Randy offers to show Todd his ass...the audience groans, and we return to a more serious note. This is quicksand, let's get out of the quicksand. it's just an issue of going in the wrong direction. If you don't mind doing work twice, OK; but if you do, then save your time and energy, and let's focus on a PKI system. So, let's do PKI now, and we add this into the tools to jump start the process. You get a list of signed objects, you traverse the list of signed attestations that you recieve, you verify up the chain to IANA, and verify that the chain is intact. For Addresses and ASes, IANA is the root. For the identities of the ISPs and RIRs, may not be a single root. IRRs aren't secure enough to use for the database system. It's not transport free? LDAP would very likely be the storage/retrieval system. Let's start coding it; 2585 for queries, it's over HTTP, lets you talk to PKI certificate abstraction. Need to cover changes to certs needed to cover address space and ASNs. Can 2585 cover certificte modification, though? Needs Andy Putnams, Intelliden, config challenge will exist regardless of the pki; how do you ensure that you don't have multiple, overlapping entries? RAS notes that if we could handle PKI inside the IRRR, it would jumpstart the data. Chris asks why we can't start doing verifications with the existing infrastructure? Randy's not saying throw away the existing infrastructure; just pause on chasing it down, and change direction for the future. RPSL is a huge overkill, 90% of it isn't used at all, would we want to put PKI in there? Sandy Murphy, Sparta. Could we use the PKI to prevent people from adding or removing routes that we don't want touched? Could the people RUNNING the IRR check before you stick it in; then we also check on the way out. RFC 2725--her name is on it, but it's really Curtis Villamizer's proposal, but it does allow for the web of trust between systems to start with. Now onto Flamingo; Manish will walk through a live demo off his netflow data. flamingo.merit.edu:4444 it's more for security than traffic engineering; for those of us doing traffic engineering, though might still be of some use. Gives a large overview when we start it up, use the minimum threshold to filter out background noise. Traffic volume based on source AS view is of somewhat interesting. Ooops, neighbor AS, actually. (or origin, depending on your router setting) quad tree works same for AS number, just 16 bit number, not 32 bit archive. collector is based off flow tools, uses similar file format. Can pause updates so you don't loose current data you're about to zoom in on, for example. last view is combined source, dest, port, etc. everything sampled by netflow all in one window. sliders are a little crude, would be nice to have text entry boxes as well as slider bars. You can also list specific networks you care about that you want to see data for. So you can see traffic sourced from a given subnet. Every bar will then be a /32 hostname, will show traffic volumes for each; can shift zoom to limit what is on the display. Can do same visualizations of darknet space. They generate darkspace network off an unnumbered interface, and generating flow data from what is seen on the scatterback. Lots of scans from lots of people. Last 10 seconds or last 2 seconds, very dynamic. so the vertical here is walking across ports. single source port hitting lots of destination ports. Can also playback feeds from netflow collector format, etc. The platform is displaying pretty well at about 5k records/second, but scaling up for for a large content provider would be tough. Most of the code is written in-house, on Linux; may port to other platforms later. Running on a 3.6ghz p4 right now, nice graphics card, 256MB nvidia graphics card, no other real specs right now. Heavy dependencies on openGL, so no licensing for that. Software tool is largely GPL free. Availability is an issue right now. In trials, happy to do more trials, that's where they'll leave it for now. Manpower issues, no QA, no support, so not sure if they can really release it to the public yet. Are there additional visualizations that might help? On the ops side, which of these ways of looking at this would help the poor folks who run NOCs? What about saving profiles the NOC can compare against to recognize quickly "bad things". Mike Hughes (I think) says it's not really a first-alert type tool, it's for a second or third level escalation tool; too hard to interpret for a front line NOC person. They find it most useful for playback, rather than realtime 'spot the attack'. Chris--scaling for netflow is always a challenge. He has 9 routers reporting 50,000 flows/second; he has 300 others to add. So the scaling part is a challenge. The SOC might find it useful. It can use pre-existing netflow/flowtool archive files, server can play those back. Chris Morrow would just like to see some rough stats on what it could support. Mike Hughes, runs layer 2 environment, could it be sFlow and layer 2 aware. Walt Prue asks if he could point at a line to see info about it. On the feature list.

2 1

Exchange Points
by sjk 18 Feb '06

18 Feb '06

We're a small facilities based ISP in Chicago and I am looking for a public exchange point for peering. I have been told, by someone at SBC, that the public NAP here is no longer accepting connections and is essentially going to shut down over time. Has anyone else heard this? Are there other exchange options - other then to haul transport to multiple net operators? Thanks -- Steve

3 2

Disaster recovery using as-prepend?
by Christopher J. Pilkington 18 Feb '06

18 Feb '06

My apologies if this question doesn't belong here. We have a PI /24 we'd like to advertise out of our primary data center for production use. (Well, actually, we'll be advertising a more specific from our /21 assignment, so already not too friendly... but I digress.) We have a disaster recovery site which will have a clone of the myriad production servers. We'd like to fail over to that site automagically. I'm thinking advertising the same prefix and just doing several as-prepends. However, now I'm not sure if this is a polite thing to do or not. Someone mentioned to me something with MEDs, but as soon as that term was used, I started twitching, and couldn't follow the conversation. Would a "good netizen" use the as-prepend method? Or am I missing a simpler/more polite solution? -Christopher

7 10