원본 기사

www.boannews.com/media/view.asp?idx=96830

 

솔라윈즈 오리온 통한 또 다른 공격자 발견! 이번엔 중국?

한 APT 그룹이 원격에서 근무하고 있는 직원인 것처럼 가장해 한 미국 조직의 네트워크에 침투하는 데 성공해 슈퍼노바(Supernova)라는 백도어를 심었다는 사실이 공개됐다. 이 공격자들이 슈퍼노

www.boannews.com

"최근 솔라윈즈 오리온 사태에 관련된 새로운 소식이 나왔다. 누군가 솔라윈즈 오리온 서버에 팀주하여 슈퍼토바라는 멀웨어를 심고 1년동안 정찰했다는 것이다. 아직 공격자는 밝혀지지ㅛ 않았는데, 중국의 스파이럴이 의심되고 있다." 기사 中

2020년 3월부터 2021년 2월까지 솔라윈즈 오리온 서버를 통해 해당 조직의 네트워크에 머무르며 정보를 빼돌렸던 사건이 있었다. 이는 누군가 솔라윈즈 오리온 서버에 슈퍼노바라는 백도어를 심어두고 1년 동안 정찰해 왔다는 것이 최근 밝혀졌으며, 공격자는 현재 비공개 상태이지만 일각에서는 중국의 스파이럴이라는 말이 나오고 있다.

이러한 문제들이 어떻게 1년 동안이나 방치되었던 것인가? 이는 결국 취약한 보안 대응 때문이다. 이번 슈퍼노바 캠페인은 고도로 표적화 된 공격이었으며, 피해 조직의 수가 적었다고 한다. 즉, APT 공격의 일환이었던 것이다. 이처럼 모든 기업들은 APT 공격의 위협에 노출되어 있다. 결국 모든 기업들이 노출되어 있지만, 그 피해를 최소화하기 위해서는 결국 보안 대책이 중요하다.

기사에서는 “하지만 이를 통해 공격자들이 다른 공격자들이 악용했던 취약점과 사건들을 적극적으로 조사해서 공격한다는 사실을 다시 한 번 알 수 있습니다. 남이 했던 것이니까 우리는 안 한다는 식의 사고방식은 찾아볼 수 없습니다.” 라고 설명하고 있고, “공동의 대응이 필요한 건 이 때문입니다. 특별히 대단한 연합체를 만들자는 게 아닙니다. 공격에 대한 정보를 서로 공유함으로써 2차, 3차 피해자를 줄이거나 막을 수 있다는 겁니다. 그들은 공격 정보를 기회로 삼는데 저희는 그러질 못해요."라고 말하고 있다. 이처럼 공격 정보에 대한 공유와 같이, 일종의 대응을 시도하는 것으로도 APT 공격에 대한 위협이 줄어들 수 있다.

또한 기사에서는 공격에 활용된 IP 주소는 총 3개였고, VPN에 접속하기 위해 정상적인 사용자 계정을 여럿 활용했는데, 이 계정들 중 다중인증 시스템으로 보호된 건 하나도 없었다고 밝혔다. 이처럼, 이중화 보안의 적용만으로도 단순하게 막을 수 있는 공격이었지만, 실패했던 것이다.

결국 보안에 대한 관심이 궁극적인 보안을 가져올 수 있다.

 

반응형

기사원문

www.boannews.com/media/view.asp?idx=96508

 

억 대 넘는 사물인터넷 장비를 위험에 노출시키는 취약점 9개 발굴

수많은 사물인터넷 장비들이 원격 코드 실행 및 디도스 공격에 노출되어 있다는 연구 결과가 나왔다. IoT 장비들에 내재되어 있는 TCP/IP 스택들에서 DNS 관련 취약점들이 다량으로 발견됐기 때문

www.boannews.com

 

"수많은 사물인터넷 장비들이 원격 코드 실행 및 디도스 공격에 노출되어 있다는 연구 결과가 나왔다. IoT 장비들에 내재되어 있는 TCP/IP 스택들에서 DNS 관련 취약점들이 다량으로 발견됐기 때문이다. 보안 업체 포스카웃(Forescout)과 제이소프(JSOF)가 공동으로 연구해 발표한 내용이다." - 기사 中...

 

4차 산업혁명 시대에 살아가면서, IoT 장비들이 증가하고 있다. IoT 장비들은 점차 우리 삶에 스며들어 가고 있고, 그 수는 점차 증가하고 있다.

