Actually, I think too many assumptions were made. Let's simplify. We know UUNet traffic capabilities were reduced significantly. Uunet has many big customers. Other big carriers had similar affects on their networks, probably particularly at peering points. We know many companies use public or private VPN services from major carriers such as these, and that both VPN types may use public internet carriers. I think therefore that the only true conclusion we could say is that if BoA's traffic was not prioritized, it therefore suffered collateral damage primarily due to traffic not being able to get through between ATM's and the central processing center. Ray Burkholder
-----Original Message----- From: Alex Rubenstein [mailto:alex@nac.net] Sent: January 25, 2003 18:45 To: nanog@nanog.org Subject: Banc of America Article
http://biz.yahoo.com/rb/030125/tech_virus_boa_1.html
Let's make the assumption that the outage of ATM's that BoA suffered was caused by last nights 'SQL Slammer' virus.
The following things can then be assumed:
a) BoA's network has Microsoft SQL Servers on them.
b) BoA has not applied SP3 (available for a week) or the patch for this particular problem (SQL Slammer) (available for many months).
c) somehow, this attack spawned on the public internet made it's way to BoA's SQL servers, bypassing firewalls (did they have firewalls?).
Another article states, "Bank of America Corp., one of the nation's largest banks, said many customers could not withdraw money from its 13,000 ATM machines because of technical problems caused by the attack. A spokeswoman, Lisa Gagnon, said the bank restored service to nearly all ATMs by late Saturday afternoon and that customers' money and personal information had not been at risk."
Does anyone else, based upon the assumptions above, believe this statement to be patently incorrect (specifically, the part about 'personal information had not been at risk.') ?
I find these statement made by BoA, based upon assumptions which are probably correct, to be very scary.
Comments?
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
While they may have VPN's at many of their branches which offer significant savings over leased lines everywhere, their web site access to personal banking information was also offline. It would be worth grepping logs to see if there was indeed a SQL server from the inside that was infected.
While they may have VPN's at many of their branches which offer significant savings over leased lines everywhere, their web site access to personal banking information was also offline. It would be worth grepping logs to see if there was indeed a SQL server from the inside that was infected.
Using VPN for branches is very different from using VPN with ATMs. Alex
Let me summarize, then ask a question: a) BoA uses the public internet for ATM transactions. The public internet was so dead, that every one of thier ATM machines was dead for many hours, even many hours longer than the public internet was dead. b) BoA uses it's own network for it's on ATM transactions. Somewhere on the a public to private connection, a firewall wasn't doing it's job, or there wasn't a firewall. Things were broken for a while, until they were able to fix all thier SQL servers. I guess my point is, if it were a), not every ATM would be dead all the time, and things would have been fixed in only a little while. Not many internet 'backbones' (at least ones BoA would have used for this application) were down as long as BoA's ATM's were. On the other hand, I think it's more likely that BoA had unprotected SQL servers, and they got it. It took a long while for BoA IT people to make it out of bed saturday morning to fix the problem. I still clearly say that I don't know what happened, and I did make assumptions (as I said in the original mail) -- but I'd still place my money on b). On Sun, 26 Jan 2003, Ray Burkholder wrote:
Actually, I think too many assumptions were made.
Let's simplify.
We know UUNet traffic capabilities were reduced significantly. Uunet has many big customers. Other big carriers had similar affects on their networks, probably particularly at peering points.
We know many companies use public or private VPN services from major carriers such as these, and that both VPN types may use public internet carriers.
I think therefore that the only true conclusion we could say is that if BoA's traffic was not prioritized, it therefore suffered collateral damage primarily due to traffic not being able to get through between ATM's and the central processing center.
-- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben -- -- Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
From: "Alex Rubenstein"
On the other hand, I think it's more likely that BoA had unprotected SQL servers, and they got it. It took a long while for BoA IT people to make it out of bed saturday morning to fix the problem.
I still clearly say that I don't know what happened, and I did make assumptions (as I said in the original mail) -- but I'd still place my money on b).
I agree, yet there is inconclusive evidence as to whether the unprotected SQL servers were in their private network or their public network, nor what data was contained on them. Like many networks, they may have just killed out switches and routers that were shared between public and private. Jack Bates BrightNet Oklahoma -Will someone using <5000 for source ports? Makes safeguard filters impossible.
Actually, I think too many assumptions were made.
Let's simplify.
We know UUNet traffic capabilities were reduced significantly. Uunet has many big customers. Other big carriers had similar affects on their networks, probably particularly at peering points.
We know many companies use public or private VPN services from major carriers such as these, and that both VPN types may use public internet carriers.
I think therefore that the only true conclusion we could say is that if BoA's traffic was not prioritized, it therefore suffered collateral damage primarily due to traffic not being able to get through between ATM's and the central processing center.
Being someonewhat familiar with the design of ATM networks, I can tell you that it is not correct. Your basic ATM gets two to three connections - one being a data access line, the other being a regular alarm line. The data access line is POTS, DS0 or, ISDN. The alarm line is POTS (the funny part is that certain large banks when buying other banks forget what the other line is used for and put a disconnect order on those creating lots of mess). The transaction data is never supposed to travel on any non-dedicated network. Alex
participants (5)
-
Alex Rubenstein -
alex＠yuriev.com -
Jack Bates -
Mike Nice -
Ray Burkholder