환경은 VM웨어의 Ubuntu 20.04버전을 기반으로 하였고 이 위에 Docker를 설치해 각 서버나 기능별로 컨테이너를 분리해 사용하려고 한다.

그냥 기본적인 확인을 위한 서버이니 메인에 접속시 Hello, World를 표시해주는 아주 간단한 서버이다. 컨테이너의 이름은 server 이며

docker run -itd --name server -p 8080:8080 ubuntu:20.04 bash

위 명령어로 실행 한다.

도커에서 suricata IPS모드를 사용하기 위해서는 관리자 권한을 필요로 한다. NFQ를 위한 설정을 해줘야 하는데 이를 iptables로 적용하고 도커에서 iptables를 사용하기 위해서 관지자 권한이 필요하기 때문이다. 따라서 컨테이너를 실행시킬때 privileged 옵션을 주어야 한다.

docker run -itd --name ips --privileged --net=container:server ubuntu:20.04 bash

위 명령어에서 –privileged 옵션으로 관리자 권한을 줬고, –net 옵션으로 server 컨테이너와 네트워크를 공유하도록 설정해주었다. –net 옵션을 주고 server와 ips 컨테이너에서 ip를 확인하면 똑같은 ip를 할당받은 것을 볼수 있다.

이제 suricata에서 제공하는 문서를 기반으로 설치를 해보자. 각 환경에서 코드를 빌드할 필요 없이, PPA방식으로 편하게 설치할 수 있다.

apt install iptables
apt install software-properties-common
add-apt-repository ppa:oisf/suricata-stable
apt update
apt install suricata jq

ppa저장소를 추가하고 suricata와 로그를 볼때 도움이 되는 jq를 설치한다. ubuntu를 사용해본 사람이라면 여기까지 오래걸리지 않을 것이다.

suricata --build-info

위 명령어를 이용해 빌드 정보를 확인할수 있으며 나오는 정보는 다음과 같다.

사진을 보면 NFQueue support에 yes로 되어있지 않으면 IPS모드를 사용할 수 없다.

nano /etc/suricata/suricata.yaml

위 파일을 수정함으로써 suricata의 기본적인 설정을 진행한다. 필자는 nano에디터를 주로 쓰지만 각자 편한 에디터를 사용하면 된다. 위 설정으로 기본적인 HOME NETWORK와 각종 로그 등을 할수 있다. 기본적인 설정은 Suricata 최신 권장설정으로 되어있으나 환경에 따라서 바꿔야 할 부분을 수정한다.

위와같이 필자는 도커 네트워크 기반이므로 172.17.0.0/24를 주었고 아이피는 호스트나 환경에 따라 달라질수 있다.

port-groups:
    #HTTP_PORTS: "80"
    HTTP_PORTS: "8080"
    SHELLCODE_PORTS: "!80"
    ORACLE_PORTS: 1521
    SSH_PORTS: 22
    DNP3_PORTS: 20000
    MODBUS_PORTS: 502
    FILE_DATA_PORTS: "[$HTTP_PORTS,110,143]"
    FTP_PORTS: 21
    GENEVE_PORTS: 6081
    VXLAN_PORTS: 4789
    TEREDO_PORTS: 3544

홈 네트워크 설정 아래있는 사용하는 포트 부분이다. 웹 서버를 8080포트로 오픈했으니 이에 맞게 수정해준다. 추가로 http-log가 비활성화 되어있는데 이를 활성화 해준다.

- http-log:
      enabled: yes
      filename: http.log
      append: yes
      #extended: yes     # enable this for extended logging information
      #custom: yes       # enable the custom logging format (defined by customformat)
      #customformat: "%{%D-%H:%M:%S}t.%z %{X-Forwarded-For}i %H %m %h %u %s %B %a:%p ->
      #filetype: regular # 'regular', 'unix_stream' or 'unix_dgram'

수정 내용을 저장하고 탐지 룰 업데이트를 진행한다. 수리카타는

suricata-update

명령어로 통합 룰 업데이트를 지원한다. 다만 기본 룰들이 전부 alert로 되어있다. 이는 탐지는 하나 패킷드롭은 하지 않는다는 것이다. 옛날에는 오탐율 때문에 필요한 항목을 직접 드롭으로 바꿔주라는 글을 봤던 기억이 있다. 하나하나 확인하는게 좋지만 일단….문자열 치환을 이용해 alert를 전부 드롭으로 바꿔준다.

suricata 룰은 업데이트 되면서 통합되어 /var/lib/suricata/rules 위치에 suricata.rules 로 저장된다. 이를 정규식을 이용해 alert를 전부 drop으로 바꿔주면 ips모드에서 패킷 차단이 가능하다.

#정규식
:%s/^alert/drop/

치환전 룰인

에서 vim을 이용해 위 정규식을 이용하면

