플로우 로그 서비스는 사용자의 네트워크 인터페이스로 들어오고 나가는 패킷들을 분석하여 통계를 제공합니다. 이 서비스를 사용하면 네트워크 인터페이스에 설정된 Security Groups 규칙에 의하여 허용 또는 거부된 패킷들의 개수, 크기 등에 대한 다양한 통계를 확인할 수 있습니다. 플로우 로그 서비스를 활용하면 사용자의 네트워크 인터페이스가 올바르게 트래픽을 주고받았는지, 누구와 통신을 수행했는지 그리고 외부에서 어떠한 침입 시도가 있었는지 등을 확인할 수 있습니다.
플로우 로그 서비스는 네트워크 인터페이스로 오가는 모든 패킷들의 헤더를 검사합니다. 현재는 인스턴스의 네트워크 인터페이스와 트랜짓 허브 연결에 대해서만 기능을 제공합니다.
단, L2 유형은 Ethernet를, L3 유형은 IPv4를, L4 유형은 TCP/UDP/ICMP인 경우에만 헤더를 검사하여 통계를 제공합니다. 검사된 패킷들은 5-tuple을 기준으로 집계됩니다.
현재 플로우 로그 서비스는 Object Storage를 저장소로 활용합니다. 사용자가 설정한 수집 간격마다 OBS(Object Storage)에 파일이 생성되며, 이 파일을 다운로드하여 실제 통계를 확인할 수 있습니다.
통계를 확인하여 Security Groups의 올바른 설정 여부, 외부 침입 시도 등을 확인할 수 있습니다.
인스턴스의 포트를 통해 들어오고 나가는 패킷의 연결 정보, 통계 등을 수집/확인하고 싶은 경우
사용 중인 네트워크 서비스에 흐르는 패킷의 연결 정보, 통계 등을 수집/확인하고 싶은 경우
Security Groups 설정에 의해 허용 또는 차단된 패킷의 연결 정보, 통계를 수집/확인하고 싶은 경우
인스턴스로의 패킷 유입 기록을 확인하고 의심스러운 주소를 차단해 인스턴스의 보안 강화를 도모하고 싶은 경우
플로우 로그 서비스에서 사용하는 리소스와 용어를 설명합니다.
| 번호 | 필드 | 설명 | 단위 | 비고 |
|---|---|---|---|---|
| 1 | timestamp_start | 해당 5-tuple이 처음 확인된 시간 | UNIX TIMESTAMP | |
| 2 | timestamp_end | 해당 5-tuple이 마지막으로 확인된 시간 | UNIX TIMESTAMP | |
| 3 | interface_id | 네트워크 인터페이스 ID | UUID | |
| 4 | owner_type | 네트워크 인터페이스를 소유한 장비의 종류 | instance 또는 transithub_attachment |
|
| 5 | owner_id | 네트워크 인터페이스를 소유한 장비의 ID | UUID | |
| 6 | subnet_id | 네트워크 인터페이스를 소유한 서브넷의 ID | UUID | |
| 7 | vpc_id | 네트워크 인터페이스를 소유한 VPC의 ID | UUID | |
| 8 | region | 리전 정보 | KR1 또는 KR2 |
* KR1: 한국(판교) 리전 * KR2: 한국(평촌) 리전 |
| 9 | protocol | 5-tuple 중에서 프로토콜 번호 | IANA에서 부여한 프로토콜 번호를 표현합니다. * 각 번호에 따른 프로토콜은 다음과 같습니다. 1: ICMP, 6: TCP, 17: UDP * 이 외에는 수집하지 않습니다. |
|
| 10 | src_addr | 출발지 주소 | IPv4 주소 | |
| 11 | dst_addr | 목적지 주소 | IPv4 주소 | |
| 12 | src_port | 출발지 포트 번호 | Integer | ICMP는 0으로 간주합니다. |
| 13 | dst_port | 목적지 포트 번호 | Integer | ICMP는 0으로 간주합니다. |
| 14 | tcp_flag | TCP flag | Integer | TCP flag는 수집 간격 내에 캡처된 패킷을 bitwise OR 처리하여 표기합니다. 자세한 내용은 표 하단의 TCP flags를 참고하세요. |
| 15 | packets | 수집 간격 동안 확인된 패킷 개수 | Integer | |
| 16 | bytes | 수집 간격 동안 확인된 패킷 크기 총합 | Byte | |
| 17 | direction | 수집된 5-tuple의 패킷 흐름 방향 | ingress, egress 또는 unknown |
|
| 18 | filter | 수집된 5-tuple의 Security Groups 판정 결과 | ACCEPT 또는 DROP |
|
| 19 | transithub_drop_no_route_packets | 라우팅 경로가 없어 트랜짓 허브 라우터가 드랍한 패킷의 수 | Integer | 트랜짓 허브와 관련된 항목으로서, 트랜짓 허브가 아닌 인터페이스는 -1로 표기됩니다. |
| 20 | transithub_drop_no_route_bytes | 라우팅 경로가 없어 트랜짓 허브 라우터가 드랍한 패킷 크기의 총합 | Byte | 트랜짓 허브와 관련된 항목으로서, 트랜짓 허브가 아닌 인터페이스는 -1로 표기됩니다. |
| 21 | transithub_drop_black_hole_packets | 트랜짓 허브 라우터에서 블랙홀 라우팅으로 결정되어 드랍된 패킷의 수 | Integer | 트랜짓 허브와 관련된 항목으로서, 트랜짓 허브가 아닌 인터페이스는 -1로 표기됩니다. |
| 22 | transithub_drop_black_hole_bytes | 트랜짓 허브 라우터에서 블랙홀 라우팅으로 결정되어 드랍된 패킷 크기의 총합 | Byte | 트랜짓 허브와 관련된 항목으로서, 트랜짓 허브가 아닌 인터페이스는 -1로 표기됩니다. |
| 23 | status | 로그 상태 | OK 또는 SKIPDATA 또는 NODATA |
* OK: 정상적으로 로깅된 5-tuple입니다. * SKIPDATA: 플로우 로그에서 제공하는 내부 용량을 초과하여 해당 수집 간격 기간 동안 수집되지 않은 패킷이 존재합니다. * NODATA: 해당 수집 간격 내에 수집된 데이터가 없습니다. |
TCP 연결이 짧은 경우 TCP Active open을 시도하는 측에서 SYN, FIN을 수집 간격 내에 송신할 수 있습니다. 이때는 SYN | FIN (2 | 1 = 3)이 기록됩니다.
반대로 수신 데이터로는 수집 간격 내에 SYN | ACK, 그리고 FIN이 수신될 수 있습니다. 이때는 SYN | ACK | FIN (16 | 2 | 1 = 19)이 기록됩니다.
SYN, ACK, RST, FIN의 각 숫자는 TCP header tcp flag bit field(RFC 793, section 3.1. Header Format)를 따릅니다.
PSH flag만 존재하는 패킷, ACK flag만 존재하는 패킷 및 일반적으로 트래픽을 송신할 때 사용하는 PSH | ACK flag는 수집에 포함하지 않습니다. 즉, SYN, SYN | ACK, FIN | ACK, RST, FIN만 기록합니다.
수집 간격을 길게 설정할 경우, 실제로는 다른 연결이지만 같은 5-tuple로 수집될 수 있습니다.
수집 간격 이내에 동일한 5-tuple로 여러 횟수 연결 수립/종료를 반복하면, 이 연결들이 논리적으로 각자 다른 연결이라고 할지라도 같은 5-tuple로 집계됩니다.
따라서 상황에 따라 적절한 수집 간격을 설정하는 것이 좋습니다.
ACCEPT에 한 번씩 기록됩니다. 트랜짓 허브 라우터에서 실제로 드랍된 패킷은 별도의 줄에 DROP과 함께 기록됩니다.연결 수립 패킷만 수집(connection setup only) 옵션의 영향을 받지 않으며, 연결 상태와 관계없이 모든 패킷을 수집합니다.