DDOS mitigation for EOS Block producers.

Other Language Versions below:

The following article is to provide some guidance on how we as block producers can protect ourselves from DDOS attacks. We also test the DDOS offerings from some cloud providers and provide the results.

As we test further DDOS mitigation services we will also published the results.

For the testing the following services were used

  • 1 x Block Producer node with incoming ports 8888, 9876.
  • DDOS attacks were performed using a SSDP attack against port 1234.
  • A DDOS simulator - no further information provided.

The reason for sending the attacks to closed ports is to demonstrate that you do not need any ports open to be vulnerable to an attack. The SSDP attack happens on the network layer which means your firewall has to deal with all the packets.

Closed ports will not protect you against a DDOS attack


When you close a port from the internet, all traffic directed to that port has to be dropped by your firewall and each of those drops require a little bit of CPU time. Now imagine a scenario where your firewall is hit with a multitude of packets at a speed of 50Gbps, all originating from different IPs that want to access port 1234. Even with that port closed, your firewall will most likely not cope with that amount of traffic.

What is a SSDP DDOS attack.


SSDP stands for the Simple Service Discovery Protocol and is a network based protocol used for the discovery of network services, mostly enabled on internet facing Wifi routers, webcams and many other IOT devices.

SSDP allows devices to easily connect to other devices by utilising UPNP (universal plug and play) messages running over UDP port 1900. These days most of these off the shelve devices provide simple instructions for setup and once configured leave these UPNP ports wide open to the internet.

An SSDP attack sends requests from multiple machines to these IOT devices, requesting a UPNP discovery packet and since the IP packets are spoofed to show the victim's IP as the source address, all of the UPNP reply packets will be forwarded to the victim.

SSPD is an amplification attack. When you request UPNP from such a device, it returns all of the available services it has to offer. That single UPNP packet request turns into multiple reply packets all send back to the victims IP.
ssdp-amplification-ddos-attack
Image courtesey of https://www.corero.com/

1. Peforming a DDOS attack against a node running behind Azure DDOS service.


Description

This tests a node running behind the Azure standard DDOS proection, their highest level of protection available.

DDOS protection: Azure Standard (https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview)
Type of DDOS: SSPD at 50Gbps
Cloud Provider: Azure
Type of BP node: Cloud

As you can see from the below the IP address does not respond much during the attack.
azure_tcp

Azure DDOS metrics showing that at the height of the attack it received about 6.25 GB/s (50Gbp/s) and was only able to stop 5.18 GB/s (41.44 Gbp/s)
azure_ddos

Conclusion:

Azure performs some protection but it never stops the full attack and let's enough packets through that the attack ultimately brings down your IP address and any sevices running behind this.The node was not able to sync correctly.

Overall result: Failure

2. Peforming a DDOS attack against a node running behind Google cloud with their standard DDOS protection.


Description

This tests a node running behind the Google standard DDOS protection, their highest level of protection available.

DDOS protection: Google Cloud Standard.
Type of DDOS: SSPD at 50Gbps
Cloud Provider: Google
Type of BP node: Cloud

Please note this is not a test against Google Shield.

google_ddos

Conclusion:

Google performs some protection and fairs okay, but overall the node does not keep up with the blockchain. There is just too much latency and dropped packets for the node to sync properly.

Overall result: Failure

3. Peforming a DDOS attack against a node running behind AWS standard Shield DDOS protection.


Description

This tests a node running behind the AWS standard DDOS protection (included free of charge), their lowest level of protection available.