따라서 사물인터넷에 발생하는 취약점은 그만큼 더 위험하다. 우리 삶에 밀접하게 다가가 있는 장비인 만큼, 프라이버시와 중요한 정보의 침해 가능성이 농후하기 때문이다. 그런 와중에 최근 포스카웃과 제이소프의 공동 연구에서, 9개의 취약점을 발견해 냈다. 이는 TCP/IP 스택 모든 부분에서 발견되고 있고, 이는 사물인터넷 생태계에서 광범위하게 사용되고 있기 때문에 문제가 심각하다고 경고했다.

해당 취약점들은 네임렉이라는 이름으로 통칭되었다. 익스플로잇에 성공할 경우, 공격자는 장비의 데이터를 훔치거나 기능을 정지시키는 공격이 가능하게 된다. 현재 다양한 분야의 기관들이 위험에 노출된 상태이고, 패치가 배포되고 있다.

하지만 사물인터넷의 특성상 패치를 적용하는 것이 어렵고, 해당 오류들을 공격자들이 얼마나 광범위하게 예측하기 어려울 수밖에 없다. 

필자는 이제는 사물인터넷이 삶에 밀접하게 다가온 만큼, 사물인터넷 장비에도 별도의 패치 관련 규정이 필요하다고 생각한다. 결국 보안은 아직까지는 규제산업이기 때문에, 아직은 규제 없이는 제조사가 성실하게 취약점을 패치하는 것이 어렵다. 결국 그 위험들은 사용자들에 전가되게 된다.

이는 곧 다시 보안 문화에 대한 생각으로 귀결된다. 단순히 보안을 규제로 보고, 투자 대비 수익이 돌아오지 않는 분야이기 때문에 투자가 줄어드는 것이다. 하지만, 보안성을 통해 해당 회사에 가져다주는 신뢰성, 보안 덕분에 유출되지 않은 정보들은 결국 수익으로 돌아오기 마련이다. 결국 기업들이 이처럼 생각하는 문화를 길러야 한다.

반응형

지난번에 모든 네트워크 망 구성을 끝냈다. 이제 시나리오에 맞게 방화벽 정책을 구성해 주면 된다.

우선 Untangle에서 Apps -> Install Apps에 들어가서 방화벽을 다운로드 받는다. 방화벽을 다운로드 받아야 룰 적용이 가능하다.

방화벽 설치 완료

다운로드가 완료되면, Apps에 다음과 같이 방화벽 아이콘이 보이게 된다.

아이콘을 눌러서, Rules에서 방화벽 정책을 설정할 수 있다. 명세를 따라서 방화벽 정책을 세운다.

 

1. 방화벽의 모든 접근 통제는 화이트리스트 기반으로 운영되어야 한다.

화이트리스트 기반 Rule을 적용하기 위해, Block all 규칙을 추가한다.

Block All

 

2. 웹 서버는 외부에서 HTTP 접속이 가능해야 한다.

해당 정책을 위해, 외부와 웹 서버 간 통신하는 HTTP 통신만 오픈해 준다. 

Allow WAN to Web Server HTTP

실제로 휴대폰을 이용하여 접속해 본 결과, 정상적으로 접속되는 것을 확인할 수 있다.

휴대폰 접속 화면(포트가 짤렸다)

3. 웹 서버는 오피스망의 개발자 PC만 HTTP포트와 SSH 포트 접속이 가능해야 한다.

해당 정책을 위해, 개발자 PC와 웹 서버 간 통신하는 HTTP 포트와 SSH 포트를 오픈해 준다. 이때, 독립성을 위해 HTTP와 SSH 정책을 각각 설정해 준다.

Allow Developer to Web Server HTTP
Allow Developer to Web Server SSH

이렇게 각각 설정해 준 뒤, 개발자 PC에서 확인해 본 결과, HTTP와 SSH가 정상 접속되는 것을 확인할 수 있다.

 

HTTP, SSH 정상 접속 확인

4. HIDS 관리 서버는 에이전트 정책 관리를 위해 오피스망 단말 전체를 대상으로 필요한 포트만 활성시킨다.

Wazuh 관리 서버의 경우, 기본 포트 및 프로토콜을 다음과 같이 명시하고 있다.

Wazuh 포트 및 프로토콜

