January 2003 - Test - lists.nanog.org

Aggregate traffic management
by Stanislav Rost 29 Jan '03

29 Jan '03

Dear NANOGers, I have a very hands-on question: Suppose I am a network operator for a decent-sized ISP, and I decide that I want to "divide" aggregate traffic flowing through a router toward some destination, in order to then send some of it through one route and the remainder through another route. Thus, I desire to enforce some traffic engineering decision. How would I be able to accomplish this "division"? What technologies (even if vendor-specific) would I use? I can think of some methods like prefix-matching classification and ECMP, but I am still not sure exactly how the latter works in practice (at the router level) and how one may set them up to achieve such load-sharing. Thank you for your expertise and lore, -- Stanislav Rost <stanrost(a)lcs.mit.edu> Laboratory for Computer Science, MIT

4 3

Re: Banc of America Article
by Steven M. Bellovin 28 Jan '03

28 Jan '03

In message <20030129040240.GA4103(a)ussenterprise.ufp.org>, Leo Bicknell writes: > > > >FWIW: > >http://www.washingtonpost.com/wp-dyn/articles/A57550-2003Jan28.html > >"About 13,000 Bank of America cash machines had to be shut down. The >bank's ATMs sent encrypted information through the Internet, and when >the data slowed to a crawl, it stymied transactions, according to a >source, who said customer financial information was never in danger of >being stolen." > OK. I -- and, I suspect, most other folks on this list -- have been predicting for years that the Internet would become *the* data network, good for all taks. Bank of America believed us. They learned that maybe we were a bit overoptimistic in our time frame.... --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

1 0

Re: What could have been done differently?
by David Lesher 28 Jan '03

28 Jan '03

> Somewhere in the equation, the sysadmin/enduser, whether Unix > or Windows, has to take some responsibility. Hence I loved this: http://www.nytimes.com/2003/01/28/technology/28SOFT.html Worm Hits Microsoft, Which Ignored Own Advice By JOHN SCHWARTZ Among the companies that found its computer system under attack by a rogue program was Microsoft, which has been preaching the gospel of secure computing. ..... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Re: Is it time to block all Microsoft protocols in the core?
by Steven M. Bellovin 28 Jan '03

28 Jan '03

In message <20030128222210.GA84278(a)pit.databus.com>, Barney Wolff writes: > >On Wed, Jan 29, 2003 at 03:50:34AM +0545, Joe Abley wrote: >> >> On Wednesday, Jan 29, 2003, at 01:25 Asia/Katmandu, Joe Abley wrote: >> >> >On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I >> >happen to have open right now) this is not the case, and has not been >> >for some time. I presume, perhaps na?vely, that other operating >> >systems have done something similar. >> >> This is not right. Guess I was typing "man" in the wrong xterms. >> >> FreeBSD (4.x, 5.x) listens to the network by default (and can be >> persuaded not to with a "-s" flag). NetBSD (1.6) does the same. > >You were right the first time, at least for FreeBSD. The "-s" flag >is applied by default - see /etc/defaults/rc.conf . Not quite as >idiot-proof as a compiled-in default, but way better than defaulting >to listening. The same is true of NetBSD 1.6; look in the same place. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)

2 1

wrt BofA ATM: is it ATM 'automated' or ATM 'async' ?
by Stewart, William C (Bill), SALES 28 Jan '03

28 Jan '03

