[도서] 인프라보안 - 10장: Security Onion 설치

설치 직후 첫 번째 장벽, so-allow

Security Onion을 처음 설치하고 나면 22번 SSH 포트 빼고는 전부 막혀 있다. 웹 콘솔에 접근하려 해도, Squert를 열려 해도 아무것도 안 된다. 그래서 제일 먼저 해야 할 게 sudo so-allow를 실행해서 관리 포트를 열어주는 작업이다.

명령을 실행하면 어떤 종류의 장치로 접근을 허용할지 물어본다.

[a] - analyst - ports 22/tcp, 443/tcp, and 7734/tcp
[l] - syslog - port 514
[o] - ossec agent - port 1514/udp
[s] - Security Onion sensor - 22/tcp, 4505/tcp, 4506/tcp, and 7736/tcp

랩 환경이라면 a를 입력해서 분석과 센서 모니터링 포트를 한 번에 다 여는 게 편하다. 실제 운영 환경에서는 당연히 인가된 IP에 ACL을 걸어야 하지만, 일단 동작하는 걸 확인하는 단계에서는 이렇게 시작한다.

그리고 여기서 한 가지 신경 써야 할 부분이 있다. 보안양파가 설치된 IP가 192.168.2.14인데, 관리 OS인 Xubuntu는 VLAN 20 대역(10.20.1.0/24)에 있어서 LAN 대역에서 바로 붙을 수가 없다. pfSense에서 VLAN20_OFFICE 규칙을 추가해서 Xubuntu IP를 소스로 지정하고 192.168.2.14로 향하는 TCP 트래픽을 허용해야 비로소 웹 UI에 접근할 수 있게 된다. 설치 자체보다 이 네트워크 경로 뚫는 작업이 더 번거로울 수도 있다.

snort.conf 네트워크 변수 설정

Security Onion을 평가용으로 설치하면 IDS 엔진은 기본적으로 Snort를 쓴다. 그리고 Snort 설정의 출발점은 /etc/nsm/센서이름/snort.conf인데, 이 파일에서 가장 먼저 손봐야 할 게 네트워크 변수 설정이다.

기본값을 그냥 두면 나중에 탐지 룰을 만들 때 "내부망에서 외부망으로의 패킷" 또는 "외부망에서 내부망으로의 패킷"이라는 방향 구분이 모호해진다. 책에서는 다음처럼 설정한다.

ipvar HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]
ipvar EXTERNAL_NET any

근데 여기서 한 가지 더 짚어두는 게 있다. IDS 센서 배치 위치에 따라 보이는 IP가 달라진다는 점이다. 센서를 라우터 상단(백본 쪽)에 두면 공인 IP만 보이고 사설 IP는 안 보인다. 반대로 NAT 안쪽에 두면 사설 IP만 탐지된다. 책에서는 이 두 케이스를 그림으로 비교하면서, 일반적으로는 NAT 안쪽에 센서를 두는 두 번째 케이스를 기준으로 설정하도록 안내한다.

회사처럼 복잡한 환경이라면 OFFICE_NET 같은 변수를 추가로 선언하고, EXTERNAL_NET을 ![HOME_NET]으로 지정해서 내부망 전체를 제외한 나머지를 외부망으로 처리하는 방식을 쓴다. 이렇게 해두면 룰 작성할 때 변수명만으로 트래픽 방향을 정교하게 구분할 수 있다.

로그 용량 튜닝, 방치하면 IDS가 죽는다

Security Onion은 실시간으로 전체 패킷 캡처(FPC)를 수행한다. SPAN 포트로 트래픽이 복사되어 들어오다 보니, eth1의 수신량이 516.6MB까지 금방 올라가는 걸 ifconfig로 직접 확인할 수 있다. 이게 며칠만 쌓여도 수백 기가, 테라바이트 단위로 불어난다.

책에서 계산해준 예시가 꽤 직관적이다. 평일 하루 100GB, 주말 30GB로 잡으면 일주일에 560GB, 시간당 약 3.3GB다. 여기에 Snort 로그와 MySQL, ELSA 로그까지 합치면 2TB짜리 디스크도 금방 찬다. 그래서 /etc/nsm/securityonion.conf에서 다음 두 값을 꼭 건드려야 한다.

DAYSTOKEEP=30
WARN_DISK_USAGE=80
CRIT_DISK_USAGE=90

랩 환경이면 DAYSTOKEEP을 5 정도로 낮춰도 된다. WARN_DISK_USAGE와 CRIT_DISK_USAGE도 실제 환경에서는 60, 70 정도로 더 보수적으로 잡는 게 낫다고 한다. 오래된 데이터를 지우는 시점이 생각보다 빠르게 오기 때문이다.

불필요한 패킷 자체를 안 쌓는 것도 중요한데, BPF(Berkeley Packet Filter)를 활용하면 된다. /etc/nsm/rules/bpf.conf에서 제외할 트래픽을 정의하면 Snort, Bro, 수리카타, PRADS 등 모든 컴포넌트에 일괄 적용된다. SMB 트래픽처럼 탐지 가치보다 용량 부담이 더 큰 트래픽을 여기서 걸러낸다.

Squert에서 탐지 로그 확인하는 흐름

설치가 끝나고 웹 브라우저로 https://192.168.2.14에 접속하면 Security Onion 홈 화면이 나오고, 거기서 Squert 링크를 클릭하면 IDS 운영 화면이 열린다. OSSEC 등 몇 가지 경보가 이미 기록돼 있는 걸 바로 볼 수 있다.

탐지가 잘 되는지 간단히 테스트하고 싶다면, 다른 VLAN에 있는 서버에서 apt-get update를 한 번 실행해보는 게 빠르다. 그러면 "ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management"라는 정책성 탐지 알림이 Squert에 기록된다. 이게 보이면 IDS가 정상적으로 트래픽을 들여다보고 있다는 뜻이다.

사실 이 탐지 자체가 실제 위협은 아니지만, 센서가 살아서 패킷을 잡고 있다는 걸 확인하는 용도로는 딱 맞다. ELSA에서 특정 도메인으로 검색 쿼리를 날려서 패킷이 실제로 수집되고 있는지까지 확인하는 과정이 이어지는데, 그게 Security Onion을 처음 띄웠을 때 "돌아가고 있구나"를 확인하는 가장 직관적인 방법이다.