Broker Dealer Cyber-Extortion Plot

Discussion in 'Wall St. News' started by InfoTech, Jul 1, 2015.

  1. InfoTech

    InfoTech

    https://www.finra.org/industry/information-notice-061915

    "In these incidents, DD4BC first sends the firm an email announcing that the firm will be a target for a DDoS attack, but that the firm can avoid the attack by paying a ransom in Bitcoin. DD4BC conducts a short “demonstration” attack, typically lasting about one hour, with the threat of further attacks if the ransom is not paid. DD4BC requests payment within 24 hours to prevent further attacks."
     
  2. One solution that so far not too many thought of (and which I have never seen in operation) is the idea of the server to switch to a different IP address and prior to the switch to communicate the switch internally to all legitimately connected applications. This at least allows for continuous connectivity to already connected clients. Newly (legitimate) connecting clients during the attack will also be diverted to the IP which is not under attack.

    Another, even better way would be to provide a gateway on the client side, similar to what IB is doing. It would allow for the ability for the server to allocate non public IPs and supply the gateway with such information (invisible to the user). As soon as the gateway finds problems to connect to its main IP it will make the switch to another IP and stick with that secondary IP as soon as a successful connection is made. Downside is added latency.

     
  3. @volpunter With these types of attacks pointing a DNS record to a different IP won't really solve the issue during an ongoing attack. The attackers will see the change right away and will redirect their DDOS packets to the new IP as well. The problem with these types of attacks is that most ISPs don't have large pipes to the internet, so if an attacker such as DD4BC starts flooding network's edge routers with 400-500Gbps of traffic, and ISP only has 10-15Gbps of pipes, then the whole datacenter will go dark for that ISP, not just the hosted target. The type of traffic DD4BC sends to the target is based on a low-level UDP protocol which has to be delivered to the edge router and looked at by the router, before the software on the router decides whether the packet should be let in or not. No matter how smart the software is in filtering packets on the router, it really does not matter because the packet has to get to the router before it can be rejected. So an attack with 400Gbps of traffic going into a 15Gbps datacenter will with a 100% certainty take that datacenter out.

    The only way to stop or avoid an attack like this, would be to hide behind someone who has even more bandwidth than the attacker, and let that entity deal with filtering packets, while only passing valid packets to the target site. In this scenario, the target site completely hides all of their public IP addresses, and changes their public DNS domains to point to that entity. In turn, the entity then accepts all traffic for that site, and redirects valid traffic to private non-published IP addresses for the target site. To an attacker or anyone coming to the target site, the target site is completely anonymous at that point. It's pretty hard to figure out where the target resides. So an attacker typically just moves on to softer targets because there is really no point in attacking a larger entity that can take entire traffic load and render it useless. There are a number of companies that offer these services now, incapsula.com, cloudflare.com, prolexic.com, etc. Major brokers and banks have already been hit with these in the last couple of months and were forced to hide their public IPs in their datacenters. Just try to do a traceroute to some of them.
     
  4. You did not read my second part of the post. A gateway will solve those problems. An ip under attack will just be shut down for the time being and the gateway will connect to another ip, possibly on a completely different network or via a different isp. That alternate ip is not known to the attacker. What I propose is basically a software solution of the hardware version you proposed. But the advantage is lower cost and much more flexibility. Downside is that saving state must be religiously adhered to else a switch would not work.

    Throwing bigger hardware into the game will never solve the problem in the long term on the other hand.

     
    Last edited: Jul 3, 2015