이중 Elastic Stack의 경우, 서버 내부에서 자체적으로 사용하기 때문에 방화벽의 영향을 받지 않는다. 또한 Wazuh Server에서도 내부적으로 동작하는 것들은 방화벽의 영향을 받지 않기 때문에, Agent와 통신하는 포트만 열어 주면 된다. 독립성을 위해 포트들은 각각 열어 주되, TCP와 UDP의 경우 동일한 기능을 수행하기 때문에 통합해서 정책을 생성해 준다.

Allow Agent to Wazuh Connection Service
Allow Agent to Wazuh Registration Service
WAZUH 정상 작동 확인

정책 설정을 완료하면 Wazuh가 정상적으로 연결되어 작동되는 것을 확인할 수 있다.

5. HIDS 관리 서버의 수정과 서비스 관리를 위하여 관리자 PC에서만 SSH 접속 가능하도록 설정

관리자 PC에서만 SSH 접속이 가능하도록 정책을 설정해 준다.

Allow Manager to HIDS Server SSH

정책 설정을 완료하면 관리자 PC에서는 HIDS 서버로 접속이 가능하고, 개발자 PC에서는 접속이 불가능하다.

관리자 정상 접속
개발자 접속 불가

6. 방화벽 접근은 오직 관리자 PC에서만 접근 가능하며, 관련 설정은 초기 설정 외에 모두 관리자 PC에서만 수행

기본 Access Rule에 방화벽에 관리자 PC에서만 웹으로 접속 가능하도록 정책을 수정한다.

Allow Manager to Firewall HTTP

이후 기본 Access Rule 중 HTTP/HTTPS로 서버에 접속할 수 있는 방법을 제거한다.

기본 Access Rule 제거

적용해 주면, 개발자는 접속이 불가능하고, 관리자만 접속이 가능해진다.

관리자 접속 확인
개발자 접속 불가능

7. 내부의 모든 망은 외부와의 인터넷이 불가능하다.

실제로 관리자 PC, 개발자 PC에서 외부 포탈 접속을 시도한 결과, 모두 접속이 불가능했다.

개발자 PC 외부접속 불가
관리자 PC 외부접속 불가

반응형

 

웹 서버 구축을 위해 우분투를 하나 별도로 생성한다. 우분투 홈페이지에서 현재 안정화된 버전인 20.04 LTS 버전의 ISO 파일을 다운로드 받았다. 이후 해당 이미지를 이용하여 VM을 생성해 볼 것이다.

VMware의 좌측 상단 메뉴에서 File - New Virtual Machine을 클릭한다. 그러면 New Virtual Machine Wizard가 나올 것이다. 이때, Custom으로 Next를 눌러 준다.

New VM Wizard

이후 Next를 누르다 보면, Install할 ISO를 고르는 창을 확인할 수 있다. 이때, Installer disk image file을 클릭하고, Browse를 통해 다운로드 받았던 우분투 ISO 이미지를 클릭한다.

우분투 이미지 선택

Next를 눌러서 리눅스 초기 계정 설정을 진행해 준다. 여기서 Username과 Password는 실제로 우분투에 들어가는 정보이기 때문에, 필히 기억해 두길 바란다.

계정 설정

이후 VM의 이름과 위치를 지정해 준다.

이름과 위치 설정, 원하는 대로 하면 된다.

이후 프로세서와 코어, 메모리, 네트워크, I/O 컨트롤러, 디스크 타입, 사이즈 등을 설정해 준다. 나중에 변경할 수 있으니 넘어가도 괜찮다. 마지막으로, 아래의 창이 뜨고, Finish를 누르면 설정이 끝난다.

설정 완료

이후 자동으로 부팅이 시작되고, 우분투가 설치되며, 자동으로 부팅까지 완료된다.

이후 웹 서버 형태를 갖추기 위해, apache2를 이용하여 웹 서버를 만들어 준다. apache2를 설치하면 자동으로 실행 및 서비스 등록까지 마치기 때문에, /var/www/html 내부의 파일만 변경하여 웹을 운용할 수 있다.

VI 편집기를 이용해 간단하게 HTML 하나를 만들고, 접속해서 확인해 본다.

웹 서버 구동 확인

웹 서버가 정상적으로 구동되는 것을 확인하였다.

이후 IPS와 웹 서버를 연동한다. IPS에는 별도의 정책을 넣지 않을 예정이며, 추후 룰을 추가해 줄 예정이다.