Over the last N years, I've often been the (Asynchronous Transfer Mode) ATM specialist for the group I'm in, as well as occasionally doing network designs and proposals for banks. While some banks use ATM to connect the networks that support their ATMs, few if any come close to 1000 Asynchronous Transfer Mode connections, much less 13000, and I haven't seen any equipment from Cisco, Lucent, Nortel, or Newbridge that could dispense cash (though all of them made equipment that needed to burn lots of cash on occasion.) NCR once tried to get people to use their PCs are routers, but I don't think any of them had ATM interfaces, though they make automated teller machines as well as cash registers. I've been frustrated by this whole "Oh, no, the bank must have done something terribly wrong" discussion. Banks really _are_ careful about potential problems that could let people siphon off money wholesale, and this doesn't sound at all like that. I don't know their current network, but the most likely causes for some generic banks' problems with teller machines during an event like this are - Using internet VPNs to connect ATMs to their servers, either dedicated 56kbps, DSL, ISDN D channel, or maybe dialup, which got stomped on by ISP traffic loads, which doesn't require that they accept any of the UDP1434 packets, just that random machines send enough of them. Remember that ATMs are very low traffic devices, so if they're using internet connections, they're small, and the flooding picks random IP addresses which isn't size-dependent. - If there actually had been an Asynchronous Transport Mode problem here, it would have been something weird like the bank using an ATM pipe from a network provider (probably a telco) to deliver internet connections on one PVC and Teller Machine and Bank Branch traffic on some or many other PVCs, and getting stomped on by the traffic load. - Another variation on that theme is that some carriers carry their internet traffic on their ATM backbones along with customer frame and ATM traffic, so even if a bank's network was entirely frame relay or frame/ATM interworking, the carrier could have trunk congestion if all their internet users started bursting heavily. - Possibly they're using some teller machine network providers that deliver to them over an internet VPN as opposed to private line or frame, and that got flooded, but that's less likely. - It's possible that a bank that uses VPNs for their ATMs and also has a publicly-visible internet banking service might share the same internet access line and firewall, and be susceptible to flooding cause either by inbound traffic or (much much less likely) outbound traffic from infected servers, while still not affecting the VPNs. It's much more likely they'd be on separate internet pipes for security and reliability, but they might be doing something like separate firewalls for separate servers sharing a pair of access lines. Besides the normal security concerns, those two kinds of operations are usually run by different organizations in any large bank, and BofA is definitely large.

1 0

Anybody doing a "Code Green" for 1434?
by Stewart, William C (Bill), SALES 28 Jan '03

28 Jan '03

Back when the Code Red worm came out, somebody wrote a program that responded to Code Red probes by using the same hole to break into the infected server and disable it. Is anybody doing that with this worm? Or does it step on the infected process too hard for that to work? Even if people don't want to run it on the open internet, due to concerns about appropriateness of reverse hacking, it might be useful for inside-the-firewall cleanup for corporations that get hit. Thanks; Bill Stewart, billstewart at att dot com bill.stewart at pobox dot com

13 17

Re: OT: Re: WANAL (Re: What could have been done differently?)
by Paul Vixie 28 Jan '03

28 Jan '03