이런식으로 바꿔준 후 저장한다. 통합된 룰들을 확인해 보면 기본적으로 Suricata에서 제공하는 룰과 별도로 emergingthreats.net에서 제공하는 룰들이 같이 병합되어 있다.

이후 NFQ 설정을 위해 iptables 옵션을 적용해준다. 이 설정을 적용하면 ips컨테이너와 같이 묶여있는 server 둘의 네트워크는 ips가 켜저있지 않으면 망 단절이 일어난다. 이게 인라인 IPS모드이다.

명령어는 아래와 같다

apt install iptables
iptables -I INPUT -j NFQUEUE
iptables -I OUTPUT -j NFQUEUE

이후 Suricata를 IPS모드로 작동시켜 준다.

suricata -c /etc/suricata/suricata.yaml -q 0

그럼 다음과 같은 화면이 뜰것이다.

이후

tail -f /var/log/suricata/fast.log

를 통해 탐지로그를 살펴보자.

이제 kali에서 hping3를 이용해 SYN Flooding을 시도해본다. 공격을 시도하는 순간 다음과 같은 로그들이 생성된다.

자주가는 카페의 기본 IP와 충돌이 나 docker 네트워크 브짓지 대역을 192.168.64.0/24로 수정했습니다

위 사진을 보면 이상한 것이 있다. 분명히 막히긴 했는데 서버에서 공격지로 나가려다 비정상 트레픽으로 차단된 ACK 로그가 있다. 탐지 룰의 트레숄드 값에 의해 통과된 일부 트래픽에 대한 응답 트레픽이 탐지 된것 같다.

또 다음사진을 보면 Suricata 경고로 flow경고가 나오고 있다. Suricata에 설정된 처리 트래픽 양보다 더 많은 트레픽이 들어와 뜨는 경고다. 따라서 기업이나 트레픽 양이 많은 곳에 적용할 경우 설정을 수정하고 IDS모드로 미리 테스트를 거친 후에 IPS모드로 전환해야 할 것 같다.

hping3에서는 랜덤 ip를 통한 Flooding공격도 가능하다. 이를 테스트 해봤는데 결과는 다음과 같다.

로그를 보면 ET DROP Spamhaus DROP Listed Traffic Inbound group이라고 되어있다. Spamhaus DROP이라는 그룹에서 DROP을 권장하는 IP리스트를 제공하고 있는데 이 리스트에 hping3의 임의ip가 포함되어 있는것 같다.

이 IPS를 적용하고서 생기는 문제점들이 있다. 이번에 생긴 문제점은 기본적으로 적용한 DROP룰 중에 APT update 서버로 향하는 트레픽을 막는 룰이 추가되어 있다.

따라서 이 룰을 Alert로 바꾸거나 주석 처리해야지 정상적인 apt update가 가능하다.

이번에 생긴 업데이트 문제 뿐만 아니라 각 룰들이 업데이트 되면서 다른 문제가 생길 가능성도 있다. 이러한 것들을 직접 핸들링 하고 테스트 하면서 수정해 줘야 한다.

• IPS(IDS)

  • 침입차단(방지)시스템으로 OSI 7 Layer의 3계층부터 7계층의 plain 데이터를 시그니쳐와 비교해 공격 유무를 탐지한다.
  • IPS는 시그니쳐에 의한 탐지와 차단을 같이 진행하며 IDS는 탐지 기능만 제공하고 있다. 다만 오탐비율도 높은편이다.

• FW

  • 방화벽이라는 장비로 3계층과 4계층에서 IP, PORT를 보고 혀용된 IP나 PORT는 허용하고 나머지 트레픽을 차단하는 역할을 한다.

  • ip기반의 블랙기스트, 화이트리스트 기능이 사용 가능하고 특정 PORT에만 접근하도록 설정도 가능하며 ip, PORT기능을 복합적으로 사용헤 악의적이나 비인가 사용자에 대한 접근을 통제한다.

• WAF

  • WAF는 웹 어플리케이션 방화벽의 약자로 기존의 방화벽이 3계층 4계층에서만 동작한 것의 한계를 벗어나 7계층에서 웹 어플리케이션에 대한 방화벽 기능을 제공한다. 일반적인 ip, PORT기반의 접근 통제보다 더 넓은 SQL Injection, 악성 스크립트 삽입 등 웹 서버에 대한 공격을 탐지하고 이를 차단하는 역할을 한다.

• UTM

  • 통합 위협 관리의 약자로 IPS, FW기능을 하나로 합친 장비라고 봐도 무방하다. 장비의 사양에 따라 WAF기능이 추가된 장비도 존재하며 기존의 2개 이상의 장비의 운영에 드는 비용이나 관리적 측면에 이점이 있다.
  • 요즘 UTM장비는 무선렌 대응이 되는 모델도 존재하며 매우 다양한 회사의 장비가 존재하고 기기의 가격보다는 시그니쳐, 펌웨어 업데이트로 인한 엔터프라이즈 라이센스 비용이 매우 큰편이다.