우리는 Suricata를 이용하여 IPS를 활용한다. 우선, 평소처럼 Suricata가 포함되어 있는 CentOS의 네트워크 인터페이스 설정을 변경해 준다. 이때, VMnet을 바꾼 뒤, 해당 VMnet에 맞게 수동으로 이더넷 설정을 변경해 줘야 한다.

변경하기 위해서, /etc/sysconfig/network-scripts/ifcfg-{Ethernet name} 형태의 파일을 이용한다.

ifcfg 파일

해당 파일을 열면, 이더넷 IP와 서브넷마스크, 게이트웨이 등을 변경할 수 있다. 우리는 eth0과 eth1을 사용할 예정이기 때문에, 두 파일을 각각 수정해 준다.

이후, service network restart를 해주게 되면, 네트워크가 재시작되면서 정상적으로 ip주소가 변경된다.

IP 변경 확인

이후, iptables에 FORWARD 정책을 NFQUEUE로 넣어 준다. 이를 통해, Suricata 프로그램을 통해 정상적으로 포워딩을 진행할 수 있다. 이때, NAT 설정까지 해 주면 Suricata를 통해서 완벽하게 포워딩이 진행되지만, 중간 방화벽 구간에서 확인하기 어렵다는 단점이 있다. 따라서 우리는 방화벽에서 직접 라우팅을 진행해 줄 예정이다. 우선 지금은 해당 정책까지만 넣고, Suricata를 실행시켜 준다.

Suricata 실행

Suricata가 실행되고, Web Server의 IP를 위치에 맞게 재설정해 준다. 그러면 당연하게, 웹 서버가 외부와 연결이 되지 않을 것이다. 그 이유는 돌아오는 패킷에 대해 NAT설정을 Suricata에서 안 해줬기 때문인데, 이를 위해 방화벽에서 정적 라우팅을 수행해 준다.

우리가 필요한 라우팅은 방화벽으로 192.168.60.0/24 대역의 Dest IP가 들어왔을 경우, 이를 IPS쪽으로 념겨줘야 한다. 따라서 방화벽에서 정적 라우팅을 진행한다.

Untangle에서 Config - Network - Routes에 들어가면 정적 라우팅을 수행할 수 있다.

정적 라우팅 수행

이렇게 정적 라우팅을 수행하면 웹 서버가 다시 외부와 연결이 가능해진 것을 확인할 수 있다.

또한, 외부에서 접속이 가능하도록, VMware 내에서 포트포워딩 설정을 진행해야 하는데, 이는 Virtual Network Editor의 NAT 설정에서 진행할 수 있다.

NAT Settings 위치

해당 버튼을 클릭하면, Port Forwarding 정책을 추가할 수 있다. 필자는 5050포트로 들어오는 IP를 우선 방화벽의 특정 포트로 보내주고, 방화벽은 그 특정 포트에서 받은 정보를 웹 서버의 80포트로 전달해 주도록 포트포워딩을 구성해 주면 된다.

방화벽에서는 6060포트를 사용하도록 하자. 5050포트로 들어오는 IP를 방화벽의 80포트로 보내주고, 방화벽에서 80포트로 정보를 받으면 웹 서버의 80포트로 전달해 주도록 포트포워딩을 구성해 본다.

우선 VMware의 NAT Settings에서 5050포트로 들어오는 정보를 방화벽의 6060포트로 전달하도록 포트포워딩을 구성한다.

1차 포트 포워딩

이후 방화벽에서 6060포트로 들어오는 정보를 웹 서버의 80포트로 전달해 줘야 한다. Untangle에서 Config-Network-Port Forward Rules에 들어간다. 여기서 포워딩 관련 룰을 추가할 수 있다. 이때, Switch to Advanced 버튼을 통해 디테일한 설정을 추가해 준다.

2차 포트 포워딩

이렇게 포트 포워딩을 수행해 준 뒤, Host PC의 5050포트만 열어 주면 외부에서도 Host PC의 5050 포트를 이용하여 웹 서버에 접속할 수 있다.

 

이렇게 인프라 구축은 완료하였다.

반응형

지난 포스트에서 방화벽 설치를 완료하였다. 별도의 정책이 없이 일단은 NAT를 제공하는 게이트웨이 형태로 운영되고 있기 때문에, 방화벽 정책을 설정하기 전에 우선 각 네트워크 영역에 필요한 이미지들을 설치한다.

