EOS의 DDoS 현실적 이슈

지금까지는 개괄적인 이슈를 살펴 보았다면, 이번부터는 EOS에서 실제로 블록 생성자들이 행하는 노력과 그에 대한 문제점들을 살펴보고자 합니다.

1. Block Producer(BP) 네트워크의 위험성

첫 번째 위험 요소로서 고민되는 문제는 BP들 간에 WireGuard를 이용해 VPN 네트워크를 구축하려는 경향이 있다는 것입니다.

WireGuard는 다양함 암호화 프로토콜을 이용하고, 설치와 운영이 용이하며, 속도 면에서도 좋은 성능을 보이는, 매우 유용한 VPN 서비스임에는 틀림없습니다.
하지만 WireGuard는 UDP 프로토콜을 이용하는 VPN 서비스로 UDP 특성 상 신뢰하지 않는 네트워크에 접속 포트를 열어두지 않는다고 하더라도 DDoS 공격이나, 네트워크에 대한 대역폭 소모 공격까지 차단할 수 는 없다는 문제점이 있습니다.

역사상 가장 큰 규모의 DDoS 공격들 (2016년 Dyn 1.2Tbps, 2018년 Github 1.3Tbps) 등은 모두 UDP 증폭 공격 이었습니다. 즉, UDP 프로토콜이 아닌 TCP 프로토콜을 사용하는 서비스로 보안을 구축하는 방안이 필요할 것으로 생각됩니다.

2. 인프라 계획의 문제점

BP 인프라 구성에서의 가장 근본적인 문제는, BP간의 통신은 안전할 것이며 정보가 잘 숨겨질 것이라는 전제를 깔고 있다는 것입니다.

즉, BP의 노드 정보를 BP간에 은밀하게 공유하고 있으니 외부로는 노드의 위치가 노출되지 않을 것이므로, DDoS 공격이 가능하지 않을 것이라 생각한다는 것입니다.
하지만, BP의 노드 리스트 정보는 해킹 혹은 사람의 실수로 인해 유출될 수 있다는 가정 하에 인프라가 설계되어야 하는게 맞다고 생각합니다.

즉, 누구든 어떠한 방식으로든 노드의 위치가 노출 되었을 때를 전제로 해야 한다는 것입니다.

3. 발표된 구조가 보호하고자 하는 대상

실제로 지금까지 발표되었던 구조는, DDoS로부터 dApp등의 서비스를 보호하기 위한 구조라기 보다는 Block Producer Node를 지키기 위한 구조라는 점 입니다.

DDoS가 예측되는 구간(Public Full Node)를 분산화 시킨 후 유사시 BP 노드로 들어오는 트래픽을 차단함으로 써 BP 인프라를 보호하는 인프라 설계는 오직 BP 들이 자격을 잃지 않기 위해 블록 생산만을 유지하는 소극적 방어로 보이며, 실제 그 위에서 다른 프로세스를 돌리는 사람들은 보호받지 못합니다.

즉, 건물주가 어떤 공격을 받았을 때 건물 에서 사업하는 세입자는 그 공격을 다 받고 건물주만 벙커에 들어가 있는 상황을 상상하시면 됩니다.

BP가 사용자들도 보호하는 구조가 아닌, 자신들의 위치를 우선시 하여 보전하는 구조를 택한다는 것은 EOS 네트워크와 커뮤니티를 챙겨주기 보다 자신들의 BP 순위를 유지하는 행동이라고 생각됩니다.

현재와 같이 CPU와 Bandwidth 자원을 제공하는 수준이라면, dApp들은 일시적인 혹은 서비스의 일부에만 영향을 받을 수도 있겠지만, 향후 EOS storage 서비스와 같이 지속적이고 안정적인 리소스를 임대해야 하는 서비스에서는 dApp의 심각한 장애를 초래할 수 밖에 없을 것습니다.

EOS42의 보고서에서도 알 수 있듯이 50 Gbps 수준의 공격만으로도 서비스에 영향을 미쳤습니다.

구글 로드발란서로 어느 정도의 방어를 할 수 있었다고는 하지만 DDoS 공격의 선례에서 알 수 있듯이 1Tbps 이상의 공격이 빈번하게 일어나고 있습니다.
방어용 인프라를 위한 비용이 BP로서의 이익에 대비해 과해서는 안되기에, 가성비가 좋은 솔루션이 필요한 것은 자명합니다. “제 Full 노드가 다운이 되면 다른 BP들의 Full 노드를 쓰면 됩니다. 저는 Block만 꾸준히 생산하면 BP의 자격은 유지할 수 있다”와 같은 안일한 사고는 EOS 생태계 전체를 위험에 빠트릴 수 있다고 생각됩니다.

4. DNS 서비스

