커피닉스, 시스템 엔지니어의 쉼터

솔라리스의 syn flooding에 대해(글 John Lee)

작성일 : 2003/09/06 14:48

글쓴이 : 좋은진호 ( http://coffeenix.net/ )

조회수 : 7263

sec-info 메일링리스트에 John Lee님이 올린 글입니다. 내용은 그대로이며, 단지 줄바꿈 정도만 수정했습니다. ^^ 아래부터 원글입니디. --------------------------------------------------------------------- 제목 : 솔라리스의 TCP_SYN_FLOODING From : John Lee (dhlee@oullim.co.kr) Date : Sat Jul 14 2001 - 10:54:52 KST 좋은 문서 감사드립니다. 도움이 많이되었습니다. 제가 알고 있는 아주 작은것 하나 말씀드리려고 합니다. 상용 운영체제인 솔라리스 시스템에 대한 건데요. 제가 옛날에 작성한 문서가 있어서리. 솔라리스 운영체제를 사용하시는 분께서는 참조해 보시기 바랍니다. ================================================================================ 잘들 아시겠지만... 솔라리스는 일반적으로 syn flooding이 통하지 않습니다. 아무리 syn packet을 날려도 시스템이 꿈적도 하지 않는 걸루 알고있습니다. 일반적인 리눅스 시스템이 packet을 5000개 정도만 날려도 먹통이 되었던 것과는 많이 다릅니다. 어느 서버 클라이언트 프로그램이 다 그렇겠지만, 서버프로그램이 listen 을 call 하게 되면 kernel이 TCP 상태를 closed 에서 listen으로 바꾸게 되죠. 이걸 passive listen 이라고 하며 뭐 그게 중요한게 아니구요. passive listen을 하면서 동시에 socket buffer 와 같은 구조체와 두개의 큐를 만들게 됩니다. 문제의 해결은 바로 이 큐에 있져... incomplete connection queue 와 complete connection queue 두개를 만들게 됩니다. 전자는 시스템에 전달되는 모든 syn packet을 저장하게 됩니다.(그러니까 처음으로 접속을 시도하는 놈은 일단 여기에 머물게 되져..) BSD source 에 보면 이건 so_q0len 이라는 entry로 되어있구요..3번 악수를 통해서 완벽하게 established 상태가 되지 않은 모든 connection 에 대한 내용이 바로 이 큐에 저장되게 됩니다.  또한 완벽하지 않은 접속상태는 RTT(Round Trip Time)동안 큐에 머물게 되며 1초라도 넘게되면 가차없이 처분됩니다. 후자는 3번 악수를 통해서 connection 이 성립된 것들이 저장되는 큐입니다. 그러니까 complete 큐에서 대기하면서 다시 accept 를 call 하는 걸 기다리는 거죠.  accept 된 것들은 큐에서 사라지게 되구요. 모든 큐는 지정된 entry의 수 (머 지정된 수가 있겠져. 128개 라든가..)에 의해서 제한을 받게 됩니다. 어떠한 이유에서든 complete connetction queue에서 지워지지 않고, 큐가 꽉차게 되면 커널은 더이상의 접속을 받지 않습니다. timeout 값은 큐에 저장된 syn segment에 의해 결정되며. 큐에 저장된 syn packet 에 대해서 ack가 수신되지 않는경우(그러니까 SYN_RCVD 상태가 되겠져.. -_-;)시간이 경과되고 그결과 그냥 packet이 drop 됩니다. tiemout 값은 syn_flood 등을 막는데 가장 중요한 것이 될꺼구요. 결과적으로 우리가 암만 syn을 날려두 이러한 접속은 incomplete connection queue에 머물게 되며. 3번 악수를 하지 않으므로 complete connection queue로 넘어가지 않는다는 점,,, 그리고 RTT에 의해서 connection이 drop 되며 이러한 경우에도 아주 special 한 알고리즘을 이용해서 valid 한 접속 요구는 받아들여진다는 점입니다. (이걸 알수가 없습니다. special 한 알고리즘을..어딜봐도 그냥 원문 그대로 입니다.special algorithm makes sure that valid connections can still get through ) ndd 명령을 이용해서 이걸 확인해 볼수있습니다. 우선 tcp_conn_req_max 라는 값이 있는데 이건 solaris 2.5 버전에서 큐 한개를 쓸때 connetction 을 몇개 까지 받을것인가에 대한값입니다. 이렇게 아수울쑤가. 큐를 한개밖에 못쓰다니.. 그래서 썬에서 제공해 주는 patch가 있습니다. 103582-12 번 패치를 받아다 설치 하면 큐를 두개로 늘려줍니다. 아 2.5 이전 버전에 해당하니깐 2.5.1 에서는 상관이 없습니다. solaris2.6 이나 7 에선 이런 변수가 없져? 당연하져. 큐를 두개를 쓰니깐. tcp_conn_req_max_q0 와 tcp_conn_req_max_q 두개의값입니다. 음..음..음... 우리 color에서 보니 전자의 값은 1024로 되어있네요.. 큐 치고는 아주 큰 큐라고 할수있습니다. (구닥다리 리눅스가 하나의 큐로 크기가 16개 였을때가 있었으니깐여) 그리고 후자의 큐는 128개 네요. 이게 진짜 큐입니다. ( 머 어느것은 가짜이겠냐만은 하는 일이 다르니깐 -_-;) 각각 변수의 값들은 관리자의 맘대로 설정이 가능합니다. 후자는 sun에서 recommendation 하는 수치가 128 이네요. max로 1024개 까지 늘릴수있다고 합니다.. 한편에서는 큐를 두개쓰는것이 필요가 없다는 주장이 나오기도 하더군요.. 아주 busy 한 web 등의 application server의 경우 실제로 incomplete connection queue에 저장되었다가 폐기되는 (그러니까 확실하게 3번 악수를 하지 않은 connection 들..)양이 전체 packet의 15%도 되지 않는다고 하네요. 어쨋든 두개의 큐를 사용한다는 점 그리고 그 알수없는 special 알고리즘을 사용한다는게 다르네요. 머 그렇다고 하네여. 와 이런걸 언제 다 공부하지. 음.. 음... ================================================================================

커피닉스, 시스템 엔지니어의 쉼터 / URL : http://coffeenix.net/board_view.php?bd_code=54