플로우 로그 서비스는 사용자의 네트워크 인터페이스로 들어오고 나가는 패킷들을 분석하여 통계를 제공합니다. 이 서비스를 사용하면 네트워크 인터페이스에 설정된 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, inter_project_peering, inter_region_peering, colocation_gateway 또는 loadbalancer |
|
| 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 패킷만을 수집합니다. 로드 밸런서에 설정된 IPACL에 의하여 DROP된 패킷의 수집은 추후 지원 예정입니다.
로드 밸런서에 접근을 시도하는 패킷, 로드 밸런서와 멤버 사이의 일반 패킷뿐만 아니라 상태 확인 패킷들도 함께 수집합니다.