> What do you think of OpenBSD still installing BIND4 as part of the > default base system and recommended as secure by the OpenBSD FAQ ? > (See Section 6.8.3 in <http://www.openbsd.org/faq/faq6.html#DNS> ) i think that bind4 was relatively easy for them to do a format string audit on, and that bind9 was comparatively huge, and that their caution is justified based on bind4/bind8's record in CERT advisories, and that for feature level reasons they will move to bind9 as soon as they can complete a security audit on the code. (although in this case ISC and others have already completed such an audit, another pass never hurts.)

2 1

RE: Banc of America Article
by alex＠yuriev.com 28 Jan '03

28 Jan '03

> I'm familiar with some enforced financial institution requirements, no > where did I find transaction data of ATMs on a dedicated network to be > _required_. Is this a common industry practice, or a mandatory standard > I have not discovered? It is a common practice. Since the alarm line is permanently connected to some monitoring company which is supposed to make up its mind about ATM still being there should a nice gentleman with a truck decide to take the entire machine with him, it is very difficult to get that line used for something else. The other line is the data line, which, in my experience, tends to be POTS or ISDN (and sometimes DS0). Maybe I am not being clear on the terminology - dedicated in this case means "non-alarm" line. Wherever the connection terminates is going to depend on implementation. > How does this relate to the No Name standalone ATM which normally have > exposed POTS wires running to the wall? If you look carefully at those wires (without flipping out mini-mart owners) you are most likely to notice that it has either two visible POTS lines or one cable carrying two phone lines. Alex

1 0

wrt BofA ATM: is it ATM 'automated' or ATM 'async' ?
by Jeff.Hodges＠KingsMountain.com 28 Jan '03

28 Jan '03

good question. anyone know the answer? JeffH ------- Forwarded Message Date: Tue, 28 Jan 2003 02:29:17 -0500 Subject: [IP] is it ATM or ATM Internet Attack's Disruptions More Serious Than Many Thought Possible From: Dave Farber <dave(a)farber.net> To: ip <ip(a)v2.listbox.com> - ------ Forwarded Message From: David Devereaux-Weber <dave(a)cable.doit.wisc.edu> Date: Mon, 27 Jan 2003 23:52:19 -0600 To: dave(a)farber.net Subject: Re: [IP] Internet Attack's Disruptions More Serious Than Many Thought Possible One interesting aspect of the reporting for this event is related to the acronym ATM. The University of Wisconsin-Madison uses Asynchronous Transfer Mode (ATM) for backbone transport. We further use LAN Emulation (LANE) on the Asynchronous Transfer Mode backbone (LANE maps IP addresses to ATM Virtual Circuits and back to IP at the far end). The LANE BUS (Broadcast and Unknown Server) on the network was swamped due to the high volume of SQLSlammer hits on broadcast and unknown addresses, effectively denying legitimate traffic. This BUS saturation did not happen with the Code Red worm several months back. We spent several hours thinking our ATM problems were distinct from the SQLSlammer problems. My question is, has anyone seen source information about the Bank of America and Automated Teller Machines? Is it possible that Bank of America was reporting Asynchronous Transfer Mode (ATM) problems and not Automated Teller Machine (ATM) problems? Dave - -- David Devereaux-Weber, P.E. Network Services Division of Information Technology The University of Wisconsin - Madison dave(a)cable.doit.wisc.edu http://cable.doit.wisc.edu - ------ End of Forwarded Message - ------------------------------------- You are subscribed as Jeff.Hodges(a)stanford.edu To unsubscribe or update your address, click http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ------- End of Forwarded Message

2 1

Re: Level3 routing issues?
by Michael Lamoureux 28 Jan '03

28 Jan '03

"dave" == Dave Stewart <dbs(a)dbscom.com> writes: dave> I've seen various references to this worm firing off and dave> saturating networks worldwide within 1 minute... if *that* isn't dave> scary, I don't know what is. It shows that someone, with the dave> right tools and enough vulnerable servers can take out a good dave> portion of the Internet in seconds. And how can we predict dave> *every* possible issue and block it? Exactly!! This is why the Right Answer (TM) is to get end-users to secure their systems and networks so that an attacker can't get a critical mass of hosts in 1 minute (or even 1 month). You can only do so much on the ISP networks. At some point, everyone needs to admit that it's impossible for us to win this battle as long as people are allowed to not care about the security of their systems. I still remember the despair I felt at how successful the sadmind worm was with Solaris and Windows vulnerabilies that were over 2 years old. Hell, that was a long time ago, and I bet there are still systems on the Internet that have those vulnerabilies. I mean, that's negligence if anything is. dave> I think there's only so much one can do in advance. Sure, we dave> all know we shouldn't have these servers exposed, but again, dave> many are in the position of having to leave them open to some dave> extent - case in point, I have a developer who uses dialup dave> (because he's in the sticks in northern Georgia, and nothing dave> else is available, and he's a skinflint who uses the free or dave> nearly-free dialup providers)... he's also not going to use a dave> VPN... he'll just bitch because he can't get to the server. Note that in the case of a worm, a VPN could work against you. If you have all the right filters in place at your "perimeter" and yet let your employees in through a VPN solution of some sort, you could still be screwed if one of their home systems gets infected somehow. IMHO, Michael

10 24