Classic_Blue_Note

원본 기사

https://www.boannews.com/media/view.asp?idx=97456 

"기업 10곳 당 1곳에는 오래되어 취약한 프로토콜을 사용하는 장비가 존재한다. 공격자들을 위한 침투 경로가 지천에 널려 있다는 것이다." 기사 中

기사에서는 SMB 프로토콜에 대해 상세히 설명하면서 해당 프로토콜을 사용하는 기업들이 많다고 언급하고 있다. 하지만 실제로 기업에서는 해당 프로토콜 이외에도 다양한 오래된 프로토콜들이 존재한다. 단적인 예로, 필자도 경험한 사례가 있었는데, 내부망이긴 하지만 윈도우XP를 사용하는 PC도 다수 존재했고, 대부분의 PC들이 서비스가 종료된 윈도우 7을 사용했다. 이는 기사에서도 언급하고 잇는데, 많은 조직들이 몇년간 취약한 프로토콜들을 제거하려고 노력해 왔지만, 내부망에서의 프로토콜들에는 상당히 무감각하다고 언급하고 있다.

또한 기사에서는 고급 해커들의 기술들에 대해서도 언급하고 있다. 그들은 누구도 다룰 수 없는 최신식 기술을 사용하는 것이 아니라, 조직 내에서 취약한 부분을 잘 찾아내기 때문이라고 하고 있는데, 워너크라이 랜섬웨어 사태에서만 봐도, 오래된 프로토콜인 SMB에서 발생했는데, 지금도 여전히 SMB는 널리 사용되고 있다.

기업 내부에서는 이보다 더 많은 프로토콜이 사용되고 있을 것이다. 그리고 그중에는 이미 취약점이 충분히 발견되었으나, 기업의 사정에 의해 업그레이드 할 수 없는 프로토콜들도 존재할 것이다. 이러한 프로토콜이 존재할 수 있다. 하지만 이를 아는 것과 모르는 것은 천지차이이다. 기업 내부에서 어떤 프로토콜이 실행되고 있는지 파악하고, 가시성을 확보하여 위험에 대비하는 것이 급선무인 것이다.

실제로 기사에서도 해당 내용을 언급하고 있다. 기업 내부에서 어떤 프로토콜이 실행되고 있는지 모르는 경우가 대다수였고, 이를 은둔의 IT라고 부르기도 했다. 오래된 프로토콜 역시 같은 맥락이라고 볼 수 있다.

기업 내부의 프로그램이 파악된다면, 파악된 정보들을 토대로 회사 내에서 꼭 필요한 프로토콜이 아닌 이상 업그레이드하거나, 프로토콜을 사용하지 않는 등의 조치가 필요하다. 하지만 회사 내에서 꼭 필요한 경우, 다른 프로토콜로 교체를 검토하거나, 보안 대책을 추가로 세우는 등의 방법을 통해 위험을 감소시킬 수도 있고, 온프레미스가 아닌 클라우드 환경을 사용하는 등 위험 전가 대책을 세울 수도 있다. 하지만 모든 위험 대책의 첫번째는 자원의 파악이다. 현재 어떤 식으로 기업의 IT 환경이 돌아가고 있는지 파악하는 것이 우선시 되어야 할 것이다.

원본기사

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

"우리 사회 전반에서 디지털화가 가속화되고 있다. 종이나 카드 같은 실물로 가능하던 일들이 이제는 스마트폰을 통해 이뤄지고 있다." (본문 中)

기사에서 말한 것과 같이, 디지털 뉴딜 정책의 일환으로 진행되는 '디지털 신분증' 구축사업도 이와 같은 맥락이다. 실물 실분증의 분실, 위/변조 및 도용 문제 등 고질적인 문제점을 해결하고, 온/오프라인을 아우르는 신원증명 수단의 필요성에 따라 이를 추진했다. 실제로 최근 모바일 공무원증을 필두로 각종 모바일 신분증들이 운영을 시작하고 있다.

정부가 지원하고 있는 디지털 신분증 사업은 정부가 발급하여 공신력을 부여하고, 블록체인을 기반으로 하는 DID 기술을 적용하여 디지털 신분증 사용 및 검증을 수행하고 있다. 탈중앙화를 통하여 신원을 증명하고, 해당 신원증명 정보를 블록체인에 공유하여 사용 및 검증에 있어서 타인이나 기관이 개입할 수 없도록 하고 있다.

DID 기술이란 분산 ID 신뢰 저장소를 통하여 운영되는 ID 서비스를 의미하는데, 기존 기관의 자체 데이터베이스, 또는 OAuth를 이용하여 타 인터넷 서비스 기업들의 데이터베이스를 사용하여 ID 서비스를 제공했다면, 이제는 블록체인을 통하여 신뢰 저장소를 구축, ID서비스를 제공하는 기술을 의미한다. 블록체인의 특성을 통하여 개인의 데이터 주권을 실현하고, 위/변조를 검증할 수 있다는 점을 이용하여 ID 서비스로의 활용성을 더욱 높이고 있다.