우선 첫번째는 Office Zone이다. 해당 zone에는 개발자 PC, 관리자 PC가 존재한다. 각각 윈도우7 이미지를 이용하여 구성하고, 네트워크를 구성해 준다.

네트워크 인터페이스 구성 방법은 이전의 방법과 동일하게 Office VMnet에 연결하면 된다. 그리고 윈도우 7 이미지 내부에서 네트워크 설정을 진행해 준다.

제어판 - 네트워크 및 인터넷 - 네트워크 및 공유 센터 에 들어가면 현재 이미지 내 네트워크 상태를 확인할 수 있다. 처음 들어가면 당연히 인터넷 연결이 되지 않고 있다. 네트워크 영역에 맞게 설정을 진행한다. 

네트워크 및 공유 센터

해당 창에서 연결 부분에 있는 로컬 영역 연결을 클릭하면 네트워크 정보를 확인할 수 있다. 해당 네트워크 정보에서 속성을 클릭한 뒤, 로컬 영역 연결 속성을 확인할 수 있는데, 여기서 IPv4에 해당하는 항목을 더블클릭한다. 그러면 IPv4 설정을 진행할 수 있다.

로컬 영역 연결 속성

그러면 IPv4 속성에서 IP주소를 설정해 줄 수 있다. 여기서 수동으로 IP를 지정해 주면 된다. 이후, 잠시 기다리면 링크가 정상적으로 연결되는 것을 확인할 수 있다.

관리자 PC IP 설정
인터넷 연결 확인

이후, 동일한 방법으로 다른 PC도 IP를 설정해 준다.

 

다음으로, HIDS 서버를 구축한다. 필자는 HIDS 서버를 위해 기존에 미리 구축해 둔 우분투 서버를 이용할 예정이다. 우분투 설치의 경우, 차후 IPS에 연결하는 웹 서버를 구축할 때 우분투를 새로 구축할 예정이므로, 그때 상세히 서술한다.

기존의 우분투 서버에 우선 네트워크를 구성한다. 기존에 하던 대로 VMnet을 이용해서 네트워크 인터페이스를 Internal로 설정해 주고, 우분투 내부에서 네트워크 설정을 진행한다.

우분투의 경우, 우측 상단의 아이콘을 통해 네트워크 설정을 진행할 수 있다. 아이콘을 클릭하고, Settings에 들어간다.

이후 설정처럼 생긴 버튼을 누르면 네트워크 설정을 진행할 수 있다.

IP 설정

이후 IPv4 설정으로 들어가 Manual로 주소 및 DNS를 설정해 주면 된다.

이후 네트워크를 한번 껏다 켜거나, 해당 이미지를 재부팅하면 정상적으로 인터넷이 연결되는 것을 확인할 수 있다. 

인터넷이 정상적으로 연결되었다면, 해당 서버의 기능을 정상적으로 수행하기 위해 Wazuh를 설치한다.

Wazuh의 경우, https://wazuh.com/start/ 에서 다운로드 가이드를 확인할 수 있다. Wazuh 서버의 설치 방식에는 All-in-one이 있고, Distributed가 존재하는데, 한 서버에 모든 구성 요소를 담을 예정이기 때문에 All-in-one 방식으로 설치한다.

해당 명령어를 통해 Wazuh 서버를 한번에 설치할 수 있다. 이때, 꼭 root 권한으로 수행되어야 하기 때문에 루트 계정에서 수행한다.

# curl -so ~/all-in-one-installation.sh https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/unattended-installation/all-in-one-installation.sh && bash ~/all-in-one-installation.sh -i

위의 명령어를 사용하면 한번에 설치할 수 있지만, 필자는 각 구성요소를 step-by-step 방식을 이용하여 설치할 예정이다. 

우선 설치를 위해 JDK11, wget, curl, unzip, libcap 등의 패키지가 필요한데, 아래 명령어를 따라가면서 차근차근 실행해 준다.

# apt install -y curl apt-transport-https unzip wget libcap2-bin software-properties-common lsb-release gnupg2
# add-apt-repository ppa:openjdk-r/ppa
# apt update
# export JAVA_HOME=/usr/ && apt install -y openjdk-11-jdk

이후 Wazuh를 설치하기 위해 아래 step을 수행한다.

# curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH 
# echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list 
# apt-get update

# apt-get install wazuh-manager

# systemctl daemon-reload
# systemctl enable wazuh-manager
# systemctl start wazuh-manager

이후 Wazuh에서 사용하는 모듈 중 하나인 Elasticsearch를 설치한다

# apt install elasticsearch-oss opendistroforelasticsearch

# curl -so /etc/elasticsearch/elasticsearch.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/elasticsearch/7.x/elasticsearch_all_in_one.yml

# curl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/elasticsearch/roles/roles.yml
# curl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/roles_mapping.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/elasticsearch/roles/roles_mapping.yml
# curl -so /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/elasticsearch/roles/internal_users.yml

# rm /etc/elasticsearch/esnode-key.pem /etc/elasticsearch/esnode.pem /etc/elasticsearch/kirk-key.pem /etc/elasticsearch/kirk.pem /etc/elasticsearch/root-ca.pem -f

# mkdir /etc/elasticsearch/certs
# cd /etc/elasticsearch/certs
# curl -so ~/search-guard-tlstool-1.8.zip https://maven.search-guard.com/search-guard-tlstool/1.8/search-guard-tlstool-1.8.zip
# unzip ~/search-guard-tlstool-1.8.zip -d ~/searchguard
# curl -so ~/searchguard/search-guard.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/searchguard/search-guard-aio.yml
# ~/searchguard/tools/sgtlstool.sh -c ~/searchguard/search-guard.yml -ca -crt -t /etc/elasticsearch/certs/
# rm /etc/elasticsearch/certs/client-certificates.readme /etc/elasticsearch/certs/elasticsearch_elasticsearch_config_snippet.yml ~/search-guard-tlstool-1.8.zip ~/searchguard -rf

# systemctl daemon-reload
# systemctl enable elasticsearch
# systemctl start elasticsearch

# /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/ -nhnv -cacert /etc/elasticsearch/certs/root-ca.pem -cert /etc/elasticsearch/certs/admin.pem -key /etc/elasticsearch/certs/admin.key

 

이후 해당 명령을 쳤을 때 다음과 같은 output이 나오면 된다.

# curl -XGET https://localhost:9200 -u admin:admin -k
 {
   "name" : "node-1",
   "cluster_name" : "elasticsearch",
   "cluster_uuid" : "J4EAfzd7R4KZv-31jBAuNA",
   "version" : {
     "number" : "7.10.0",
     "build_flavor" : "oss",
     "build_type" : "rpm",
     "build_hash" : "51e9d6f22758d0374a0f3f5c6e8f3a7997850f96",
     "build_date" : "2020-11-09T21:30:33.964949Z",
     "build_snapshot" : false,
     "lucene_version" : "8.7.0",
     "minimum_wire_compatibility_version" : "6.8.0",
     "minimum_index_compatibility_version" : "6.0.0-beta1"
   },
   "tagline" : "You Know, for Search"
 }

이후 Wazuh에서 사용하는 모듈 중 하나인 Filebeat를 설치한다.

# apt-get install filebeat

# curl -so /etc/filebeat/filebeat.yml https://raw.githubusercontent.com/wazuh/wazuh-documentation/4.1/resources/open-distro/filebeat/7.x/filebeat_all_in_one.yml

# curl -so /etc/filebeat/wazuh-template.json https://raw.githubusercontent.com/wazuh/wazuh/4.1/extensions/elasticsearch/7.x/wazuh-template.json
# chmod go+r /etc/filebeat/wazuh-template.json

# curl -s https://packages.wazuh.com/4.x/filebeat/wazuh-filebeat-0.1.tar.gz | tar -xvz -C /usr/share/filebeat/module

# mkdir /etc/filebeat/certs
# cp /etc/elasticsearch/certs/root-ca.pem /etc/filebeat/certs/
# mv /etc/elasticsearch/certs/filebeat* /etc/filebeat/certs/

# systemctl daemon-reload
# systemctl enable filebeat
# systemctl start filebeat

이후 해당 명령을 쳤을 때 다음과 같은 output이 나오면 된다.

# filebeat test output
 elasticsearch: https://127.0.0.1:9200...
   parse url... OK
   connection...
     parse host... OK
     dns lookup... OK
     addresses: 127.0.0.1
     dial up... OK
   TLS...
     security: server's certificate chain verification is enabled
     handshake... OK
     TLS version: TLSv1.3
     dial up... OK
   talk to server... OK
   version: 7.10.0

