트래픽 침해사고 (NTP , ICMP echo reply)

최근들어 IDC 네트워크 침해사고에 NTP 공격기법과 ICMP echo reply 가 보이기 시작했다.

가장 전통적인 증폭 공격이라면 공격자가 소스IP를 victim의 IP로 위조하여 증폭하려는 네트워크의 broadcast 주소에 icmp request를 요청하면, 이에 대해 broadcast 내 모든 디바이스들이 해당 IP로 icmp echo reply로 응답하는 그러나 지금은 역사속에 사라진 smurf 공격으로 거슬러 올라갈 수 있다

ICMP echo reply

TCPUMP 명령어로 확인시

20:47:59.132590 IP 192.168.0.18> 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132594 IP 192.168.0.13> 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132597 IP 192.168.0.24 > 192.168.0.1 ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132603 IP 192.168.0.22 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132604 IP 192.168.0.16> 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132611 IP 192.168.0.12 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132612 IP 192.168.0.34> 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132619 IP 192.168.0.22 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132627 IP 192.168.0.33 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132636 IP 192.168.0.16 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132641 IP 192.168.0.26 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132656 IP 192.168.0.34 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132660 IP 192.168.0.55 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132668 IP 192.168.0.15 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

20:47:59.132669 IP 192.168.0.26 > 192.168.0.1 : ICMP echo reply, id 0, seq 0, length 1052

IP가 변조되어 트래픽이 발생하기때문에 해당부부은 네트워크 엔지니어가 스위치 MRTG를 확인하며 조치를 취하여만 한다.

이후, UDP 기반의 공격으로는 2013년 spamhaus에 대한 300Gbps의 공격으로 이슈화가 된 DNS(53/udp) 증폭 공격을 시작으로 default community string인 public을 사용하는 snmp(161/udp)에 대량의 응답을 요청하는 snmp 증폭 공격이 잠시 유행한 적이 있었고, 최근에는 ntp(123/udp) 증폭 공격이 큰 이슈가 되고 있다.

TCPUMP 명령어로 확인시

12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8
12:30:04.830337 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830344 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830351 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830367 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830371 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830379 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830387 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830395 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830406 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440
12:30:04.830412 IP 192.168.1.85.123 > 10.1.1.173.44948: NTPv2, Reserved, length 440

여기에서 문제는, ntp의 monlist가 기본적으로 600개의 최근 질의/응답 목록을 보여 주기 때문에 단 몇십~몇백 바이트의 한 질의 패킷에 440byte씩 쪼개어져 결국 약 x20배의 증폭이 되어 4,000 byte 이상의 응답 패킷을 생성하게 된다는 것이다. 그리고, 짧은 시간에 많은 질의를 하게 되면 한 서버에 수백 Mbps 이상의 공격 트래픽이 유발될 수 있다.

해당 NTP 공격을 막으려면 ACL 설정을 해야한다 (Access Control List)

해당 123번 포트를 인바운드 필터링/아웃바운드 필터링을 deny(차단)해야한다.

ACL을 적용 하고 난 후에 TCPDUMP 로 패킷을 확인시

12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8
12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8
12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8
12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8
12:30:04.830324 IP 10.1.1.173.44948 > 192.168.1.85.123: NTPv2, Reserved, length 8

요청에 응답하라는 보내라고 들어오는 패킷이 들어와도 ACL설정으로 인하여 응답하지않는 모습이다.

저희 네트워크 스위치에도 해당 문제로 인하여 ACL(Access Control List) 룰을 만들어 운영중입니다.

FAMILY SITE

CONTACT US