- NANOG - lists.nanog.org

Arbor Networks
by c johnson 29 Jan '03

29 Jan '03

Has anyone had experiences with Arbor Networks Peakflow DOS and Traffic products? If so could you share your experiences, whitepapers, evaluations, etc. off list? I am interested in the generalized view of the effectiveness of the product as well as any enhancement requests that operators may have for either product. Thanks _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Re: What could have been done differently?
by Michael.Dillon＠radianz.com 29 Jan '03

29 Jan '03

> His main thesis was basically that every > OS in common use today, from Windows to UNIX variants, has a fundamental > flaw in the way privileges and permissions are handled - the concept of > superuser/administrator. He argued instead that OSes should be redesigned to > implement the principle of least privilege from the ground up, down to the > architecture they run on. OpenSSH's PrivSep (now making its way into other > daemons in the OpenBSD tree) is a step in the right direction. Capability-based systems like EROS-OS are a way of addressing this issue. Have a look at http://www.eros-os.org/ If you only read one article then pick this summary from IEEE Software magazine http://www.eros-os.org/papers/IEEE-Software-Jan-2002.pdf The slammer worm made its way into some very unexpected places. It seems that in many organizations, once the UDP packet made its way to one MS-SQL server through one hole, it then acquired all the privileges of the IP address that supposedly belonged to a database server. Since traffic from the database server was considered to be trustworthy, it was able to easily reach and infect many more internal MS-SQL servers that were on internal networks unconnected to the Internet. In other words, there were MS-SQL servers acting as Application Layer Gateways to transport the worm into protected networks. The random nature of the addresses chosen by the worm virtually guaranteed that every single network path in the world containing MS-SQL servers would be infected. --Michael Dillon

1 0

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 29 Jan '03

29 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 29 Jan '03

29 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