이번주는 지난주에 이어 원격지에 있는 호스트로부터 해당 호스트의 정보를 어떻게 얻는지에 대한 방법과 관련한 강의를 계속합니다.



3. Portscanning Methodology



---3.1 TCP connect () scanning



가장 기본적인 port scanning technique 이다. connect() system call은 상대 host의 interesting port들과 연결해 준다. 만약 port 가 열려있다면 connect() call은 성공할 것이다. 이 방법의 좋은 점은 어떤 권한 없이 누구나 connect() 를 호출할 수 있으며, 따라서 어떠한 user라도 port scan을 할 수 있다는 것이다. 또 하나의 장점은 속도가 빠르다는 것이다. socket들을 병렬적으로 호출할 수 있으며 따라서 scan에 걸리는 시간을 단축할 수 있다. 그러나 단점을 들자면, 이 방법은 발견되기 쉽고, 또 걸러지기도 쉽다. 웬만한 logger들은 connect() 연결을 다 기록하며, scan 후에는 target의 log에 엄청나게 많은 연결 시도와, error message를 남길 것이다.



---3.2 TCP SYN scanning



이 방법은 흔히 "half-open" scanning 으로 불리는데, 왜냐하면 이 방법은 하나의 완전한 TCP connection을 열지 않기 때문이다. target port에 SYN packet을 날리면, SYN|ACK나 RST가 응답으로 오게 되는데, SYN|ACK는 port가 열렸음을, RST는 port가 닫혔음을 나타낸다. 만약 SYN|ACK가 도착하면 바로 RST를 보내서 connection을 terminate시킨다. 이 방법의 좋은 점은 connect()보다 잘 발견되지 않는다. (tool이 없어서 발견을 못하는 것이 아니라, 대부분 이를 log하는 tool을 가지고 있지 않기 때문) 그러나 이러한 packet을 만들어 주기 위해서는 root privilage가 필요하다.



---3.3 TCP FIN scanning



그러나 아쉽게도 TCP SYN scan도 그리 은밀한 scan 방법은 아니다. 어떤 firewall이나 packet filter들은 허가되지 않은 port로의 SYN packet을 걸러내고, 여러 log들도 이러한 시도들을 기록한다. 그러나 FIN scan 같은 경우는 별일 없이 목적을 잘 수행할 수 있다. 이 방법은 phrack 49, article 15의 글에 자세히 나와있다. 간단히 idea를 말하게 되면, 닫힌 port들은 FIN packet에 대해서 RST로 응답을 하게 되며, 열린 port들은 이러한 FIN packet을 무시한다. 단점으로는 이 방법 역시 packet을 조작해야 하므로 root privilage가 필요하며, 이 방법은 net 의 bug에 의한 것이므로 언제든지 고쳐질 수 있다. 그리고 또 scan의 결과는 arch, OS depend하므로, 실제 scan의 결과를 잘 믿을 수 없다. 그러나 장점들을 열거하자면, 이러한 packet을 log하기는 상당히 어려우며(log가 가능해도 bug를 고치지 않으면 어불성설..) 몇몇 firewall을 통과할 수 있고, 또 이와 같은 idea로 여러 방법들을 많이 만들 수 있다. 이 scan 방법은 신기하게 M$에는 통하지 않는다.



---3.4 Fragmentation scanning



이는 별로 새로운 방법은 아니고 다른 방법의 변형으로 보면 된다. scan을 하는데, 하나의 packet을 보내는 것이 아니라, 이 packet을 잘게 쪼개서 보낸다. 이 방법은 TCP header를 찢어서 보내므로, packet filter나 그외 여러 가지 등이 이 packet이 뭐 하는지를 알기 어렵게된다. 조심!! 어떠한 프로그램들은 이러한 작은 packet들을 잘 다루지 못한다. 이 방법은 IP fragment들을 queue하는 packet filter나 firewall에는 소용이 없다.



---3.5 FTP bounce attack



* ftp bounce attack : well described in doc. CERT Advisory CA-97.27 - FTP_bounce



target을 scan하기 위해, ftp의 PORT 명령을 사용해서, passive "User-DTP"에 target box의 어떤 port 번호를 써준다. 그 후에 LIST 명령으로, 현재의 directory를 짝고, 결과는 Server-DTP channel을 사용해서 보낸다. 만약 target host의 우리가 원하는 port가 열려있다면, 이러한 transfer는 성공할 것이다( 150, 226 response를 발생시킨다.). 아니라면, '425 Can't build data connection : Connection refused.' 라는 message를 발생한다. 이때에는 또 다른 PORT 명령을 사용해서 target의 다른 port를 연결한다. 이 방법의 장점은 명확하다. 이 방법을 쓰게 되었을 때, 이를 추적하기 어려우며, 또 firewall이나 packet filter등을 통과할 "수" 도 있다. 단점이라면, 이 방법은 느리고 어떤 ftp에서는 아예 PORT기능을 disable시켰을 수도 있다.



---3.6 UDP ICMP port unreachable scanning



이 scan 방법은 UDP를 쓴다는 점에서 위의 TCP scan방법과는 대조된다. 확실히 UDP protocol은 더 간단하지만 scan을 구현하는 것은 좀 더 어렵다. 이는 왜냐하면 open port는 ACK packet을 보낼 필요가 없으며, closed port는 error packet을 보낼 필요가 없다. 그래도 다행인 것은 많은 host들은 closed UDP port로 packet을 보내면 ICMP_PORT_UNREACH error를 응답해 준다. 따라서 무엇이 닫혀있는 port인가를 알 수 있고 이를 제하면 열린 port라는 것을 알 수 있다. 그러나 UDP packet이나, ICMP error들이 꼭 도착한다고 보장을 하지 못하므로, UDP scanner들은 packet전달과정에서 누락된 packet의 재전송 부분을 구현해야 한다. 또 이러한 방식에 scan에서 문제가 되는 부분은 속도이다. 많은 기계들이 RFC1812 section 4.3.2.8을 참조하여, ICMP error message rate들을 제한하기 때문에 scan이 느리게 동작할 수밖에 없다.



---3.7 UDP recvfrom() and write() scanning



non-root 사용자들은 port unreachable error들을 직접 읽지 못하나, Linux등은 "매우" 훌룽해서 이러한 message를 받았을 때, 간접적으로 user에게 알려준다. 예를 들면 write()를 닫힌 port에 써줄 때, 이 작업은 실패한다. 또 recvfrom()같은 함수의 경우 이 함수가 non-blocking UDP socket에서 구현될 때, ICMP error message를 받지 못했을 때, EAGAIN("Try Again", errno 13)을 반환하며, 받았을 경우 ECONNREFUSED("Connection refused", errno 111)을 반환한다. 이는 nmap의 사용자가 root가 아닐때 UDP scan을 수행하는 방법이다.



---3.8 ICMP echo scanning



솔직히 이것은 port scanning 이 아니다. ICMP는 port destinantion을 갖지 않기 때문이다. 그러나 이 기능은 많은 수의 host를 scan할 때 유용하게 쓰인다.