DDoS 공격 상태에서의 DNS의 특징을 보면 다음과 같습니다.

공격자가 도메인(주소)에 대해 공격 명령을 내리면 봇은 해당 도메인에 대해 DNS Query를 통해 해당 서버의 IP 주소를 확인하고 DDoS 공격을 진행하게 됩다.

이 때 방어자 입장에서는 서버의 IP를 변경하게 되면 공격을 피할 수 있게 됩니다.

하지만, 이 때 사용자에게 서비스를 제공하기 위해서 DNS 정보를 갱신하게 되는데 만약 DNS의 TTL (Time to live) 설정이 길게 설정되어 있을 경우 DNS 정보 갱신 기간이 길어져 해당 시간 동안은 장애를 피할 수 없습니다.

만약 TTL 설정이 짧게 설정 되어있다면, 정보 갱신 시간이 짧기에 IP 변경에 따른 장애는 피할 수 있지만, 이 경우엔 공격자가 DNS 서버를 공격하여 DNS 서버에 장애가 발생시킬 수 있고, 사용자들은 DNS 정보를 얻을 수 없어 서비스에 장애가 발생할 것입니다. 심지어, IP 정보를 모두 변경하였다 하여도, 공격자는 DNS 재질의를 통해 변경된 주소를 쫓아와서 공격하는 악순환이 반복될 수도 있습니다. (그냥 집이 자꾸 이사를 해도 쫓아와서 공격하는 행위를 하는 겁니다.)

저희가 이 부분이 문제라고 생각하는 이유는 BP들이 DNS를 사용하여 통신을 하기 때문입니다. 이전 Dyn사의 공격으로 모든 서비스가 단절된 사례를 들기도 했습니다. 결코 DNS는 DDoS 방어 측면에서 좋은 통신 방식은 아닙니다.

5. 노드 분산 시 고려 사항

노드를 분산시켜 Single Point of Failure(단일 실패점) 를 회피하려는 움직임은 항상 옳습니다.

하지만 분산 노드 그중 핵심 노드의 안전성이 가장 먼저 고려 되어야 합니다.
최근 HKEOS에서 발표한 부탄에 슈퍼 노드를 세우겠다는 발표는 이러한 점에서 문제점이 있습니다.

먼저 부탄의 인터넷 인프라 상황을 살펴보아야 합니다.
2017년 기준으로, 부탄의 해외망 인프라는 10G에 불과한걸로 알려졌습니다. 현재 10G급 회선을 추가하려고 했지만 주변국과의 이해관계 때문에 협상이 지지부진한 것으로 알려져 있습니다. 만약 연내 해당 협상이 완료되어 회선이 공급된다고 해도 10G 급 2회선으로는 앞서 언급한 거대한 규모의 DDoS를 버텨낼수가 없습니다.

앞서 발생한 공격들이 해당 노드에 발생한다면 단지 해당 노드의 문제가 아니라 부탄 국가 전체의 인터넷 인프라에 피해를 줄 것입니다. 아무리 그래도 국가 전체 인터넷이 다운될 정도의 공격이 가능한가?에 대한 의문이 들 수 있습니다.

이미 각각 2007년 에스토니아, 2016년 라이베리아에 발생한 DDoS 사태로 인해 해당 나라들은 인터넷에서 사라진 경험이 있습니다.

노드의 분산도 중요하지만, 분산된 인프라가 얼마나 안전하고 확장성 있는 인프라 환경위에 놓였는지도 중요한 고려 사항이란 걸 잊어서는 안될 것 입니다.

6. NodEOS의 이슈

현재 EOS 노드 실행 데몬인 nodEOS의 설정은 config.ini 또는 실행 시 옵션을 통해 노드의 구성이나 기능 들을 설정 할 수 있습니다.

하지만 nodEOS는 daemonize 옵션이 없습니다.

물론 여러가지 방법으로 백그라운드 실행은 할 수 있지만 daemonize 옵션이 없다는 건 운영에 큰 불편함이 될 것 같습니다.

만약 nodEOS의 설정이나 다른 노드들의 주소(p2p address)등이 바뀌게 된다면 nodEOS를 강제로 종료한 후 다시 실행해야 됩니다. 장애가 발생하거나 또는 공격 상황에서 nodEOS 를 다 종료한 후 다시 실행하는 구조는 서비스를 안정적으로 공급하기에 좋은 구조가 아닙니다.

또한 설정에 대한 검증 또한 노드를 실행하는 사용자(주로 BP가 되겠지만)에게 의존할 수 밖에 없습니다.

지금까지 EOS의 네트워크 구조의 취약점에 대해 살펴 보았습니다.
다음 번에는 저희 OWDIN 이 구축하고자 하는 방향에 대해서 조금 더 풀어보겠습니다.
감사합니다.