The Whole Evocash/FLO Fiasco

Quote:

We have seen many posts in the last couple of days from people who say that Evocash has not been subject to a DDoS attack on their website. Normally we
would ignore these posts seeing that most of the nonsense that is posted is
coming directly from FLO themselves. We can assure you that we have been
subjected to one of the biggest DDoS attacks that we have ever seen, we do not
know where this originated from but if we were really pushed we think we would
probably only need one guess.

We don’t really want to waste too much time on this and thought it was best to
just answer one main post from someone called Eagle9.
No doubt there will be more posts after ours from the people that think they
know better but this is our one and only reply on the subject, we will not be
posting anything else regarding the attack on our website.

Post
The basis of the attack is to overload a victim\'s computer resources by
flooding them with traffic. This is done by commanding multiple compromised
systems to send high rates of traffic. In addition, the traffic is often
formulated in such a way that it consumes resources at abnormal rates.

Answer
More or less correct, but don't forget that every element near to our
servers also needs to be able to handle the load, not just the servers
themselves.

The servers would most probably handle a full gigabit/second of traffic
without problems although the real back end servers that handle the requests
would never see any of this attack traffic, it would be stopped beforehand by
our firewalls.

It is more accurate say that what are attacked are the ROUTES TO the
servers: the routers, firewalls and communications lines that make it possible
to get to our servers.

Post
So if the server's resources are being overloaded, then why do they respond
just fine when you attempt to go to the evocash website through the metropipe
tunnel? Do they also have connections in the twilight zone? If a server is
overloaded, it's overloaded.

Answer
Not so, the servers have never been overloaded but the routes to them.

If we can't just absorb a DDoS attack (which we do regularly with smaller
attacks) we first block all access at the highest level we can.

We start to selectively remove blocks at our border routers on a per-network
basis, keeping the size of the attack manageable and gradually allowing more
people from more networks to have access.

This means we block access from the AS numbers where the DDoS attack was mostly
heavily coming from. First you have to block everything, then slowly open access
up, making the blocking rules more complex and more specific.

Whilst this blocking is in place Evocash is accessible from some places and not
from others. Which is why some networks have been able to access (for example
Metropipe networks and large parts of Europe) and other networks have not (most
of Russia and large parts of the USA).

Post
I decided to see what the response was like through the tunnel so I did what is
called a trace route. It's a way of seeing what route a packet takes to a
destination. I did several trace routes originating from various places on the
planet including what is thought to be the domiciles of the evocash severs.

Answer
Sometimes a valid diagnosis but we generally route from servers and
front-end machines in various places to our real back-end servers, specifically
to help us mitigate attacks like these.

Post
I originated the traceroutes from Spain (Madrid), Dominica, and Singapore. In
each case the response time to evocash was extremely acceptable when using the
tunnel. The fact here is that I was able to reach the servers! So if evocash
was, in deed, under a \"heavy ddos attack\" as they proclaimed, I should have
not received a response from the servers or at the very least an extremely slow
response. But I didn\'t. Everything was just fine.

Answer
The servers are almost always fine. If you trace a route that is not under
attack you\'ll reach our servers with no problem at all. But the moment we
publish that route (point www.evocash.com over it) in our DNS, the attack
follows and floods the line. Some back-door routes are always available and
never published so we always maintain administrative control over Evocash.

Post
However, on the outside (without the use of metropipe), evocash could not be
reached when attempting trace routes to their servers.
What does this mean? It would appear that Evocash has blocked their Normal IP
addresses and only allowed the IP addresses that were coming from
metropipe.

Answer
Completely unintentional and nothing more than a coincidence. We didn\'t (and
can\'t completely) analyze exactly which places we blocked and which not. And I
assure you that the Metropipe IP addresses have not been specifically allowed or
denied. Having no connection with them, we don\'t even know what they all are.

Replies to other messages:

Post
Evo has removed the "A" records from DNS in an attempt to stop the
so-called \"DDOS\" attack. This will prevent client from resolving the IP
xxx.xxx.xxx.xxx to the name evocash.com.

Answer
Not true, we jut point it towards our best and biggest connection, implement
attack mitigation measures and weather the storm.

Post
They are also probably *attempting* to deny all traffic at the firewall, save
for the Metropipe tunneler

Answer
Not true, the attack was big enough to have to implement blocking on core
routers of large backbones and only by general direction of the attacks, not on
such a fine level as individual IP addresses.

Post
The EVO guys should have obviously invested in one of these:
Radware Defense Pro These units work wonders for the InfoSec Teams and networks
at Ebay.

Answer
Yeah sure, just need to buy about 20 of them and a gigabit of real internet
bandwidth to plug them into. Then have to increase Evocash fees by 1000
times to pay for it.