Abuse 관련 내용은, 이렇게 AWS Abuse팀에서 인지하고 정보에 등록 된 root mail이나 보안담당자 메일주소로 공지 해줍니다.
또는, 내부 담당자가 이러한 침해사실을 인지하는 경우들도 있을 수 있습니다. 그럴 때, 어떻게 대처 해야 하는지 살펴보도록 하겠습니다.
많이 간과 하시는 것 중에 하나는, 본문 내용을 꼼꼼히 살피셔야 합니다. 어떻게 대응 해야 하는지에 대한 내용들을 모두 포함하고 있습니다.
AWS Abuse 팀으로 부터 Abuse Report를 수신 했을 때
다양한 형태의 침해 유형이 있습니다만, 그 중 가장 빈번하게 발생하는 것은 EC2가 DoS 공격의 봇으로 활용 되는 것입니다.
내가 원치 않아도 공격지로 활용 됨에 따라, 트래픽 비용이 과다 청구 될 수 있으며 정상적인 서비스가 차단 될 수도 있습니다.
보편적으로 원인은 EC2 내 보안취약점을 이용하는 경우들이 대다수입니다.
아래 사례의 메일을 보면서 다시 한번 말씀 드려보도록 하겠습니다.
아래 메일 내용까지 살펴보시는 것이 중요한데, 메일 하단에 위와 같이 상세 정보를 포함하고 있습니다.
위와 같은 경우는, 내 계정에 있는 서울리전의 특정 EC2 인스턴스에서 외부로 DoS 공격을 유발하고 있다는 내용입니다.
Source IP는 서울리전에 존재하는 EC2의 IP 혹은 NAT IP일 것입니다.
Destination IP는 Target이 되는 IP, DestPort의 경우 Target IP의 Port로 142.240.x.x의 443 port로 공격을 하고 있는 것을 확인 할 수 있습니다.
1. 현상 차단 : 이러한 경우는 문제가 지속되고 있을 확률이 높기에 서비스에 영향이 없는 포트라면 보안그룹을 통해 먼저 차단 합니다. 서비스하고 있지 않는 인스턴스의 경우는 Route Table 조정을 통해 Outbound 자체를 막아도 됩니다.
- Outbound Rule 통한 대상 아이피와 Port 차단
2. 근본 원인 분석 : 실제로 문제가 되는 인스턴스로 접근하여 이상유무 점검합니다.
- 이상 Process 점검 : 서비스에서 활용 되거나 시스템에서 활용하는 프로세스가 최근에 실행 된 비인가 프로세스 여부 체크
- 포트 점검 : 위 경우는 443 이지만, 불법적인 프로세스로 인한 미사용 포트가 동작하고 있지 않은지 확인
- 비인가 파일 점검 : /tmp 와 같은 임시디렉토리 내 파일 업로드 여부 확인
- 최근 접속 이력 확인 : /var/log/secure 와 last 명령 등 로그 확인을 통해 비인가 사용자 접속 여부를 확인 합니다.
3. 근본 원인 제거 :
- 이 과정에서 많이들 하시는 실수가 인스턴스를 백업 하셨다가 다시 생성 하시는 경우가 있습니다. 현재 상태 그대로는 문제가 그대로 남아있기에 AMI 통해서 복제 하시게 되면 문제가 되고 있는 상황도 그대로 다시 발생 합니다.
4. 조치사항 보고 : 근본 원인 분석 과정과 현상 차단 등과 같이 조치 및 확인 한 내용에 대해서 AWS 측에 회신 해주어야 합니다.
– Abuse Mail 에 회신하여 조치사항이나 확인 된 내용을 회신 해줍니다. 근본 원인을 찾지 못했다고 하더라도, 조치를 하고 있음을 회신 해주셔야 계정이 중지 되는 것을 막을 수 있습니다.
근본 원인 분석의 경우, 시스템에 대한 이해를 가지고 계시지 않는 분들의 경우 어려움을 겪을 수 있습니다.
이와 같은 경우는, AWS Support Center를 통해서 문의 하시거나 저희 베스핀글로벌 서비스를 이용 하셔서 기술지원 받아보시기 바랍니다.
AWS Support Case : https://console.aws.amazon.com/support/home#/case/create?issueType=technical
Bespin Global : https://www.bespinglobal.com/contact/
감사합니다.