이후 마지막으로, Wazuh에서 사용하는 모듈 중 하나인 Kibana를 설치한다.

# apt-get install opendistroforelasticsearch-kibana

# mkdir /usr/share/kibana/data
# chown -R kibana:kibana /usr/share/kibana/data

# cd /usr/share/kibana
# sudo -u kibana /usr/share/kibana/bin/kibana-plugin install https://packages.wazuh.com/4.x/ui/kibana/wazuh_kibana-4.1.4_7.10.0-1.zip

# mkdir /etc/kibana/certs
# cp /etc/elasticsearch/certs/root-ca.pem /etc/kibana/certs/
# mv /etc/elasticsearch/certs/kibana_http.key /etc/kibana/certs/kibana.key
# mv /etc/elasticsearch/certs/kibana_http.pem /etc/kibana/certs/kibana.pem

# setcap 'cap_net_bind_service=+ep' /usr/share/kibana/node/bin/node

# systemctl daemon-reload
# systemctl enable kibana
# systemctl start kibana

이후, 해당 서버의 Kibana 웹을 통해 Wazuh를 사용할 수 있다.

Kibana의 초기 아이디와 패스워드는 admin/admin이며, Kibana의 기본 포트는 5601이기 때문에 해당 포트로 접속하면 Wazuh를 확인할 수 있다.

Wazuh Manager 설치 완료

 

이후 명세와 같이, 오피스망에 Wazuh Agent를 설치한다. 오피스망은 윈도우이기 때문에, 홈페이지에서 Wazuh Agent 윈도우 설치 파일을 다운로드 받아서 설치 및 배포를 진행한다.

다운로드 받은 폴더에서 CMD 창을 켜서, 해당 명령을 수행한다.

> wazuh-agent-4.1.4-1.msi /q WAZUH_MANAGER="<SERVER_IP>" WAZUH_REGISTRATION_SERVER="<SERVER_IP>"

필자의 경우, 다음과 같이 명령을 수행했다.

다른 PC들도 동일하게 적용해 준다. 이후 Wazuh Manager에서 Agent를 확인해 보면, PC들이 추가된 것을 확인할 수 있다.

Agent 설정 완료

 

반응형

지난번에 큰 명세는 끝내 놓은 상태에서, 가상 보안 인프라 환경 구축을 시작한다.

우선 Untangle을 설치한다.

Untangle 설치 및 네트워크 구성

Untangle의 설치 자체는 간단하다. 그냥 단순히 Next만 눌러주면 되고, 일반 소프트웨어를 설치하는 방식과 유사하다고 볼 수 있다. Untangle을 설치하고 나면 로그인 창이 뜨고, 설치 시 넣어 준 아이디와 패스워드를 입력하면 다음과 같은 대시보드를 확인할 수 있다.

Untangle 대시보드

Untangle에서 중요한 것은 네트워크 설정이다. 단순히 Next만 모두 눌러준 뒤 부팅이 정상적으로 수행되었다면, 우선 Config - Network에서 Interface 창을 켜 준다. 현재 필자는 모든 설정이 완료되어 있는 상태이지만, 독자를 위해 다시 처음부터 설정을 진행할 예정이다.

우선 VMnet을 이용하여 가상 네트워크 망을 새로 만들어야 한다. 우리가 필요한 망은 1번에서 제시한 구성도처럼, 디폴트로 존재하는 NAT망을 제외하고 Office, Internal DMZ, IPS, External DMZ Zone이 필요하다.

Untangle과 연결하는 망은 NAT, Office, Internal DMZ, IPS뿐이지만, 나중에 External DMZ 망도 만들어야 하기 때문에 미리 네트워크 세팅을 해 줄 것이다. 

우선 VMware 설정의 Edit - Virtual Network Editor로 들어간다.

Virtual Network Editor

이곳에서 전체 VMnet들의 네트워크 설정이 가능하다. 관리자 권한이 아닐 경우, 확인만 가능하고 변경이 불가능하므로 우측 하단의 Change Settings 버튼을 통해 관리자 권한으로 변경한다. 이후 Reloading이 되면, 설정 변경이 가능하다.

Virtual Network Editor

