[펌] 보안 PortSentry
os/Linux 2004. 6. 30. 08:32 |Psionic PortSentry - 포트 스캔 탐지와 능동적 방어
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
$Id: README.install,v 1.30 2002/04/08 17:24:14 crowland Exp crowland $
E-Mail : sentrysupport@psionic.com
Date : 04-08-2002
Version: 2.0b1
소 개
=-=-=
이것은 긴 인스톨 매뉴얼이다. 만일 여러분이 뒤에 이어질 모든 것과 프로그램 로직안에 깃든 나의 광기어린 방법을 이해하길 원한다면, 여러분은 이 매뉴얼 파일을 읽어야만 한다.
만일 여러분이 이런 것에 대해 관심이 없다면 아래의 내용들을 뛰어넘어라.
PortSentry는 보안 제품들 중에 Psionic의 TriSentry Suite의 일부분이다.
만약 여러분들이 이 도구가 마음에 들고 여러분들이 정말 우리의 다른 제품들에 관심이 있다면 우리의 웹사이트를 참고하라:
http://www.psionic.com
PortSentry는 포트스캔을 탐지하기 위한 많은 옵션들을 가지고 있다.
포트스캔이 발견되면, PortSentry는 다음과 같은 방식들로 반응한다.
- 사건을 나타내는 log 는 syslog()를 통해 만들어진다.
- 타겟 호스트(포트 스캔 공격을 한 컴퓨터)는 TCP Wrappers를 위해서 자동적으로 /etc/hosts.deny에 기록된다.
- 로컬 호스트에서는 타겟 시스템을 데드 호스트(인터넷상에 없는 컴퓨터)로 간주하여, 타겟 호스트를 경유하는 모든 경로가 자동적으로 재구성된다.
- 로컬 호스트는 로컬패킷필터를 통하여, 타겟 호스트로부터 오는 모든 패킷을 무시하기 위하여 자동적으로 재구성된다.
이러한 의도는 관리자에게 그들의 호스트가 스캔되고 있다는 것을 확신시켜주기 위함이다.
이미 이러한 동작을 하는 유사한 프로그램들이 있다.( klaxon 등등) 나는 단지 전체적인 아이디어에 작은 변화(auto blocking 과 같은)를 더했을 뿐이다. 더하여, 스텔스 스캔 탐지(stealth scan detection)를 위한 포괄적인 지원까지...
PortSentry 2.x는 libpcap을 사용하기 위해서 재구성되었다. 이전에 공격을 감지하기 위해 묶여진 포트들을 사용하던 "고전적인" 모드들은 사라졌다. 만약 그 "고전적인" 모드들을 선호한다면, PortSentry 1.1 버전을 사용하길 바란다.
설치
=-=-=-=
첫 단계:
여러분의 에디터로 portsentry_config.h 파일을 가져와서 다음사항이 여러분이 원하는 바와 맞는지 확인해라:
CONFIG_FILE - PortSentry 구성파일의 경로
WRAPPER_HOSTS_DENY - TCP wrapper의 hosts.deny 파일의 경로와 이름
SYSLOG_FACILITY - PortSentry가 사용할 syslog 프로그램
SYSLOG_LEVEL - 메시지를 보내기 위한 syslog level
나는 여러분이 무엇을 하고 있는지 알지 못한다면 이러한 옵션들을 절대 바꾸지 말 것을 제안한다.
※ 참고
1. 고급사용자들은 SYSLOG_FACILITY를 LOG_DAEMON에서 LOG_LOCAL0로 바꾸고 싶어할 수도 있을 것이다. (아니면, 또 다른 LOCAL log 감시프로그램)
여러분은 syslog.conf 파일을 편집할 수 있으며 이것으로 분리된 모니터링을 위해 PortSentry 메시지를 직접 시스템에 있는 PortSentry 자신만의 파일에 가져다 놓을 수도 있다.
2. [경고] : 절대로 이 파일 내용에서 "#" 표시를 지우지 마시오.
이런 "#" 표시들은 주석표시가 아니라, 헤더들을 예비적으로 처리하기 위해 C 컴파일러를 요구하는 것들입니다.
만약 여러분들이 "#" 표시들을 지워버린다면 여러분들은 컴파일 에러들을 보게 될 것입니다.
3. 참고 2번을 다시 한번 읽어보라. 우리는 "#" 표시를 지우고 그로 인해서 프로그램을 컴파일 할 수 없게 되어 문의를 해오는 수많은 사람들을 보았다. portsentry_config.h 파일은 2.x 버전이 베타 버전으로 있는 한은 계속 같이 존재할 것이다.
두번째 단계:
이어서, portsentry.conf를 여러분의 에디터로 가져와서 다음의 옵션을 체크하고 바꿔라:
INTERFACE - 여러분이 모니터 하기를 원하는 interface(CPU와 단말 장치와의 연결 부분을 이루는 회로) 이름. 대부분의 사람들은 이 부분을 "auto"로 남겨둘 수 있고 이 때 PortSentry는 첫번째 interface를 선택하여 모니터 할 것이다. 다른 분들은 아마도 여러개의 interface들을 가지고 있음에도 오직 하나만 보기를 원할 것이다(말하자면 외부 방화벽 interface). 이런 경우는 여러분들이 interface 이름을 직접 설정해 줄 수도 있다. eth0를 보기 위해서는 "/dev/eth0"과 같이 경로명을 포함시키지 말고, 단순히 interface 이름 "eth0"를 적어 넣는다. 등등.. 이런 식으로... PortSentry는 한 번에 오직 한 개의 interface 만을 볼 수 있기 때문에 여러개의 Interface 이름을 적어 넣으면 안된다.
INTERFACE_ADDRESS - PortSentry는 당신이 감시하려 하는 Interface의 IP 주소를 필요로 한다. 현재 버전의 PortSentry는 자동으로 해당 Interface의 IP주소를 찾아내지 못한다. 하지만 앞으로 곧 지원될 것이다. 만약 여러분이 IP 주소를 적어 넣지 않는다면 PortSentry는 당연히 아무런 일도 하지 않을 것이다. 이것은 DHCP 또는 유동 IP 사용자들에게는 적합하지 못하다(매번 바뀌어지는 IP주소를 적어 넣어주고 재시작 해야하므로...-.-a). 하지만 베타 버전이 버전업 되면서 DHCP나 유동 IP 사용자들도 편리하게 사용할 수 있도록 할 것이다. 현재로서는 매번 IP주소를 적어주거나 아니면 스크립트를 작성하여 매번 시스템을 재시작 할 때마다 자동으로 실행되어 새로이 바뀐 IP주소를 자동으로 지정해 주도록 해줘야 한다.
TCP_PORTS - 콤마(,)로 분리된 PortSentry가 감시하기를 원하는 TCP포트의 문자열. 이 문자열은 그 안에 어떠한 공백문자도 가져서는 안된다. 여러분은 여러분이 원하는 만큼의 소켓을 집어넣을 수 있다. 하지만 아마도 Berkely Packet Filter (BPF) 의 길이가 너무 커져서 문제가 될 수도 있다. 만일 이런 문제가 발생한다면 여러분들은 로그 파일에서 에러 메시지를 볼 수 있을 것이고 문자열의 길이를 더 줄여야만 할 것이다.
UDP_PORTS - 이것은 UDP 포트 라는 것을 제외하고는 위와 동일하다.
IGNORE_FILE - 여러분이 항상 무시하길 바라는 호스트의 IP 주소들의 목록이 기록된 파일의 경로. 이것은 나중에 설명될 것이다.
BLOCKED_FILE - 접속금지(blocked)된 호스트의 IP 주소들의 목록이 기록된 파일의 경로.
RESOLVE_HOST - 이 옵션은 호스트들에 대한 DNS 해석을 꺼버린다. 만약 여러분이 느린 DNS 서버를 가지고 있다면 해석을 끄는 것은 더욱 효과적일 것이다. 또한 만약 여러분이 이것을 켜놓는다면 공격자는 되돌아 오는 DNS 응답을 볼 수 있을 것이고 여러분이 연결상태를 감시하고 있다는 것을 (공격자가) 알게 될 것이다. 기본값으로 이 옵션을 꺼놓는다.
BLOCK_UDP -이 옵션(0)은 UDP탐지에 대한 모든 자동적인 반응을 못하도록 한다. UDP는 쉽게 위조될 수 있기 때문에, 정상적으로 존재해야 할 모든 호스트들을 접근금지 시키는 방식으로, 공격자가 보호받는 호스트에 대해 DOS공격(서비스거부공격)을 할 수 있다. 이 옵션을 "0"으로 하면 연결이 여전히 log된 상태라도, 모든 자동적인 반응을 못하게 할 것이다. 이 옵션(0)은 주로 인터넷에 노출되어 있는 호스트에 유용하다. 내부 호스트에 대해서는 여러분은 이 옵션을 (자동적인 반응이) 가능 하도록 놔둬야 할 것이다. 만약 누군가 내부적으로 여러분에게 스푸핑된(spoofed) 패킷을 보낸다면 여러분은 서비스거부보다 더 큰 문제점에 직면하게 될 것이기 때문이다.
BLOCK_TCP - TCP라는 것을 제외하곤 BLOCK_UDP와 같다. (패킷 위조는 그리 큰 문제가 아니다. 왜냐면 PortSentry가 완전한 접속이 이루어지를 기다리고 있고, 이것은 베이직모드에 있어 패킷위조를 하는 것보다 더 힘들기 때문이다. 나는 이것을 인터넷에 연결된 호스트에 대해서도 사용가능하도록 남겨둘 것이다.) 스텔스 스캔 탐지모드에 있어서 UDP 경고는 다음과 같다:
공격자는 패킷 위조를 통하여, 여러분이 막지 않길 원하는 호스트에 대해서 접근금지(block)시킬 수 있다.
(나는 이것이 문제가 될 때까진 걱정하지 않지만 여러분은 이것에 대해 인식하고 있어야 한다.)
수개월간 우리는 이 명백한 문제에 대해서 글을 올리고 말해주는 사람들을 접해왔다. 그렇다. 우리는 패킷 위조, 서비스 거부, 등등에 대해서 알고 있다. 우리는 단지 그 문제의 심각성을 시스템 절충안과 비교하지 않는다. 우리는 이 옵션을 대부분의 호스트([방화벽] 위에서 싸우기 일쑤인 특정 호스트들을 제외하고)들에 대해서 사용 가능하게(막도록) 놔둘 것이다. 여러분이 어떤 설정을 해야 할 지에 대한 좀 더 자세한 답변은 README.stealth를 읽어보라.
KILL_ROUTE - 여기에는 공격이 탐지되었을 때, 공격자가 타고온 경로를 없애기(drop) 위해 실행될 명령을 정의할 수 있다. 정상적인 실행을 위해서는, *절대경로* 전체와 필요한 옵션을 다 붙인 route 명령이 필요하다. $TARGET$ 문자열은 공격하고 있는 호스트 IP주소로 대체될 것이며, 반드시 이 옵션안에서 존재해야 한다. 자신의 gateway는 local subnet상에서 *죽어있는 호스트*가 될 것이다. 어떤 시스템에서는 로컬호스트 주소인 (127.0.0..1)을 넣더라도 아마 작동을 할 것이다. 공격중인 호스트로부터의 모든 패킷은 이 주소로 보내질 것이며, 호스트를 엉망으로 만들지 않을 것이다. 좀 더 현대적인(발전된) route 명령어는 "-blackhole" or "-reject" 옵션을 포함할 것이다. 여러분의 man(1) 페이지를 체크해 보라. 만약 route 명령어가 이런 기능을 지원한다면 이것을 사용할 수 있다.(비록 그럴지라도 나는 그 대신에 패킷필터링을 사용할 것을 권장한다. 아래를 참조하라.)
또한 "asynchronous route"라고 알려진, 기본적으로는 하나의 루트를 통해 여러분의 호스트에 들어가고 다른 (죽은) 루트에 보내져버리는 패킷을 의미하는, 것이 생길 수 있음을 알고 있어야 한다. 이것은 완전한(full) TCP 접속요구에는 잘 동작하지만, UDP나 스텔스 스캔모드에 있어서는 이것은 패킷이 PortSentry를 활성화시키는 것을 여전히 허용하고 여러분은 PortSentry가 보내주는 "already blocked"라는 경고를 계속하여 받게 될 것이다. UDP 스캔에 대해서 이 방법은 ICMP message들이 공격자에게 되돌아가는 것을 막아서 모든 포트가 open 된 상태로 나타나게 된다. 그러나, 만약 공격자가 실제 공격소스 exploit를 실행하고 있다면, 앞의 drop route 방법은 소용이 없다. asynchronous route는 만약 공격자가 대응되는 응답이 어떻게 진행 될지 알고 있으면, 패킷이 시스템에 도달하게 되고, 공격자가 UDP를 이용하여 장님상태의 (blind) 공격을 할 수 있도록 허용할 것이다.
이것을 막는 최선의 방법은 Linux ipfwadm/ipchains 나 *BSD ipfw와 같은 로컬 패킷필터를 사용하는 것이다. 이것은 매우 깔끔한 방법이며 config 파일안에 자세하게 설명되어 있다. $PORT$ 문자열은 공격자에 의해 연결된 포트로 대체될 것이지만, 이 옵션이 항시 요구되는 것은 아니다. $MODE$ 문자열은 (tcp, udp)에서 blocking이 일어난 모드를 나타내는 것이지만, 이 역시 항시 요구되는 것은 아니다.
KILL_HOSTS_DENY - 이것은 TCP wrappers가 사용하는 hosts.deny 파일에 적기 위한 스트링의 포맷이다. 다시말해 $TARGET$ 문자열은 공격자의 IP로 대체되기 위해 확장되며 반드시 요구된다. 여러분은 (%h, twist 등)뿐만 아니라 어떠한 TCP wrapper의 escape 코드들을 넣을 수 있다. $PORT$ 문자열은 공격자에 의해 연결된 포트로 대체될 것이지만, 이 옵션이 항시 요구되는 것은 아니다. $MODE$ 문자열은 (tcp, udp)에서 blocking이 일어난 모드를 나타내는 것이지만, 이 역시 항시 요구되는 것은 아니다.
KILL_RUN_CMD - 이것은 공격자를 향한 route를 제거하기 *이전에* 작동시키기 원하는 명령이다. 공격이 탐지되었을 때, 여러분이 실행하기 원하는 어떠한 program이나 script를 집어넣을 수 있다. 나는 절대 ATTACKING HOST(공격하는 호스트)에 대해서 보복공격 작업을 집어넣지 않길 권고한다. 실제로, 포트스캔을 하고 있는 호스트는 해킹을 당한 임의의 호스트이다. 그러므로, 만약 여러분이 보복을 한다면, 아마도 여러분은 선량한(?) 사람들을 공격하는 것이 될 것이다. 보안의 목적은 쫓아버리는 것이다. 여러분은 그들을 화나게 해서 여러분에게 개인적인 복수를 하게 되기를 원치 않을 것이다. 유념하라. 비록 13살 어린이도 그들의 윈도우 컴퓨터에서 DoS(서비스거부) 공격을 실행하여서, 여러분의 인생을 비참하게 만들 수 있다는 것을...
위에서 보았듯이 $TARGET$, $PORT$, 그리고 $MODE$ 문자열은 유용하지만 이 옵션에 반드시 요구되는 것은 아니다.
KILL_RUN_CMD_FIRST - 이 값을 "0"으로 설정하면 위의 명령이 route가 제거되기 전에 실행되도록 만든다. 이 값을 "1"로 설정하면 위의 명령이 이미 blocking이 된 후에 실행되도록 만든다. (역자 주: portsentry.conf 파일의 해당 설정 부분의 주석 설명을 보면 "0"이 이후에 실행되는 것이고 "1"이 이전에 실행되는 것으로 반대로 설명이 되어 있습니다. 아마도 portsentry.conf 파일에 있는 내용이 맞는 것 같습니다.. README.install 파일 내용이 틀린 듯 하네요.. 쩝.. );P
SCAN_TRIGGER - PortSentry는 자신의 호스트에 접속하였던 호스트를 기억하는 state engine를 가지고 있다. 이 값의 설정은 PortSentry가 반응동작하기 전에 PortSentry에게 감시되는 port의 몇 번까지의 접속을 허용하도록 말해줄 것이다. 이것은 순차인 것과 임의적인 포트스캔을 둘 다 탐지한다. 디폴트값은 0이며, 이는 즉각 반응한다. 그 값을 1 또는 2로 해주면 잘못된 경고를 줄일 것이다. 그리고 이보다 높은 값들은 3회이상 다른 포트들에 접근했을 때와 같은 경우, 아주 수상한 행동을 감지하게 될 것이다. 일반적으로 여러분은 아무런 생각없이, 이 값을 0으로 놔둘 수 있다.
세번째 단계:
여러분의 문서 편집기로 portsentry.ignore 파일을 가져와서 그 안에 감시되고 있는 포트에 접근해도 (보안장치를 작동하지 않고) 무시해 버릴 호스트를 추가하라. 이것은 적어도 localhost(127.0.0.1)와 내부 네트워크의 IP주소를 포함해야만 한다. 우리는 *절대* 여러분과 동일네트워크상에 있는 모든 호스트 IP 주소를 집어넣는 것을 권장하지 않으며, 대신 그렇게 하기 위해서 여러분들은 netmask를 사용할 수 있다. 설정하는 형식은 아래와 같다:
<IP Address>/<Netmask Bits>
192.168.2.0/24
192.168.0.0/16
등등...
우리는 너무 많은 호스트들을 적어 넣는 것을 권장하지 않는다. 아주 "신뢰관계"에 있는(friendly) 호스트일지라도 여러분에게 있어 누가 여러분에게 연결을 하고 있는지를 보는 것은 아주 중요한 일일 것이다. 이것은 여러분이 내부 호스트의 결탁(외부의 해킹에 의한)을 보다 빨리 탐지하는데 도움을 줄 것이다.
자신의 편집증에 충실해라. 그렇다. 이런 일은 일어나며 우리는 *상당수*의 경우 관리자들이 너무 많은 무시해버릴 호스트들을 적어 넣었고 그들 *내부 호스트들의 결탁(외부의 해킹에 의한)*에 의해서 해킹당했다는 사례들을 들었다.
네번째 단계:
컴파일(Compile). make 명령을 내리면, 여러분은 여러분의 시스템타입을 고르고, build하고 인스톨할 수 있게 된다. 원래 default directory는 /usr/local/psionic/portsentry2 이다. 만약 여러분이 이 디렉토리가 마음에 들지 않는다면 Makefile을 수정하고 새로운 경로에 영향을 주는 여러분의 portsentry.conf 와 portsentry_config.h 파일들을 확인하라.
build한 후에 make install 명령을 내리면 여러분이 지정한 인스톨 디렉토리에 복사본 파일들을 만들어 준다.
다섯번째 단계:
PortSentry를 작동시켜라. 설치한 후에 PortSentry를 작동하는데 있어 두 가지 방법이 있다:
1) 설치 디렉토리(/usr/local/psionic/portsentry2, 등등..)로 이동(cd)하여 다음을 실행시켜라:
./portsentry
2) 바로 명령을 실행시켜라:
/usr/local/psionic/portsentry2/portsentry
"Stealth" TCP scan detection mode [BETA] (스텔스 TCP 스캔 탐지 모드 - 베타)
PortSentry는 자신의 호스트로 들어오는 모든 패킷들을 감시할 것이다. 만일 들어오는 패킷이 portsentry.conf 설정 파일에서 TCP_PORTS 변수에 입력되어진 감시 대상 포트 목록의 포트를 향한다면 그에 대응하여 호스트를 막아버릴 것이다.
이 방법은 connect() 스캔, SYN/half-open 스캔, XMAS 스캔, FIN 스캔, NULL 스캔, 등을 감지해 낼 것이다. UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
"Stealth" UDP scan detection mode [BETA] (스텔스 UDP 스캔 탐지 모드 - 베타)
이것은 위의 TCP stealth mode와 작동방법은 동일하다. UDP 포트들을 나열하면, 그 포트들은 감시된다. 이것은 어떠한 소켓도 묶지 않으며, 실제 스텔스 스캔 탐지 모드가 아닌 중에도 거의 동일하게 동작한다.( 모든 UDP 패킷에 반응한다.) UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
** Advanced Logic Mode **
-PortSentry는 포트들을 감시하는 방법이 아주 뛰어나다. FTP와 같은 몇몇 프로토콜에 있어서, 클라이언트는 실제적으로 ephemeral range인 1024번에서 65535번까지의 범위에서 포트들을 연다. 그리고 서버는 *역으로* 여러분에게 접속한다. 보통은 이런 방식이 포트스캐너가 동작할 수 있게 해준다. 그러나 PortSentry는 호스트로 들어오는 접속을 감시할 것이고, 이러한 "임의적인" 접속연결(binding)로 향하는 것인지 아닌지를 결정할 것이다. 만약 임의적인 접속연결로 향한다면, 그 한번의 접속이 무시된다. 접속이 끊어지자마자 window는 닫히고 모든 방어체계가 다시 활동한다. 이것은 실제로 초보적인 stateful inspection engine이다. UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
인스톨을 확인하라:
local log 파일의 마지막부분에 PortSentry의 초기화 메시지가 있어야 한다.
성공적인 PortSentry의 초기화 메시지는 아래와 같이 나타날 것이다:
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: Monitoring interface eth0 and address: 10.1.1.1
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: Monitoring TCP ports: 1,11,110,143,635,1080. . .
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: PortSentry is initialized and monitoring.
********************************************************************
** 마지막 줄은 PortSentry가 적절하게 초기화되었음을 나타낸다...... **
** 만약 여러분이 이런 메시지를 보지 못했다면 무언가가 틀린 것이다. **
********************************************************************
이제 여러분은 다른 호스트로 가서 텔넷으로 은폐된 폭팔물(PortSentry)이 장치된 포트로 접근할 수 있다.
[주의] 절대로 여러분이 서비스 받을 위치에서 보호받는 호스트로 접근하지 마시오. 이유는 만일 그렇게 하면 여러분은 스스로 자신을 막아버리게 될 것이기 때문이다.
위의 주의점을 다시 한 번 숙지하라. 우리는 아래와 비슷한 것을 우리에게 알리는 사람들을 봤다.(만들어진 예기지만, 여러분들은 이 예기를 참고 할 수 있다)
"안녕하세요, 제가 일년에 일주 정도만 헬리콥터를 타고서만 접근가능한 north atlantic의 고립된 석유 시추선에 있는 나의 웹 서버에다가 port sentry 를 설치했는데요. 그리고 나서 저는 웹 서버에 접속할 수 있는 온전한 행성에서 유일한 관리 시스템으로 가서 보호받는 포트에 텔넷으로 접근하여 port sentry 를 테스트 해 보았습니다. 지금으로서는 port sentry가 온전하게 작동하는 것 같습니다. 왜냐하면 제가 저의 컴퓨터에 접근할 수 없기 때문입니다. 하지만 이젠 제 컴퓨터에 접근해야겠는데요. 저 좀 도와주시겠어요?"
그건 그렇고...
여러분은 곧 다음과 같은 것들을 보게 될 것이다:
Mar 5 21:17:39 packetmonkey portsentry[2286]: attackalert: Host 192.168.2.15 has been blocked via wrappers with string: "ALL: 192.168.2.15"
Mar 5 21:17:39 packetmonkey portsentry[2286]: attackalert: TCP SYN scan from host 192.168.2.15/192.168.2.15 to TCP port: 143 from TCP port: 31337
만약 여러분이 접속이 끊어지고 다시 telnet으로 접속하기를 시도한다면 여러분은 방금 전의 호스트에 접근할 수 없음을 확인해야 한다. 이러한 동작이 확인된다면, 축하한다! 여러분은 PortSentry를 제대로 작동시킨 것이다.
만약 여러분의 로그체크 데몬이 띄워져 있다면 여러분이 서버에 접속할 때, 위의 접근거부 상황에 대한 경고 메시지 내용이 로그파일에 나타나는 것을 확인할 수 있을 것이다.
만약 여러분이 netstat -rn 명령을 하면 여러분은 이전에 동작하던 의심가는 호스트로의 죽은 경로를 보게 될 것이다.( 내가 이전에 권장했던 것과 같이, 패킷필터를 사용하지 않으면...)
PortSentry 명령들을 리눅스 시작 스크립트파일(startup file)에 쓰고 나서, 여러분이 한 작업으로 돌아와라.
이게 어떻게 도움이 될 것인가 하면??
여기 몇몇 좋은 생각들이 있다.
- Run as a UDP service on port 69 to catch TFTP probes.
(TFTP 침입을 잡기 위해서는 포트 69에 UDP 감지모드를 가동하라.)
- Run as a UDP service on port 161,162 to catch SNMP probes.
(SNMP 침입을 잡기 위해서는 포트 161,162에 UDP 감지모드를 가동하라.)
- Run as a UDP service in the port range 32000-33000 to catch RPC probes.
(RPC 침입을 잡기 위해서는 포트범위 32000-33000 에 UDP 감지모드를 가동하라.)
- Run as a TCP service on port 143 to catch IMAP probes.
(IMAP 침입을 잡기 위해서는 포트 143에 TCP 감지모드를 가동하라.)
- Run as a TCP service on ports 11,15 to catch netstat/systat probes.
(netstat/systat 침입을 잡기 위해서는 포트 11,15에 TCP 감지모드를 가동하라.)
- etc. 등등
실제로 PortSentry는 빠르게 반응해서, 공격자에 의한 호스트 포트스캔은 감시대상 포트에 접근이 있은 후 1초이내에 차단될 것이다.
UDP 스캔에 대해서는 모든 포트가 "열려진 상태"로 나타나게 함으로써 여러분을 스캔하는 이들을 매우 짜증스럽게 만들 것이다.
TCP 스캔에서 공격자는 어떠한 응답도 얻을 수 없을 것이다.
안전성
=-=-=-
만약 우리가 프로그램의 안전에 대한 고려사항 중 잊고 놓친 것이 있다면, 여러분이 그 내용을 BugTraq에 올리기 전에 우리에게 알려주기를 원한다 :).
메시지
=-=-=-=-
가능한 모든 states/errors/successes and unknowns(상태/오류/성공 그리고 알 수 없는 것들)은 syslog 파일에 쓰여진다.
다음의 tag들이 의미하는 바는:
adminalert: - PortSentry의 상태를 나타내는 메시지.
securityalert: - 보안 관련 사건들이 일어났음을 나타내는 메시지
attackalert: - 스캔을 감지했다는 것과 그에 따른 동작이 실행되었다는 것.
파일들
=-=-=
현 상태로는, 모든 호스트들은 그들이 접속금지(blocked) 되었을 때 portsentry.history 파일뿐만 아니라 portsentry.blocked 파일에 기록된다. blocked file은 PortSentry가 다시 시작될 때마다 지워진다. history file은 간단히 덧붙여지며 일정한 기한까지 접속금지(blocked)된 호스트들의 기록으로 사용할 수 있다.
기한이 지난 후에 여러분은 공격했던 호스트들에 대해 죽은 경로를 삭제하고, 호스트를 hosts.deny 파일에 저장하길 원할 수도 있다. 이것은 전적으로 여러분의 결정에 달려있다. 만약 여러분이 공격자가 다시 접근할 때 접근금지(blocking)을 작동시키기를 원한다면, 단지 PortSentry를 재시작하거나 혹은 blocked file에서 개개의 호스트를 제거하면 된다.
대부분의 시스템에서 여러분이 접근금지시킨 호스트로의 경로를 회복시키길 원한다면 여러분은 단순히 아래와 같이 경로를 지움으로써 회복시킬 수 있다:
리눅스:
route del <ip_address> reject
기타:
route delete <ip_address> <dead_route>
또는 간단히 여러분의 패킷 필터들을 쏟아냄으로써 가능하다.
이것이 바로 내가 말하고자 한 것이다. 로그파일의 내용을 보는 것뿐만이 아니라 여러분이 다른 문제점들도 알 수 있도록 하기 위해서, 나는 여러분이 Abacus 프로젝트의 Logcheck를 사용하길 강력히 권장한다. 그리고 PortSentry가 여러분에게 무엇을 알리려고 하는지 살펴보길 권장한다. 여러분은 본 프로그램을 아래 주소에서 찾을 수 있다:
http://www.psionic.com
이 문서를 읽어준 것에 감사히 생각하고, 질문이나 추가적인 조언이 있다면 내게 메일로 써 주기를 바란다.
감사한다,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
$Id: README.install,v 1.30 2002/04/08 17:24:14 crowland Exp crowland $
E-Mail : sentrysupport@psionic.com
Date : 04-08-2002
Version: 2.0b1
소 개
=-=-=
이것은 긴 인스톨 매뉴얼이다. 만일 여러분이 뒤에 이어질 모든 것과 프로그램 로직안에 깃든 나의 광기어린 방법을 이해하길 원한다면, 여러분은 이 매뉴얼 파일을 읽어야만 한다.
만일 여러분이 이런 것에 대해 관심이 없다면 아래의 내용들을 뛰어넘어라.
PortSentry는 보안 제품들 중에 Psionic의 TriSentry Suite의 일부분이다.
만약 여러분들이 이 도구가 마음에 들고 여러분들이 정말 우리의 다른 제품들에 관심이 있다면 우리의 웹사이트를 참고하라:
http://www.psionic.com
PortSentry는 포트스캔을 탐지하기 위한 많은 옵션들을 가지고 있다.
포트스캔이 발견되면, PortSentry는 다음과 같은 방식들로 반응한다.
- 사건을 나타내는 log 는 syslog()를 통해 만들어진다.
- 타겟 호스트(포트 스캔 공격을 한 컴퓨터)는 TCP Wrappers를 위해서 자동적으로 /etc/hosts.deny에 기록된다.
- 로컬 호스트에서는 타겟 시스템을 데드 호스트(인터넷상에 없는 컴퓨터)로 간주하여, 타겟 호스트를 경유하는 모든 경로가 자동적으로 재구성된다.
- 로컬 호스트는 로컬패킷필터를 통하여, 타겟 호스트로부터 오는 모든 패킷을 무시하기 위하여 자동적으로 재구성된다.
이러한 의도는 관리자에게 그들의 호스트가 스캔되고 있다는 것을 확신시켜주기 위함이다.
이미 이러한 동작을 하는 유사한 프로그램들이 있다.( klaxon 등등) 나는 단지 전체적인 아이디어에 작은 변화(auto blocking 과 같은)를 더했을 뿐이다. 더하여, 스텔스 스캔 탐지(stealth scan detection)를 위한 포괄적인 지원까지...
PortSentry 2.x는 libpcap을 사용하기 위해서 재구성되었다. 이전에 공격을 감지하기 위해 묶여진 포트들을 사용하던 "고전적인" 모드들은 사라졌다. 만약 그 "고전적인" 모드들을 선호한다면, PortSentry 1.1 버전을 사용하길 바란다.
설치
=-=-=-=
첫 단계:
여러분의 에디터로 portsentry_config.h 파일을 가져와서 다음사항이 여러분이 원하는 바와 맞는지 확인해라:
CONFIG_FILE - PortSentry 구성파일의 경로
WRAPPER_HOSTS_DENY - TCP wrapper의 hosts.deny 파일의 경로와 이름
SYSLOG_FACILITY - PortSentry가 사용할 syslog 프로그램
SYSLOG_LEVEL - 메시지를 보내기 위한 syslog level
나는 여러분이 무엇을 하고 있는지 알지 못한다면 이러한 옵션들을 절대 바꾸지 말 것을 제안한다.
※ 참고
1. 고급사용자들은 SYSLOG_FACILITY를 LOG_DAEMON에서 LOG_LOCAL0로 바꾸고 싶어할 수도 있을 것이다. (아니면, 또 다른 LOCAL log 감시프로그램)
여러분은 syslog.conf 파일을 편집할 수 있으며 이것으로 분리된 모니터링을 위해 PortSentry 메시지를 직접 시스템에 있는 PortSentry 자신만의 파일에 가져다 놓을 수도 있다.
2. [경고] : 절대로 이 파일 내용에서 "#" 표시를 지우지 마시오.
이런 "#" 표시들은 주석표시가 아니라, 헤더들을 예비적으로 처리하기 위해 C 컴파일러를 요구하는 것들입니다.
만약 여러분들이 "#" 표시들을 지워버린다면 여러분들은 컴파일 에러들을 보게 될 것입니다.
3. 참고 2번을 다시 한번 읽어보라. 우리는 "#" 표시를 지우고 그로 인해서 프로그램을 컴파일 할 수 없게 되어 문의를 해오는 수많은 사람들을 보았다. portsentry_config.h 파일은 2.x 버전이 베타 버전으로 있는 한은 계속 같이 존재할 것이다.
두번째 단계:
이어서, portsentry.conf를 여러분의 에디터로 가져와서 다음의 옵션을 체크하고 바꿔라:
INTERFACE - 여러분이 모니터 하기를 원하는 interface(CPU와 단말 장치와의 연결 부분을 이루는 회로) 이름. 대부분의 사람들은 이 부분을 "auto"로 남겨둘 수 있고 이 때 PortSentry는 첫번째 interface를 선택하여 모니터 할 것이다. 다른 분들은 아마도 여러개의 interface들을 가지고 있음에도 오직 하나만 보기를 원할 것이다(말하자면 외부 방화벽 interface). 이런 경우는 여러분들이 interface 이름을 직접 설정해 줄 수도 있다. eth0를 보기 위해서는 "/dev/eth0"과 같이 경로명을 포함시키지 말고, 단순히 interface 이름 "eth0"를 적어 넣는다. 등등.. 이런 식으로... PortSentry는 한 번에 오직 한 개의 interface 만을 볼 수 있기 때문에 여러개의 Interface 이름을 적어 넣으면 안된다.
INTERFACE_ADDRESS - PortSentry는 당신이 감시하려 하는 Interface의 IP 주소를 필요로 한다. 현재 버전의 PortSentry는 자동으로 해당 Interface의 IP주소를 찾아내지 못한다. 하지만 앞으로 곧 지원될 것이다. 만약 여러분이 IP 주소를 적어 넣지 않는다면 PortSentry는 당연히 아무런 일도 하지 않을 것이다. 이것은 DHCP 또는 유동 IP 사용자들에게는 적합하지 못하다(매번 바뀌어지는 IP주소를 적어 넣어주고 재시작 해야하므로...-.-a). 하지만 베타 버전이 버전업 되면서 DHCP나 유동 IP 사용자들도 편리하게 사용할 수 있도록 할 것이다. 현재로서는 매번 IP주소를 적어주거나 아니면 스크립트를 작성하여 매번 시스템을 재시작 할 때마다 자동으로 실행되어 새로이 바뀐 IP주소를 자동으로 지정해 주도록 해줘야 한다.
TCP_PORTS - 콤마(,)로 분리된 PortSentry가 감시하기를 원하는 TCP포트의 문자열. 이 문자열은 그 안에 어떠한 공백문자도 가져서는 안된다. 여러분은 여러분이 원하는 만큼의 소켓을 집어넣을 수 있다. 하지만 아마도 Berkely Packet Filter (BPF) 의 길이가 너무 커져서 문제가 될 수도 있다. 만일 이런 문제가 발생한다면 여러분들은 로그 파일에서 에러 메시지를 볼 수 있을 것이고 문자열의 길이를 더 줄여야만 할 것이다.
UDP_PORTS - 이것은 UDP 포트 라는 것을 제외하고는 위와 동일하다.
IGNORE_FILE - 여러분이 항상 무시하길 바라는 호스트의 IP 주소들의 목록이 기록된 파일의 경로. 이것은 나중에 설명될 것이다.
BLOCKED_FILE - 접속금지(blocked)된 호스트의 IP 주소들의 목록이 기록된 파일의 경로.
RESOLVE_HOST - 이 옵션은 호스트들에 대한 DNS 해석을 꺼버린다. 만약 여러분이 느린 DNS 서버를 가지고 있다면 해석을 끄는 것은 더욱 효과적일 것이다. 또한 만약 여러분이 이것을 켜놓는다면 공격자는 되돌아 오는 DNS 응답을 볼 수 있을 것이고 여러분이 연결상태를 감시하고 있다는 것을 (공격자가) 알게 될 것이다. 기본값으로 이 옵션을 꺼놓는다.
BLOCK_UDP -이 옵션(0)은 UDP탐지에 대한 모든 자동적인 반응을 못하도록 한다. UDP는 쉽게 위조될 수 있기 때문에, 정상적으로 존재해야 할 모든 호스트들을 접근금지 시키는 방식으로, 공격자가 보호받는 호스트에 대해 DOS공격(서비스거부공격)을 할 수 있다. 이 옵션을 "0"으로 하면 연결이 여전히 log된 상태라도, 모든 자동적인 반응을 못하게 할 것이다. 이 옵션(0)은 주로 인터넷에 노출되어 있는 호스트에 유용하다. 내부 호스트에 대해서는 여러분은 이 옵션을 (자동적인 반응이) 가능 하도록 놔둬야 할 것이다. 만약 누군가 내부적으로 여러분에게 스푸핑된(spoofed) 패킷을 보낸다면 여러분은 서비스거부보다 더 큰 문제점에 직면하게 될 것이기 때문이다.
BLOCK_TCP - TCP라는 것을 제외하곤 BLOCK_UDP와 같다. (패킷 위조는 그리 큰 문제가 아니다. 왜냐면 PortSentry가 완전한 접속이 이루어지를 기다리고 있고, 이것은 베이직모드에 있어 패킷위조를 하는 것보다 더 힘들기 때문이다. 나는 이것을 인터넷에 연결된 호스트에 대해서도 사용가능하도록 남겨둘 것이다.) 스텔스 스캔 탐지모드에 있어서 UDP 경고는 다음과 같다:
공격자는 패킷 위조를 통하여, 여러분이 막지 않길 원하는 호스트에 대해서 접근금지(block)시킬 수 있다.
(나는 이것이 문제가 될 때까진 걱정하지 않지만 여러분은 이것에 대해 인식하고 있어야 한다.)
수개월간 우리는 이 명백한 문제에 대해서 글을 올리고 말해주는 사람들을 접해왔다. 그렇다. 우리는 패킷 위조, 서비스 거부, 등등에 대해서 알고 있다. 우리는 단지 그 문제의 심각성을 시스템 절충안과 비교하지 않는다. 우리는 이 옵션을 대부분의 호스트([방화벽] 위에서 싸우기 일쑤인 특정 호스트들을 제외하고)들에 대해서 사용 가능하게(막도록) 놔둘 것이다. 여러분이 어떤 설정을 해야 할 지에 대한 좀 더 자세한 답변은 README.stealth를 읽어보라.
KILL_ROUTE - 여기에는 공격이 탐지되었을 때, 공격자가 타고온 경로를 없애기(drop) 위해 실행될 명령을 정의할 수 있다. 정상적인 실행을 위해서는, *절대경로* 전체와 필요한 옵션을 다 붙인 route 명령이 필요하다. $TARGET$ 문자열은 공격하고 있는 호스트 IP주소로 대체될 것이며, 반드시 이 옵션안에서 존재해야 한다. 자신의 gateway는 local subnet상에서 *죽어있는 호스트*가 될 것이다. 어떤 시스템에서는 로컬호스트 주소인 (127.0.0..1)을 넣더라도 아마 작동을 할 것이다. 공격중인 호스트로부터의 모든 패킷은 이 주소로 보내질 것이며, 호스트를 엉망으로 만들지 않을 것이다. 좀 더 현대적인(발전된) route 명령어는 "-blackhole" or "-reject" 옵션을 포함할 것이다. 여러분의 man(1) 페이지를 체크해 보라. 만약 route 명령어가 이런 기능을 지원한다면 이것을 사용할 수 있다.(비록 그럴지라도 나는 그 대신에 패킷필터링을 사용할 것을 권장한다. 아래를 참조하라.)
또한 "asynchronous route"라고 알려진, 기본적으로는 하나의 루트를 통해 여러분의 호스트에 들어가고 다른 (죽은) 루트에 보내져버리는 패킷을 의미하는, 것이 생길 수 있음을 알고 있어야 한다. 이것은 완전한(full) TCP 접속요구에는 잘 동작하지만, UDP나 스텔스 스캔모드에 있어서는 이것은 패킷이 PortSentry를 활성화시키는 것을 여전히 허용하고 여러분은 PortSentry가 보내주는 "already blocked"라는 경고를 계속하여 받게 될 것이다. UDP 스캔에 대해서 이 방법은 ICMP message들이 공격자에게 되돌아가는 것을 막아서 모든 포트가 open 된 상태로 나타나게 된다. 그러나, 만약 공격자가 실제 공격소스 exploit를 실행하고 있다면, 앞의 drop route 방법은 소용이 없다. asynchronous route는 만약 공격자가 대응되는 응답이 어떻게 진행 될지 알고 있으면, 패킷이 시스템에 도달하게 되고, 공격자가 UDP를 이용하여 장님상태의 (blind) 공격을 할 수 있도록 허용할 것이다.
이것을 막는 최선의 방법은 Linux ipfwadm/ipchains 나 *BSD ipfw와 같은 로컬 패킷필터를 사용하는 것이다. 이것은 매우 깔끔한 방법이며 config 파일안에 자세하게 설명되어 있다. $PORT$ 문자열은 공격자에 의해 연결된 포트로 대체될 것이지만, 이 옵션이 항시 요구되는 것은 아니다. $MODE$ 문자열은 (tcp, udp)에서 blocking이 일어난 모드를 나타내는 것이지만, 이 역시 항시 요구되는 것은 아니다.
KILL_HOSTS_DENY - 이것은 TCP wrappers가 사용하는 hosts.deny 파일에 적기 위한 스트링의 포맷이다. 다시말해 $TARGET$ 문자열은 공격자의 IP로 대체되기 위해 확장되며 반드시 요구된다. 여러분은 (%h, twist 등)뿐만 아니라 어떠한 TCP wrapper의 escape 코드들을 넣을 수 있다. $PORT$ 문자열은 공격자에 의해 연결된 포트로 대체될 것이지만, 이 옵션이 항시 요구되는 것은 아니다. $MODE$ 문자열은 (tcp, udp)에서 blocking이 일어난 모드를 나타내는 것이지만, 이 역시 항시 요구되는 것은 아니다.
KILL_RUN_CMD - 이것은 공격자를 향한 route를 제거하기 *이전에* 작동시키기 원하는 명령이다. 공격이 탐지되었을 때, 여러분이 실행하기 원하는 어떠한 program이나 script를 집어넣을 수 있다. 나는 절대 ATTACKING HOST(공격하는 호스트)에 대해서 보복공격 작업을 집어넣지 않길 권고한다. 실제로, 포트스캔을 하고 있는 호스트는 해킹을 당한 임의의 호스트이다. 그러므로, 만약 여러분이 보복을 한다면, 아마도 여러분은 선량한(?) 사람들을 공격하는 것이 될 것이다. 보안의 목적은 쫓아버리는 것이다. 여러분은 그들을 화나게 해서 여러분에게 개인적인 복수를 하게 되기를 원치 않을 것이다. 유념하라. 비록 13살 어린이도 그들의 윈도우 컴퓨터에서 DoS(서비스거부) 공격을 실행하여서, 여러분의 인생을 비참하게 만들 수 있다는 것을...
위에서 보았듯이 $TARGET$, $PORT$, 그리고 $MODE$ 문자열은 유용하지만 이 옵션에 반드시 요구되는 것은 아니다.
KILL_RUN_CMD_FIRST - 이 값을 "0"으로 설정하면 위의 명령이 route가 제거되기 전에 실행되도록 만든다. 이 값을 "1"로 설정하면 위의 명령이 이미 blocking이 된 후에 실행되도록 만든다. (역자 주: portsentry.conf 파일의 해당 설정 부분의 주석 설명을 보면 "0"이 이후에 실행되는 것이고 "1"이 이전에 실행되는 것으로 반대로 설명이 되어 있습니다. 아마도 portsentry.conf 파일에 있는 내용이 맞는 것 같습니다.. README.install 파일 내용이 틀린 듯 하네요.. 쩝.. );P
SCAN_TRIGGER - PortSentry는 자신의 호스트에 접속하였던 호스트를 기억하는 state engine를 가지고 있다. 이 값의 설정은 PortSentry가 반응동작하기 전에 PortSentry에게 감시되는 port의 몇 번까지의 접속을 허용하도록 말해줄 것이다. 이것은 순차인 것과 임의적인 포트스캔을 둘 다 탐지한다. 디폴트값은 0이며, 이는 즉각 반응한다. 그 값을 1 또는 2로 해주면 잘못된 경고를 줄일 것이다. 그리고 이보다 높은 값들은 3회이상 다른 포트들에 접근했을 때와 같은 경우, 아주 수상한 행동을 감지하게 될 것이다. 일반적으로 여러분은 아무런 생각없이, 이 값을 0으로 놔둘 수 있다.
세번째 단계:
여러분의 문서 편집기로 portsentry.ignore 파일을 가져와서 그 안에 감시되고 있는 포트에 접근해도 (보안장치를 작동하지 않고) 무시해 버릴 호스트를 추가하라. 이것은 적어도 localhost(127.0.0.1)와 내부 네트워크의 IP주소를 포함해야만 한다. 우리는 *절대* 여러분과 동일네트워크상에 있는 모든 호스트 IP 주소를 집어넣는 것을 권장하지 않으며, 대신 그렇게 하기 위해서 여러분들은 netmask를 사용할 수 있다. 설정하는 형식은 아래와 같다:
<IP Address>/<Netmask Bits>
192.168.2.0/24
192.168.0.0/16
등등...
우리는 너무 많은 호스트들을 적어 넣는 것을 권장하지 않는다. 아주 "신뢰관계"에 있는(friendly) 호스트일지라도 여러분에게 있어 누가 여러분에게 연결을 하고 있는지를 보는 것은 아주 중요한 일일 것이다. 이것은 여러분이 내부 호스트의 결탁(외부의 해킹에 의한)을 보다 빨리 탐지하는데 도움을 줄 것이다.
자신의 편집증에 충실해라. 그렇다. 이런 일은 일어나며 우리는 *상당수*의 경우 관리자들이 너무 많은 무시해버릴 호스트들을 적어 넣었고 그들 *내부 호스트들의 결탁(외부의 해킹에 의한)*에 의해서 해킹당했다는 사례들을 들었다.
네번째 단계:
컴파일(Compile). make 명령을 내리면, 여러분은 여러분의 시스템타입을 고르고, build하고 인스톨할 수 있게 된다. 원래 default directory는 /usr/local/psionic/portsentry2 이다. 만약 여러분이 이 디렉토리가 마음에 들지 않는다면 Makefile을 수정하고 새로운 경로에 영향을 주는 여러분의 portsentry.conf 와 portsentry_config.h 파일들을 확인하라.
build한 후에 make install 명령을 내리면 여러분이 지정한 인스톨 디렉토리에 복사본 파일들을 만들어 준다.
다섯번째 단계:
PortSentry를 작동시켜라. 설치한 후에 PortSentry를 작동하는데 있어 두 가지 방법이 있다:
1) 설치 디렉토리(/usr/local/psionic/portsentry2, 등등..)로 이동(cd)하여 다음을 실행시켜라:
./portsentry
2) 바로 명령을 실행시켜라:
/usr/local/psionic/portsentry2/portsentry
"Stealth" TCP scan detection mode [BETA] (스텔스 TCP 스캔 탐지 모드 - 베타)
PortSentry는 자신의 호스트로 들어오는 모든 패킷들을 감시할 것이다. 만일 들어오는 패킷이 portsentry.conf 설정 파일에서 TCP_PORTS 변수에 입력되어진 감시 대상 포트 목록의 포트를 향한다면 그에 대응하여 호스트를 막아버릴 것이다.
이 방법은 connect() 스캔, SYN/half-open 스캔, XMAS 스캔, FIN 스캔, NULL 스캔, 등을 감지해 낼 것이다. UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
"Stealth" UDP scan detection mode [BETA] (스텔스 UDP 스캔 탐지 모드 - 베타)
이것은 위의 TCP stealth mode와 작동방법은 동일하다. UDP 포트들을 나열하면, 그 포트들은 감시된다. 이것은 어떠한 소켓도 묶지 않으며, 실제 스텔스 스캔 탐지 모드가 아닌 중에도 거의 동일하게 동작한다.( 모든 UDP 패킷에 반응한다.) UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
** Advanced Logic Mode **
-PortSentry는 포트들을 감시하는 방법이 아주 뛰어나다. FTP와 같은 몇몇 프로토콜에 있어서, 클라이언트는 실제적으로 ephemeral range인 1024번에서 65535번까지의 범위에서 포트들을 연다. 그리고 서버는 *역으로* 여러분에게 접속한다. 보통은 이런 방식이 포트스캐너가 동작할 수 있게 해준다. 그러나 PortSentry는 호스트로 들어오는 접속을 감시할 것이고, 이러한 "임의적인" 접속연결(binding)로 향하는 것인지 아닌지를 결정할 것이다. 만약 임의적인 접속연결로 향한다면, 그 한번의 접속이 무시된다. 접속이 끊어지자마자 window는 닫히고 모든 방어체계가 다시 활동한다. 이것은 실제로 초보적인 stateful inspection engine이다. UDP/스텔스 스캔 경고가 적용된다. (README.stealth파일을 읽어보라.)
인스톨을 확인하라:
local log 파일의 마지막부분에 PortSentry의 초기화 메시지가 있어야 한다.
성공적인 PortSentry의 초기화 메시지는 아래와 같이 나타날 것이다:
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: Monitoring interface eth0 and address: 10.1.1.1
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: Monitoring TCP ports: 1,11,110,143,635,1080. . .
Mar 5 21:16:00 nemesis portsentry[2286]: adminalert: PortSentry is initialized and monitoring.
********************************************************************
** 마지막 줄은 PortSentry가 적절하게 초기화되었음을 나타낸다...... **
** 만약 여러분이 이런 메시지를 보지 못했다면 무언가가 틀린 것이다. **
********************************************************************
이제 여러분은 다른 호스트로 가서 텔넷으로 은폐된 폭팔물(PortSentry)이 장치된 포트로 접근할 수 있다.
[주의] 절대로 여러분이 서비스 받을 위치에서 보호받는 호스트로 접근하지 마시오. 이유는 만일 그렇게 하면 여러분은 스스로 자신을 막아버리게 될 것이기 때문이다.
위의 주의점을 다시 한 번 숙지하라. 우리는 아래와 비슷한 것을 우리에게 알리는 사람들을 봤다.(만들어진 예기지만, 여러분들은 이 예기를 참고 할 수 있다)
"안녕하세요, 제가 일년에 일주 정도만 헬리콥터를 타고서만 접근가능한 north atlantic의 고립된 석유 시추선에 있는 나의 웹 서버에다가 port sentry 를 설치했는데요. 그리고 나서 저는 웹 서버에 접속할 수 있는 온전한 행성에서 유일한 관리 시스템으로 가서 보호받는 포트에 텔넷으로 접근하여 port sentry 를 테스트 해 보았습니다. 지금으로서는 port sentry가 온전하게 작동하는 것 같습니다. 왜냐하면 제가 저의 컴퓨터에 접근할 수 없기 때문입니다. 하지만 이젠 제 컴퓨터에 접근해야겠는데요. 저 좀 도와주시겠어요?"
그건 그렇고...
여러분은 곧 다음과 같은 것들을 보게 될 것이다:
Mar 5 21:17:39 packetmonkey portsentry[2286]: attackalert: Host 192.168.2.15 has been blocked via wrappers with string: "ALL: 192.168.2.15"
Mar 5 21:17:39 packetmonkey portsentry[2286]: attackalert: TCP SYN scan from host 192.168.2.15/192.168.2.15 to TCP port: 143 from TCP port: 31337
만약 여러분이 접속이 끊어지고 다시 telnet으로 접속하기를 시도한다면 여러분은 방금 전의 호스트에 접근할 수 없음을 확인해야 한다. 이러한 동작이 확인된다면, 축하한다! 여러분은 PortSentry를 제대로 작동시킨 것이다.
만약 여러분의 로그체크 데몬이 띄워져 있다면 여러분이 서버에 접속할 때, 위의 접근거부 상황에 대한 경고 메시지 내용이 로그파일에 나타나는 것을 확인할 수 있을 것이다.
만약 여러분이 netstat -rn 명령을 하면 여러분은 이전에 동작하던 의심가는 호스트로의 죽은 경로를 보게 될 것이다.( 내가 이전에 권장했던 것과 같이, 패킷필터를 사용하지 않으면...)
PortSentry 명령들을 리눅스 시작 스크립트파일(startup file)에 쓰고 나서, 여러분이 한 작업으로 돌아와라.
이게 어떻게 도움이 될 것인가 하면??
여기 몇몇 좋은 생각들이 있다.
- Run as a UDP service on port 69 to catch TFTP probes.
(TFTP 침입을 잡기 위해서는 포트 69에 UDP 감지모드를 가동하라.)
- Run as a UDP service on port 161,162 to catch SNMP probes.
(SNMP 침입을 잡기 위해서는 포트 161,162에 UDP 감지모드를 가동하라.)
- Run as a UDP service in the port range 32000-33000 to catch RPC probes.
(RPC 침입을 잡기 위해서는 포트범위 32000-33000 에 UDP 감지모드를 가동하라.)
- Run as a TCP service on port 143 to catch IMAP probes.
(IMAP 침입을 잡기 위해서는 포트 143에 TCP 감지모드를 가동하라.)
- Run as a TCP service on ports 11,15 to catch netstat/systat probes.
(netstat/systat 침입을 잡기 위해서는 포트 11,15에 TCP 감지모드를 가동하라.)
- etc. 등등
실제로 PortSentry는 빠르게 반응해서, 공격자에 의한 호스트 포트스캔은 감시대상 포트에 접근이 있은 후 1초이내에 차단될 것이다.
UDP 스캔에 대해서는 모든 포트가 "열려진 상태"로 나타나게 함으로써 여러분을 스캔하는 이들을 매우 짜증스럽게 만들 것이다.
TCP 스캔에서 공격자는 어떠한 응답도 얻을 수 없을 것이다.
안전성
=-=-=-
만약 우리가 프로그램의 안전에 대한 고려사항 중 잊고 놓친 것이 있다면, 여러분이 그 내용을 BugTraq에 올리기 전에 우리에게 알려주기를 원한다 :).
메시지
=-=-=-=-
가능한 모든 states/errors/successes and unknowns(상태/오류/성공 그리고 알 수 없는 것들)은 syslog 파일에 쓰여진다.
다음의 tag들이 의미하는 바는:
adminalert: - PortSentry의 상태를 나타내는 메시지.
securityalert: - 보안 관련 사건들이 일어났음을 나타내는 메시지
attackalert: - 스캔을 감지했다는 것과 그에 따른 동작이 실행되었다는 것.
파일들
=-=-=
현 상태로는, 모든 호스트들은 그들이 접속금지(blocked) 되었을 때 portsentry.history 파일뿐만 아니라 portsentry.blocked 파일에 기록된다. blocked file은 PortSentry가 다시 시작될 때마다 지워진다. history file은 간단히 덧붙여지며 일정한 기한까지 접속금지(blocked)된 호스트들의 기록으로 사용할 수 있다.
기한이 지난 후에 여러분은 공격했던 호스트들에 대해 죽은 경로를 삭제하고, 호스트를 hosts.deny 파일에 저장하길 원할 수도 있다. 이것은 전적으로 여러분의 결정에 달려있다. 만약 여러분이 공격자가 다시 접근할 때 접근금지(blocking)을 작동시키기를 원한다면, 단지 PortSentry를 재시작하거나 혹은 blocked file에서 개개의 호스트를 제거하면 된다.
대부분의 시스템에서 여러분이 접근금지시킨 호스트로의 경로를 회복시키길 원한다면 여러분은 단순히 아래와 같이 경로를 지움으로써 회복시킬 수 있다:
리눅스:
route del <ip_address> reject
기타:
route delete <ip_address> <dead_route>
또는 간단히 여러분의 패킷 필터들을 쏟아냄으로써 가능하다.
이것이 바로 내가 말하고자 한 것이다. 로그파일의 내용을 보는 것뿐만이 아니라 여러분이 다른 문제점들도 알 수 있도록 하기 위해서, 나는 여러분이 Abacus 프로젝트의 Logcheck를 사용하길 강력히 권장한다. 그리고 PortSentry가 여러분에게 무엇을 알리려고 하는지 살펴보길 권장한다. 여러분은 본 프로그램을 아래 주소에서 찾을 수 있다:
http://www.psionic.com
이 문서를 읽어준 것에 감사히 생각하고, 질문이나 추가적인 조언이 있다면 내게 메일로 써 주기를 바란다.
감사한다,