dongho-jung
commented
3 years ago monitor
- incoming traffic volume은 snmp나 sar같은 다른 통계로 집계할 수 있을거 같아요
- webserver access log는 벤더사별 버전별로 패턴을 정리해야 하는데 힘들수도 있겠네요. 근데 대부분의 웹서버들이 에러는 *.error.log에 따로 로깅해두고 있는걸로 알고 있어서 어쩌면 생각보다 쉬울수도 있겠네요
- concurrent connection 이건 bpf로 가능할거 같아요
- incoming traffic sampling capture가 가장 접근하기 쉽고 정석적인 방법일텐데 이 방법은 해당 서비스에 너무 종속될 위험이 있을거 같아요
Identify and analysis
아 여기에 다 써놓으셧네요. 그냥 한번 더 리뷰할게요. 위에는 제 개인적인 의견으로 봐주세요.
- tcpdump도 내부적으로는 bpf를 쓰고 있는걸로 알고 있어요. tcpdump가 동적으로 프로그래밍이 가능하고 부하도 bpf를 바로 쓰는것과 차이가 크지 않다면 네트워크 쪽은 tcpdump로 접근해도 괜찮을거 같네요
- tcpdstat httpry, argus에 대한 리서치가 좀 더 필요할거 같아요. PoC 단계에서 활용해 볼 수 있지만 결국 저희 프로젝트에서 구현하려면 직접 짜야할수도 있어서요. 근데 프로토콜 종류 식별이나 http header 파싱은 어렵지 않을것 같고 concurrent connection도 시간 들이면 구현 가능할거 같아요
- incoming traffic을 수집할 수 없는 경우는 생각하지 않을게요. webserver access log 분석은 위의 방법들과 병행한다고 가정하겠습니다.
suggest
- 대역폭 소진 공격: 이 부분은 서버 자체에서 acl 설정 외에도 cdn 구축이나 ddos mitigation solution 같은걸 제안해볼 수 있을거 같아요
- 웹서버 자원 공격(Syn(Ack/Fin) Flooding), DB connection: 이건 직관적이어서 어렵지 않을거 같아요. 근데 비정상 패킷이나 임계치 같은 heuristic한 값들은 고르거나 조정해주기 어려울수 있겠네요
- 웹서버 자원 공격(Slow header or Slow data Flooding): timeout을 미리 설정해둔 경우라면 문제가 없겠지만 그렇지 않은 경우에 공격을 받았을 때 어떻게 대응할 수 있을지 고민이 필요할거 같아요. 현재 established된 connection이 얼마나 오래된 애인지 알 수 있는 방법이 있을지? 리서치해보면 좋겠네요
- 봇 vs 브라우저 식별 방안: 이건 시나리오보다 하나의 솔루션으로 제안해볼 수 있겠네요. robots.txt같은거랑 같이요.
monitor
• incoming traffic volume 방화벽, IDS등의 네트워크 장비를 통해 웹서비스 운영 망으로 유입되는 트래픽의 bps와 pps 규모를 확인하여 평시와 비교 • webserver access log 웹서버의 접속 로그를 확인하여 비정상 접속 증가여부 확인 • concurrent connection 방화벽, IDS등의 네트워크 장비를 통해 웹서버가 연결 유지하고 있는 커넥션 규모를 확인하여 평시와 비교 • incoming traffic sampling capture 웹서비스 운영 망으로 유입되는 트래픽의 일부를 수집하여 분석
Identify and analysis
(1) incoming traffic을 수집할 수 있는 경우 • packet dump tcpdump와 같은 트래픽 캡쳐 툴을 이용하여 incoming traffic 일부를 pacap 형태로 저장 • analysis tcpdstat : 수집된 트래픽의 프로토콜 종류등에 관한 정보 확인 ngrep, httpry : http header에 관한 정보 확인 argus : concurrent connection에 관한 정보 확인 • scenarios drawn tcpdstat, tcpdump : 대역폭 소진공격(ex.UDP,ICMP flooding) 여부 판단 ngrep, httpry : DB connection 부하유발 공격(ex. Get flooding)여부 판단 argus : 웹서버 자원(TCP Stack) 부하유발 공격(ex. syn flooding) 여부 판단
(2) incoming traffic을 수집할 수 없는 경우 • webserver access log 서버 접속로그를 확인하여 접속자의 request page에 대한 통계와 특정 시간동안 발생되는 request 횟수에 대한 통계를 확인
suggest
• 대역폭 소진 공격 - ex. UDP, ICMP Flooding 웹서버 앞단에 위치한 방화벽이나 상단 라우터(ISP의 협력 필요)에서 해당 프로토콜을 모두 차단하도록 ACL 설정하여 대응 • 대역폭 소진 공격 - ex. TCP Flooding size가 큰 TCP Flooding 공격은 프로토콜 기준으로 차단할 수 없으므로 source ip 별 pps에 대한 임계치 정책을 설정하여 대응 • 웹서버 자원 소모 공격 - ex. Syn(Ack/Fin) Flooding syn flooding 공격은 웹서버 OS의 TCP stack 자원을 소모하는 공격으로서 source ip 별 pps에 대한 임계치 정책을 설정하여 대응하거나 패킷의헤더를 검사하여 옵션필드가 없는 등의 비정상 패킷을 차단하여 대응 • DB connection 부하유발 공격 - ex. Get(Post) Flooding 다수의 HTTP 요청을 유발하여 웹서버와 DB 사이의 연동에 부하를유발하므로 특정 시간 동안 발생하는 요청 수에 대한 임계치를 설정하여 해당 임계치 이상으로 요청을 발생하는 source ip를 차단 또한, HTTP header를 확인하여 HTTP 표준에 맞지 않는 field가 설 정되었을 경우 해당 field 값을 signature로 설정하여 차단 • 웹서버 자원 소모 공격 - ex. Slow header or Slow data Flooding 이 공격은 요청을 완료하지 않고 해당 connection을 지속적으로 유지하는 공격이므로 하나의 요청에 대한 timeout 값을 설정하여 특정 시간동안 요청이 완료되지 않을 경우 connection을 강제 종료시켜서 차단 • 봇 vs 브라우져 식별 방안 일반적인 봇은 브라우져와 달리 웹서버의 응답코드에 반응하여 행동하지 않으므로 웹서버에서 302 moved temporary와 같은 코드로 응답하여 봇이 발생시키는 요청을 차단