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
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.
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 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
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