연례 보안 검토 중에 올해 초 우리 조직의 웹 서버에 대한 위협을 받은 사건이 생각났습니다. 그것은 조직 정책에 관한 것이며 우리 사이트에 DDoS를 위협했습니다. 다행히도 나쁜 일은 없었고 공허한 위협으로 판명되었습니다. 그러나 우리는 우리의 반응에 박수를 보낸 CIO, CSO, CEO 및 호스팅 제공업체에 즉시 통보했습니다. 우리 조직(교육 부문)의 특성상 선제적 대응에는 현지 법 집행 기관과의 협력을 포함해 많은 사람이 참여했습니다.
빈 위협에 대한 우리의 대응이 충분했음에도 불구하고 웹 앱에 대한 공격 계획이 얼마나 적은지 깨닫게 되었습니다. 현재 설정은 다음과 같습니다.
- 기업 방화벽 뒤에 있지 않은 Linode VPS(설명할 가치가 없는 긴 사연이 있습니다)
- 로컬 연결만 허용하는 동일한 서버의 PostgreSQL DB
- 현재 보안을 위해 모범 사례를 따르고 있는 Nginx 서버 [1]
- 인증서 인증으로 마이그레이션 중인 SSH 액세스
- 모든 최신 서버 설정이 있고 최신 버전의 코드 푸시 및 마이그레이션된 데이터베이스 설정만 필요한 백업 VPS(현재는 테스트 서버로 사용되지만 지리적 중복 옵션으로도 구상됨)
내 질문은 서버를 잠그고 DDoS로부터 보호하기 위해 취해야 할 다른 단계로 요약될 수 있을 것 같습니다. 우리는 사용하고 싶습니다Cloudflare 비즈니스DDoS 보호 기능이 있지만 항상 필요한 것은 아니며 한 달에 200달러는 조직에 약간 부담스러운 금액입니다. 나한테 이게 필요한 걸까? 임시 DDoS 보호를 허용하는 솔루션이 있습니까? 그렇지 않다면 공격 중/공격 후에 안정성을 유지하는 가장 좋은 방법은 무엇입니까? 마지막으로, 공격이 발생할 경우 법 집행 기관을 지원할 수 있도록 어떤 로깅을 구현해야 합니까?
답변1
서버를 잠그고 DDoS로부터 보호하려면 어떤 다른 조치를 취해야 합니까?
- 사용되지 않는 모든 포트와 프로토콜을 방화벽으로 차단하세요. 적용 가능하고 신뢰할 수 있는 IP로만 액세스를 제한하십시오.
- 적시에 모든 보안 패치 및 업데이트를 적용하십시오.
- 의심스러운 활동 급증에 대해 경고할 수 있는 네트워크 모니터 구현
한 달에 200달러는 조직에 있어서 약간 가파른 금액입니다. 나한테 이게 필요한 걸까?
아니요. 가치를 더해 필수품이 되기 전까지는 그럴 수 없습니다.
임시 DDoS 보호를 허용하는 솔루션이 있습니까?
예. DDoS 서비스 구현의 복잡성을 해결하는 데 상당한 양의 사전 시간 투자가 필요할 수 있습니다. http://www.blacklotus.net/protect/emergency-ddos-protection그러한 주문형 서비스 중 하나입니다.
그렇지 않다면 공격 중/공격 후에 안정성을 유지하는 가장 좋은 방법은 무엇입니까?
그냥 거기 앉아서 가져가세요. 이것이 DDoS의 본질입니다. IP에 대해 방화벽을 시도하고 차단할 수 있지만 공격이 실제로 분산되어 있다면...물총으로 산불을 진압하는 것과 같습니다.
마지막으로, 공격이 발생할 경우 법 집행 기관을 지원할 수 있도록 어떤 로깅을 구현해야 합니까?
들어오는 소스 IP, 타임스탬프 및 기타 관련 포렌식 데이터의 로그를 유지합니다. 예를 들어 웹 서버인 경우 사용자 에이전트, 요청된 리소스를 기록해 보세요. 초당 패킷, 초당 요청 수와 같은 트래픽 속도가 도움이 됩니다.
DDoS는 결국 수학적 분석으로 귀결됩니다. 누군가가 당신을 갈취하려고 한다면 그들은 당신이 이를 방지하기 위해 보호비를 지불하도록 강요할 만큼 당신의 사업을 방해할 수 있다고 장담하는 것입니다. 규모가 중요한 요소입니다. 소규모 운영자를 무너뜨리는 것이 더 쉽지만 비용을 덜 지불할 수 있습니다. 이메일 위협을 받은 경우 가장 좋은 조치는 이를 무시하는 것입니다. DDoS 공격을 시작하고 유지하려면 상당한 봇넷 리소스가 필요합니다. DDoS 공격이 스패머처럼 모든 사람을 노골적으로 공격할 수는 없습니다. 그들은 위협하기 쉬운 대상을 찾기 위해 대규모 피싱 공격을 하고 있을 가능성이 있습니다. DDoS 괴물의 특성상 정교한 패킷 필터링 방지 체계를 구축하거나 외부 서비스와 계약할 예산이 없으면 피해자는 상당히 무력합니다.
답변2
inetplumber의 답변은 훌륭합니다.
또 다른 옵션은 사용자에게 영향을 주지 않고 더 큰 공격을 처리할 수 있도록 앱을 확장하도록 구성하는 것입니다. 예를 들어, VPC 내부에서만 액세스할 수 있는 PostgreSQL 서버를 사용하여 Amazon AWS에 Virtual Private Cloud(VPC)를 설정할 수 있습니다. 여러 서버에 로드를 분산하도록 로드 밸런서 프런트 엔드를 설정할 수 있습니다.
그렇게 하면 사전 투자 없이 최대 100대(또는 그 이상)의 서버를 빠르게 확장할 수 있고 매우 빠르게(이미 구성한 경우) 확장할 수 있어 훨씬 더 어려운 목표가 될 수 있다는 장점이 있습니다. 실제로 공격을 받은 시간 동안에만 해당 서버에 대한 비용을 지불하면 됩니다. 공격을 받지 않은 경우 웹 서버 하나와 데이터베이스 서버 하나에 대해서만 비용을 지불하면 됩니다.
어려운 부분은 설정하는 것이며 확실히 현재 구성보다 다소 복잡합니다. 빠르게 확장하려면 더 많은 작업이 필요합니다. 하지만 계획을 세우기 위해 할 수 있는 일을 찾고 있다면(특히 다른 문제로 인해 미래의 표적이 될 수 있다고 생각하는 경우) 그게 바로 그것입니다.
답변3
서버를 잠그고 DDoS로부터 보호하려면 어떤 다른 조치를 취해야 합니까?
웹앱이 대화형이 아니고 콘텐츠만 표시하는 경우: 캐시 시간이 짧은 nginx + 프록시 캐시를 사용하세요(보통 1~5분이면 괜찮습니다). 이는 성능을 크게 향상시키고 공격자가 더 많은 리소스를 할당하도록 강요합니다.
불필요한 모든 것을 필터링하는 제한된 방화벽을 설정하십시오.IN과 OUTINPUT/OUTPUT/FORWARD-Policy를 DROP으로 설정합니다. 나가는 모든 연결 시도를 기록하십시오(UPD 포트 53 제외).
SSH를 정적 관리 IP로 제한할 수 없는 경우 22222와 같은 대체 높은 포트를 사용하면 "hello mcfyl - 거기 있는 사람"이 많이 방지됩니다.
또한, 무차별 대입 공격으로부터 SSH를 보호하려면 fall2ban/denyhosts를 사용하십시오.
관리자 리소스가 있는 경우: OSSEC 및 경량 WAF를 사용하십시오(nginx용 naxsi가 있고 경량이며 mod_security와 같은 PITA는 아님). 그러나 그러한 설치를 설정하고 유지 관리할 사람이 필요합니다.
백업을 구현하고 대기 서버를 백업 대상으로 사용
웹앱 코드를 최신 상태로 유지하세요. 오픈 소스 프로젝트를 사용하는 경우 해당 보안 메일링리스트에 가입하세요.
취약점이 많은 것으로 알려진 소프트웨어는 피하십시오.
admin-login 및/또는 managament-webapps를 사용하는 경우: 해당 로그인 + SSL에 대한 기본 인증을 설정합니다(자체 서명된 인증서는 괜찮습니다).
개발 등을 위해 포트를 여는 대신 가능하다면 SSH 터널링을 사용하세요.
그렇지 않다면 공격 중/공격 후에 안정성을 유지하는 가장 좋은 방법은 무엇입니까?
- 침착하게 지내다
- 그러한 사건에 대한 경험이 있는 사람이 있어야 합니다.
- 비상 계획을 준비해 두세요
당신이 이미 한 가장 중요한 일은 일이 일어나기 전에 그것에 대해 생각하고 가능한 대책을 세우는 것입니다.