DDOS protection: AWS standard shield (https://aws.amazon.com/shield/tiers/)
Type of DDOS: SSPD at 50Gbps
Cloud Provider: AWS
Type of BP node: Cloud

aws_ddos

Conclusion:

AWS provides some protection and fairs okay, but overall the node still goes down and does not keep up with the blockchain. There is just too much latency and dropped packets for the node to sync properly.

Overall result: Failure

4. Peforming a DDOS attack against a node running behind the Google Load balancing service.

Description

This tests a Google network load balancer that is published to the outside worls using an external IP address, which load balanced traffic on TCP ports 8888 & 9876 to two EOS nodes running on internal IPs.

DDOS protection: Google Network Load Balancer
Type of DDOS: SSPD at 50Gbps
Cloud Provider: Google
Type of BP node: Cloud

Termius_-_supermon_eos42_io

Jungle3_EOS_Network_Monitor__CryptoLions_io_

Conclusion:

Google Load Balancer takes all the DDOS packets and has no effect on any incoming traffic. All nodes stay perfectly synced up to the network.

Overall result: Success

5. Peforming a DDOS attack against a node running behind AWS Load Balancer that is protected by standard Shield DDOS protection.


Description

This tests a node running behind the AWS Load Blancer, that includes AWS standard DDOS protection.

DDOS protection: AWS Load balancer + AWS standard shield (https://aws.amazon.com/shield/tiers/)
Type of DDOS: SSPD at 50Gbps
Cloud Provider: AWS
Type of BP node: Cloud

Test (1)
aws_lb

Test (2)
aws_lb2

Conclusion:

AWS tests were mixed. During the 1st attack, not enough of the attack was stopped for the node to stay synced. However after stopping the first attack and starting a second, it does at that point seem to provide protection.

It's almost as if AWS learns and then starts to stop the attack after a while.

The above tests were performed twice, 20 hours apart and the same results occured.

UPDATE

"Elastic Load Balancing scales your load balancer as traffic to your application changes over time. Elastic Load Balancing can scale to the vast majority of workloads automatically."

This is probably why at first it fails, but then it scales up to meet the additional demand.

AWS ELB does seem to work, but takes 4-5 minutes to scale up to the new demand.

Overall result: Reasonable.

6. Incapsula DDOS protection - coming soon...

DDOS mitigation.

Below are some guidelines on how you can protect yourself against a DDOS attack.

Monitor your nodes and have a failover plan.

The most reliable and cheapest method is to actively monitor your nodes and network so in the event of an attack you migrate your active Block producer keys to another node on a different IP and network.

Do not create DNS records.

Don't create DNS records for your Block Producers, it's fairly rudimentary to scan A records attached to a domain using brute force.
Change all your Block producer IPs from the ones you have used on the testnets, since an attacker might of collected these in advance.

Use Google Load balancing services.

For the cloud our current findings show that the Google Load Balancing Service provide sufficient DDOS protection.

Do not allow ingress connections to your BP from the internet.

By not allowing ingress connections, this your BP IP address hidden. For as long as an attacker does not know your IP address they cannot attack you.

For those on baremetal - purchase a TCP/UDP DDOS proxy protection service OR use Google Load Balancer.

Using these types of services you can forward all traffic back to your BP and configure your firewall to only accept traffic from the DDOS proxy IP.
Although your external IP is still exposed, it provides an additional layer of security since all incoming connections will be coming via DDOS proxy service.

Please note that none of the above are perfect solutions and that's because preventing DDOS attacks are very hard.

Some additional settings you can apply on your firewall.

Connection limiting: the number of new connection requests is limited, existing connections are preferred.
Age filtering: idle connections are removed from the IP tables in firewall.
Source rate filtering: when there are limited number of IP addresses involved in a DDoS attack, outer IP addresses that break the norm are identified.
Dynamic filtering: create a short-span filtering rule and remove that rule after that time-span.

The ultimate DDOS protection - BGP reroutes

If you are lucky enough to own a class C subnet and you have equipment that can handle BGP routing you can partner with a DDOS scrubbing service.

In this scenario when you encounter a DDOS attack you republish your BGP routes to send all traffic destined to your IP address via another third party, which removes (scrubbing) all DDOS packets and forwards only clean packets back to your network.

Unfortunately this is out of reach for most of us, becuase of the costs and also the requirement to have a internet facing class C subnet.

Overall Conclusion

I hope this helps shed some light on how we can all protect ourselves from DDOS attacks.

Also from now until the 2nd of June, EOS42 will be providing free DDOS testing. If you would like us to test your solution please contact me at charles@eos42.io OR reach me on telegram @ankh2054.

There is no commitment to share your results with the community, all tests will be performed confidentially.

Additional resources

Article by EOSnodeone about AWS DDOS protection.
https://steemit.com/eos/@eosnodeone/prevent-ddos-with-aws-network-load-balancer

Best Practices for DDoS Protection and Mitigation on Google Cloud Platform
https://cloud.google.com/files/GCPDDoSprotection-04122016.pdf

Korean



EOS 블록생성자를 위한 DDOS 공격 완화

이 글의 목적은 블록생성자가 DDOS 공격으로부터 EOS네트워크를 보호할 수 있는 방법에 대한 지침을 제공하는 것입니다. 또한 일부 클라우드 업체가 제공하는 DDOS protection 대한 테스트 결과를 제공합니다. 향후 지속적으로 DDOS 공격 완화를 위한 테스트와 결과를 공개하도록 하겠습니다.

테스트를 위해 다음과 같은 서비스가 사용되었습니다.
 Incoming Ports가 8888, 9876인 블록생산자 노드
 DDOS 공격은 포트 1234에 대한 SSPD 공격을 사용하여 수행하였습니다.
 DDOS 봇넷 – 추가정보는 제공되지 않습니다
폐쇄형 포트에게 공격을 보내는 이유는 포트를 열어 두지 않아도 공격에 취약함을 보여주기 위해서 입니다. SSDP 공격은 네트워크 계층에서 발생하기 때문에 당신의 방화벽이 모든 패킷을 처리할 수 있어야 함을 의미합니다.

폐쇄된 포트라도 당신을 DDOS공격으로부터 보호하지는 못합니다.
인터넷에서 포트를 닫을 때, 해당 포트로 향하는 모든 트래픽은 방화벽에 의해 제거되어야 하며, 각각을 제거할 때 약간의 CPU 타임이 필요하게 됩니다. 당신의 방화벽이 50Gbps의 속도로 포트 1234에 액세스하려는, 서로 다른 IP의 다수의 패킷을 소화하는 시나리오를 상상해 봅시다. 포트가 닫혀 있더라도 방화벽은 트래픽 양에 거의 대처하지 못하게 될 것입니다.

SSDP DDOS 공격이란 무엇입니까?

SSDP는 Simple Service Discovery Protocol의 약자이며 네트워크 서비스 발견을 위해 사용되는 네트워크 기반 프로토콜입니다. 주로 인터넷에 연결된 Wifi 라우터, 웹캠, 그리고 많은 기타 IOT 장치에 사용될 수 있습니다. SSDP는 UDP포트 1900 에 실행되는 UPNP (범용 플러그 앤 플레이) 메시지를 사용하여 장치들을 다른 장치들에 쉽게 연결할 수 있게 합니다. 최근의 대부분의 IOT 장치들은 초기 세팅 시 간략한 설명만을 제공하고, 한번 구성되면 이러한 UPNP 포트를 인터넷에 대부분 공개 시킵니다.
SSDP 공격은 UPNP 검색 패킷을 요청하여, 여러 기기 들로부터 이러한 IOT 장치들을 공격하게 합니다. 이는 IP 패킷이 스푸핑*(Spoofing: 이 공격은 한 사람이나 프로그램이 데이터를 위조하여 다른 사람이나 프로그램이 다른 사람으로 성공적으로 위장하여 불법적인 이점을 얻는 상황입니다) 되어 피해 IP를 원천 주소로 표시하므로, 모든 UPNP 응답 패킷이 피해 IP에게 전송 되어버리는 상황입니다.
SSPD는 증폭 공격입니다. 이러한 장치에서 당신이 UPNP를 한가지 기기에 요청하면, 이는 그 기기가 제공가능한 모든 서비스들로 바뀌어 실행됩니다. 단일 UPNP 패킷 요청이 다중 응답 패킷들로 바뀌어, 이것들이 모두 피해자 IP로 다시 전송되 버리는 것입니다.

Image courtesey of https://www.corero.com/

<각 시나리오 별 DDOS 공격 테스트 수행>

1. Azure DDOS 보호 서비스를 실행 후, 노드 생성에 대한 DDOS 공격을 수행


설명: 이 테스트는 Azure 표준 DDOS 보호 중, 최고 수준의 보호기능을 사용한 테스트입니다. **DDOS protection:** Azure Standard (https://docs.microsoft.com/en-us/azure/virtual-network/ddos-protection-overview) **Type of DDOS:** SSPD at 50Gbps **Cloud Provider:** Azure **Type of BP node:** Cloud

아래 결과에서 볼 수 있듯이, IP주소가 공격하는 동안 많이 응답하지 못합니다.

Azure DDOS 매트릭은 6.25 GB/s (50Gbp/s) 의 공격수준에서 5.18 GB/s (41.44 Gbp/s) 수준 밖에 방어할 수 없음을 보여줍니다.

결론: Azure는 일부 보호기능을 수행하지만 완전한 공격을 막을 수는 없었으며, 당신의 IP 주소와 이를 통해 실행되는 서비스들을 차단할 만한 충분한 패킷들을 통과 시켰습니다. 노드가 올바르게 동기화 될 수 없었습니다.
전체 결과: 실패

2. Google 클라우드의 표준 DDOS 보호 실행 후 DDOS 공격을 수행

설명: 이 테스트는 Azure 표준 DDOS 보호 중, 최고 수준의 보호기능을 사용한후 노드 생성에 대한 공격을 시행하였습니다.

DDOS protection: Google Cloud Standard.
Type of DDOS: SSPD at 50Gbps
Cloud Provider: Google
Type of BP node: Cloud
*이 테스트는 Google Shield 를 사용한 테스트가 아닙니다.

결론: Google클라우드는 일부 보호는 수행하였지만, 전체적으로는 노드가 블록 체인을 제대로 유지하지 못하였습니다. 지연이 너무 많았고 패킷들을 드롭 시켜서 노드를 제대로 동기화 하지 못하였습니다.
전체 결과: 실패

3. AWS 표준 Shield DDOS 보호 실행후 노드 생성에 대한 DDOS 공격을 수행 (최저수준의 보호기능 실행)


DDOS protection: AWS standard shield (https://aws.amazon.com/shield/tiers/)
Type of DDOS: SSPD at 50Gbps
Cloud Provider: AWS
Type of BP node: Cloud

결론: AWS는 어느 정도의 보호는 제공하였지만, 전체적으로 노드가 여전히 다운되어 블록체인을 유지할 수 없었습니다. 마찬가지로, 지연이 너무 많았고 패킷들을 드롭 시켜서 노드를 제대로 동기화 하지 못하였습니다.
전체 결과: 실패

4. Google Load balancing service 를 실행후 노드생성에 대한 DDOS 공격을 수행


설명: 이 테스트는 TCP포트 8888과 9876위 트래픽을 내부 IP들 위에서 실행되는 두개의 EOS 노드에게 부하 분산시킵니다.

DDOS protection: Google Network Load Balancer
Type of DDOS: SSPD at 50Gbps
Cloud Provider: Google
Type of BP node: Cloud

결론: Google Load Balancer는 모든 DDoS 패킷을 수용하였으며, 수신 트래픽에는 영향을 미치지 않습니다. 모든 노드가 완벽하게 네트워크에 동기화되었습니다.
전체결과: 성공

5. Incapsula DDOS 보호 – 곧 제공될 예정입니다.

<DDOS 공격 완화 전략>

다음은 DDoS 공격으로부터 자신을 보호 할 수 있는 방법에 대한 몇 가지 지침입니다.
노드를 모니터하고 장애 조치 계획을 세우십시오.
가장 신뢰할 수 있고 가장 저렴한 방법은 노드와 네트워크를 적극적으로 모니터링하여 공격이 발생할 경우, 활성 블록생성자 키를 다른 IP 및 네트워크의 다른 노드로 마이그레이션하는 것입니다.

DNS 기록을 만들지 마십시오.

블록생성자의 DNS 기록을 생성하지 마십시오. 무차별 대입을 사용하여 도메인에 연결된 A 기록을 스캔하는 것은 매우 기초적입니다. 공격자가 사전에 수집할 수 있기 때문에. 테스트 넷에서 사용한 모든 블록생성자 IP 들을 변경하시기 바랍니다.

Google Load Balancing Service 를 사용하십시오.

클라우드에 대한 EOS42의 현재 연구 결과에 따르면 Google Load Balancing Service 는 충분한 DDoS 보호를 제공합니다.

인터넷상에서 당신의 블록생성자에게 진입 연결을 허용하지 마십시오.
진입연결을 허용하지 않음으로써 블록생성자 IP 주소가 숨겨집니다. 공격자가 귀하의 IP 주소를 모르는 한 공격자는 귀하를 공격 할 수 없습니다.

베어 메탈 (baremetal) 장비의 경우 – TCP/ UDP DDOS 프록시 보호 서비스를 구입하거나 Google Load Balancer 를 사용하십시오.

이러한 유형의 서비스를 사용하면 모든 트래픽을 BP로 전달시키며, 방화벽이 DDOS 프록시 IP로부터의 트래픽 만 수락하도록 구성 할 수 있습니다. 당신의
외부 IP는 여전히 노출되어 있겠지만, 모든 들어오는 연결이 DDOS 프록시 서비스를 통해 들어오기 때문에 추가적인 레이어의 보완을 제공할 것입니다.

DDOS 공격 방지는 매우 어렵 기 때문에 위의 방법 중 어느 것도 완벽한 해결책은 아니라는 점에 유의하십시오

방화벽에 적용할 수 있는 몇가지 추가 설정

Connection limiting: 새로운 연결 요청의 수가 제한되고, 기존 연결이 선호됩니다.
Age filtering: idle 연결이IP 테이블에서 제거됩니다.
Source rate filtering: DDoS 공격과 관련된 IP 주소의 수가 제한적일 때, 표준치을 벗어나는 외부 IP 주소가 식별됩니다.
Dynamic filtering: 짧은 기간 필터링 규칙을 만들고 해당 기간 이후에 해당 규칙을 제거합니다.

궁극적 DDOS 보호 – BGP reroutes

당신이 클래스 C 서브넷을 소유 할 수 있고, BGP 라우팅을 처리 할 수 있는 장비가 있으면 DDOS scrubbing 서비스를 이용할 수 있을 것입니다..
이 시나리오에서 DDoS 공격이 발생하면 BGP 경로를 다시 게시하여 IP 주소로 향하는 모든 트래픽을 다른 Third Party를 통해 전송합니다. 그러면 모든 DDOS 패킷이 제거 (scrubbing) 되고 깨끗한 패킷 만 네트워크로 다시 전달됩니다.
불행히도 현재 이는 비용과 인터넷에 클래스 C 서브넷을 사용할 수 있는 자격요건 때문에, 우리 대부분의 범주를 벗어나 있습니다.

전반적인 결론
저는 이 글을 통해 EOS 블록생성자와 커뮤니티 모두가 DDOS 공격으로부터 자기자신을 보호하고 예방하는 대 도움이 되기를 바랍니다.
또한 지금부터 6월 2일까지 EOS42는 무료 DDOS 방어 테스트를 제공 할 것입니다. 당신의 노드 생성 환경을 테스트하기를 원한다면 charles@eos42.io로 이메일 또는 텔레그램 @ ankh2054 로 연락바랍니다.
모든 테스트의 결과는 기밀로 수행될 것입니다.
(기술적인 부분은 번역이 매끄럽지 못할 수 있습니다. 영어원문을 참고하시기 바랍니다.)