방화벽이 왜 필요한지 그리고 네트워크 보안을 위해 방화벽을 최상으로 꾸미는
방법에 대해 알아보자.
글/ Paul Wouters 역/ 이기동(자유기고가)
방화벽은 여러분에게 가장 큰 도움을 주는 친구가 될 수도 있고 예측하기 어려
운 많은 문제의 원인이 될 수도 있다. 언제 네트워크에 방화벽을 놓는 것을 고
려해 보아야 하는가? 필요하다는 것이 확실하다면 네트워크의 어느 곳에 두어
야 하는가? 보통, 방화벽 정책은 정책결정자가 “저는 네트워크를 보호하기 위
하여 방화벽을 놓고자 합니다”라고 하는 의견을 기초로 하여 임원진 회의의
결과로 나오기 때문에 기술적인 논의가 잘 이루어지지 못한다. 한 조직에서 방
화벽을 설치하고자 할 때는 그러한 이유에 대해서 생각해 볼 필요가 있다. 무
엇으로부터 보호하려는 것인가? 이러한 작업을 수행하려면 어떻게 해야 하는
가? 이 기사는 고려할 필요가 있는 문제를 명확히 하는 것을 목적으로 한다.
방화벽이란 무엇인가?
이 질문에 답하기 쉽게 보이지만 그렇지 않다. 보안 전문가들은 방화벽이란 통
과하는 모든 네트워크 패킷을 체크하고 시스템 관리자가 세운 규정에 의하여
특정한 패킷을 거부하는 기능을 수행하는 전용 시스템이라고 이야기한다. 요즘
우리는 웹서버(Firewall-1과 다양한 NT & 유닉스 시스템)를 운영하는 방화벽
과 방화벽 응용프로그램을 구동하는 웹서버를 볼 수 있다. 이제는 네트워크 패
킷을 걸러내는 모든것을 방화벽이라고 부르는 것이 일반적이다. 따라서 방화벽
은 패킷을 걸러내는 기능 또는 그러한 기능을 수행하는 소프트웨어를 지칭한
다. 그리고 어떤때는 이러한 응용프로그램을 수행하는 하드웨어를 지칭하기도
한다. 방화벽을 위해 특별한 하드웨어나 소프트웨어를 구입할 필요는 없다.
리눅스 서버(400불 정도 되는 386 PC에서 돌아가는)는 상용 방화벽의 많은 보
호 기능을 제공한다. 게다가 훨씬 융통성 있고 설정하기도 쉽다.
과연 방화벽이 필요한가?
몇 년 전에 필자는 네덜란드 유닉스 사용자 그룹(NLUUG) 회의에 참석하였다.
주제 중 하나는 ‘네트워크 보호를 위한 방화벽 사용’에 대한 내용이었다. 발
표자들의 연설을 듣고난 후에도 필자는 방화벽이 필요한 충분한 근거를 다룬
논점을 찾을 수 없었다. 필자는 아직도 이것이 사실이라고 생각한다. 잘 운영되
는 네트워크에서는 무의미한 패킷을 걸러 버리는 방화벽이 필요치 않다. 모든
시스템이 잘못된 데이터에 대처할 수 있도록 해야 한다. 하지만 이론과 실제
는 다르기 마련이다. 여러분이 네트워크를 아주 탄탄하게 제어하고 있지 않는
이상 여러분의 사용자들은 다양한 소프트웨어를 워크스테이션에 설치하고 싶어
할 것이다. 또한 여러분은 생각치도 못한 방법으로 사용하고 있을 수도 있다.
게다가, 일반적인 운영체계에서 새로운 보안 구멍은 언제든지 발견된다, 그리고
시스템마다 각각 ‘모든’버그가 수정된 최신 버전을 설치하였는지 확인하기란
매우 어렵다.
두 가지 이유로 중앙에서 통제하는 방화벽은 귀중한 방어선이 된다. 여러분은
사용자들이 임의로 소프트웨어를 설치하는 것을 통제해야 한다. 또, 여러분은
워크스테이션의 보안 통제가 가능한 한 자주 갱신되고 있는지 확인해야 한다.
그러나, 여러분은 그러한 상태가 항상 유지되는지 신뢰할 수 없다. 따라서 방화
벽은 항상 필수적이며 현실적인 것이라 할 수 있다.
죽음의 Ping
몇 달 전에 인터넷 보안 세계에서 작은 위기가 몰려왔다. 이를 악명 높은 ‘죽
음의 Ping’이라고 한다. BSD 소켓 코드 중 특정 부분에서 조각난 네트워크
패킷의 크기를 체크하지 못하는 경우가 있기 때문이다. 조각난 패킷이 다시 합
쳐지면 패킷은 최대로 허용하는 패킷 사이즈보다 몇 바이트 커지게 되었다. 이
코드에서는 이러한 상황이 절대 일어날 수 없을 것이라고 가정하였기 때문에
내부 변수가 최대값보다 더 커질 수 없도록 만들어졌다. 결과적으로는 코드를
제멋대로 생성하는 심한 악성 오버플로우가 일어났고 이런 경우 컴퓨터는 보통
다운된다. 이 버그는 많은 공동체에 영향을 미쳤다. 왜냐하면 그 코드가 BSD
소켓 안에 실제로 존재하기 때문이다. 이 코드는 새로운 소프트웨어(또는 펌웨
어)에서 기반으로 자주 사용되기 때문에 광범위한 시스템이 이러한 버그에 영
향을 받기 쉽다. ‘죽음의 Ping’으로부터 공격받을 수 있는 운영체계의 리스
트는 Mike Bremford's씨의 페이지, http://prospect.espresence.com/ping/에서
찾을 수 있다. 운영체계보다는 이서네트 스위치, 라우터, 모뎀, 프린터, 허브와
방화벽과 같은 많은 장치가 이러한 문제에 의심을 받기 쉽다. 시스템에 커다란
로드가 걸릴수록 버퍼를 초과하는 것은 더욱 치명적이다.
두 번째로 이 버그가 대단히 위험한 이유는 악용하는 경우가 흔히 일어난다는
것이다. MS 윈도 운영체계는 ICMP ping 프로그램을 실행할 때 패킷의 크기를
잘못 계산하고 있다. 사용할 수 있는 최대 패킷 사이즈는 65527인데 이는 실제
로 IP 패킷이 허용하는 최대값이다. 그러나 윈도에서 수행할 때는 65527 바이
트의 데이터 조각이 생성되고 IP 헤더가 붙게 된다. 분명히, 65535바이트가 넘
는 패킷이 만들어지는 것이다. 따라서, 여러분이 해야 할 것은 다음과 같이 입
력하는것 뿐이다.
ping -l 65527 victim.com
이러한 방법이 한번 알려지면 사람들이 지구 전역으로 즐겁게 ping을 시도하는
동안 전세계적으로 서버들이 다운된다. Mike씨의 페이지에 있는 리스트를 볼
수 있더라도 공격받을 수 있는 장치 모두 패치가 나와있지는 않다. 그 패치가
있더라도 시스템 관리부에서는 그러한 장비 모두를 수정하는데 최소한 며칠이
걸릴 것이다. 여기서 방화벽이 가장 확실한 역할을 한다. 이렇게 중요한 보안
문제가 발견되면 네트워크에 접속하는 지점에서 접근을 금지시킬 수 있다. 현
재 방화벽을 가지고 있다면 여러분 대부분은 데이터베이스 서버가 공격받지 않
는다고 확인할 때까지 아마도 모든 ICMP 패킷을 걸러버릴 것이다. 이러한 시
스템 중 한두 대가 공격을 받을 수 있다면 사실은 많은 수가 그런 것이다.
최근에 MS 제품에서 쉽게 악용할 수 있는 또다른 버그가 발견되었다. C와
Perl로 만들어진 작은 프로그램인 winnuke는 윈도 95나 윈도 NT의 139번 포
트로 특정한 데이터를 보내어 네트워킹 코드를 완전히 파괴하고 따라서 그 시
스템은 네트워크를 통한 접속을 전혀 받아들이지 못하게 된다. 이틀만에 이러
한 문제를 해결한 임시 수정판을 사용할 수 있게 되었다. 이 글을 쓰고 있을
때에는 MS에서 공식적인 패치가 올라오지 않고 있었다. 방화벽에 의하여 보호
받는 네트워크는 수정판이 발표될 때까지 139번 포트를 임시로 막아 둘 수 있
다. 대부분 네트워크의 인터넷으로 나가고 들어오는 지점에서 139번 포트의
netbios는 거의 필요가 없다. 그리고, 그러한 사고가 나기 전에 이미 차단해 두
어야 한다.
여기서의 경험적 결론은 방화벽의 신속성과 강력함이 우리에게 귀중한 도구가
될 수 있다는 것이다.
방화벽으로 어떻게 네트워크를 보호하는가?
여기에는 물어 보아야 할 기본적인 질문이 있다.
1. 무엇을 보호할 필요가 있는가?
2. 어떤 사람으로부터 보호할 필요가 있는가?
3. 방화벽을 네트워크에서 어느 곳에 위치시켜야 하는가?
4. 방화벽을 어떻게 설정하여야 하는가?
5. 무엇이 일어나고 있는지 어떻게 감시하는가?
이러한 질문에 정확히 답변하려면 전체 네트워크의 지도를 그려보는 것이 매우
중요하다. 각각의 장치를 하나하나 그릴 필요는 없는데 그것은 자주 바뀌기 때
문이다. 분리된 서브넷, 라우터, 허브와 물리적 위치(층, 사무실, 방)를 그려보
라. 네트워크에서 가장 안전할 필요가 있는 중요한 부분도 포함한다.
무엇을 보호해야 하는가?
대부분의 방화벽은 LAN 전체를 보호하는데 쓰인다. 이러한 경우에는 보통 인
터넷 라우터를 방화벽으로 사용한다. 적절히 설정된 인터넷 라우터는 IP 스푸
핑을 막기 위하여 로컬에서 쓰이는 IP 번호를 걸러 낸다(예를 들어 10.*, 127.*,
192.x.y.*). 또한 바깥에서 들어왔는데 내부에서만 쓰이는 IP 번호를 쓰는 모든
패킷을 걸러 버려야 한다. 이러한 부류의 패킷은 모두 시스템에 속임수를 걸기
위한 시도만 하기 때문에 접근이 바로 거부되어야 한다. 다음, 바깥으로 나가는
트래픽 중 등록되지 않은 IP 번호나 클래스를 가진 IP 트래픽을 걸러 버린다.
이는 쓸모 없는 패킷을 보내지 못하도록 하는 것(또는 인터넷 스푸핑으로부터
사용자들을 보호하는 것) 뿐만 아니라 자체적인 보안을 위한 것이다. 특히 윈
도 제품군은 RFC를 준수하지 않는 것으로 보인다. 필자는 IP 번호 6.6.6.6을 할
당하여 로컬 프린터를 공유하고 있는 윈도 95 시스템을 본 적이 있다. 인터넷
라우터가 이러한 패킷을 걸러 버리지 않는다면 인쇄하려는 문서가 인터넷으로
나가 버릴 수도 있다. 방화벽이 자주 쓰이는 또다른 목적은 단일 시스템을 보
호하기 위한 것이다. 방화벽을 써서 단일 시스템을 지키고자 한다면 방화벽 바
깥에 있는 어떤 것에도 의존하지 않아야 한다. 그렇지 않으면 여러분의 방화벽
은 잘못된 보안 감각을 심어주는 것은 물론 아무런 목적을 이룰 수 없게 될 것
이다. 여러분의 보호를 받는 서버가 보호받지 못하는 PC에서 온 데이터를 사
용하고 있다면, 누군가가 서버의 데이터에 심각한 손상을 가하기 위하여 PC의
정보를 위조할 수 있다. 또한 PC에 접속한 누군가가 신뢰하는 PC에서 온 것처
럼 속여서 서버에 접근할 수 있다. 그 시스템이 다른 시스템에 의존한다면 그
시스템들도 보호하기 위해서 여러분은 방화벽을 비교적 상부에 설치해야 할 것
이다. 방화벽을 통과하지 못하도록 하려는 응용프로그램 중 좋은 예로 NFS가
있다. 이러한 형태의 방화벽은 매우 설정하기 쉽다. 이렇게 민감한 서버에서는
모든 프로토콜을 사용할 수 없도록 금지하고 서버의 IP만 전달하도록 하여 외
부에서 온 IP가 IP 스푸핑하는 것을 꼭 차단하도록 한다. 단일 시스템이나 작
은 서브넷을 보호하는 전형적인 방화벽 규칙을 세우는 스크립트는 리스트 1에
서 볼 수 있다.
리스트 1：전형적인 방화벽 규칙을 지정하는 스크립트
# Delete all rules (This makes this script re?unnable without
# getting double firewall rules)
/sbin/ipfwadm ? ?
/sbin/ipfwadm ? ?
# Set default to accept.
/sbin/ipfwadm ? ? accept
# Forward to and from your protected server
/sbin/ipfwadm ? ? accept ? all ?0.0.0.0/0 ?your_server/32 ?
# Dont forward all other destinations
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?0.0.0.0/0
# Drop obviously fake packets
/sbin/ipfwadm ? ? allow ? all ?127.0.0.0/24 ?127.0.0.0/24 ?lo
/sbin/ipfwadm ? ? deny ? all ?127.0.0.0/24 ?0.0.0.0/0 ?
/sbin/ipfwadm ? ? deny ? all ?10.0.0.0/8 ?0.0.0.0/0 ?
# Drop your_server packets from the outside (assuming eth0 is your
# external interfdace)
/sbin/ipfwadm ? ? deny ? all ?your_server/32 ?0.0.0.0/0 ?i
?eth0
# same for your firewall.
/sbin/ipfwadm ? ? deny ? all ?your_firewall/32 ?0.0.0.0/0 ?
?eth0
# Optional: deny firewall as destination.
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?your_firewall/32 ?
# Finally, protect sensitive ports of your_server
[ ... ]
사실 실제 네트워크에서는 예제와 같이 간단하지 않다. 대부분의 네트워크에는
다른 서브넷의 부분인 여러 시스템이 있다. 학교와 같은 커다란 조직에서는 많
은 사람이 이서네트에 물리적으로 접근할 수 있다는 문제가 있다. 이러한 네트
워크를 보호하는 가장 좋은 방법은 서브넷을 물리적으로 개별적인 케이블로 연
결하여 사용하는 것이다. 예를 들어, 시스템 관리부 사무실에는 분리된 서브넷
을 할당하는 것이 가장 훌륭한 정책이라고 본다. 왜냐하면 시스템 관리자들은
특권을 가진 계정을 사용할 필요가 있기 때문이다.
복잡한 네트워크
일상적인 경우 여러분이 보호하고자 하는 네트워크는 보통 몇 가지 제한된 작
업밖에 하지 않는다. 전형적인 네트워크에서 사람들은 웹, 전자우편, POP과 데
이터베이스 서버에 접속하기 위한 telnet(윈도 애플리케이션 에서는 숨겨진 형
태) 등을 사용하기를 원한다. 매스커레이딩은 인터넷 접속에 대한 모든 기능에
는 영향을 주지 않으면서도 관리자 네트워크에 속하는 개별 시스템에는 연결할
수 없도록 해준다(매스커레이딩 호스트가 침입당하여 뚫리지 않는한 그렇다.
이경우에도 매스커레이딩 호스트가 어떤 기타 서비스도 하지 않고 오로지 매스
커레이딩에만 충실하다면 침입 자체가 거의 불가능 하다고 할 수 있다). 여기
에는 또다른 장점이 있다. TCP-wrappers를 통하여 데이터 베이스 서버에 대
한 접근을 보호할 수 있는데 이는 특정한 호스트만 데이터베이스에 접근하는
것을 허가한다. 새 클라이언트 시스템이 네트워크에 추가되면 /etc/hosts.* 파일
을 반드시 알맞게 수정해 주어야 한다. masquerading 기능을 사용한다면 이
엔트리가 반드시 필요하지는 않다. 왜냐하면 새로운 시스템은 masquerading
될 것이고 masqu eradi ng 호스트의 IP 번호는 데이터베이스 서버가 이미 알
고 있기 때문이다. 여러분이 물리적으로 관리 네트워크를 분리할 수 없다면 일
종의 암호화 기법을 생각할 수도 있다. Kerberos는 이러한 경우 많이 쓰인다,
그러나 또한 ssh-PPP 터널(ssh란 키를 쌍으로 사용하는 암호화 알고리듬이다)
을 사용할 수 있다. masquerading 호스트와 데이터베이스 서버 사이에 ssh로
간단하게 (암호화된) 가상 사설망을 구축할 수 있다. 단, 여기서는 학생들이 장
난으로 리눅스 시스템을 부팅하여 엿볼 가능성을 차단하여야 한다. 복잡한 네
트워크에서 누가 위협을 가하는지 알아내는 것은 매우 중요하다. 그 위협은 일
반적으로 외부가 아닌 내부에 있는데 외부에서의 위협은 인터넷 라우터/방화벽
시스템으로 보호할 수 있기 때문이다. 또한, 여기서 일어날 수 있는 IP 스푸핑
으로부터 여러분 자신을 보호하는 것을 잊지 않도록 한다.
방화벽 설정하기
방화벽을 설정하는 방법에는 기본적으로 두 가지 방향이 있다. 첫 번째로 가장
안전한 셋업은 ‘분명히 허용하는 것 외에는 모두 거부’하는 방법이 있다. 단
점은 왜 안되는 서비스가 많은지 궁금해하는 사용자가 많이 있을 수 있다는 것
이다. 방화벽이 클라이언트는 없고 서버만 있는 아주 작은 서브넷을 보호하는
경우에는 이러한 접근 방법이 적절하다. 이러한 방화벽을 셋업하는 스크립트는
리스트 2에서 볼 수 있다. 이러한 형태의 방화벽은 어떠한 프로세스가 실행되
고 있는지에 대하여 많은 지식을 필요로 한다. 적당한 문서를 갖추지 못하였거
나 투자할 시간이 충분하지 않다면 시도하지 말라.
리스트 2 : ‘분명히 허용하는 것 외에는 모두 거부’하는 방화벽
# Delete all rules
/sbin/ipfwadm ? ?
# Set default policy deny
/sbin/ipfwadm ? ? deny
# Allow telnets
/sbin/ipfwadm ? ? accept ? tcp ?0.0.0.0/0
1024:65535 ?your_server/32 23 ?
[ ....]
# Last rule: match failed attempts so we can
# log the entries
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?0.0.0.0/0 ?
두 번째로 더 쉬운 셋업은 ‘분명히 거부하는 것 외에는 모두 허용’하는 방법
이 있다. 이것은 네트워크를 완전히 개방하지만 위험하거나 필요 없는 프로토
콜을 통제한다. 예를 들어, 어떤 ISP는 모든 ‘CU-SeeMe’ 트래픽을 막기 위
해 이러한 기능을 사용한다. 왜냐하면, 이러한 종류의 트래픽은 전체 네트워크
를 붐비게 하기 때문이다. 이러한 종류의 방화벽을 세팅하는 방법은 리스트 3
에서 볼 수 있다.
리스트 3 : ‘분명히 거부하는 것 외에는 모두 허용’하는 방화벽
Listing 3. ?llow Everything... Firewall
# Delete all rules
/sbin/ipfwadm ? ?
# Set default policy accept
/sbin/ipfwadm ? ? accept
# unallow telnets
/sbin/ipfwadm ? ? deny ? tcp ?0.0.0.0/0
?your_server/32 23 ?
[ ...]
# Silently allow the packet
무엇이 일어나고 있는지 어떻게 감시하는가?
앞의 두 예제에서 보아 온 것처럼 리눅스 커널이 sysl og 기능을 사용해서 분
명히 거부된 패킷에 대한 로그를 남기도록 하기 위해 모든 거부 규칙은 -o 옵
션을 가지고 있다. 그러한 로그에 남기지 않고 거부하였을 때 언젠가 여러분은
문제가 패킷 필터에 있음을 알기 전에 몇 시간 동안 버그를 잡는 헛수고를 할
지도 모른다. 이 메시지는 /var/log/messages 나 /var/log/syslog 파일에 나타
나는데 syslog 데몬(/etc/syslog.conf)을 어떻게 설정하는가에 따라 달려 있다.
여러분은 정기적으로 방화벽 시스템에 있는 로그 파일을 체크해야 한다. 공격
을 받아 메시지가 넘쳐 나도 로그를 기록할 수 있는 충분한 디스크 공간이 있
는지 확인하도록 한다. 가능하다면 로그 파일은 독립된 파티션에 두도록 한다.
여기에는 syslog 데몬이 공통적인 문제의 증거를 잡는 로그 엔트리가 있다. 로
그 엔트리는 리눅스 시스템과 같이 리빙스톤의 라우터에서 온 것이다.
Jan 2 15:17:57 unreachable.xtdnet.nl 15 deny: UDP from
130.244.101.74.137 to 194.229.18.53.137
이것은 아마도 방화벽이 공격받은 흔적 중에서 가장 많이 볼 수 있는 것이다.
137번 포트는 MS 윈도 시스템이 자신의 로컬 네트워크에서 이름을 찾는
NetBios 네임-서비스 포트이다. 그러나, 정확히 설정하지 못하면 윈도 시스템
은 NetBios 요청을 다른 시스템이 하도록 이끈다. 이러한 요청은 한 사용자의
telnet, FTP, WWW 요청에서 발생될 수도 있다. 로그 파일에 이렇게 평범한
오류로 가득 차지 않도록 하기 위해서 거부 규정을 -o 플래그 없이 사용해도
좋다. 방문자 중 하나가 루트 파티션을 netbios 로그로 가득 채우면 실제 로그
인은 수행을 멈추게 되고 보통은 서버를 다운시키게 된다.
Jan 2 17:12:34 unreachable.xtdnet.nl 2 deny: UDP from
10.0.3.1.61107 to 194.229.18.29.80 seq 1471CB0, ack 0x0, win 8192, SYN
이 메시지는 잘못 설정된 호스트에 원인이 있다. 10.*.*.* 내의 IP 번호는 LAN
에서 사용하도록 예약된 것이다. 우리는 이 호스트가 잘못 설정된 인터넷
masquerading 호스트임을 알아냈다. 그것은 실제 IP 번호 대신 masqueraded
네트워크에서 온 IP 번호를 사용하고 있다. 잘못 설정하게 되면 패킷은 방화벽
이 잡아내기 전에 다른 많은 라우터를 통하여 떠돌아다니게 된다. 대형 백본
ISP는 쓸모 없는 패킷을 걸러 내지 않는데 걸러 버리게 되면 인터넷 어느 곳
에서나 IP 스푸핑을 쉽게 시도 할 수 있게 하기 때문이다. 그러한 패킷을 전부
다 걸러 버리는 ISP를 절대로 신뢰하지 않도록 한다. 여러분 자신이 직접 해결
하도록 한다.
Jan 20 06:57:33 unreachable.xtdnet.nl 14 deny: UDP from
xx.yy.zz.aa.904 to 194.229.18.27.111
방화벽이 공격받았다는 것을 위에서 증명할 수 있다. 누군가가 RPC 데몬(UDP
포트번호 111)에 어떠한 데몬이 실행되고 있는지 요청하려고 한다. 해커가 모
든 포트를 스캔하여 대부분의 RPC 서비스를 찾더라도 그들에게 정보를 바로
주지 않는 것이 좋은 아이디어이다. 일반적으로 인터넷의 서버와 주고받는
RPC 서비스는 거의 필요가 없다.
해커들이 스캔하는 포트는 쉽게 발견된다. 왜냐하면 여러분의 로그 파일 안에
있는 필터 규칙에서 추적할 수 있는 방법을 남겨 두었기 때문이다.
Jan 3 22:16:55 unreachable.xtdnet.nl 44 deny: TCP from
xx.yy.zz.aa.17231 to 194.229.18.27.23 seq 1473731D0, ack 0x0, win 49152,
SYN
이것은 방화벽이 공격받았다는 또다른 사실을 보여준다. RPC서버에서 위와 같
은 공격을 받은 후에 우리는 이 호스트를 막아 두었다. 이 사이트의 메일 관리
자에게 응답이 없기 때문에 우리는 호스트의 모든 포트에 접근을 금지하였다.
Fab 4 09:10:17 polly.xtdnet.nl kernel: IP fw-in deny eth1 TCP
0.0.0.0:68 255.255.255.255.:67 L=328 S=0x00 I=4 F=0x0000 T=60
68번 포트는 bootp(DHPC) 포트이다. 어떤 시스템은 bootp 서버에 요청 신호를
마구 보낸다. 이는 윈도 95를 운영하는 컴퓨터나 또는 SNMP를 지원하는데 IP
번호를 필요로 하는 지능형 허브가 될 수도 있다(이 문제는 우리 중 한사람이
몇 달에 걸쳐 풀어냈다).
Jan 27 09:47:00 masq.xtdnet.nl kernel: IP fw-in deny eth1 TCP
10.0.4.6:1992 204.162.96.21:80 L=48 S=0x00 l=2993 F=0x0000 T=63
이 시스템은 masquerading 호스트를 라우터로 정의하지 않았다, 따라서 지능
적으로 동작하도록 시도한다. 그러나 아직도 정확한 게이트웨이를 찾지 못한
다.
Jan 28 09:10:17 masq.xtdnet.nl kernel: IP fw-in deny eth1 TCP
194.229.18.2:3128 194.229.18.36.2049 L=44 S=0x00 l=23859
F=0x0000 T=63
무슨 일이 일어났는지 이해하려면 우리는 TCP/IP의 내부적인 동작을 조금 자
세히 알아볼 필요가 있다. 모든 연결은 출발지 IP, 출발지 포트, 도착지 IP와
도착지 포트가 특정하게 결합됨을 확인할 수 있다. telnet, WWW 또는 캐시와
같이 잘 알려진 서비스를 찾는 것은 특정한 포트를 사용하기 위하여 늘 있는
일이다. 잘 알려진 서비스에 연결을 확인하기 위해서 로컬 시스템에 임의로 정
한 특정한 포트가 할당된다. 이 시스템이 다른 시스템에 잘 알려진 서비스의
접속을 시도한다면 TCP/IP 연결을 서비스에 따라 구분할 수 있어야 한다.
1024번 아래의 포트 번호는 임의의 포트로 정의할 수 없는데 왜냐하면 이들은
자주 쓰이거나 잘 알려진 서비스에 예약되어 있기 때문이다.
이제, 로그 엔트리를 다시 살펴보자. 194.229.18.36 컴퓨터는 194.229.18.2의
3128번 포트(캐시 서버)에 연결하고자 셋업하기를 원한다. 여기서 운영체계가
임의로 특정한 포트를 요청하고 2049번 포트가 할당된다. 그 다음 캐시 서버의
연결을 초기화한다. 194.228.18.36의 포트 2049번에 패킷에 대답을 보냄으로써
(194.229.18.2의 3128번 포트) 캐시 서버가 응답한다.
그러나 194.229.18.36 역시 방화벽 규칙을 사용하고 있는데 이 규칙에서는 NFS
를 막고 있다. 이는 다른 잘 알려진 서비스와는 달리 1024번 포트 아래에 위치
하지 않고 2049번 포트를 사용한다. 따라서 캐시 서버의 응답을 걸러 버리게
된다. 여러분은 이것이 내부 네트워크에서 생긴 것인지 아닌지 접속을 구분함
으로써 문제를 해결할 수 있다. TCP 헤더의 SYN또는 ACK 플래그가 설정되
어 있는지 점검해 보면 연결시작점을 결정할 수 있다. 2049번 포트에 접속하는
것을 걸러 내는 올바른 방법은 접속을 허용하면서 초기화 될 때 다음과 같이
한다.
/sbin/ipfwadm -l -i deny -S 0.0.0.0/0
-D 0.0.0.0/0 2049 -P tcp -y -Weth0 -o
Jan 2 11:22:58 unreachable.xtdnet.nl 38 deny: TCP from
193.78.240.90.8080 to 194.229.18.2.1642 seq F72DA7C6, ack
0xED8FDEA1, win 31744, SYN ACK
비슷한 상황이 여기에도 있다. 어떠한 시스템에서 임의로 설정한 특정 포트로
1642번을 선택하였다. 그러나 방화벽은 1642번 포트가 안전하지 못하다고 결정
하고 막아 두었다. Livingstone Postmaster 소프트웨어 사는 유닉스 호스트와
라우터/방화벽 사이에 이 포트를 사용하기 때문에 밖에서 이 포트에 전달하는
데이터를 걸러 버린다. 일반적으로 높은 번호의 포트는 막지 않는 것이 바람직
하지만 막아 두었다면 보호가 필요한 시스템의 포트만 막도록 한다. 예를 들어,
여러분의 라우터와 터미널 서버만 1642번 포트를 막고 유닉스 서버를 위해서는
개방된 상태로 남겨 둔다.
다음, 라우터/방화벽은 내부 시스템의 1642번 포트에서 도착하는 패킷을 받는
다. 이렇게 되면 라우터의 1642번 포트가 막혀 있더라도 패킷을 네트워크 내부
의 시스템에 전달할 수 있다
작은 결점이 있다면 뛰어난 해커에게 정보를 유출할 가능성이 있다는 것이다.
그들은 어느 것이 라우터, 방화벽, 라우터 또는 방화벽과 교신하는 유닉스 호스
트인지 알기 위하여 모든 IP 번호를 체크할 수 있다. 그러나, 그들은 다른 방법
을 통해서도 같은 정보를 찾을 수 있을 것이다. 예를 들면, traceroute 명령은
어떠한 시스템이 패킷 전송에 사용되고 있는지, 그리고 그것이 라우터인지, 방
화벽인지 아니면 두 가지 역할을 모두 하는지에 대한 많은 정보를 제공한다.
여러분은 위의 예제에서 설명한 -y 옵션을 사용할 수 있다. 모든 라우터/방화
벽이 이러한 옵션을 제공하는 것은 아니다.
Random Notes
여러분의 방화벽을 공격하는 것은 대부분 간단한 탐색 신호이다. 이는 여러분
의 문이 잠겼는지 확인하는 낯선 사람과 비슷하다. 위에서 사용한 방화벽 규칙
은 많은 문제를 겪지 않고 이들을 방어할 수 있어야 한다.
누군가가 문이 잠겨 있는 것 이상의 사실을 알아내려 한다면 어떻게 될까? 누
군가가 정말 당신에게 관심을 가지고 있다는 게 밝혀지면 어떻게 될까? 이것의
첫 번째 징후로는 방화벽에서 히트수가 놀랄 만큼 증가한다는 것이다. 여러분
이 취해야 할 첫 번째 단계는 시스템 관리자에게 연락하는 것이다. 만약 여러
분이 이러한 단계에서 정말로 아무도 믿을 수 없다면 메일 관리자에게 메일을
보내지 말고 그들이 알려주는 기술 지원 전화 번호도 믿지 말아야 한다. 전화
번호부에서 고객지원부 전화번호를 찾아라. 그 회사와 통화가 되면 무슨 일이
일어나는지 가능한 한 많은 정보를 제공하도록 한다. 여러분이 사이트의 관리
를 믿을 수 있다면 공격은 멈출 것이라고 확신할 수 있다. 가끔 이러한 접근이
실패하는 경우가 있다. 간혹 회사의 관리자가 공격에 결탁하거나 사용자들에게
유닉스 셸을 제공하는 ISP로부터 공격받는 경우가 있다. 이러한 ISP는 그 시간
에 대단히 많은 사람들이 연결이 되어 있을 것이므로 방화벽 로그의 시간 기록
에서 악용하는 사람을 추적한다는 것이 거의 불가능하다. 지금까지 우리에게
이러한 경우가 한번 있었다. 우리는 사이트의 탐색과 해킹의 원인으로 관리에
문제가 있다는 것에 의혹을 제기하였다. 우리는 해커들이 방화벽을 통하여 들
어올 수 있게 하였고 따라서 그들이 하는 일에 대해서 많은 정보를 수집할 수
있었다.
우리는 두 가지 도구를 사용하였다. 첫째로 인터넷 수퍼 서버 (inetd)를 바꾸어
xinetd라 하였다. inetd에는 대단히 많은 양의 귀중한 정보를 로그 파일에 기록
할 수 있는 옵션이 있다. 둘째로, 우리는 연결 요청이 우리에게 ident를 조사하
는 신호를 보내는데 충분히 길만큼 연결하고 있는지 확인하기 위해서 nologin
프로그램을 실행할 필요가 있었다.
/* nologin.c */
main() {
printf("You have no login on this machine.n");
sleep(60);
}
우리는 /etc/xinetd.conf에 probe되는 서비스가 가능하게 하였다. 예를 들어, 원
격 로그인 셸 rsh를 셋업하기 위해서는,
service call
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /bin/nologin
}
우리는 ident 탐색과 모든 서비스에 대한 원격 호스트 로그인을 가능하게 하였
다.
defaults
{
log_type = FILE /var/log/xinetd.log
log_on_success = HOST USERID
log_on_failure = HOST RECORD USERID ATTEMPT
instance
}
결국 방화벽에 이러한 가짜 서비스를 개방할 준비가 되었다. 설명한 로그인 레
벨이 상당히 높다는 것은 알고 있어야 한다. 여러분의 로그 파일은 극단적으로
커질 것이다. 그러나, 실제로 서비스할 때 로그 기록을 금지해서는 안된다. 예
를 들어, 보기에 아무런 해가 없는 finger 요청 로그 메시지를 몇 번 받았다.
그 요청을 받게되면 다른 시스템에서 온 탐색 요청을 거꾸로 추적한다. 탐색하
고 있는 시스템은 그 사실을 전혀 모른다. 그러나, 이 해커는 보안 시스템에서
탐색을 시작하기 전에 시스템 관리자가 로그온 했는지 알아보기 위해서 finger
명령을 내릴 때 일반적인 시스템을 사용하는 실수를 저질렀다. 물론 일반적인
시스템에는 ident 데몬이 실행되고 있다. 따라서 그의 이름이 로그에 기록되었
다.
방화벽은 필요하다
‘죽음의 Ping’의 예에서 본 것처럼 방화벽은 네트워크의 생명을 지켜줄 수
있다. 더 나아가서 우리가 TCP/IP 프로토콜의 동작에 대해 조금만 이해하고
있다면 방화벽을 설정하는 것이 무척 쉽다는 것을 보았다. 최근에 우리의 한
고객을 방문했을 때 그들의 두 방화벽을 살짝 엿보았다. 두 방화벽은 108일 동
안 가동하고 있었다. 그들은 리눅스 커널 버전 2.0.23에 앨런 콕스(Alan Cox)씨
의 Ping 패치를 포함하여 계속 운영하고 있다. 메인 인터넷 서버를 보호하는
방화벽에는 규정된 크기를 초과하는 ping 패킷을 네번 받은 것이 기록되었다.
또한 몇몇 학생들이(실수이건 고의건 간에) 불법 IP 번호를 사용하는 것을 방
지하고 있었다. 역시 잘못된 설정된 시스템이 쓸모 없는 IP 트래픽을 보내는
것을 기록한다. 유즈넷 뉴스도 다루고 있는 메인 인터넷 서버를 보호하는 방화
벽은 테라바이트급의 IP 트래픽을 보내고 있다. 이 방화벽은 네트워크에 보안
을 추가하는데 매우 안정되고 가치 있는 것으로 판명되었다. 단, 여기에는 외부
시스템만큼 믿을 수 없는 내부 시스템에 대하여 대비책을 세워두어야 한다. 그
리고 전체 이서네트 케이블을 제어하는 것이 모든 영역에서 보증되지는 않는다
는 사실을 알아야 한다.
Paul Wouter씨는 머드 프로그램을 만들려고 리눅스 0.99p18로 유닉스에 입문
했다. 그는 현재 Xtended Internet의 시스템 관리자이고 광범위한 종류의 유닉
스를 다루고 있음에 불구하고도 그의 리눅스에 대한 사랑은 깊어만 간다. 그가
일할 때 earthmud.org에서 어슬렁거리는 것을 볼 수 있다. 그의 전자메일 주소
는 paul@stdnet.nl이다.
방법에 대해 알아보자.
글/ Paul Wouters 역/ 이기동(자유기고가)
방화벽은 여러분에게 가장 큰 도움을 주는 친구가 될 수도 있고 예측하기 어려
운 많은 문제의 원인이 될 수도 있다. 언제 네트워크에 방화벽을 놓는 것을 고
려해 보아야 하는가? 필요하다는 것이 확실하다면 네트워크의 어느 곳에 두어
야 하는가? 보통, 방화벽 정책은 정책결정자가 “저는 네트워크를 보호하기 위
하여 방화벽을 놓고자 합니다”라고 하는 의견을 기초로 하여 임원진 회의의
결과로 나오기 때문에 기술적인 논의가 잘 이루어지지 못한다. 한 조직에서 방
화벽을 설치하고자 할 때는 그러한 이유에 대해서 생각해 볼 필요가 있다. 무
엇으로부터 보호하려는 것인가? 이러한 작업을 수행하려면 어떻게 해야 하는
가? 이 기사는 고려할 필요가 있는 문제를 명확히 하는 것을 목적으로 한다.
방화벽이란 무엇인가?
이 질문에 답하기 쉽게 보이지만 그렇지 않다. 보안 전문가들은 방화벽이란 통
과하는 모든 네트워크 패킷을 체크하고 시스템 관리자가 세운 규정에 의하여
특정한 패킷을 거부하는 기능을 수행하는 전용 시스템이라고 이야기한다. 요즘
우리는 웹서버(Firewall-1과 다양한 NT & 유닉스 시스템)를 운영하는 방화벽
과 방화벽 응용프로그램을 구동하는 웹서버를 볼 수 있다. 이제는 네트워크 패
킷을 걸러내는 모든것을 방화벽이라고 부르는 것이 일반적이다. 따라서 방화벽
은 패킷을 걸러내는 기능 또는 그러한 기능을 수행하는 소프트웨어를 지칭한
다. 그리고 어떤때는 이러한 응용프로그램을 수행하는 하드웨어를 지칭하기도
한다. 방화벽을 위해 특별한 하드웨어나 소프트웨어를 구입할 필요는 없다.
리눅스 서버(400불 정도 되는 386 PC에서 돌아가는)는 상용 방화벽의 많은 보
호 기능을 제공한다. 게다가 훨씬 융통성 있고 설정하기도 쉽다.
과연 방화벽이 필요한가?
몇 년 전에 필자는 네덜란드 유닉스 사용자 그룹(NLUUG) 회의에 참석하였다.
주제 중 하나는 ‘네트워크 보호를 위한 방화벽 사용’에 대한 내용이었다. 발
표자들의 연설을 듣고난 후에도 필자는 방화벽이 필요한 충분한 근거를 다룬
논점을 찾을 수 없었다. 필자는 아직도 이것이 사실이라고 생각한다. 잘 운영되
는 네트워크에서는 무의미한 패킷을 걸러 버리는 방화벽이 필요치 않다. 모든
시스템이 잘못된 데이터에 대처할 수 있도록 해야 한다. 하지만 이론과 실제
는 다르기 마련이다. 여러분이 네트워크를 아주 탄탄하게 제어하고 있지 않는
이상 여러분의 사용자들은 다양한 소프트웨어를 워크스테이션에 설치하고 싶어
할 것이다. 또한 여러분은 생각치도 못한 방법으로 사용하고 있을 수도 있다.
게다가, 일반적인 운영체계에서 새로운 보안 구멍은 언제든지 발견된다, 그리고
시스템마다 각각 ‘모든’버그가 수정된 최신 버전을 설치하였는지 확인하기란
매우 어렵다.
두 가지 이유로 중앙에서 통제하는 방화벽은 귀중한 방어선이 된다. 여러분은
사용자들이 임의로 소프트웨어를 설치하는 것을 통제해야 한다. 또, 여러분은
워크스테이션의 보안 통제가 가능한 한 자주 갱신되고 있는지 확인해야 한다.
그러나, 여러분은 그러한 상태가 항상 유지되는지 신뢰할 수 없다. 따라서 방화
벽은 항상 필수적이며 현실적인 것이라 할 수 있다.
죽음의 Ping
몇 달 전에 인터넷 보안 세계에서 작은 위기가 몰려왔다. 이를 악명 높은 ‘죽
음의 Ping’이라고 한다. BSD 소켓 코드 중 특정 부분에서 조각난 네트워크
패킷의 크기를 체크하지 못하는 경우가 있기 때문이다. 조각난 패킷이 다시 합
쳐지면 패킷은 최대로 허용하는 패킷 사이즈보다 몇 바이트 커지게 되었다. 이
코드에서는 이러한 상황이 절대 일어날 수 없을 것이라고 가정하였기 때문에
내부 변수가 최대값보다 더 커질 수 없도록 만들어졌다. 결과적으로는 코드를
제멋대로 생성하는 심한 악성 오버플로우가 일어났고 이런 경우 컴퓨터는 보통
다운된다. 이 버그는 많은 공동체에 영향을 미쳤다. 왜냐하면 그 코드가 BSD
소켓 안에 실제로 존재하기 때문이다. 이 코드는 새로운 소프트웨어(또는 펌웨
어)에서 기반으로 자주 사용되기 때문에 광범위한 시스템이 이러한 버그에 영
향을 받기 쉽다. ‘죽음의 Ping’으로부터 공격받을 수 있는 운영체계의 리스
트는 Mike Bremford's씨의 페이지, http://prospect.espresence.com/ping/에서
찾을 수 있다. 운영체계보다는 이서네트 스위치, 라우터, 모뎀, 프린터, 허브와
방화벽과 같은 많은 장치가 이러한 문제에 의심을 받기 쉽다. 시스템에 커다란
로드가 걸릴수록 버퍼를 초과하는 것은 더욱 치명적이다.
두 번째로 이 버그가 대단히 위험한 이유는 악용하는 경우가 흔히 일어난다는
것이다. MS 윈도 운영체계는 ICMP ping 프로그램을 실행할 때 패킷의 크기를
잘못 계산하고 있다. 사용할 수 있는 최대 패킷 사이즈는 65527인데 이는 실제
로 IP 패킷이 허용하는 최대값이다. 그러나 윈도에서 수행할 때는 65527 바이
트의 데이터 조각이 생성되고 IP 헤더가 붙게 된다. 분명히, 65535바이트가 넘
는 패킷이 만들어지는 것이다. 따라서, 여러분이 해야 할 것은 다음과 같이 입
력하는것 뿐이다.
ping -l 65527 victim.com
이러한 방법이 한번 알려지면 사람들이 지구 전역으로 즐겁게 ping을 시도하는
동안 전세계적으로 서버들이 다운된다. Mike씨의 페이지에 있는 리스트를 볼
수 있더라도 공격받을 수 있는 장치 모두 패치가 나와있지는 않다. 그 패치가
있더라도 시스템 관리부에서는 그러한 장비 모두를 수정하는데 최소한 며칠이
걸릴 것이다. 여기서 방화벽이 가장 확실한 역할을 한다. 이렇게 중요한 보안
문제가 발견되면 네트워크에 접속하는 지점에서 접근을 금지시킬 수 있다. 현
재 방화벽을 가지고 있다면 여러분 대부분은 데이터베이스 서버가 공격받지 않
는다고 확인할 때까지 아마도 모든 ICMP 패킷을 걸러버릴 것이다. 이러한 시
스템 중 한두 대가 공격을 받을 수 있다면 사실은 많은 수가 그런 것이다.
최근에 MS 제품에서 쉽게 악용할 수 있는 또다른 버그가 발견되었다. C와
Perl로 만들어진 작은 프로그램인 winnuke는 윈도 95나 윈도 NT의 139번 포
트로 특정한 데이터를 보내어 네트워킹 코드를 완전히 파괴하고 따라서 그 시
스템은 네트워크를 통한 접속을 전혀 받아들이지 못하게 된다. 이틀만에 이러
한 문제를 해결한 임시 수정판을 사용할 수 있게 되었다. 이 글을 쓰고 있을
때에는 MS에서 공식적인 패치가 올라오지 않고 있었다. 방화벽에 의하여 보호
받는 네트워크는 수정판이 발표될 때까지 139번 포트를 임시로 막아 둘 수 있
다. 대부분 네트워크의 인터넷으로 나가고 들어오는 지점에서 139번 포트의
netbios는 거의 필요가 없다. 그리고, 그러한 사고가 나기 전에 이미 차단해 두
어야 한다.
여기서의 경험적 결론은 방화벽의 신속성과 강력함이 우리에게 귀중한 도구가
될 수 있다는 것이다.
방화벽으로 어떻게 네트워크를 보호하는가?
여기에는 물어 보아야 할 기본적인 질문이 있다.
1. 무엇을 보호할 필요가 있는가?
2. 어떤 사람으로부터 보호할 필요가 있는가?
3. 방화벽을 네트워크에서 어느 곳에 위치시켜야 하는가?
4. 방화벽을 어떻게 설정하여야 하는가?
5. 무엇이 일어나고 있는지 어떻게 감시하는가?
이러한 질문에 정확히 답변하려면 전체 네트워크의 지도를 그려보는 것이 매우
중요하다. 각각의 장치를 하나하나 그릴 필요는 없는데 그것은 자주 바뀌기 때
문이다. 분리된 서브넷, 라우터, 허브와 물리적 위치(층, 사무실, 방)를 그려보
라. 네트워크에서 가장 안전할 필요가 있는 중요한 부분도 포함한다.
무엇을 보호해야 하는가?
대부분의 방화벽은 LAN 전체를 보호하는데 쓰인다. 이러한 경우에는 보통 인
터넷 라우터를 방화벽으로 사용한다. 적절히 설정된 인터넷 라우터는 IP 스푸
핑을 막기 위하여 로컬에서 쓰이는 IP 번호를 걸러 낸다(예를 들어 10.*, 127.*,
192.x.y.*). 또한 바깥에서 들어왔는데 내부에서만 쓰이는 IP 번호를 쓰는 모든
패킷을 걸러 버려야 한다. 이러한 부류의 패킷은 모두 시스템에 속임수를 걸기
위한 시도만 하기 때문에 접근이 바로 거부되어야 한다. 다음, 바깥으로 나가는
트래픽 중 등록되지 않은 IP 번호나 클래스를 가진 IP 트래픽을 걸러 버린다.
이는 쓸모 없는 패킷을 보내지 못하도록 하는 것(또는 인터넷 스푸핑으로부터
사용자들을 보호하는 것) 뿐만 아니라 자체적인 보안을 위한 것이다. 특히 윈
도 제품군은 RFC를 준수하지 않는 것으로 보인다. 필자는 IP 번호 6.6.6.6을 할
당하여 로컬 프린터를 공유하고 있는 윈도 95 시스템을 본 적이 있다. 인터넷
라우터가 이러한 패킷을 걸러 버리지 않는다면 인쇄하려는 문서가 인터넷으로
나가 버릴 수도 있다. 방화벽이 자주 쓰이는 또다른 목적은 단일 시스템을 보
호하기 위한 것이다. 방화벽을 써서 단일 시스템을 지키고자 한다면 방화벽 바
깥에 있는 어떤 것에도 의존하지 않아야 한다. 그렇지 않으면 여러분의 방화벽
은 잘못된 보안 감각을 심어주는 것은 물론 아무런 목적을 이룰 수 없게 될 것
이다. 여러분의 보호를 받는 서버가 보호받지 못하는 PC에서 온 데이터를 사
용하고 있다면, 누군가가 서버의 데이터에 심각한 손상을 가하기 위하여 PC의
정보를 위조할 수 있다. 또한 PC에 접속한 누군가가 신뢰하는 PC에서 온 것처
럼 속여서 서버에 접근할 수 있다. 그 시스템이 다른 시스템에 의존한다면 그
시스템들도 보호하기 위해서 여러분은 방화벽을 비교적 상부에 설치해야 할 것
이다. 방화벽을 통과하지 못하도록 하려는 응용프로그램 중 좋은 예로 NFS가
있다. 이러한 형태의 방화벽은 매우 설정하기 쉽다. 이렇게 민감한 서버에서는
모든 프로토콜을 사용할 수 없도록 금지하고 서버의 IP만 전달하도록 하여 외
부에서 온 IP가 IP 스푸핑하는 것을 꼭 차단하도록 한다. 단일 시스템이나 작
은 서브넷을 보호하는 전형적인 방화벽 규칙을 세우는 스크립트는 리스트 1에
서 볼 수 있다.
리스트 1：전형적인 방화벽 규칙을 지정하는 스크립트
# Delete all rules (This makes this script re?unnable without
# getting double firewall rules)
/sbin/ipfwadm ? ?
/sbin/ipfwadm ? ?
# Set default to accept.
/sbin/ipfwadm ? ? accept
# Forward to and from your protected server
/sbin/ipfwadm ? ? accept ? all ?0.0.0.0/0 ?your_server/32 ?
# Dont forward all other destinations
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?0.0.0.0/0
# Drop obviously fake packets
/sbin/ipfwadm ? ? allow ? all ?127.0.0.0/24 ?127.0.0.0/24 ?lo
/sbin/ipfwadm ? ? deny ? all ?127.0.0.0/24 ?0.0.0.0/0 ?
/sbin/ipfwadm ? ? deny ? all ?10.0.0.0/8 ?0.0.0.0/0 ?
# Drop your_server packets from the outside (assuming eth0 is your
# external interfdace)
/sbin/ipfwadm ? ? deny ? all ?your_server/32 ?0.0.0.0/0 ?i
?eth0
# same for your firewall.
/sbin/ipfwadm ? ? deny ? all ?your_firewall/32 ?0.0.0.0/0 ?
?eth0
# Optional: deny firewall as destination.
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?your_firewall/32 ?
# Finally, protect sensitive ports of your_server
[ ... ]
사실 실제 네트워크에서는 예제와 같이 간단하지 않다. 대부분의 네트워크에는
다른 서브넷의 부분인 여러 시스템이 있다. 학교와 같은 커다란 조직에서는 많
은 사람이 이서네트에 물리적으로 접근할 수 있다는 문제가 있다. 이러한 네트
워크를 보호하는 가장 좋은 방법은 서브넷을 물리적으로 개별적인 케이블로 연
결하여 사용하는 것이다. 예를 들어, 시스템 관리부 사무실에는 분리된 서브넷
을 할당하는 것이 가장 훌륭한 정책이라고 본다. 왜냐하면 시스템 관리자들은
특권을 가진 계정을 사용할 필요가 있기 때문이다.
복잡한 네트워크
일상적인 경우 여러분이 보호하고자 하는 네트워크는 보통 몇 가지 제한된 작
업밖에 하지 않는다. 전형적인 네트워크에서 사람들은 웹, 전자우편, POP과 데
이터베이스 서버에 접속하기 위한 telnet(윈도 애플리케이션 에서는 숨겨진 형
태) 등을 사용하기를 원한다. 매스커레이딩은 인터넷 접속에 대한 모든 기능에
는 영향을 주지 않으면서도 관리자 네트워크에 속하는 개별 시스템에는 연결할
수 없도록 해준다(매스커레이딩 호스트가 침입당하여 뚫리지 않는한 그렇다.
이경우에도 매스커레이딩 호스트가 어떤 기타 서비스도 하지 않고 오로지 매스
커레이딩에만 충실하다면 침입 자체가 거의 불가능 하다고 할 수 있다). 여기
에는 또다른 장점이 있다. TCP-wrappers를 통하여 데이터 베이스 서버에 대
한 접근을 보호할 수 있는데 이는 특정한 호스트만 데이터베이스에 접근하는
것을 허가한다. 새 클라이언트 시스템이 네트워크에 추가되면 /etc/hosts.* 파일
을 반드시 알맞게 수정해 주어야 한다. masquerading 기능을 사용한다면 이
엔트리가 반드시 필요하지는 않다. 왜냐하면 새로운 시스템은 masquerading
될 것이고 masqu eradi ng 호스트의 IP 번호는 데이터베이스 서버가 이미 알
고 있기 때문이다. 여러분이 물리적으로 관리 네트워크를 분리할 수 없다면 일
종의 암호화 기법을 생각할 수도 있다. Kerberos는 이러한 경우 많이 쓰인다,
그러나 또한 ssh-PPP 터널(ssh란 키를 쌍으로 사용하는 암호화 알고리듬이다)
을 사용할 수 있다. masquerading 호스트와 데이터베이스 서버 사이에 ssh로
간단하게 (암호화된) 가상 사설망을 구축할 수 있다. 단, 여기서는 학생들이 장
난으로 리눅스 시스템을 부팅하여 엿볼 가능성을 차단하여야 한다. 복잡한 네
트워크에서 누가 위협을 가하는지 알아내는 것은 매우 중요하다. 그 위협은 일
반적으로 외부가 아닌 내부에 있는데 외부에서의 위협은 인터넷 라우터/방화벽
시스템으로 보호할 수 있기 때문이다. 또한, 여기서 일어날 수 있는 IP 스푸핑
으로부터 여러분 자신을 보호하는 것을 잊지 않도록 한다.
방화벽 설정하기
방화벽을 설정하는 방법에는 기본적으로 두 가지 방향이 있다. 첫 번째로 가장
안전한 셋업은 ‘분명히 허용하는 것 외에는 모두 거부’하는 방법이 있다. 단
점은 왜 안되는 서비스가 많은지 궁금해하는 사용자가 많이 있을 수 있다는 것
이다. 방화벽이 클라이언트는 없고 서버만 있는 아주 작은 서브넷을 보호하는
경우에는 이러한 접근 방법이 적절하다. 이러한 방화벽을 셋업하는 스크립트는
리스트 2에서 볼 수 있다. 이러한 형태의 방화벽은 어떠한 프로세스가 실행되
고 있는지에 대하여 많은 지식을 필요로 한다. 적당한 문서를 갖추지 못하였거
나 투자할 시간이 충분하지 않다면 시도하지 말라.
리스트 2 : ‘분명히 허용하는 것 외에는 모두 거부’하는 방화벽
# Delete all rules
/sbin/ipfwadm ? ?
# Set default policy deny
/sbin/ipfwadm ? ? deny
# Allow telnets
/sbin/ipfwadm ? ? accept ? tcp ?0.0.0.0/0
1024:65535 ?your_server/32 23 ?
[ ....]
# Last rule: match failed attempts so we can
# log the entries
/sbin/ipfwadm ? ? deny ? all ?0.0.0.0/0 ?0.0.0.0/0 ?
두 번째로 더 쉬운 셋업은 ‘분명히 거부하는 것 외에는 모두 허용’하는 방법
이 있다. 이것은 네트워크를 완전히 개방하지만 위험하거나 필요 없는 프로토
콜을 통제한다. 예를 들어, 어떤 ISP는 모든 ‘CU-SeeMe’ 트래픽을 막기 위
해 이러한 기능을 사용한다. 왜냐하면, 이러한 종류의 트래픽은 전체 네트워크
를 붐비게 하기 때문이다. 이러한 종류의 방화벽을 세팅하는 방법은 리스트 3
에서 볼 수 있다.
리스트 3 : ‘분명히 거부하는 것 외에는 모두 허용’하는 방화벽
Listing 3. ?llow Everything... Firewall
# Delete all rules
/sbin/ipfwadm ? ?
# Set default policy accept
/sbin/ipfwadm ? ? accept
# unallow telnets
/sbin/ipfwadm ? ? deny ? tcp ?0.0.0.0/0
?your_server/32 23 ?
[ ...]
# Silently allow the packet
무엇이 일어나고 있는지 어떻게 감시하는가?
앞의 두 예제에서 보아 온 것처럼 리눅스 커널이 sysl og 기능을 사용해서 분
명히 거부된 패킷에 대한 로그를 남기도록 하기 위해 모든 거부 규칙은 -o 옵
션을 가지고 있다. 그러한 로그에 남기지 않고 거부하였을 때 언젠가 여러분은
문제가 패킷 필터에 있음을 알기 전에 몇 시간 동안 버그를 잡는 헛수고를 할
지도 모른다. 이 메시지는 /var/log/messages 나 /var/log/syslog 파일에 나타
나는데 syslog 데몬(/etc/syslog.conf)을 어떻게 설정하는가에 따라 달려 있다.
여러분은 정기적으로 방화벽 시스템에 있는 로그 파일을 체크해야 한다. 공격
을 받아 메시지가 넘쳐 나도 로그를 기록할 수 있는 충분한 디스크 공간이 있
는지 확인하도록 한다. 가능하다면 로그 파일은 독립된 파티션에 두도록 한다.
여기에는 syslog 데몬이 공통적인 문제의 증거를 잡는 로그 엔트리가 있다. 로
그 엔트리는 리눅스 시스템과 같이 리빙스톤의 라우터에서 온 것이다.
Jan 2 15:17:57 unreachable.xtdnet.nl 15 deny: UDP from
130.244.101.74.137 to 194.229.18.53.137
이것은 아마도 방화벽이 공격받은 흔적 중에서 가장 많이 볼 수 있는 것이다.
137번 포트는 MS 윈도 시스템이 자신의 로컬 네트워크에서 이름을 찾는
NetBios 네임-서비스 포트이다. 그러나, 정확히 설정하지 못하면 윈도 시스템
은 NetBios 요청을 다른 시스템이 하도록 이끈다. 이러한 요청은 한 사용자의
telnet, FTP, WWW 요청에서 발생될 수도 있다. 로그 파일에 이렇게 평범한
오류로 가득 차지 않도록 하기 위해서 거부 규정을 -o 플래그 없이 사용해도
좋다. 방문자 중 하나가 루트 파티션을 netbios 로그로 가득 채우면 실제 로그
인은 수행을 멈추게 되고 보통은 서버를 다운시키게 된다.
Jan 2 17:12:34 unreachable.xtdnet.nl 2 deny: UDP from
10.0.3.1.61107 to 194.229.18.29.80 seq 1471CB0, ack 0x0, win 8192, SYN
이 메시지는 잘못 설정된 호스트에 원인이 있다. 10.*.*.* 내의 IP 번호는 LAN
에서 사용하도록 예약된 것이다. 우리는 이 호스트가 잘못 설정된 인터넷
masquerading 호스트임을 알아냈다. 그것은 실제 IP 번호 대신 masqueraded
네트워크에서 온 IP 번호를 사용하고 있다. 잘못 설정하게 되면 패킷은 방화벽
이 잡아내기 전에 다른 많은 라우터를 통하여 떠돌아다니게 된다. 대형 백본
ISP는 쓸모 없는 패킷을 걸러 내지 않는데 걸러 버리게 되면 인터넷 어느 곳
에서나 IP 스푸핑을 쉽게 시도 할 수 있게 하기 때문이다. 그러한 패킷을 전부
다 걸러 버리는 ISP를 절대로 신뢰하지 않도록 한다. 여러분 자신이 직접 해결
하도록 한다.
Jan 20 06:57:33 unreachable.xtdnet.nl 14 deny: UDP from
xx.yy.zz.aa.904 to 194.229.18.27.111
방화벽이 공격받았다는 것을 위에서 증명할 수 있다. 누군가가 RPC 데몬(UDP
포트번호 111)에 어떠한 데몬이 실행되고 있는지 요청하려고 한다. 해커가 모
든 포트를 스캔하여 대부분의 RPC 서비스를 찾더라도 그들에게 정보를 바로
주지 않는 것이 좋은 아이디어이다. 일반적으로 인터넷의 서버와 주고받는
RPC 서비스는 거의 필요가 없다.
해커들이 스캔하는 포트는 쉽게 발견된다. 왜냐하면 여러분의 로그 파일 안에
있는 필터 규칙에서 추적할 수 있는 방법을 남겨 두었기 때문이다.
Jan 3 22:16:55 unreachable.xtdnet.nl 44 deny: TCP from
xx.yy.zz.aa.17231 to 194.229.18.27.23 seq 1473731D0, ack 0x0, win 49152,
SYN
이것은 방화벽이 공격받았다는 또다른 사실을 보여준다. RPC서버에서 위와 같
은 공격을 받은 후에 우리는 이 호스트를 막아 두었다. 이 사이트의 메일 관리
자에게 응답이 없기 때문에 우리는 호스트의 모든 포트에 접근을 금지하였다.
Fab 4 09:10:17 polly.xtdnet.nl kernel: IP fw-in deny eth1 TCP
0.0.0.0:68 255.255.255.255.:67 L=328 S=0x00 I=4 F=0x0000 T=60
68번 포트는 bootp(DHPC) 포트이다. 어떤 시스템은 bootp 서버에 요청 신호를
마구 보낸다. 이는 윈도 95를 운영하는 컴퓨터나 또는 SNMP를 지원하는데 IP
번호를 필요로 하는 지능형 허브가 될 수도 있다(이 문제는 우리 중 한사람이
몇 달에 걸쳐 풀어냈다).
Jan 27 09:47:00 masq.xtdnet.nl kernel: IP fw-in deny eth1 TCP
10.0.4.6:1992 204.162.96.21:80 L=48 S=0x00 l=2993 F=0x0000 T=63
이 시스템은 masquerading 호스트를 라우터로 정의하지 않았다, 따라서 지능
적으로 동작하도록 시도한다. 그러나 아직도 정확한 게이트웨이를 찾지 못한
다.
Jan 28 09:10:17 masq.xtdnet.nl kernel: IP fw-in deny eth1 TCP
194.229.18.2:3128 194.229.18.36.2049 L=44 S=0x00 l=23859
F=0x0000 T=63
무슨 일이 일어났는지 이해하려면 우리는 TCP/IP의 내부적인 동작을 조금 자
세히 알아볼 필요가 있다. 모든 연결은 출발지 IP, 출발지 포트, 도착지 IP와
도착지 포트가 특정하게 결합됨을 확인할 수 있다. telnet, WWW 또는 캐시와
같이 잘 알려진 서비스를 찾는 것은 특정한 포트를 사용하기 위하여 늘 있는
일이다. 잘 알려진 서비스에 연결을 확인하기 위해서 로컬 시스템에 임의로 정
한 특정한 포트가 할당된다. 이 시스템이 다른 시스템에 잘 알려진 서비스의
접속을 시도한다면 TCP/IP 연결을 서비스에 따라 구분할 수 있어야 한다.
1024번 아래의 포트 번호는 임의의 포트로 정의할 수 없는데 왜냐하면 이들은
자주 쓰이거나 잘 알려진 서비스에 예약되어 있기 때문이다.
이제, 로그 엔트리를 다시 살펴보자. 194.229.18.36 컴퓨터는 194.229.18.2의
3128번 포트(캐시 서버)에 연결하고자 셋업하기를 원한다. 여기서 운영체계가
임의로 특정한 포트를 요청하고 2049번 포트가 할당된다. 그 다음 캐시 서버의
연결을 초기화한다. 194.228.18.36의 포트 2049번에 패킷에 대답을 보냄으로써
(194.229.18.2의 3128번 포트) 캐시 서버가 응답한다.
그러나 194.229.18.36 역시 방화벽 규칙을 사용하고 있는데 이 규칙에서는 NFS
를 막고 있다. 이는 다른 잘 알려진 서비스와는 달리 1024번 포트 아래에 위치
하지 않고 2049번 포트를 사용한다. 따라서 캐시 서버의 응답을 걸러 버리게
된다. 여러분은 이것이 내부 네트워크에서 생긴 것인지 아닌지 접속을 구분함
으로써 문제를 해결할 수 있다. TCP 헤더의 SYN또는 ACK 플래그가 설정되
어 있는지 점검해 보면 연결시작점을 결정할 수 있다. 2049번 포트에 접속하는
것을 걸러 내는 올바른 방법은 접속을 허용하면서 초기화 될 때 다음과 같이
한다.
/sbin/ipfwadm -l -i deny -S 0.0.0.0/0
-D 0.0.0.0/0 2049 -P tcp -y -Weth0 -o
Jan 2 11:22:58 unreachable.xtdnet.nl 38 deny: TCP from
193.78.240.90.8080 to 194.229.18.2.1642 seq F72DA7C6, ack
0xED8FDEA1, win 31744, SYN ACK
비슷한 상황이 여기에도 있다. 어떠한 시스템에서 임의로 설정한 특정 포트로
1642번을 선택하였다. 그러나 방화벽은 1642번 포트가 안전하지 못하다고 결정
하고 막아 두었다. Livingstone Postmaster 소프트웨어 사는 유닉스 호스트와
라우터/방화벽 사이에 이 포트를 사용하기 때문에 밖에서 이 포트에 전달하는
데이터를 걸러 버린다. 일반적으로 높은 번호의 포트는 막지 않는 것이 바람직
하지만 막아 두었다면 보호가 필요한 시스템의 포트만 막도록 한다. 예를 들어,
여러분의 라우터와 터미널 서버만 1642번 포트를 막고 유닉스 서버를 위해서는
개방된 상태로 남겨 둔다.
다음, 라우터/방화벽은 내부 시스템의 1642번 포트에서 도착하는 패킷을 받는
다. 이렇게 되면 라우터의 1642번 포트가 막혀 있더라도 패킷을 네트워크 내부
의 시스템에 전달할 수 있다
작은 결점이 있다면 뛰어난 해커에게 정보를 유출할 가능성이 있다는 것이다.
그들은 어느 것이 라우터, 방화벽, 라우터 또는 방화벽과 교신하는 유닉스 호스
트인지 알기 위하여 모든 IP 번호를 체크할 수 있다. 그러나, 그들은 다른 방법
을 통해서도 같은 정보를 찾을 수 있을 것이다. 예를 들면, traceroute 명령은
어떠한 시스템이 패킷 전송에 사용되고 있는지, 그리고 그것이 라우터인지, 방
화벽인지 아니면 두 가지 역할을 모두 하는지에 대한 많은 정보를 제공한다.
여러분은 위의 예제에서 설명한 -y 옵션을 사용할 수 있다. 모든 라우터/방화
벽이 이러한 옵션을 제공하는 것은 아니다.
Random Notes
여러분의 방화벽을 공격하는 것은 대부분 간단한 탐색 신호이다. 이는 여러분
의 문이 잠겼는지 확인하는 낯선 사람과 비슷하다. 위에서 사용한 방화벽 규칙
은 많은 문제를 겪지 않고 이들을 방어할 수 있어야 한다.
누군가가 문이 잠겨 있는 것 이상의 사실을 알아내려 한다면 어떻게 될까? 누
군가가 정말 당신에게 관심을 가지고 있다는 게 밝혀지면 어떻게 될까? 이것의
첫 번째 징후로는 방화벽에서 히트수가 놀랄 만큼 증가한다는 것이다. 여러분
이 취해야 할 첫 번째 단계는 시스템 관리자에게 연락하는 것이다. 만약 여러
분이 이러한 단계에서 정말로 아무도 믿을 수 없다면 메일 관리자에게 메일을
보내지 말고 그들이 알려주는 기술 지원 전화 번호도 믿지 말아야 한다. 전화
번호부에서 고객지원부 전화번호를 찾아라. 그 회사와 통화가 되면 무슨 일이
일어나는지 가능한 한 많은 정보를 제공하도록 한다. 여러분이 사이트의 관리
를 믿을 수 있다면 공격은 멈출 것이라고 확신할 수 있다. 가끔 이러한 접근이
실패하는 경우가 있다. 간혹 회사의 관리자가 공격에 결탁하거나 사용자들에게
유닉스 셸을 제공하는 ISP로부터 공격받는 경우가 있다. 이러한 ISP는 그 시간
에 대단히 많은 사람들이 연결이 되어 있을 것이므로 방화벽 로그의 시간 기록
에서 악용하는 사람을 추적한다는 것이 거의 불가능하다. 지금까지 우리에게
이러한 경우가 한번 있었다. 우리는 사이트의 탐색과 해킹의 원인으로 관리에
문제가 있다는 것에 의혹을 제기하였다. 우리는 해커들이 방화벽을 통하여 들
어올 수 있게 하였고 따라서 그들이 하는 일에 대해서 많은 정보를 수집할 수
있었다.
우리는 두 가지 도구를 사용하였다. 첫째로 인터넷 수퍼 서버 (inetd)를 바꾸어
xinetd라 하였다. inetd에는 대단히 많은 양의 귀중한 정보를 로그 파일에 기록
할 수 있는 옵션이 있다. 둘째로, 우리는 연결 요청이 우리에게 ident를 조사하
는 신호를 보내는데 충분히 길만큼 연결하고 있는지 확인하기 위해서 nologin
프로그램을 실행할 필요가 있었다.
/* nologin.c */
main() {
printf("You have no login on this machine.n");
sleep(60);
}
우리는 /etc/xinetd.conf에 probe되는 서비스가 가능하게 하였다. 예를 들어, 원
격 로그인 셸 rsh를 셋업하기 위해서는,
service call
{
socket_type = stream
protocol = tcp
wait = no
user = nobody
server = /bin/nologin
}
우리는 ident 탐색과 모든 서비스에 대한 원격 호스트 로그인을 가능하게 하였
다.
defaults
{
log_type = FILE /var/log/xinetd.log
log_on_success = HOST USERID
log_on_failure = HOST RECORD USERID ATTEMPT
instance
}
결국 방화벽에 이러한 가짜 서비스를 개방할 준비가 되었다. 설명한 로그인 레
벨이 상당히 높다는 것은 알고 있어야 한다. 여러분의 로그 파일은 극단적으로
커질 것이다. 그러나, 실제로 서비스할 때 로그 기록을 금지해서는 안된다. 예
를 들어, 보기에 아무런 해가 없는 finger 요청 로그 메시지를 몇 번 받았다.
그 요청을 받게되면 다른 시스템에서 온 탐색 요청을 거꾸로 추적한다. 탐색하
고 있는 시스템은 그 사실을 전혀 모른다. 그러나, 이 해커는 보안 시스템에서
탐색을 시작하기 전에 시스템 관리자가 로그온 했는지 알아보기 위해서 finger
명령을 내릴 때 일반적인 시스템을 사용하는 실수를 저질렀다. 물론 일반적인
시스템에는 ident 데몬이 실행되고 있다. 따라서 그의 이름이 로그에 기록되었
다.
방화벽은 필요하다
‘죽음의 Ping’의 예에서 본 것처럼 방화벽은 네트워크의 생명을 지켜줄 수
있다. 더 나아가서 우리가 TCP/IP 프로토콜의 동작에 대해 조금만 이해하고
있다면 방화벽을 설정하는 것이 무척 쉽다는 것을 보았다. 최근에 우리의 한
고객을 방문했을 때 그들의 두 방화벽을 살짝 엿보았다. 두 방화벽은 108일 동
안 가동하고 있었다. 그들은 리눅스 커널 버전 2.0.23에 앨런 콕스(Alan Cox)씨
의 Ping 패치를 포함하여 계속 운영하고 있다. 메인 인터넷 서버를 보호하는
방화벽에는 규정된 크기를 초과하는 ping 패킷을 네번 받은 것이 기록되었다.
또한 몇몇 학생들이(실수이건 고의건 간에) 불법 IP 번호를 사용하는 것을 방
지하고 있었다. 역시 잘못된 설정된 시스템이 쓸모 없는 IP 트래픽을 보내는
것을 기록한다. 유즈넷 뉴스도 다루고 있는 메인 인터넷 서버를 보호하는 방화
벽은 테라바이트급의 IP 트래픽을 보내고 있다. 이 방화벽은 네트워크에 보안
을 추가하는데 매우 안정되고 가치 있는 것으로 판명되었다. 단, 여기에는 외부
시스템만큼 믿을 수 없는 내부 시스템에 대하여 대비책을 세워두어야 한다. 그
리고 전체 이서네트 케이블을 제어하는 것이 모든 영역에서 보증되지는 않는다
는 사실을 알아야 한다.
Paul Wouter씨는 머드 프로그램을 만들려고 리눅스 0.99p18로 유닉스에 입문
했다. 그는 현재 Xtended Internet의 시스템 관리자이고 광범위한 종류의 유닉
스를 다루고 있음에 불구하고도 그의 리눅스에 대한 사랑은 깊어만 간다. 그가
일할 때 earthmud.org에서 어슬렁거리는 것을 볼 수 있다. 그의 전자메일 주소
는 paul@stdnet.nl이다.