• proxy 서버

  • 프록시 서버는 많은 웹 연결이 SSL 암호화로 이루어 지면서 보안장비에서 plain데이터 기반의 공격탐지가 불가능하다. 패킷들이 암호화 되면서 이들이 공격인지 아닌지에 대한 판단이 어렵기 때문이다. 그렇기 때문에 프록시 서버단에서 SSL 암호화를 진행하고 프록시 서버와 웹서버는 엄호화가 되지 않은 상태로 통신하게 되면서 중간에 보안장비가 패킷의 공격유무를 판단하는것이 일반적이다.
  • 프록시 서버의 사용은 위 사례도 있지만 원래는 중간경유 서버를 주어 공격또는 장애에 대한 능동적인 방어를 위해 사용되었다. 예를 들면 A서버가 B라는 프록시 서버를 통해 서비스중인데 B를 목적지로 한 공격이 발생했다. 그럴경우 A서버는 피해가 적고 모든 피해는 B가 받게 되므로 프록시 서버만 다시 바꿔주면 정상적인 서비스가 가능하다.
  • 프록시 서버 사용의 다른 목적으로는 로드벨런스 기능이 있다. 한 서비스에 대해 많은 사용자가 집중되는 경우 여러게의 미러서버를 두고 프록시 서버에서 부하를 분산해주는 역할을 한다.

• 로그수집

  • 보안장비에서 수집된 로그데이터들을 한번에 볼수 있게 수집해주는 장비이다. ELK, Sqlunk 등이 있으며 각 장비에서 수집된 로그를 키워드 별로 바인딩 한 후 데시보드를 통해 원하는 로그를 보여준다.

• SIEM

  • SIEM은 보안정보 이벤트 관리의 약자이다. SIEM장비를 처음 써본건 군에 있을때 이다. 군에서는 부대별로 SIEM장비를 도입하고 군단급 이상 사령부에서는 예하 부대의 국방망, 인터넷망, 전술망에 대한 통합 2차 관제를 수행했다. 필자가 있던 군단급에서는 인터넷 망을 제외한 국방망, 전술망에 대한 관제를 진행할때 Splunk에 있는 SIEM을 주로 사용했다. Splunk는 spl이라는 데이터 질의어를 이용해 공격으로 예상되는 시나리오를 작성하고 이에 대한 로그들을 볼수 있게 해준다.

설명이 길었다. 각설하고 이번 포스트의 목적은 오픈소스 IPS, IDS인 수리카타(Suritaca)를 소개하고 다음 포스트에서 수리카타의 기본적인 설치와 모의공격을 테스트 해볼 예정이다.

오픈소스 IPS, IDS로는 Suricata와 Snort이며 Snort는 단일 스레드 기반으로 작동한다. 따라스 그만한 성능저하가 예상되는데 이를 개선하여 나온 Suricata는 다중스레드 기반으로 동작하는 프로그램이다.

수리카타의 공식 홈페이지는 https://suricata.io/ 이다. 위에 접속하면 기본 도큐먼트로 설치와 운용가이드가 나와있다. 이 포스트는 공식 문서를 바탕으로 작성되었다.

수리카타는 패킷 복제 기반인 IDS와 인라인 기반인 IPS를 둘다 지원하는 오픈소스이다. 이러한 오픈소스는 탐지현황 데시보드가 기본적으로 지원되지 않지만, Splunk나 ELK를 통해 데이터 시각화가 가능하다.

필자는 외부로 서버를 장기간 오픈할 일이 있을때 수리카타를 같이 운용하는 편이며 기본적인 네트워크 구성도는 다음과 같다.

위 그림처럼 Docker를 통해 구성하며 필요에 따라서 프록시 서버를 FW으로 대체할수도, 구성이 바뀔수도 있다.

위 구성으로 한달 좀 넘게 프로젝트 개발용 서버를 운용해본 결과 오탐도 있었지만 많은 종류의 공격이 들어오는걸 볼수 있었다.

공개된지 얼마 안된 취약점이 공격으로 들어오는 경우도 있고, 디렉터리 리스팅, RCE 공격 등 다양한 공격이 탐지되었다. 보통은 외국에서 들어왔고 이중 오탐도 있었지만 직접 로그를 뜯어봤을때 무차별 대입공격도 확인되었다.

외국에서는 봇을 만들어서 무차별적으로 공격을 떄리는 단체가 있다고 하는데 이런 공간에 서버를 그냥 오픈해놨다는게 너무 안일했다는 생각이 든다.

다음 포스트에서는 수리카타를 직접 설치하고 위 구성도 처럼 서버를 구성하는것을 포스팅 할 예정이다.