처음에는 디폴트로 VMnet0, VMnet1, VMnet8이 구성되어 있을 것이다. 그중 VMnet8은 NAT으로 기본 설정되어 있다. 우리가 NAT로 사용하던 네트워크가 사실은 VMnet8인 것이다.

우리는 각 망을 모두 Host-only로 구성할 것이다. VMnet에는 Bridged, NAT, Host-only 구성이 존재하는데, 각각의 구성에 대한 내용은 여러 블로그에 충분히 잘 정리되어 있으니 별도로 서술하지는 않는다. 우리가 필요한 구성은 각 VMware 가상 머신끼리 연결되는 것이기 때문에, Host-only 구성을 사용한다.

Add Network 버튼을 누르고, 사용할 VMnet을 고른다. 이후 Rename Network 버튼을 통해 이름을 Office로 변경해 준다. 이름의 경우, 나중에 가상 머신의 네트워크를 세팅할 때 사용되기 때문에, 알아보기 쉬운 이름을 사용하면 된다. 필자는 사전에 정해둔 각 네트워크의 별칭을 사용할 예정이다. 

이후 하단의 Host-only로 칸을 옮겨 주고, 체크박스 2개를 모두 지워 준다. 체크박스의 의미는 각각 호스트PC와 연결한다는 것, 그리고 DHCP 서비스를 사용하는 것인데, 우리는 둘 다 사용하지 않을 예정이므로 둘 다 지워 준다.

이후 Subnet IP와 Subnet mask를 설정해 준다. 필요로 하는 네트워크 ID와 Netmask를 각각 넣어주면 된다. 필자는 Office 망을 192.168.30.0/24로 설정할 예정이기 때문에, Subnet IP에 192.168.30.0, Subnet mask에 255.255.255.0을 기입해 줬다.

네트워크 생성 예시

위 그림과 같이 네트워크를 생성해 주면 된다. 같은 방식으로, Internal DMZ, IPS, External DMZ 영역을 각각 만들어 준다.

VMnet 세팅 완료

이렇게 VMnet 세팅이 완료되었다. 이제 VMnet을 사용 가능하다.

해당 VMnet들을 방화벽인 Untangle에 연결해 줘야 한다. 이를 위헤 네트워크 인터페이스를 추가해 준다.

VMware에서는 VM별로 네트워크 인터페이스를 설정해 줄 수 있는데, 우측 하단의 인터페이스 창에서 우클릭을 통해 Settings로 들어가도 되고, 좌측 라이브러리 창 또는 상단의 탭을 이용하여 Settings에 들어갈 수 있다.

VM Settings

Settings에서는 위와 같은 창이 뜰 것이다. 여기서 네트워크 어댑터를 추가해 주면 된다. 보통 1개로 구성되어 있을 텐데, 메인 어댑터로 두고, Office, Internal, IPS에 연결할 총 3개의 네트워크 인터페이스를 추가해 준다. 각각 우측의 Network Connection에서 Custom으로 설정하고, 우리가 미리 설정해 둔 VMnet 중 별칭을 통해 확인해서 연결해 주면 된다.

네트워크 인터페이스 설정 완료

이렇게 설정이 완료되었다. 이후 Untangle에 들어가서 Config - Network에 들어가면 우리가 연결해 준 인터페이스들이 정상적으로 올라온 것을 확인할 수 있다.

Config - Network
Unknown Interface가 올라온다.

 

인터페이스들이 올라왔으면, edit을 눌러 준다. 이후 Config type을 Addressed로 바꿔 주고, WAN 인터페이스(외부망과 연결되는 인터페이스)만 하단의 Is WAN Interface 칸을 클릭해 준다. 우리는 NAT 영역의 주소가 WAN 인터페이스이다.

그리고 Static으로 주소, 넷마스크, 게이트웨이, DNS를 각각 설정해 준다. 동일한 방식으로 나머지 3개의 인터페이스도 모두 설정해 주고, 우측 하단의 Save를 누르면 방화벽의 네트워크 설정은 끝난다.

네트워크 인터페이스 설정
네트워크 인터페이스 설정 완료

방화벽의 네트워크 설정이 완료되었다. 추가로, 방화벽이 NAT 역할까지 해 줘야 하기 때문에, 하단의 IPv4 Options인 NAT 트래픽을 설정해 준다.

WAN NAT 설정

 

이렇게 방화벽 네트워크 설정이 완료되었다.

반응형

+ Recent posts