신기술의 도입은 양날의 검이다. 신기술의 발전에 따라 더 편한 서비스를 제공할 수도 있지만, 어떤 문제점이 발생할지는 아무도 모르는 것이다. 하지만 반대쪽 날을 잘 다스릴 수만 있다면, 검 없이 싸우는 것보다는 나을 것이다. 또다른 문제로, 양날의 검을 다스리기 위해 날을 모두 없애 버린다면 그 검을 사용하는 의미 또한 없어질 것이다.

신기술을 통해 지속적으로 개인정보 서비스도 발전해가고 있는데, 적절한 규제를 통해 안전한 서비스를 제공해야 하겠지만, 너무 과도한 제재로 인해 기술의 의미가 없어지는 것도 좋지 않은 상황일 것이다. 그 적절한 균형을 맞추는 것이 중요하다.

원본 기사

www.boannews.com/media/view.asp?idx=97016&skind=D

어도비에서 "원스톱 어노말리 숍(One-Stop Anomaly Shop)", 줄여서 OSAS라는 오픈소수 도구를 개발하여 공개하였다. 해당 도구는 머신러닝을 기반으로 하고 있고, 데이터 셋에서 이상한 점을 발견하게 해 주는 기능을 갖고 있다. 데이터 유형별 레이블을 생성함으로써, 로그 데이터에 새로운 구조를 추가해 주는 머신러닝 도구라고 볼 수 있다.

OSAS를 사용할 경우, 특정 데이터 셋에서 어떤 변수, 또는 변수의 조합이 가장 좋은 결과를 가져다 줄 지 빠르게 알 수 있다고 기사에서 설명하고 있다. 컴퓨터 연산에서 이상 현상을 잡아내는 것과 데이터 셋의 맥락에서 이상한 이유를 밝혀내고 설명하는 것은 또 다른 의미이기 때문에, 후자의 부분에서 OSAS가 유용하게 사용될 수 있다고 설명하고 있다.

OSAS는 ELK Stack을 기반으로 만들어져 있으며, 도커 이미지를 통해 배포되고 있다. 또한 머신러닝 부분은 파이썬으로 작성되어 있다. 배포 가이드는 공식 깃허브를 통해 확인할 수 있다.(https://github.com/adobe/OSAS)

어도비 외에도 다양한 소프트웨어 개발 업체들이 머신런이 관련 도구들을 무료로 풀어나가고 있다. 이번달 초에도 마이크로소프트에서 MITRE의 ATT&CK 프레임워크를 이용하여 자사의 공격 트래픽 데이터를 결합한 머신 러닝 모델을 공개한 적이 있었는데, 이처럼 거대한 기업에서 오픈 소스 생태계에 기여하는 것은 좋은 영향력을 행사할 수 있을 것으로 보인다.

보안에서 오픈소스란 양날의 검이다. 오픈 소스 생태계를 통해 여러가지 좋은 보안 솔루션 또는 소프트웨어들을 무료로 사용할 수 있어 비용적인 측면에서 긍정적이지만, 소스가 공개되어 있는 만큼, 공격자들의 화이트박스 테스트를 통한 공격이 가능하기 때문이다. 과거에는 이러한 문제 때문에 오픈소스 기여를 잘 안하는 경우가 많았지만, 최근 보안 생태계에서도 ELK, Snort 등을 기반으로 한 오픈소스 도구들이 늘어가는 추세이다.

이러한 오픈소스 도구들이 늘어나면서, 단순히 오픈소스를 그 자체로 사용하는 것이 아니라, 여타 프로그램에 응용해서 사용하는 경우도 많이 있었는데, 최근 보안 시스템 구축 실습 과제를 진행하면서 사용했던 Wazuh도 그 중 하나이다. 해당 프로그램 역시 ELK Stack을 기반으로 운영되고 있으며, Kibana App 형태로 서버를 운영할 수 있도록 구축되어 있다.

보안도 점차 오픈소스 생태계에 적응해 나가는 만큼, 오픈소스에 대한 투자와 지원도 이루어져야 할 것이다. 단순히 사용하는 것만 아니라, 꾸준한 기여를 통해 오픈소스 생태계에서의 한 가닥으로 나아가는 것은 어떨까.

원본 기사

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이후 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} 형태의 파일을 이용한다.

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

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

이후, iptables에 FORWARD 정책을 NFQUEUE로 넣어 준다. 이를 통해, Suricata 프로그램을 통해 정상적으로 포워딩을 진행할 수 있다. 이때, NAT 설정까지 해 주면 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 설정에서 진행할 수 있다.

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

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

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

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

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

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