4. 리눅스 보안에 대하여
1. 들어가며
사람은 그런가보다. 자신이 관심이 있는 것이 있다면 그것에 집착을 느끼는 것 같다. 원래 강사신청을 하면서 리눅스의 보안은 그냥 가볍게 다루고 넘어가려고 하였다. 그것보다 오히려 기본적인 내용들에 충실한 강의 내용이 보다 많은 초보자들에게 도움을 줄수 있으리라는 막연한 생각 때문이었다.
허나, 최근에 필자가 근무하는 곳에 수없이 많은 해킹 시도와 그에따른 일부 리눅스 box의 문제들 그로부터 이루어진 네트웍 속도의 저하는 필자로 하여금 해킹에 대해서 관심을 갖게 하였다. 그렇다고 지금 필자 자신이 전문적이고 정확한 보안대책을 가지고 있다는 얘기는 아니다. 필자 또한 일반 유저 들처럼 노력하고 열심히 이해하고 있는 상황이라고 말할 수 있을 것이다. 사실은 해킹과 관련한 문제들로 인하여 몇주를 고생했는지 모르겠다. 그래서 원고 마감이 넘어서야 원고를 전해주는 실수와 미안한 행동을 하게 되었는지도 모르겠다.
아무튼 필자 자신의 관심과 현재적 상황으로 인하여 기초적인 사항을 조금은 소홀히 다루게 된 것에 대해서 모든 리눅서에게 사과의 말씀을 전하고 싶다. 허나, 모든 노력을 다해서 보안 부분 만큼은 확실히 짚고 넘어갈 생각이다.
자, 그러면 강의를 시작해 보겠다.
앞에서도 언급 하였지만 최근에 필자가 근무하는 학교에서 운영중인 각 서버들에 많은 무리들의 해킹 시도가 있었다 그러나 해킹 시도는 있었으나 그 이상의 일들은 할 수가 없었다.(몇몇 클라이언트 서버는 제외하고.) 그 이유는 아주 간단하다. 해킹을 할 수 없도록 문제의 발생 소지를 최대한 억제시켜 놓았기 때문이다. 물론, 이후에 약간의 문제가 있기는 했지만... 그렇다면 어떻게 해킹을 원천 봉쇄를 시킬수 있으며 어떻게 하면 좀더 크래커들의 마수에 걸리지 않고 시스템을 운영할 수 있는가? 이것을 이야기 하고자 한다.
흔한 얘기로 한국 대학 사이트는 크래커들의 놀이터라고 한다. 그건 사실이다. 다양한 보안과 감시를 한다 할지라도 해킹을 하려고 노력하는 사람들의 의지와 노력은 정말로 대단한 것이다. 그 말은 결국 언젠가는 해킹을 당할 수도 있다는 말과 같다. 그 말속에는 해킹 툴의 다양화,각종 데몬들의 상시적인 버그,사용자들의 부주의 등이 항시 존재하기 때문이다. 운동경기의 전략 가운데 공격이 최후의 방어라고 하는 얘기가 있다. 즉, 아무리 수비가 탄탄한 상대라고 할지라도 공격하는 사람들에게 있어서 수비의 한계는 언제나 존재하는 법이라는 것이다.
그러나 역설적으로 최대한 방어를 하다가 역습을 노리는 기습작전이라는 것도 있다. 견고한 수비를 하는 가운데 상대의 헛점을 노려서 득점을 하는 것이다. 전자는 크래커이며 후자는 시스템 관리자인 것이다. 즉 오늘의 주제는 후자인 방어자의 입장과 방어자의 방어 무기들을 최대한 만들어서 공격자의 공격을 잘 이겨낼 수 있도록 하는 것을 주제로 할 것이다.
2. 방화벽을 이용하여 시스템의 보안을 최적화
방화벽이라 함은 원래 자동차의 한 부분을 지칭하는 용어로써 차안과 엔진블록 사이를 나누기 위한 장치를 일컫는다. 이것의 역할은 자동차가 폭발할 때 승객의 안전을 보호하기 위해 만들어진 것이다. 그러던 것이 컴퓨터에 도입 되면서는 외부로부터 내부를 보호하는 장비와 기술을 일컫는 말로 변환이 되었다. 즉, 다시 말해서 방화벽이란 2개의 네트워크 사이에서 접근제어 정책을 구현할 수 있도록 하는 시스템이나 시스템들의 집합을 의미하는 용어로 자리매김 하였다. 일반 사용자의 경우에는 이런 고민까지 할 필요가 없겠지만 대부분 관리자들의 경우에는 항상 기계적인 관점에서 자신의 업무를 이해해야 할 것이다.
이런 시스템관리자의 입장에서 본다면, 보안이란 네트웍 상에서 수신,송신 되어지는 패킷을 차단하는 것과 패킷을 허용하는 것 두 측면을 고려해야 할 것이다. 이것은 닭이 먼저냐? 병아리가 먼저야? 라는 답없는 질문과도 같은 얘기일 것이다. 차단에 우선 두느냐? 허용하는 것에 우선을 두느냐? 사실 정답은 없을 것이다.
이것은 보안 정책을 어떻게 세우는가와 맥락이 같기 때문이다. 즉, 자신이 관리하는 시스템의 상태와 내용들을 면밀히 분석하여 나름대로 보안에 자신이 있다면 패킷을 허용하는 정책을 쓸수도 있고 그렇지 않다면 반대로 패킷을 차단하는 것이 바람직 할 것이다. 즉, 보안의 핵심은 보안 정책이 무엇이냐? 에 따라 다양한 형태의 보안 기법과 장비들의 설정이 결정되어지는 것이다. 이것은 관리자의 몫이라고 할 수 있다.(전적인 것은 아니지만.)
그럼 보안을 위해서는 무엇부터 손을 델것인가? 그것은 열이면 아홉이 방화벽을 이야기 할 것이다. 필자 또한 그렇게 생각한다. 방화벽을 구축하기 위해서는 방화벽에 대한 정책을 만들어 내는 것이 우선이라고 생각한다. 왜냐하면 방화벽은 접근제어 정책을 구현하기 때문이다. 다음장의 그림처럼 즉, 라우터 앞단에서 모든 패킷을 필터링 할 것인지, 그 뒤의 그림처럼 라우터의 뒷단에 물려서 차단해야할 패킷만 필터링을 할 것인지 아니면 중요한 서버들의 앞단에 놓아서 서버들만을 방어해 낼 것인지 등의 전략을 먼저 기획하는 것이 방화벽을 설치할 때 최우선 과제이다. db server와 같은 중요한 자료가 들어 있는 서버들은 방화벽을 이중으로 하거나 애초에 wan 구간에서는 접근을 못하도록 막아내는 것도 정책과 보안에 대한 고민속에서 그 해답이 나올수 있기 때문이다.
위에서 간단히 방화벽에 대한 정책과 그와 관련된 그림 자료를 참고삼아 방화벽의 원칙에 대해서 이야기 하였다. 자, 이제부터는 구체적으로 방화벽에 대해서 먼저 알아보기로 하자.
방화벽이란 무엇인가?
방화벽(firewall)은 네트워크 내부 또는 네트워크 상호간의 특수한 임무를 담당하는 "경찰과 같은 존재라고 할 수 있을 것이다. 방화벽은 외부에서 내부로 들어오는 트래픽 차단, 패킷 필터링(packet filtering) 그외 네트웍 주소 변환(nat: network address translation), 프록시 캐쉬 서비스( proxy cache service) 인증과 암호화를 통한 vpn구현 등의 다양한 기능을 제공한다. 일반적인 경우는 위의 그림과 라우터의 뒷 단에서 외부 네트웍과 내부 네트웍 사이에서 내부 네트웍을 보호하는임무를 수행하는 것이 대부분이다. 보다 구체적으로 얘기하자면 학교나 회사등에 설치되어 있는 네트웍에서 ras등을 통한 전화접속 , 전용선, 또는 프레임 릴레이등 원거리 통신 서비스를 통한 인터넷 접속을 통제하는 것이 방화벽의 중요한 일이며 그러하기에 효과적인 방화벽은 네트웍 안팎의 모든 통신 내용을 점검하여 허용된 통신만 가능하도록 하는 것이 가장 이상적이라고 할 수 있다. 일단, 방화벽을 통과하게 하면 방화벽은 유명무실한 존재가 되는 것이다. 바로 이것이 방화벽의 맹점이라고 할 수 있다. 물론 이를 해결하고자 방화벽을 이중,삼중으로 설치하는 곳도 있으나 그것은 특수한 경우라고 생각한다. 일반적으로는 방화벽은 라우터, 방호 호스트, 기타 하드웨어의 조합과 같이 하나의 장치가 아니라 완전한 네트웍 보안 정책의 일부라는 점을 명심해야 한다.
보안 정책에는 내부 사용자에 대한 강력한 권고사항이 있어야 할 것이다. 그리고 네트웍 접속, 다이얼-인과 다이얼-아웃, 디스크 및 데이터 암호와, 바이러스 방지에 대한 단체의 정책, 그리고 내부 학생,직원 등의 내부자에 대한 교육이 포함되어야 한다. 이는 해킹 사고의 많은 경우가 내부자의 실수로 기인하는 것이 많이 있기 때문이다. 현재 나와 있는 가장 빠른 전용회선은 t3이다. 이것은 초당 45mbps의 속도로 데이터를 전송해 주는 회선이다. ppp 사용자부터 시작해서 10m,100m 사용자 그 누구이던 간에 모든 사용자는 방화벽의 보호 대상이 감시, 대상이 되어야 한다. 영화 리얼 맥코이에서도 보았듯이 보안에는 항상 어딘가 헛점이 있기 때문이다.
왜 방화벽이 필요한가?
인터넷의 기하급수적인 발전은 많은 기업과 기관으로부터 인터넷에 발을 들여놓지 않으면 안되게끔 만들었다. 싫든,좋든 인터넷에의 가입은 이제는 모두에게 전제가 되어진 것이다. 또한 db의 발전은 많은 기업과 단체에 업무의 효율성을 기하게 해주었다. 바로 이 모든 것은 컴퓨터에 의해서 가능해진 일들이다. 그러나 요즘의 데이터베이스는 인트라넷과 연동되어서 운영이 되어지고 있다. 즉, 기업의 고급 정보, 예컨대 지적 재산권,자금현황,거래처 상황,개발기술등이 인터넷에 연결이 되어져 있다고 생각하면 될 것이다. 이는 지금도 제주도에 가면 있는 문 없는 집들이 있는 것 과 다를 것이 없다고 생각한다. 주인이 없으면 언제든지 그 집의 중요한 물건들을 훔쳐갈 수 있는 것과 같다고 할 수 있을 것이다.
크랙커 중에는 자신의 능력을 재미 삼아 과시하는 사람도 있지만 불순한 생각과 불순한 의도로 크랙을 시도하는 경우가 대부분의 경우이다. 며칠 전에도 신문에 나왔듯이 상대 회사의 고객 정보를 유출시켜 자사의 이득을 취하는 경우가 바로 단편적인 예라고 할 수 있다. 바로 이것이 방화벽이 필요한 이유이며 이들의 불순한 의도로부터 자사의 이익을 지켜내는 것이 방화벽의 존재 이유이다. 방화벽은 보안 뿐 아니라 네트웍 관리에 대한 보증 수표가 되기도 한다.
방화벽시스템은 과연 안전한 것인가?
한마디로 100% 안전한 보증 수표는 아니다. 방화벽은 방화벽을 통과하지 않는 패킷에 대해서는 막을수 있는 방법이 없다. 인터넷에 연결된 많은 기관들이, 단체들이 인터넷에 연결된 선로를 따라 유출될 수 있는 데이타의 보호를 위해서는 관심이 많다. 그래서 대부분의 방화벽 시스템이 라우터의 앞단이나 바로 뒷단에 포진을 시키는 것이다. 하지만 내부자에 의한 불법적인 정보 유출이나 모뎀을 통하여 침입해 들어오는 유저에 대해서는 상대적으로 그다지 관심이 없다. 이들의 접근에 대해서도 보안은 절대적으로 필요하다!!!. 또 그에 대한 정책수립 또한 필요하다!!!
값비싼 외산의 방화벽 제품을 구매하면서도 내부 네트웍을 통해서 들어오고 나가는 정보의 유출에 대해서는 신경도 쓰지 않는 것은 빛 좋은 개살구일 따름이다.. 방화벽이 최대한의 안정성과 완벽함을 보장받기 위해서는 내부 보안구조의 일부로서 동작하게금 일관성을 가지는 것이 좋다. 물론, 그렇다고 내부 패킷만을 필터링 하자는 얘기는 아니다. 방화벽에 대한 정책은 냉철하고, 현실적이어야 하며, 전체 네트웍의 현재 상태와 보안 수준을 잘 파악하고 추진 해야한다.
예를 들어 예산이라든가 회사의 일급정보 또는 개발기술등의 중요한 데이터가 존재하는 서버나 장소는 네트웍에 연결을 하지 말아야 할 것이며, 이런 서버나 장비는 내부 네트웍으로부터도 엄격한 차단이 필요하다. 대부분의 이런 중요한 데이터들은 db 서버에 존재할 것이다. db또한 인터넷의 발전에 발맞춰 인트라넷 환경으로 변하고 있는 것이 사실이고 현재의 상황임을 우리는 잘 알고 있기 때문이다.
그러나 이것을 과연 우리들만 아는가? 그렇지 않다.!!! 크래커 또한 잘 알고 있다. 아니, 오히려 우리들 보다 몇배는 더 잘 알고 있을 것이다. 그러하기에 db 서버나 그룹웨어 서버들은 별도로 관리를 한다든가 아니면 이중으로 방화벽을 설치하여 보안에 만전을 기해야 할 것이다.
한가지 지난 이야기를 하고자 한다. 몇 달전 대만의 어느 프로그래머가 개발해서 널리 퍼뜨렸다는 cih 바이러스를 기억할 것이다. 그때 국내의 pc들 중 실지로 피해를 경험했던 것들은 몇 만대를 헤아린다는 어느 방송의 보도가 있었을 것이다. 그 당시 필자 역시 많은 수의 pc들을 수리하고 롬바이오스와 보드가 일체형이었던 pc들은 용산을 가지고 가서 rom bios를 교체하거나 보드 전체를 갈기도 했던 기억이 생각난다. 여러번의 주의와 관심을 집중 시켰지만 그것은 모든 이들의 생각에 인식되어지진 못했던 것 같다. 아무리 바이러스의 피해를 이야기해도 관심이 없는 사람은 나중에 더욱더 혹독한 고생을 해야만 했었을 것이다.
생각해보라!!! 윈도우를 다시 깔고 그와 관련된 소프트웨어를 새로 깐다는 것을. 그리고 그동안 가지고 있던 귀중한 데이터들의 분실은 또 어떻게 하란 말인가? 이는 게으른자의 결과이다. 이렇듯 바이러스는 pc를 사용하는 모든 이들에게 공포의 대상이 아닐수 없을 것이다. 그러하기에 바이러스도 철저히 원천봉쇄 시킬 프로그램의 하나인 것이다.
사실, 방화벽은 바이러스에 대해서 그리 안정적이지는 못하다. 요즘에 발생하는 대부분 바이러스의 경우 네트웍을 기반으로 널리 퍼뜨리는 것이 보편적이라고 할 수 있다. 그러하기에 더욱더 문제가 심각하다. cih뿐 아니라 멜리사 바이러스 그외의 트로이목마와 같은 프로그램은 네트웍을 통하여 전파되고 감염을 시킨다. 방화벽은 만병 통치약이 아니다.!!!
그러하기에 모든 사용자들을 대신하여 모든 것을 막을 수 없으며, 네트워크의 전자우편이나 복사를 통해 전달된 바이러스에 대해 효과적으로 막을 수 없으며, 이러한 사례들은 여러가지 버젼의 sendmail 에서, 혹은 ghoscript, postscript viewer,각종 네트웍을 따라 움직이는 변종 바이러스 등에서 흔히 볼수 있었다. 바이러스를 너무 과소 평가하거나 우습게 생각지를 말아야 한다.!!! 한번에 모든 데이터를 파괴하는 것이 바이러스이기 때문이다. 바이러스는 방화벽이나 시스템 관리자들도 모르는 사이에 들어와서 순식간에 네트웍과 소중한 자료를 없애 버리는 무서운 적이라고 할 수 있다. 바이러스에 대한 대책 또한 보안의 한 부분으로서 취급하는 것이 마땅하다고 생각되어 진다.
그리고 바이러스에 대한 보안 대책은 바이러스를 네트웍 상에서 발견하겠다는 생각보다는 중요한 시스템이 부팅될때 마다 바이러스를 스캐닝 할 수 있도록 하는 편이 좋다. 바이러스 스캐닝 도구를 이용하여 네트워크를 보호하는 것은 플로피디스크, 모뎀, 인터넷 등에서 들어오는 바이러스를 막는 것이다. 방화벽에서 바이러스를 막는 방식은 단지, 인터넷에서의 바이러스 침투를 막는 것 밖에 없다. 대부분은 플로피디스크에 의해 전달된다는 사실을 우리 모두 기억해야 한다.
방화벽의 종류와 형태
방화벽 시스템의 형태
스크리닝 라우터(screening router)
간단한 방화벽 구성으로서 표준 라우터(cisco, 3com, bay network)를 사용한다. 일반적으로 ip 필터링 기능이 추가된 라우터를 이용해 들어오거나 나가는 패킷에 대한 접근을 제어하는 방법이다. 포트 번호와 소스, 목적지 주소에 근거해 다양한 패킷 필터링을 사용한다. 구현하기가 무척 쉬운 장점이 있는 반면, 먼저 로그 정보를 기록할 수 없고 만일 하드웨어적인 버그가 있다면 망 전체가 공격당할 위험이 있다. 또한 모든 라우터가 적절한 필터 메카니즘을 제공하지 않으며, 마지막으로 접근한 사용자는 확인할 수 있는 인증이 불가능하다. 그러나 타 시스템에 비해서 안정적이고 표준화 되어 있기 때문에 아직도 이런 구성을 이용하는 곳이 많다.
베스션 호스트(bastion host)
시스템 관리자가 망 보안의 가장 강력한 장소로 인식하며, 내부망으로 침입할 수 있는 영역으로 베스션 호스트를 통하게 함으로 써 위험 지역의 범위를 안정시키는 역할을 해 준다. 일반적으로 베스션 호스트는 높은 보안 상태를 유지하고 있다고 가정하고, 감사(audit), 기능 또는 추적(trail)기능을 갖고 있으며, 보안 유지를 위한 응용 소프트웨어들이 존재한다. 대부분이 2개의 패킷 필터링 라우터 사이의 유닉스 시스템을 베스션 호스트라고 한다. 외부 라우터는 인터넷과 베스션 사이의 트래픽만 허락된다. 내부 라우터는 내부 네트웍(안전한 네트웍)과 베스션의 트래픽만이 허락된다. 그러나, 베스션 호스트 방식의 방화벽에도 많은 문제점이 있다. 베스션호스트 시스템의 문제점은 아래와 같다. 첫째, 비용이 많이 든다는 사실이다. 이 방화벽의 구성은 최소한 2개의 유닉스 시스템과 2개의 라우터가 있어야 구현이 가능하다. 둘째, 유닉스 시스템 자체의 보안문제를 들 수 있다. 계속해서 발견되는 유닉스 보안 문제에 대처할 길이 없다. 대부분의 베스 션 호스트 방화벽은 전문가들의 기술에 의존하고 있다.
듀얼 홈 게이트웨이
스크리닝 라우터 없이 내부망과 외부망 사이에 시스템을 놓고 시스템의 tcp/ip 포워딩(forwarding) 기능을 막음으로써 구현되는 방화벽을 말한다. 즉, 외부나 내부에서 들어오는 모든 패킷을 ip base에서 필터링하는 것을 의미한다. 일반적으로 내부망과 외부망 사이의 직접적인 트래픽은 불가능하다.
따라서 듀얼 홈 게이트웨이(dual homed ga teway)는 내부망과 외부망의 두 개 인터페이스를 갖고 있어야 한다. 예를 들면 lan 카드, slip 인터페이스, 한 개의 lan 카드로 구성될 수 있다.
스크린 호스트 게이트웨이
스크린 호스트 게이트웨이(screened host gateway)는 가장 많이 사용되고 있는 방화벽 시스템의 예로서, 모든 데이터는 일차적으로 라우터에서 어느정도 필터링한 후 내부 방화벽 호스트로 전송되고 그런후 방화벽 호스트에 의하여 내부 네트웍내의 해당 시스템으로 보내질 여부가 판별된 후 전송되어진다. 스크린 호스트 방화벽은 외부 데이터가 직접적으로 내부망으로 전송되기 때문에 이중 홈 호스트 방화벽보다는 보안력이 미약하다. 따라서 스크린 호스트 시스템이 외부 침입자에 의하여 무너진다면, 스크린 호스트 시스템이 내부망의 다른 시스템과 연결되어 있다는점 때문에 내부망의 전체 보안정책에 혼란이 발생한다.앞서 설명한 스크리닝 라우터 방화벽과 베스션 호스트 방화벽 시스템의 문제점을 해결하기 위해 두 개의 방화벽 시스템을 결합한 것으로 구성된다.
베스션 호스트는 내부의 안전한 망에 위치하고 스크린 라우터 베스션 호스트를 외부망에서 접근 가능한 유일한 통로로 한다. 이 방화벽은 보다 안전한 방법이기는 하지만 비용이 많이 든다는 문제가 있다.
스크린 서브넷 게이트웨이
이 방화벽 시스템은 스크린 호스트 게이트웨이와 유사하다. 차이점은 스크린 호스트 게이트웨이에서 베스션 호스트 대신에 독립 된 서브넷으로 방화벽 시스템을 구성한다는 것 스크린 서브넷 게이트웨이는 내부망과 외부망 양쪽에서 접근할 수 있어야 되고, 스크린 서브넷을 통한 직접적인 내부망과 외부망 사이의 트래픽은 불가능하게 구성돼 있어야 한다.
기술에 따른 방화벽의 유형
패킷 필터링 게이트웨이
패킷 필터링은 크게 서비스 의존 패킷 필터링( service dependent packet filtering)과 서비스 독립 패킷 필터링( service independent packet filtering)으로 구분된다. 서비스 의존 패킷 필터링은 라우터가 특별한 서비스을 이용할 경우 사용하는 서비스 포트번호를 기준으로 패킷을 필터링하는 방법이다. 예을 들면, 텔넷 서비스(telnet service)는 일반적으로 tcp서비스 포트번호를 23번을 사용하기 때문에 관리자는 이 포트번호를 이용하여 텔넷서비스 접속을 허용 또는 거절할 수 있다. 최근에 소개된 레이어4 스위칭( layer 4 switching)이 서비스 의존 패킷 필터링을 근거로 한 기술이라고 볼 수 있다.
일반적으로 스위치들은 레이어2 스위칭(layer2 switching)으로 프레임의 헤더정보 내의 맥주소(mac address)를 검색한 후 데이터를 전송하고, 레이어3 스위칭( layer3 switching)은 osi 3계층에 해당되는 데이터 주소를 이용한 라우팅 기능을 통하여 전송한다. 반면에 레이어4 스위칭( layer 4 switching)은 osi 4 계층과 같이 송신처와 수신처의 노드간의 투명한 통신에 대한 서비스를 제공한다. 즉, 레이어 4 스위칭은 tcp( transmission control protocol)와 udp( user datagram procol )의 서비스 포트번호를 근간으로 패킷들을 검색하고 필터링 한다.
서비스 독립 패킷 필터링( service independent packet filtering)은 특정 서비스 또는 서비스 포트번호와 관계없이 네트웍상의 모든 패킷들을 필터링하는 방법이다. 일반적인 ip 패킷 필터링이 좋은 예제이다. 패킷 필터링은 관리자의 패킷 필터링 규칙 설정방법에 의하여 서버와 클라이언트간의 서비스에 관여된 여러가지 내부 네트웍 패킷들도 필터링 가능하다. 또한 패킷 필터링을 통한 인터넷 접속 제한은 모든 사용자들에게 동일하게 적용될 것이다.
단점이라면 경계선 방어가 되지 않고, 외부와 내부 시스템이 직접 연결된다는 것이다. 그리고 해커가 소스와 목표 어드레스, 포 트 등을 마음대로 조작할 수 있으며, 또한 사용자 인증 기능이 내부망에 존재하게 된다. 제품으로는 체크 포인트 파이어월(chec k point firewall-1), sun spf-100, 네트웍-1, 파이어월/플러스, 애틀랜틱 시스템 그룹 인터넷 시큐어 라우터(atlantic system g r oup internet secure router) 등이 있다.
서킷 레벨 게이트웨이
서킷 레벨 게이트웨이(circuit-level gateway)는 방화벽으로 동작하는 시스템에 내부 시스템이 외부망과의 접속을 의뢰하고, 방화벽 시스템은 요구에 따라 외부망과의 접속을 수행한다. 방화벽과의 통신을 위해 클라이언트는 특별한 프로토콜 (예를 들면, s o cks)을 사용해야한다. 즉, tcp 서비스에 관련된 프로그램들이 다시 컴파일돼야하며, 보통은 내부망에서 외부망 접속을 통제한다.
장점이라면 내부망과 외부망의 연결을 차단하고, 보안 담당자가 관리하는 하나의 포트를 이용해 내부망과 외부망을 연결하는 것 이다. 그러나 비표준 포트로 ftp, telnet 을 사용해서 방화벽의 우회가 가능하기 때문에 제어의 정도가 보통 라우터보다 못하다 . 또 애플리케이션 프로토콜을 자체로 번역하지 못해 애플리케이션 레벨에서 트래픽을 감시/통제하지 못한다. 제품으로는 블랙홀 ( black hole) 등이 있다.
애플리케이션 게이트웨이
애플리케이션 부분에서 보안 서비스를 제공한다. 네트웍 간의 모든 통신은 단절되고, 프록시(proxy)라고 부르는 애플리케이션 데이터 브리지를 통해서 네트웍 서비스가 개별적으로 허용된다. 장점으로는 경계선 방어를 제공하며, 애플리케이션 데이터를 제외한 어떤 네트웍 패킷도 네트웍 사이를 통과할 수 없게 한다. 필요시 인증 기능을 통합할 수도 있다. 또한 애플리케이션 레벨의 로깅 및 감사 기능을 제공한다. 단점으로는 비교적 속도가 느리며, 프로토콜이 제한된다는 점. 이로 인해 명성이 보장되지 않는다. 제품에는 tis gauntlet inte rnet firewall, raptor eagle, ans interlock, scc sidewinder 등이 있다.
하이브리드
하이브리드(hybrid gateway)는 패킷 필터링 방식과 애플리케이션 방식을 혼합한 것이다. 장점이라면 속도가 빠르고, 보안 정책 변경이 빠르다는 것을 들 수 있다. 반면 관리가 복잡하고 보안에 비례해 복잡성이 증가한다는 단점도 있다. 또 필터링 게이트웨 이에서 볼 수 있는 약점도 마찬가지로 갖고 있으며, 방화벽에서 운용되는 서버들이 노출될 수 있다는 것과 가격이 비싼것도 단점 이다. 제품에는 bnt 보더웨어 파이어월 서버(border ware firewall server), 디지털 파이어월 for 유닉스, 해리스 사이버가드(h a rris cyberguard), ibm netsp, sos 브림스톤(brimstone), 체크 포인트 파이어월-1(텔넷, ftp 프록시 도입) 등이 있다
3. 각종 버그를 통한 크랙 사례 와 대응방법
(1) sendmail daemon mode 취약성
sendmail은 표준 smtp 포트인 25번으로 들어오는 mail 연결에 대해 접속을 처리할 수 있는 서버모드로 수행 될 수 있고 이 서버 모드는 오직 root만이 수행 할 수 있도록 되어있다. 하지만 sendmail 버전 8.7 ~ 8.8.2 코드 작성시의 오류로 인해 실행자가 root인지를 검사하는 루틴이 그냥 통과 되어버리는 문제점이 있다. 그러므로 임의의 사용자도 서버모드로 sendmail을 수행 할 수 있게 된다.
추가로 sendmail 8.7의 경우에는 sighup signal을 받을 경우 서버자체가 재시작된다. 재시작을 위해 exec()함수가 사용되며 이 ? root 권한으로 재시작된다. 따라서 일반사용자 권한을 가진 공격자는 sendmail 환경을 조작하여 임의의 프로그램을 수행 할 수 있게 된다. 이를 통하여 root의 권한으로 임의의 프로그램을 수행할 수 있게 된다.
* 해결책
- sendmail 8.8.3을 설치한다.
ftp://ftp.sendmail.org/ucb/src/sednmail.8.8.3.tar.z
- ca-96.24에 들어있는 anti-smtp 프로그램을 설치하여 root이외의 권한으로 sendmail 을 서버모드로 수행할 수 있게 한다.
(2) sendmail 8.7.5 취약성
* 자원고갈 문제
전자우편이 .forward 파일 또는 .forward 또는 alias 파일 내의 :include: 문장에 의해 지정된 프로그램에 전달될 경우, 그 프 로그램은 .forward 파일 또는 :include: 문장에서 참조하는 파일의 소유자 (이러한 사용자들을 제어사용자라고 부름) 권한으로 실행되며, 프로그램이 아닌 파일에 전달될 경우에는 해당 파일이 제어사용자의 권한으로 열려진다. 전자우편이 즉시 전달되지 못한 경우, 메일 큐에 저장되며 적절한 권한을 확보할 수 있도록 제어사용자의 이름으로 큐 파일에 기록해 둔다. 이때 getpwuid(3) 를 호출하여 얻어진 제어사용자의 이름만 기록되는데, getpwuid가 실패하면 sendmail 디폴트 사용자(8.7.* 버전의 defaultuser 옵션, 이전 버전의 "u" 및 "g" 옵션에 의해 지정됨)로 지정된다. 어떤 경우 시스템 자원이 고갈되면 /etc/passwd 파일 내에 해당 uid에 대한 항목이 존재하더라도 getpwuid(3)가 실패할 수 있는 데, getpwuid는 "uid가 발견되지 않음" 과 "시스템 자원이 없음"을 의미하는 오류값을 구별하지 못하며 따 라서 sendmail도 이를 구분하지 못하게 되어 디폴트 사용자로 지정되는 것이다. sendmail의 특정 자원이 고갈되면 sendmail은 디 폴트사용자 소유의 파일을 생성하며 생성된 파일들은 디폴트사용자 소유의 다른 파일에 접근하는데 사용될 수 있게 되고 상위 권 한을 갖는 다른 사용자의 권한을 획득할 수도 있다.
* 버퍼 오버 플로우 문제
sendmail의 버전 8.7.5 과 그 이전의 버전에서 몇가지의 버퍼오버플로우 문제가 있으며 국지 사용자에 대해 인가되지 않은 관리자 권한을 허용할 수도 있다. 이를 통해 공격자가 root권한을 얻을 수 있다.
* 해결책
문제들을 해결하려면 업체들이 제공하는 패치를 설치하거나, 최신의 sendmail 버전을 설치해야 하며, 자원고갈에 대해서는 send mail의 저자인 eric allman이 제공한 다음과 같은 임시 조치를 취할 수 있다.
"proc" 메일러로서 smrsh(sendmail restricted shell)를 이용하여
디폴트사용자로서 수행되는 프로그램을 제한할 수 있다. 손상을 최소화시키는 방법은 문제가 생기지 않도록 디폴트사용자를 설정하는
것이다. sendmail은 호환성의 향상을 위해 디폴트사용자를 1:1(daemon)로 지정하지만 특별한 "mailnull" 계정을
이용하면 위험을 최소화시킬 수 있다. "ma ilnull" 사용자는 다른 어떠한 파일도 소유하지 않아야 하며, 실질적인 홈
디렉토리나 쉘을 갖지 않도록 해야 하는데, 다음 은 패스워드 파일 항목과 /etc/group 항목의 예이다.
○ /etc/passwd
mailnull:*:32765:32765:sendmail default user:/no/such/dir:/no/such/shell
○ /etc/groups
mailnull:*:32765:
이렇게 사용자를 추가한 후에, /etc/sendmail.cf의 "defaultuser=1:1" 라인을
"defaultuser=mailnull" 로 바꿔야 하며, 만약 8.6.* 버전을 사용하고 있는 경우에는 "ou1",
"og1" 라인들을 "ou32765"과 "og32765"로 바꿔야 한다.
마지막으로, sendmail 8.7.* 버젼과 함께 제공된 m4(1) 기반의 sendmail 구성 방식을 사용하고 있을 경우, 다음을 m4 입력 파일 (통상적으로sendmail.mc)에 추가해 주어야 한다.
define('confdef_user_id', 32765:32765)
* 탐지 및 예방
패치의 설치, 업그레이드, 또는 임시 조치를 취한 이후에라도 다음과 같은 점들에 유의해야 한다.
- 모든 sendmail 버전에 대해 smrsh 를 사용해야 한다.
- /bin/mail을 사용하고 있을 경우, mail.local로 교체해야 한다. mail.local은
sendmail 배포본에 포함되어 있으며, 기타 운영체제에도 포함되어 있다.
(3) talkd 버퍼오버플로우 대책
talk 명령에 사용되는 talkd 프로그램에 취약성이 발견되었다. 침입자가 특정 dns 데이터를 만들어 원격지에서 임의의 명령을 관리자(root) 권한으로 수행시킬 수 있다. talk는 사용자 터미널상의 텍스트를 다른 사용자의 터미널로 복사하는 통신 프로그램이고 talkd는 다른 사용자의 talk 대화 요청을 감지하는 데몬이다. talk 연결의 과정에서 talkd 프로그램은 연결을 요청한 호스트의 이름을 확인하기 위하여 dns lookup을 실행한다. 이때 되돌아온 호스트 이름이 저장된 버퍼의 한계를 검사하지않아 talkd의 내부 스택 영역을 겹쳐 쓸 수 있다. 따라서, 침입자는 호스트 이름에 대한 정보를 조작하여 talkd 프로그램이 임의의 명령을 실행하도록 조작 할 수 있으며, talkd는 관리자(root) 권한으로 실행되므로 침입자가 수행시킨 명령도 관리자(root)의 권한을 가지고 실행된다.
사용자 시스템이 talk 연결을 허용하는지 알아 보려면 /etc/inetd.conf를 확인하면 된다.
# grep -i "^[a-z]*talk" /etc/inetd.conf
이를 통해서 침입자가 원격지에서 관리자(root) 권한으로 임의의 명령을 수행시킬 수 있다. 침입자는 시스템에 계정을 가지고 있을 필요가 없다.
* 해결책
1. dns 기반의 공격들
bind 4.9.4 패치 레벨 1 이상의 버전을 설치.
2. 다른 네트워크 프로그램
다음의 위치에서 올바른 호스트이름/ip-주소 확인을 위한 서브루틴을
구해 호스트이름을 lookup 하는 모든 프로그램에 포함시켜야한다.
ftp://info.cert.org/pub/tools/validatehostname/isvalid.c
3. 제조업체로부터의 패치 설치
4. talkd 프로그램을 쓰지못하게 한다(inetd.conf 파일 수정
(4) sendmail mime 버퍼오버플로우 대책
sendmail의 8.8.3 과 8.8.4 버전에 있는 보안상의 취약점으로 인하여 외부사용자가
관리자(root) 권한을 획득할 수 있다. sendmail 은 email 메시지의 7bit자료를 8bit mime으로 변환하는데 이
변환작업시 한계에 대한 부적절한 검사로 인해 sendmail이 관리자(root) 권한으로 수행되는 동안 sendmail의 내부
스택공간에 임의의 코드를 덮어 쓸 수가 있다. email의 mime 변환은 주로 마지막 전달자, 즉 지역 호스트의 메일박스 또는
프로그램에서 이루어지므로 방화벽이 있더라도 취약성을 가진다. 이를 통하여 외부의 사용자가 관리자(root) 권한을 획득할 수
있다.
* 해결책
최신의 sendmail로 업그레이드(upgrade)한다.
- ftp://ftp.sendmail.org/pub/sendmail/
(5) ftpd 에서 시그날 제어대책
ftpd 프로그램 설계상 문제로 인하여, 특정 명령이 실행될때 잠시 루트의 권한을 가진후 본래의 권한으로 돌아와야 하는데 이를 조작하여 다른 시그날을 가로챌 수 있다. 이 취약성은 시그날을 제어하는 루틴을 이용하여 프로세서의 권한이 관리자(root)가 될수있을때까지 다른 시그날을 잡아낸다. 일반 사용자와 익명의 사용자에게 서비스가 허가된 상황에서 사용자는 관리자(root)의 권한으로 파일에 접근할 수 있다.
ftpd 서버의 설치 형태에 따라 침입자는 서버의 파일들을 읽고 쓸수 있게 한다. 이 공격은 취약성이 있는 ftpd 서버가 설치된 시스템과 네트워크 연결을 만들 수 있는 침입자만 있으면 공격이 가능하다. 이를 통하여 계정 소유자 그리고 익명의 사용자는 ftp를 이용할 때 관리자(root)의 권한으로 파일들에 접근하여 읽고 쓸수 있다.
* 해결책
각각의 벤더에서 제공하는 패치를 설치하거나, 이 취약점이 보강된 기타 ftpd 프로그램을 설치한다.
(6) inn 버그
사용자가 부정한 news 제어 문자를 inn(internetnews server)프로그램(버전 1.5 이하)에 보내 비인가된 사용자가 임의의 명령을 실행시킬 수 있다. inn 데몬(innd) 프로그램은 "eval" shell명령을 사용하는 shell script (parsecontrol)에서 "newgroup"와 "rmgroup" 제어 메시지를 처리하는데 이 제어 메시지들이 eval 명령으로 넘겨질 때 shell에 특수한 문자(shell 명령 등)들을 검사하지 않는다. 따라서 usenet을 이용할 수 있는 사용자는 누구나 그 서버에서 innd가 가지고 있는 uid 권한으로 임의의 명령을 실행시킬 수 있다. 또한 innd 프로그램은 메시지를 보낸 사용자가 newsgroup을 지우거나 생성하는 권한이 있는가를 검사하기 전에 "eval"을 실행하기 때문에 pgpverify와 같은 프로그램을 쓰는 것이 도움이 되지 못한다. 방화벽 뒤의 news 서버도 이공격에 취약하다.
innd v1.5 까지 이 공격에 취약하며 다음과 같이 innd의 버전을 확인한다.
% telnet news.your.site 119
connected to news.your.site...
escape character is '^]'
200 news.your.site internetnews server inn 1.4unoff4 05-mar-96 ready
이를 통해서 원격지의 비인가된 사용자가 innd 프로세스와 같은 권한으로 임의의 명령을 실행할 수 있다.
* 해결책
1. inn 1.5.1 로 업그레이드 한다.
2. 패치를 설치한다.
(7) x window system libxt 취약점과 대책
open group에 의해 배포된 xt 라이브러리와 xc/lib/xt/error.c파일에서 버퍼오버플로우 취약성이 존재하는데 이 라이브러리를 이용하여 만든 프로그램에 setuid나 setgid가 설정된 경우, 공격자는 허용되지않은 사용자 권한으로 임의의 명령을 실행시킬 수 있다. 만약 setuid root가 설정되어 있으면 root의 권한을 불법으로 획득할 수 있다.
이러한 취약성은 x11 release 6.3 이전 버전의 소스코드를 이용하여 작성된 프로그램에 setuid나 setgid를 설정하여 이용할 경우 일어나는데 이러한 x 응용프로그램들은 주로 /xc/config/cf/site.def 파일의 projectroot 항목에 지정된 디렉토리에 위치한다.
* 해결책
1. 다음에서 x11 release 6.3을 가져와서 교체 설치한다.
ftp://ftp.x.org/pub/r6.3/tars/xc-1.tar.gz, xc-2.tar.gz, xc-3.tar.gz
2. 또는, 자신의 x window 업체로부터 제공되는 패치를 설치한다.
3. 또는, 취약한 x 응용프로그램을 찾아 setuid bit나 setgid bit를 제거한다.
(8) xlock 프로그램 취약점과 대책
xlock은 x 터미널을 잠그기 위한 프로그램인데 일부 xlock 프로그램이 버퍼 오버플로우 보안문제점을 가질 수 있으며, 어떤 환경에서 setuid 또는 setgid 권한이 설정되어 있을 경우 일반 사용자가 시스템에 불법적으로 접근할 수 있다. 다양한 시스템에서 이와 같은 취약성이 있는 xlock 프로그램들이 발견되었으며, 이를 해결하기 위한 패치들이 제공되고 있다.
* 해결책
1. 패치를 적용하는 방법
각각의 시스템에 해당하는 패치를 가져와서 설치한다. 현재 이 취약점을 가지고 있는 시스템들은 다음과 같다.
data general corporation
freebsd, inc.
hewlett-packard company
ibm corporation
linux : devian
suse
sun microsystems, inc
2. 임시적 해결 방법
패치를 가져와서 설치하는 것이 불가능한 경우 관리자로 로그인한 후 다음과 같이 조치한다.
- setuid 또는 setgid 권한을 가진 xlock 실행을 정지시킨다.
- xlockmore 프로그램의 최신버전(4.02)를 설치한다.
ftp://ftp.x.org/contrib/applications/xlockmore-4.02.tar.gz
(9)msql 취약점과 대책
침입자는 수행중인 msql database 서버시스템에 권한없는 접근을 얻을 수 있다. msql서버 소프트웨어 msqld, msql2d는 msql서버에서 제공된 것보다 큰 스트링을 포함하는 질의(query) 생성에서 침입자는 스택에 덮어쓰기를 하여 임의의 코드로 수행될 수 있다.
* 해결책
다음을 참조바랍니다(msql 2.0-rel and msql2.0.1)
ftp://ftp.secnet.com/pub/patches/msql2-patches.tar.gz
(10) samba를 위한 버그 수정
이 보안 취약점은 samba의 모든 버젼에서 발견되었으며 접근이 허용되지 않은 원격 사용자가 samba 서버에서 root 권한을 획득할 수 있다. samba의 보안 취약점으로 인해 원격 사용자가 samba 서버에서 root 권한을 획득할 수 있다. 보안 허점에 대한 이러한 내용은 인텔 기반 플랫폼상에서 운영되는 samba 서버들에서만 가능하다. 이 취약점을 이용하는 실제적인 방법이 인터넷상에 공개 되어있으며 특히 인텔 리눅스 서버에 적용될 수 있다.
* 해결책
samba의 새로운 버전에서는 이러한 보안 허점이 수정되었다. 새로운 버전은 1.9.17.p2로서 다음의 ftp를 통해서 얻을 수 있다.
ftp://samba.anu.edu.au/pub/samba/samba-1.9.17.p2.tar.tz
또한, 새로운 버전은 보안 허점을 이용하려는 모든 시도에 대해서 메시지 를 로깅하는 루틴을 포함하고 있다.
samba의 log 파일에 기록되는 내용은 아래와 같다.
error: invalid password length 999
your machine may be under attack by a user exploiting an old bug
attack was from ip=aaa.bbb.ccc.ddd
여기서, aaa.bbb.ccc.ddd는 침입을 시도한 시스템의 ip 주소이다.
새로운 정보는 samba www 사이트를 참조하기바람
http://samba.anu.edu.au/samba
(11) lynx 임시 파일 취약점과 대책
lynx는 텍스트형태의 웹브라우저로서 유닉스 시스템에서 수행중에 영구 임시파일을 /tmp에 저장한다. lynx가 만드는 임시파일의 이름은 시스템의 다른 사용자가 쉽게 추측할 수 있고, 공격자는 race condition을 이용하여 임시파일에 링크를 걸거나 다른 파일로 대체하는 등의 해킹을 할 수 있다.
* 해결책
1. 아래에서 fotemods 패치를 가져다가 적용하고, /tmp 디렉토리에 'sticky 비트' 가 설정 되어있는지 확인한다. http://www.slcc.edu/lynx/fote/patches
drwxrwxrwt /tmp
sticky 비트가 설정되지 않았으면 다음과 같이 하여 설정한다.
# chmod 1777 /tmp
2. 다음과 같이 임시파일이 저장되는 디렉토리를 /tmp가 아닌 다른 디렉토리로 지정한다.
가. lynx 2.7.1에서 lynx2-7-1/userdefs.h 파일내의 #define temp_space 부분을 lynx를 실행하는 사용자만이 쓰기 가능하도록 설정된 디렉토리로 바꾼다.
나. lynx_temp_space 환경변수를 .profile, .cshrc 등의 파일에 지정해준다.
(12) lynx 다운로드 취약점과 대책
lynx 2.7.1 이하 버전이 설치되어있는 시스템에서 일반 사용자가 임의의 파일을 실행하거나 읽을 수 있다.
1. captive lynx installation
lynx 사용자는 captive 조건하에서 쉘프롬프트 또는 임의의 명령을 실행할 수 없지만,이 취약점을 이용하여 쉘프롬프트에 접근할 수 있다.
2. 전체 lynx 환경
웹관리자가 자신의 홈페이지에 특별히 조작된 url을 등록하여 lynx 사용자가 인지하지 못하는 사이 로컬 시스템에서 임의의 명령을 수행하도록 할 수 있다.
* 해결책
1997-06-26 이후 버전의 lynx는 이러한 취약점이 해결되었으며, lynx 2.7.1 버전에 대한 패치는 다음 사이트에서 제공된다.
http://www.slcc.edu/lynx/fote/patches/lynx2-7-1/src/lydownload.c
(13) ip 서비스 거부공격과 대책
최근 teardrop, land이라는 서비스 거부공격용 해킹 프로그램이 인터넷에널리 퍼지고 있다.
1. teardrop
몇몇 시스템에서는 tcp/ip 단편 재조합방법(fragmentation re-assembly)의 구현상의 문제로 인하여 겹쳐진(overlapped) ip단편(fragment)을 제대로 처리하지 못하는 문제점을 가진다.
시스템 내부적으로 ip 단편을 모아서 ip 데이타그램을 만드는 함수는 다음과같다.
memcpy((ptr + fp->offset), fp->ptr, fp->len)
이 함수이전에서 단편의 길이(fp->len)가 특정길이를 넘는지의 여부는검사하지만 단편의 길이가 0 이하로 설정되어있는 경우는 검사하지 않는다. 즉, 0 이하의 값을 가질 경우 단편은 이전의 복사된 단편에 겹쳐지게 된다. 몇몇 시스템은 이런문제에 대한 에러처리를 하지못하고 멈추게 된다. 공격자가 원격지에서 이런 약점을 이용한 teardrop을 사용하여공격할 경우 시스템이 멈추거나 재부팅된다.
2. land
몇몇 시스템에서는 tcp/ip 구현상의 문제로 인하여 수신하는 syn 제어패킷의 출발지주소와 목적지 주소가 해당 패킷을 수신하는 시스템의 ip주소를 가지는 경우 이를 제대로 처리하지 못하고 멈추게되는 문제를 가진다. 공격자가 원격지에서 이런 약점을 공격할 수 있는 land를 사용하여 공격할 경우 시스템이 멈추거나 재부팅된다.
* 해결책
1. 시스템별 패치를 설치한다. - 첨부참조
2. land의 경우 내부망 사용자의 원격지공격을 막기위하여 관리자는 외부로 나가는 라우터에서 출발지의 주소가 내부망의 주소가 아닌 다른주소로 속여서 외부로 나가는 패킷을 필터링하여 내부사용자의 외부망공격을 막을 수 있다.
참고 :
http://ds.internic.net/internet-drafts/draft-ferguson-ingress-filtering-03.txt
(14) apache 웹서버 보안취약점과 대응책
이 취약점을 이용하여 외부 사용자는 웹서버를 실행하는 사용자의 권한으로 임의의 명령을수행할 수 있다.
1. cfg_getline()에서의 버퍼오버플로우
cfg_getline()은 htaccess, htpasswd, mod_imap 파일을 읽을 때 사용하는 함수로 공격자가 이 파일들에 접근할 수 있다면 이 파일을 수정하여 버퍼오버플로우 공격에 이용할 수 있다.
2. mod_include에서의 코딩에러
mod_include 코딩시에 버퍼오버플로우 또는 자프로세(child process)스를 무한루프에 빠지게 하는 문제점이 있다.
3. no2slash() 의 비효율성
이로 인해 cpu time이 증가하여 시스템에 과부하를 줄 수 있다.
4. logresolve 프로그램의 버퍼오버플로우
logresolve 프로그램은 ip 주소를 호스트이름으로 변환하는 프로그램이다. dns 서버를 제어할 수 있는 공격자는 logresolve의 버퍼오버플로우 취약점을 이용할수 있다.
5. mod_proxy의 취약점
mod_proxy의 ftp proxy 부분은 클라이언트에 전달하기 위해 원격 ftp 서버로부터 디렉토리리스트를 받아서 이를 html 형태로 변환해 준다. 취약점을 이용하여 apache 서버에 코어덤프를 야기할 수 있으며, 주로 서비스 거부 공격에 이용될 수 있다.
6. proxy cache의 버퍼오버플로우
mod_proxy가 수행되면 apache는 캐쉬된 파일을 웹서버를 수행한 사용자 권한으로 디스크에 저장하는데, 만일 공격자가 이 사용자의 권한을 갖게되면 파일이름을 수정하여 버퍼오버플로우를 일으킬 수 있다.
7. htaccess 파일
htaccess 파일을 읽을 수 없을 때 apache는 이를 무시한다.
(15) redhat linux 4.2 lpd/printfilter/groff
redhat linux에 포함된 프린터필터(printerfilter) 소프트웨어 패키지는 프린트될 파일의종류를 결정하기 위하여 lpd를 호출한다. 그리고, 그 파일의 타입에 적합한를 필터적용하여 파일을 프린트하게 된다. 필터는 일반적으로 지원 어플리케이션을 호출하기 위한 쉘 스크립트로 되어있다. 이 필터의 첫번째 문제점은 일부 필터들이 ,/tmp를 프린트를 위한임시영역으로 사용한다는 것이다. 이때, symlink를 이용하여 새로운파일을 생성하거나, 겹쳐쓸 수 있다.(lpd는 사용자는 bin으로 그룹은 root로수행된다.)
첫번째 문제점은 많은 지원 어플리케이션들이 모두 보안에 관한 모든 문제점이 고려되어 작성된것이 아니라는 것이다. 한 예가 groff 이다.troff/groff 요청을 이용하여명령을 수행시킬 수 있다. 결과적으로 troff에 대한 기본적인 지식을 가진 사용자라면 troff 문서를 원격서버로 전달하여원격 서버에서 사용자 bin, 그룹 root로서 임의의 명령어를 수행시킬 수 있다.
프린터 필터를 사용하여 troff와 같은 어플리케이션을 사용하는 다른 운영체제에서도 동일한 문제가 발생할 수 있으므로 주의해야 한다. 이 문제점을 이용하여 국지사용자가 bin사용자 또는 root 그룹권한으로 새로운 파일을 생성하거나 기존의 파일에 겹쳐 쓸 수 있다. 또한 국지및 원격사용자가 bin사용자 또는 root 그룹 권한으로 임의의 명령을 수행 시킬 수있다.
* 해결책
다음패치를 설치한다.
ftp://ftp.redhat.com/updates/4.2/i386/groff-1.10-8.1.i386.rpm
ftp://ftp.redhat.com/updates/4.2/i386/rhs-printfilters-1.41.1-1.i386.rpm
(16) xterm과 xaw 취약점과 대책
mit x consortium, x consortium inc 및 open group x project 팀을 통해 배포된 터미널 에뮬레이터인 xterm(1)과 xaw 라이브러리에 취약점이 존재하며, 이를 이용하여 공격자는 관리자(root) 권한을 획득할 수 있다.이진코드를 포함한 임의의 긴 문자열을 교묘하게 구성하여 자원을 설정하는데 사용하면 루트권한을 획득할 수 있다. xterm(1)에 setuid-root 권한이 설정된 경우 또는 xaw 텍스트 위젯이 setuid-root권한이 설정된 프로그램에 의해서 사용되는 경우 이러한 취약점에 노출된다.
1. xterm 취약점이 있는 버전
resources release inputmethod preedittype *keymap
x11r3 no no yes
x11r4 no no yes
x11r5 no no yes
x11r6 no no yes
x11r6.1 yes yes yes
x11r6.2 yes yes yes
x11r6.3 yes yes yes
x11r6.4 yes yes yes
2. xaw 라이브러리 취약점이 있는 버전
resources release inputmethod preedittype
x11r6 yes yes
x11r6.1 yes yes
x11r6.2 yes yes
x11r6.3 yes yes
x11r6.4 yes yes
* 해결책
1. 임시해결책
- xterm으로부터 setuid-root 권한을 제거한다.
# chmod 0755 <path-to-xterm>/xterm
- xaw 텍스트 위젯을 사용하는 프로그램들의 setuid-root 권한을 제거한다.
# chmod 0755 <setuid-root-program>
(17) kde 보안 취약점과 대책
kde(k desktop environment)는 유닉스 워크스테이션을 위한 통합된 그래픽 데스크탑 환경을 제공한다. kde는 이러한 환경의 일부로서, setuid root 설정된 kppp와 스크린 락 환경인 klock을 공급한다. 하지만 이 두 프로그램은 지역 사용자가 루트 권한을 획득할 수 있도록 하는 여러가지 보안 취약점이 존재한다.
* 해결책
공식 패치를 설치하기 전까지 klock과 kppp 프로그램에서 setuid 비트를 제거한다.
chmod a-s klock kppp
(18) linux pam 취약점 및 대책
최근에 보급된 linux pluggable authentication modules(pam-0.64-2과 그 이하 버전들)의 pam_unix_passwd.so 모듈에 심각한 보안 취약점이 있어 /etc/shadow 파일에 읽기/쓰기 권한을 획득할 수 있다. rfc/faqs에 기술된 데로 수동으로 시스템에 리눅스 pam을 설치하였다면 시스템은 취약하며, 레드헷 5.x를 설치하였다면 좀더 안전하다. 왜냐하면 레드헷 5.x에서는 취약한 모듈을 새로운 pam_pwdb.so로 대체하였기 때문이다. 이 취약점을 확인하기 위한 간단한 점검 방법은 다음과 같다.
$ grep pam_unix_passwd /etc/pam.conf /etc/pam.d/passwd
이 취약점으로 인해 /etc/shadow 파일에 대한 읽기/쓰기 권한을 얻을 수 있고, 로컬에서 시스템 관리자 권한을 획득할 수 있다.
* 해결책
아직 패치가 발표되지 않은 상태임
임시적으로 passwd 프로그램의 setuid 비트를 제거한다.
chmod -s /usr/bin/passwd
(19) 트로이 목마 버전의 tcp wrapper
tcp wrappers는 유닉스 시스템에서 네트워크 서비스를 필터링하고 모니터링할 수 있는 도구이다. 최근 공격자에 의해 소스가 변경되어 트로이목마가 숨겨진 tcp_wrappers_7.6.tar.gz이 배포되고 있다. 이 트로이 목마는 1999년 1월 21일 이후, 몇몇 ftp 서버에서 발견되고 있다. 트로이목마 버전의 tcp wrapper는 소스 포트가 421번을 가지고 있는 접속이 시도될 경우 root로의 접근을 허락한다. 또한 이 트로이 목마 버전은 컴파일 도중에 사용자 계정과 시스템의 정보를 'whoami'와 'uname -a'를 이용하여 얻은 후 외부에 전자메일을 통해 발송한다. 따라서 이 트로이 목마 버전의 tcp wrapper가 동작 중인 호스트에 공격자는 시스템 관리자 권한으로 불법 침입이 가능해 진다.
* 해결책
1. tcp wrapper 무결성 검사
1999년 1월 21일 06:16:00(gmt) 이후에 tcp wrapper를 다운로드 받았다면 무결성을 확인해 보아야만 한다. md5 체크섬에 의한 무결성 점검값은 다음과 같다.
정상적인 버전일 경우 :
tcp_wrappers_7.6.tar.gz
md5 = e6fa25f71226d090f34de3f6b122fb5a
size = 99438
tcp_wrappers_7.6.tar
md5 = 5da85a422a30045a62da165404575d8e
size = 360448
트로이 목마 버전일 경우 :
tcp_wrappers_7.6.tar.gz
md5 = af7f76fb9960a95a1341c1777b48f1df
size = 99186
2. 새로운 tcp wrapper 설치
tcp wrapper를 개발하고 관리하고 있는 wietse venema는 자신의 pgp 사인을 덧붙인
tcp_wrappers_7.6.tar.gz을 보급하고 있다.
다음 사이트에서 tcp wrapper를 구할 수 있다.(기존 사이트가 공격당해 옮김)
ftp://ftp.porcupine.org/pub/security/
또는 cert coordination center의 tcp wrapper 사용도 안전하다.
ftp://ftp.cert.org/pub/tools/tcp_wrappers/tcp_wrappers_7.6.tar.gz
md5 checksum: e6fa25f71226d090f34de3f6b122fb5a
3. 소스 포트 번호 421인 패킷 차단
네트워크 차원(침입차단시스템, 라우터 등)에서 소스 포트 번호가 421인 패킷을 차단할 수도 있다. 하지만 이러한 경우 합법적인 접속이 421번 소스 포트 번호를 사용할 경우 서비스가 되지 않을 수도 있으므로 권장할 만한 방법은 아니다.
(20) ftp serv-u 2.5 취약점 및 대책
ftp serv-u 2.5에서 일반 사용자가 ftp 명령과 함께 155문자 이상의 스트링을 보내 서버를 다운시킬 수 있는 취약점이 발견되었다.
* 해결책
다음 사이트에서 새로운 베타버전의 프로그램을 설치한다.
ftp://ftp.cat-soft.com/beta
(21) 트로이 목마 사고
트로이목마는 "보안 위협을 일으킬 수 있는 사용자 권한을 공격할 수 있는 숨겨진 기능을 가진 유용한 것처럼 가장한 프로그램으로 트로이목마는 프로그램의 사용자가 의도하지 않은 일들을 한다." 트로이목마는 사용자가 프로그램을 설치하거나 이미 다른 방법에 의해서 불법적인 접근을 한 공격자에 의해 설치될 수 있다. 그러면 공격자는 다른 사용자가 트로이목마를 실행하므로써 시스템을 파괴 하고자 하는 시도를 한다.
최근 다음과 같은 트로이목마 관련 사고들이 일어나고 있다.
1. 인터넷 익스클로러(ie)의 거짓 업그레이드
최근에 마이크로소프트사의 ie 웹브라우저를 무료로 업그레이드하라는 전자 우편이 광범위하게 배포되고 있다. 그러나 마이크로소프트사는 패치나 업그레이드를 전자우편을 통해서 제공하지 않고 전자우편을 통해서는 보안 게시(security bulletins)만을 보급한다고 한다. 메일 메시지에는 ie0199.exe라는 실행 프로그램이 첨부되어 있다. 설치 후에 그 프로그램은 몇몇 시스템에 대한 수정과 다른 원격 시스템으로의 접속을 시도하게 된다.
트로이목마의 한 버전은 다음과 같은 메시지를 보낸다.
as an user of the microsoft internet explorer, microsoft corporation provides you with this upgrade for your web browser. it will fix some bugs found in your internet explorer. to install the upgrade, please save the attached file (ie0199.exe) in some folder and run it.
위와 같은 메시지는 실제 마이크로소프트사가 보낸 것이 아니다. 다음 위치에 있는 마이크로소프트 ie 웹 사이트를 참조할 것을 권유한다.
http://www.microsoft.com/windows/ie/security/default.asp
2. 트로이 목마 버젼의 tcp wrappers
최근 공격자에 의해 tcp wrapper의 소스코드가 수정되어 트로이목마를 포함한다고 발표되었다(ca-99-01-trojan-tcp-wrappers, ka-99-9-trojan tcp wrapper 참조).
여기에 관한 권고문은 다음 위치에서 구할 수 있다.
http://www.cert.org/advisories/ca-99-01-trojan-tcp-wrappers.html
http://www.certcc.or.kr/advisory/ka99/ka99-09.txt
(23) 트로이목마 버젼의 util-linux
util-linux는 리눅스 시스템을 위한 몇몇 기본적인 유틸리티를 포함하는 배포판이다. 1999년 1월 22일에서 1월 24일 사이에 최소한 한 ftp 서버의 util-linux-2g.tar.gz 파일에 트로이목마가 있다. 이 트로이 목마는 미러 ftp 사이트를 통해서도 배포될 수 있었다. 트로이목마 버전의 util-linux에는 /bin/login이 수정되어 있다. 이 수정된 코드는 공격자에게 호스트 이름과 로그인한 사용자의 uid가 포함된 전자우편을 공격자에게 보낸다. 또한 어떤 사용자에게 명령을 실행시킬 수 있는 로그인 프로프트를 제공해 주도록 수정되었다.
트로이목마가 설치되었는지 확인하기 위한 빠른 방법은 다음의 명령을 실행시켜 보는 것이다.
$ strings /bin/login | grep "helo"
실행결과 아래의 결과가 나타나면 트로이 목마 버전의 util-linux-2.9g이 설치되어 있는 것이다.
helo 127.0.0.1
실행결과 아무런 출력이 없으면 트로이목마가 설치되지 않은 것이다.
util-linux의 개발자에 의해서 제공되는 사이트에서 안전한 파일을 받을 수 있다.
ftp://ftp.win.tue.nl/pub/linux/utils/util-linux/util-linux-2.9h.tar.gz
* 이전의 트로이목마들
트로이목마 프그램들은 새로운 것이 아니고 트로이목마에 대한 배경과 역사에 대해 다음을 참조할 수 있다.
http://www.cert.org/advisories/ca-99-01-trojan-tcp-wrappers.html
http://www.cert.org/vul_notes/vn-98.07.backorifice.html
http://www.cert.org/advisories/ca-94.14.trojan.horse.in.irc.client.for.unix.html
http://www.cert.org/advisories/ca-94.07.wuarchive.ftpd.trojan.horse.html
http://www.cert.org/advisories/ca-94.05.md5.checksums.html
http://www.cert.org/advisories/ca-94.01.ongoing.network.monitoring.attacks.html
http://www.cert.org/advisories/ca-90.11.security.probes.html
사용자가 트로이목마를 실행하면 다음과 같은 행위를 할 수 있다.
- 사용자가 지울 수 있는 파일의 삭제
- 사용자가 읽을 수 있는 파일을 공격자에게 전송
- 사용자가 수정할 수 있는 파일의 변조
- 불법적인 네트워크 접속을 가능하게 하는 프로그램등과 같은 다른 프로그램을 설치
- 취약점을 공격하여 상위 권한 획득을 시도
- 바이러스 설치
- 다른 트로이목마 설치
* 해결책
시스템 관리자는 설치된 모든 소프트웨어에 대해서 신뢰할 수 있는 출처로 부터 받아온 것인지, 전송 중에 수정되지는 않았는지에 대해 신경을 써야 한다. 전자서명을 사용할 수 있으면 서명값으로 검증하도록 한다. 소프트웨어 개발자와 보급자들은 모든 소프트웨어의 생산과 보급에서 강력한 암호학적 검증을 사용한다. 청하지 않은 전자우편을 통해서 전달된 어떤 프로그램도 실행하지 않는다.
웹 페이지로부터 자바 애플릿, 자바스크립트, 액티브 엑스 등과 같은 내용을 실행할 때 주의하라. 웹 브라우저에 자동으로 웹 페이지의 내용을 실행하지 않도록 설정하도록 한다. 최소한의 권한으로 일상의 작업을 수행하도록 한다. 가령 전자우편을 읽는 일상적인 작업을 위해 "root"나 "administrator" 등의 권한으로 수행하지 않는다. 시스템 파일의 무결성을 점검할 수 있는 tripwire 같은 도구를 설치하여 운영한다. 사용자들에게 트로이목마의 위험성을 교육한다.
잘 알려진 트로이목마를 찾아내기 위한 침입차단시스템이나 바이러스 백신 제품을 사용한다. 터미널 에뮬레이터를 위한 ssh, 웹 서버에서의 x.509 공개키 인증서 등과 같은 암호학적으로 강력한 상호 인증 시스템 사용을 채택하라.
파일에 트로이목마를 있는지 확인할 때, 타임 스탬프, 파일 사이즈, 혹은 다른 파일 속성들에 의존하지 말라.
비인가된 소프트웨어 다운로드시 주의하라.
모든 보안 기관에서는 권고문과 다른 경고문들에 디지털 서명을 한다.
(24) 레드햇 리눅스 6.0 inn 취약점 및 대책
레드햇 리눅스 6.0의 inn 프로그램에 보안 문제점이 발견되었다. inn.conf 파일이나 innconf 환경변수를 수정함으로써 'news' 사용자는 시스템 관리자 권한으로 임의의 명령어를 수행할 수 있다. 이 취약점은 레드햇 리눅스 6.0 이전 버전의 inn에는 발견되지 않는다.
* 해결책
레드햇 리눅스 6.0 사용자는 버전별로 다음과 같이 패치한다.
alpha:
rpm -uvh ftp://updates.redhat.com/6.0/alpha/inn-2.2-9.alpha.rpm
rpm -uvh ftp://updates.redhat.com/6.0/alpha/inn-devel-2.2-9.alpha.rpm
rpm -uvh ftp://updates.redhat.com/6.0/alpha/inews-2.2-9.alpha.rpm
i386:
rpm -uvh ftp://updates.redhat.com/6.0/i386/inn-2.2-9.i386.rpm
rpm -uvh ftp://updates.redhat.com/6.0/i386/inn-devel-2.2-9.i386.rpm
rpm -uvh ftp://updates.redhat.com/6.0/i386/inews-2.2-9.i386.rpm
sparc:
rpm -uvh ftp://updates.redhat.com/6.0/sparc/inn-2.2-9.sparc.rpm
rpm -uvh ftp://updates.redhat.com/6.0/sparc/inn-devel-2.2-9.sparc.rpm
rpm -uvh ftp://updates.redhat.com/6.0/sparc/inews-2.2-9.sparc.rpm
source rpm:
rpm -uvh ftp://updates.redhat.com/6.0/srpms/inn-2.2-9.src.rpm
(25) 죽음의 ping
이 녀석은 얼마전에 필자의 학교 시스템에서 발생한 경우이기에 상당히 치가 떨리는 녀석이다. 멀쩡하던 네트웍이 어느 순간부터 느려지기 시작했다. 처음에는 늘 그렇듯이 외부망의 속도에 문제가 있어서 그렇겠지 하고 생각을 하고 있었다. 그런데 며칠이 지나도 네트웍의 속도 개선이 이어지지 않았고 내부 사용자들에게 문의 전화가 계속 이어졌다. 하여 패킷 스니퍼 유틸리티를 구하여 학교 전체의 패킷 검사를 면밀히 시작 하였다. 그 와중에 기본 게이트웨이는 정신을 못차리고 여러번 죽었다 살았다를 반복을 했었다. 학교 패킷을 분석 하던중 여러군데의 내부 외부에서 엄청난 양의 패킷을 라우터에 날리는 것을 발견할 수 있었다. 바로 이것이 네트웍 속도 저하와 라우터 다운의 원인이었던 것이다.
그래서 세션월로 외부에서 많은 양의 패킷을 날리는 사이트와 ip를 막아 버리고 내부에서 넘어오는 패킷은 서버 관리자와 협의하여 문제의 소지를 없애면서 네트웍의 안정성을 확보 할 수 있었다. 공포의 ping은 서버가 타겟이 되는 경우도 있지만 필자의 경우처럼 라우터가 그 표적이 되는 경우도 있다. 그렇게 되면 내부 네트웍은 ping을 날리는 시간 만큼은 거의 마비가 된다고 보면 될 것이다.
이건 아주 간단하게도 할 수가 있다.
ping -l 65527 xxx.com
이를 차단하기 위해서는 먼저 어디에서 패킷이 날아오는지를 확인해야 할 것이며 그를 위해서는 tcpdump 같은 도구를 사용하기를 바란다. 그리고 문제를 완전히 해결하기 위하여 관리자에게 연락을 취하여 라우터 단에서 막아낼 수 있도록 조언을 해줘야 할 것이다. 그것이 가장 확실하면서 정확히 문제를 해결할 수 있는 길이기 때문이다.
(26) 패킷 스니퍼
패킷 스니퍼를 이용하여 해킹을 시도하는 것은 아주 흔한 경우의 하나이다. 필자의 경우도 몇번 인가를 패킷 스니퍼를 이용한 해킹을 경험했던 기억이 있다. 패킷 스니퍼 사용자의 경우 먼저, 미리 확보해 놓은 id나 정보를 이용하여 내부 네트웍에 접근하여 스니핑을 걸어서 패킷 가운데 passwd,login,su 등의 단어들을 캐치해서 그 내용을 보관하여 둔다. 그렇게 해서 또다른 id와 패스워드를 획득하고 그런후에 루트의 패스워드까지 얻어 내는 것이다. ssh나 다른 암호화된 패스워드를 사용하면 이런 공격을 방해할 수가 있다. pop 계정을 위한 atop 같은 것도 스니퍼의 공격을 방어할 수 있다.
위와 같이 다양한 형태의 데몬 버그,툴을 이용한 해킹의 예들을 보았다. 앞의 예에서 다 다루지 못한 또다른 허술함들은 아마도 인터넷에 자신의 서버나 장비가 연결되어 있다면 항시 열려 있다고 할 수 있을 것이다. 그러하기에 관리자는 그 모든 가능성에 만전을 기해야 할 것이다. 그것이 바로 크랙으로부터 귀중한 자산을 보호하는 길일 것이다.
4. 방화벽 구축하기
그렇다면 방화벽은 어떻게 구축해야 할 것인가? 일반적으로 방화벽은 두가지의 형식으로 이루어진다고 할 수 있다. 하나는 기본 게이트웨이인 라우터에서 방화벽을 사용하는 것이 있으며 다른 하나는 라우터의 후단에 물려서 외부에서 들어오는 패킷을 필터링 해주는 것이 있다.
방화벽 설정하기
방화벽을 설정하는 방법에는 기본적으로 두 가지 방향이 있다. 첫 번째로 가장 안전한 셋업은 ‘분명히 허용하는 것 외에는 모두 거부’하는 방법이 있다. 단점은 왜 안되는 서비스가 많은지 궁금해하는 사용자가 많이 있을 수 있다는 것 이다. 방화벽이 클라이언트는 없고 서버만 있는 아주 작은 서브넷을 보호하는 경우에는 이러한 접근 방법이 적절하다. 이러한 방화벽을 셋업하는 스크립트는 리스트 2에서 볼 수 있다. 이러한 형태의 방화벽은 어떠한 프로세스가 실행되고 있는지에 대하여 많은 지식을 필요로 한다. 적당한 문서를 갖추지 못하였거나 투자할 시간이 충분하지 않다면 시도하지 말라.
리스트 1 : ‘분명히 허용하는 것 외에는 모두 거부’하는 방화벽
# 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에서 볼 수 있다.
리스트 2 : ‘분명히 거부하는 것 외에는 모두 허용’하는 방화벽
# 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
무엇이 일어나고 있는지 어떻게 감시하는가?
앞의 두 예제에서 보아 온 것처럼 리눅스 커널이 syslog 기능을 사용해서 분명히 거부된 패킷에 대한 로그를 남기도록 하기 위해 모든 거부 규칙은 -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는 그 시간에 대단히 많은 사람들이 연결이 되어 있을 것이므로 방화벽 로그의 시간 기록에서 악용하는 사람을 추적한다는 것이 거의 불가능하다.
5. 최적의 보안 작업을 위해서
tcp wrapper은 호구인가?
tcp_wrapper는 무엇이며, 어떻게 동작하는가? tcp_wrapper는 localhost로 들어오는 systat, finger, ftp, telnet, rlogin, rsh, exec, tftp, talk 등의 여러 인터넷 서비스에 대한 요청(request)을 관찰하고 필터링 하는 역할을 한다.
wrapper의 작동원리
client program(telnet)-----server(in.telnetd)-----application(remote login)
client program(ftp)-----server(in.ftpd)-----application(file transfer)
위와 같이 telnetd나 ftpd와 같은 프로그램이 telnet또는 ftp와 같은 프로토콜(protocol)의 요청을 받아들여 실제 작업을 수행하는 것이 인터넷 서비스의 원리이다. tcp wrapper는 client와 server사이에 위치하며 어떤 프로토콜에 대해서 어떤 호스트의 어떤 사용자가 요청을 하였는가를 체크하여 허용되는 경우에는 실제 server를 불러주고, 그렇지 못한 경우에는 이런 정보들을 log로 남긴다. 이런 이유로 해서 tcpd(실제 wrapper)의 사용에는 overhead가 걸리지 않는다.
client(ftp)-----tcp wrapper(tcpd)-----server(in.ftpd)
결점
tcpd의 경우에는 가장 처음에 오는 client의 요청에만 반응하기 때문에 여러가지 서비스를 요구하는 nfs서비스에 대해서는 사용이 쉽지 않다. 이 문제는 관련된 서비스에 관한 문서를 참고하도록 한다.
실행방법
실제 문서에는 쉬운 방법과 어려운 방법을 모두 설명하였으나, 설치와 관련되어서는 마찬가지인 관계로 어렵다는 방법을 설명하겠다. 전혀 어렵지 않다.
/etc/inetd.conf의 항목에 대해서 첫번째 줄을 두번째 줄로 바꾸는 방식처럼 바꾼다.
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -s /tftpboot
자 여기에 주목하라. /usr/sbin처럼 실제 데몬이 위치한 디렉토리는 다음 장에서 real_daemon_dir로 사용되게 된다. 이 디렉토리는 inetd.conf를 보고 알 수도 있고, which in.telnetd라고 해도 알 수 있다.
tcpd의 로그는 syslogd에 의해 결정된다. 실제 log가 남는 위치는 /etc/syslog.conf를 참고하라. 메시지는 log파일에 추가되고, console로 보내지거나 아니면 @loghost로 mail형태로 보내진다.
참고문서
readme file ftp.win.tue.nl:/pub/security/tcp_wrapper.ps.z (postscript)
ftp.win.tue.nl:/pub/security/tcp_wrapper.txt.z (flat text)
버그
irix는 많은 버그를 가지고 있으며 오래된 convexos또는 sunos5에는 조그만 버그가 있다.
설치에 필요한 파일들
tcp_wrappers-7.6.tar.gz
hosts.allow
hosts.deny
rfinger
압축 해제
다음 명령을 이용하여 압축을 해제한다.
gzip -cd tcp_wrappers-7.6.tar.gz | tar xvf -
컴파일
우선 make 만 하면,
% make
usage: edit the real_daemon_dir definition in the makefile then:
make sys-type
if you are in a hurry you can try instead:
make real_daemon_dir=/foo/bar sys-type
and for a version with language extensions enabled:
make real_daemon_dir=/foo/bar style=-dprocess_options sys-type
this makefile knows about the following sys-types:
generic (most bsd-ish systems with sys5 compatibility)
386bsd aix alpha apollo bsdos convex-ultranet dell-gcc dgux dgux543
dynix epix esix freebsd hpux irix4 irix5 irix6 isc iunix
linux machten mips(untested) ncrsvr4 netbsd next osf power_unix_211
ptx-2.x ptx-generic pyramid sco sco-nis sco-od2 sco-os5 sinix sunos4
sunos40 sunos5 sysv4 tandem ultrix unicos7 unicos8 unixware1 unixware2
uts215 uxp
if none of these match your environment, edit the system
dependencies sections in the makefile and do a 'make other'.
이렇게 나오고, 여기서 우선 real_daemon_dir 과 sys-type을 알 수 있다.
real_daemon_dir은 /etc/inetd.conf 파일 내에서 inetd들이 존재하는 디렉토리를 찾음으로서 알 수 있다. 다음은 /etc/inetd.conf 파일의 일부이다.
ftp stream tcp nowait root /usr/sbin/ftpd
telnet stream tcp nowait root /usr/sbin/telnetd
shell stream tcp nowait root /usr/sbin/rshd
login stream tcp nowait root /usr/sbin/rlogind
exec stream tcp nowait root /usr/sbin/rexecd
이 부분에서 daemon들이 /usr/sbin에 있음을 알 수 있다. 따라서 real_daemon_dir은 /usr/sbin이다.
sys-type은 다음 명령으로 확인한다.
% uname -a
osf1 foo.snu.ac.kr v4.0 564 alpha
이 예에서 sys-type 은 osf임을 확인할 수 있다.
이제는 make 명령으로 컴파일을 한다.
% make real_daemon_dir=/usr/sbin osf
이 때, 에러 또는 경고 메세지를 반드시 확인하도록 한다.
실행 파일의 복사
컴파일이 다 되었으면 tcpd, tcpdmatch, tcpdchk, safe_finger, try-from 파일이 생성되었을 것이다. tcpd 를 real_daemon_dir에 복사한다. 나머지 실행파일은 /usr/local/bin과 같은 적당한 곳에 복사한다.
# cp tcpd /usr/sbin
# cp tcpdmatch tcpdchk safe_finger try-from /usr/local/bin
hosts.allow, hosts.deny의 수정과 복사
이제는 각 서비스 별로 서비스를 열고 닫을 호스트를 정해준다. 이는 hosts.allow와 hosts.deny를 수정하면 된다. 파일을 수정하는 방법은 다음과같다.
% vi hosts.allow
/etc/inetd.conf에서 현재 시스템에서 작동 중인 인터넷 서비스를 확인하고 그 데몬들의
이름을 확인한다. 시스템에서 사용하지 않은 데몬이 있을 경우는 hosts.allow 파일에서 # 를 붙인다.그리고, 각 데몬의
이름을 /etc/inetd.conf에서 확인하여 정확히 바꾸어 준다. 다음은 서비스별로 deny 할 호스트를 지정한다. 기본적으로
all 로서 allow하고, deny할 호스트를 expect 다음에 지정한다. 이 때, dns name보다는 ip
address를 사용하기를 권장한다.
예)
rlogind: all \
except 147.46.67. \
147.46.10.10 \
147.46.82.242 \
147.46.80.220
hosts.allow의 수정이 끝나면, hosts.deny를 수정하는데, hosts.allow에서 except를 통해 지정했으므로 다음과 같이 설정한다.
% cat hosts.deny
all: all : (/usr/local/etc/rfinger %h %a %d >> /var/log/rfingerlog)¦
hosts.allow와 hosts.deny의 수정이 끝났으면 /etc 디렉토리에 복사를 한다.
% cp hosts.allow /etc
% cp hosts.deny /etc
rfinger의 복사
rfinger는 deny 된 host 접근을 log하기 위한 shell script이다. 파일은 /usr/local/etc에 복사하도록한다. 그리고 실행가능하도록 권한을 수정 한다.
% cp rfinger /usr/local/etc
% chmod a+x /usr/local/etc/rfinger
inetd.conf의 수정
이제는 inetd.conf 를 수정할 차례이다.
#############
# tcp wrapper
#
#ftp stream tcp nowait root /usr/sbin/ftpd ftpd
#telnet stream tcp nowait root /usr/sbin/telnetd telnetd
#shell stream tcp nowait root /usr/sbin/rshd rshd
#login stream tcp nowait root /usr/sbin/rlogind rlogind
#exec stream tcp nowait root /usr/sbin/rexecd rexecd
#
ftp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/ftpd
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/telnetd
shell stream tcp nowait root /usr/sbin/tcpd /usr/sbin/rshd
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/rlogind
exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/rexecd
wrapper를 통한 서비스만을 수정하는데, 원래의 설정을 그대로 복사한 후, #기호를 붙이고 /usr/sbin/ftpd 등의 각 서비스를 /usr/sbin/tcpd - 디렉토리는 해당 디렉토리임 - 로 바꾼다. 그리고, 마지막에 그 전에 있던 서비스를 기입한다. 위의 예를 잘 참고하자.
tcpdchk를 이용한 configuration 확인
여기까지가 wrapper의 설정은 끝났다. 이제는 tcpdchk를 통해서 제대로 설정이 되었는지를 확인한다.
% tcpdchk
이 때 에러가 나오면 해당 configuration를 수정한다.
tcpdmatch를 이용한 configuration 확인
설정이 제대로 되었으면 tcpdmatch 를 통해 설정한 호스트에서 들어 왔을 때 deny 되는지 allow 되는지 여부를 확인한다.
usage: tcpdmatch [-d] [-i inet_conf] daemon[@host] [user@]host
-d: use allow/deny files in current directory
-i: location of inetd.conf file
% tcpdmatch ftpd yahanbi
warning: yahanbi: hostname alias
warning: (official name: yahanbi.snu.ac.kr)
client: hostname yahanbi.snu.ac.kr
client: address 147.46.102.22
server: process ftpd
matched: /etc/hosts.allow line 39
access: granted
%tcpdmatch telnetd plaza.snu.ac.kr
client: hostname plaza.snu.ac.kr
client: address 147.46.80.220
server: process telnetd
matched: /etc/hosts.deny line 17
command: (/usr/local/etc/rfinger plaza.snu.ac.kr 147.46.80.220 telnetd >> /var/log/rfingerlog)
access: denied
inetd의 재시동
여기까지 이상이 없이 되었으면 이제는 inetd를 재시동하여 wrapper가 작동하도록 한다. 우선 ps 명령으로 pid를 찾아낸다.
% ps -u root | grep inetd
388 ?? i 0:08.56 /usr/sbin/inetd
그리고 hup를 통해 작동시킨다.
% kill -hup 388
설치 확인
ccs.sogang.ac.kr 등 deny된 호스트에서 접근 했을 때, deny가 되고, log가 /var/log/rfingerlog 에 남아 있는지 확인한다. 우선, 우리는 텔넷에서 처럼 전송 제어 프로토콜(tcp)의 연결이 어떻게 이루어지는지 알 필요가 있다. tcp 네트워크 연결은 ‘클라이언트/서버’ 모델에 기반을 둔다. 텔넷 프로그램은 서버 프로그램 또는 telnetd 또는 in.teln etd(시스템 설정에 따라 다르다)라 불리는 데몬과 통신하는 하나의 클라이언트이다. 대부분의 리눅스 배포본들은 네트워크 데몬으로 /usr/sbin 디렉터리에서 in.[serv ice]d라는 이름을 사용하기 때문에 필자는 여기서부터 이름을 정하는 관례를 따를 것이다.
모든 네트워크 서비스에 대한 요청은 가장 먼저 인터넷 데몬, inetd 통하여
이루어진다(세상살이가 다 그렇지만 이 규칙에도 예외가 있다. 뒤에서 알아보겠다). 데몬은 네트워크 연결 요청에 대해서 어떻게
응답할 것인지 결정하기 위하여 두개의 설정 파일을 사용한다. /etc/servi ces에는 각각의 서비스 이름과 그 포트 번호가
나열되어 있다. /etc/inetd.conf에는 서비스 이름, 프로그램 이름, 서비스를 제공하는 데몬의 이름이 나와 있다. 리스트
1과 2는 /etc/services와 /etc/inetd.conf 파일의 일부이다. 내 시스템의 인터넷 주소를
my.linux-box.com이라 가정하고 다음과 같이 입력하였다면,
telnet your.machine.com
텔넷 클라이언트는 출발지의 인터넷 주소 my.linux-box.com과 도착지의 인터넷 주소 your.machine.com와 포트 번호를 담은 패킷을(다른 것들과 함께) 보낸다. 텔넷의 포트 번호는 23번이다. inetd는 /etc/services에서 23번 포트를 찾고 서비스 이름이 텔넷이라는 것을 알게 된다.
그 다음 텔넷을 /etc/inetd.conf에서 찾고 in.teln etd라 불리는 데몬을 실행할 필요가 있는지 알아본다. 리스트 2의 가장 오른쪽 컬럼에서 볼 수 있다. inetd는 in.telnetd를 포트 23을 연결하기 위하여 in.telnetd를 실행한다. 그 다음 또 접속하는 요구가 있는지 감시하는 일을 한다. in.telnetd가 클라이언트에 응답하면 사용자 이름과 패스워드를 묻고 텔넷 세션을 시작한다.
만약 여러분의 시스템으로 누구도 텔넷 접속을 하지 못하도록 하고 싶다면 어떻게 할까? 접속을 요청하는 출발지 주소를 보거나 또는 시스템이나 도메인 밖의 모든 주소를 거부하기 위해서 in.telnetd의 코드를 수정할 수 있다.
만약 텔넷이 유일한 네트워크 서비스라면 이 문제는 무척 쉽지만 수많은 네트워크 서비스가 존재하기 때문에 시스템에서 모든 데몬마다 접근을 제한하도록 수정하는 것은 끔직한 일이다.
리스트 1：/etc/services의 예
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
exec 512/tcp # bsd rexecd(8)
login 513/tcp # bsd rlogind(8)
shell 514/tcp cmd # bsd rshd(8)
리스트 2：/etc/inetd.conf의 예
ftp stream tcp nowait root in.ftpd
telnet stream tcp nowait root in.telnetd
#smtp stream tcp nowait root smtpd
shell stream tcp nowait root in.rshd
login stream tcp nowait root in.rlogind
exec stream tcp nowait root in.rexecd
여기서 tcp_wrappers가 이러한 끔직한 일에서 구해 줄 것이다. wrappers 프로그램은 inetd와 in.telnetd, in.ftpd와 같은 네트워크 데몬 사이에 있는 작은 데몬이다. 모든 tcp 접속은 시작될 때 기본적으로 같은 방식을 따르게 되므로 wrappers 프로그램은 거의 모든 tcp 네트워크 서비스에 대한 접근을 제어하는데 사용할 수 있다.
wrappers가 설치되면 인터넷 데몬은 보통 네트워크 데몬 대신 wrappers를 실행하기 위하여 다시 설정된다. wrappers는 접속된 출발지 주소와 서비스를 체크하고 접속을 허가할 것인지 결정한다. 만약 your.machine.com이 내가 보낸 텔넷 세션의 요청을 거부한다면 접속을 끊는 길밖에 없다. 접속이 허용되면 모든 것은 정상적으로 처리되는데 wrappers는 실제로 내 텔넷 클라이언트에서만 작동하는 것은 아니다. 어느 쪽에나 wrappers는 시스템에 성공적으로 연결되었는지 알 수 있도록 하기 위해서 시스템 로그에 기록한다.
보안관련 각종 tool
1. 전자우편 - pgp:통신상에서 전자메일을 보호하기위한 암호화 툴로 가장 많이쓰이고있다.
2. 방화벽 - tcp-wrapper접근 제어 리스트를 통하여 관리자가 네트워크 접근을 필터링하고 기록하는 유닉스 기반의 방화벽 툴.
3. xinetd - tcp-wrapper와 비슷한 기능을 제공하는 보다 보안이 강화된 inetd 버전으로 시간에 따라 서비스를 제한하는 기능도 가지고 있다.
4. drawbridge - pc 기반의 패킷 필터링 툴
5. tis firewall toolkit - 인터넷 방화벽 구축용 공개 소프트웨어
6. tcpr - 방화벽을 통하여 나가는 telnet과 ftp에 투명성 있는 프락시 기능을 제공하는 펄로 작성된 툴
7. 보안스캐너 침입탐지
satan(system administrator tool for analyzing networks)
보안 스캐너로 네트워크를 통하여 시스템의 취약점을 조사하여 분석한다.
8. iss - 또 다른 보안 스캐너로 네트워크를 통하여 시스템의 취약점을 조사하여 분석한다.
10. courtney - 네트워크를 감시하여 사탄 공격시도를 탐지하는 툴로 tcpdump로부터 입력을 받아 주어진 시간내에 특정 호스트 로부터의 새로운 서비스 요청 수를 감시한다.
11. gabriel - 또 다른 사탄 공격 감지 툴
12. 네트워크 argus - ip 계층에서 데이터그램을 잡아 기록하는 툴로 사용자가 정의한 사건을 탐지하고 보고할 수 도 있다.
13. arpwatch - 하드웨어 이터넷 주소와 ip 주소 쌍을 모니터링하는 툴로 로컬 네트워크에서 위장 ip를 탐지할 수 있다.
14. nfswatch - 로컬 네트워크의 모든 nfs 서버로의 클라이언트 요청을 모니터링하는툴.
15. netlog - 모든 tcp와 udp 관련 패킷을 기록하고 분석하는 툴.
16. portmap - 표준 portmap의 대체 프로그램으로서 portmap에 대해 알려진 대부분의 보안 허점을 수정한 portmap. nis 패스워드 파일의 도용, 인증되지 않은 ypset 명령 및 nfs 파일핸들의 도용을 방지
17. rpcbind - sun rpcbind의 대체프로그램으로서 tcp-wrapper 형태의 접근제어 및 풍부한 로깅을 제공함
18. cpm - 네트워크 인터페이스가 promiscuous mode로 되어있는지 검사.
19. 시스템 tripwire - 각 파일의 디지털 서명을 작성하여 중요 시스템 파일들의 변조유무를 검사하는 도구
20. cops - unix 시스템의 보안상 문제점을 검사하는 툴
21. tiger - cops와 비슷한 툴로 사용이 더 편리하고 파일 변조유무를 검사하는 기능도 가지고 있다.
22, npasswd - 추측 가능한 패스워드를 검사하는 패스워드 변환 툴로 sun의 nis도 지원한다.
23. passwd+ - 또 다른 패스워드 변환 툴
24. opie(one time password in everything) - s/key를 기반으로 개발된 일회용 패스워드를 구현
25. merlin - 다른 보안툴들(cops, tamu tiger, crack, tripwire, spi등)을 패키지화하여 관리하는 툴
26. lsof - 시스템 내의 모든 열려있는 파일들을 나열하는 툴로 네트워크 연결에 대해 이를 사용하는 프로세스의 추적 등에 유용하게 사용됨
그외의 보안을 위한 다양한 방법들...
필요없는 서버 데몬을 죽인다. 리눅스를 설치할 때 대부분의 데몬이 패키지와 함께 올라간다. 써비스 하지않는 데몬은 확인하여 부팅시 기본적으로 올라가지 않도록 해야 한다.
그럼 첫 번째로 inted 수퍼 서버에 의해 자동 관리되는 녀석을 건드려 보기로 하겠다.
[root@slug /etc]# cat inetd.conf |more
# inetd.conf this file describes the services that will be available
# through the inetd tcp/ip super server. to re-configure
# the running inetd process, edit this file, then send the
# inetd process a sighup signal.
#
# version: @(#)/etc/inetd.conf 3.10 05/27/93
#
# authors: original taken from bsd unix 4.3/tahoe.
# fred n. van kempen, <waltje@uwalt.nl.mugnet.org>
#
# modified for debian linux by ian a. murdock <imurdock@shell.portal.com>
#
# modified for rhs linux by marc ewing <marc@redhat.com>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# echo, discard, daytime, and chargen are used primarily for testing.
#
# to re-read this file after changes, just do a 'killall -hup inetd'
#
#echo stream tcp nowait root internal
# echo, discard, daytime, and chargen are used primarily for testing.
#
# to re-read this file after changes, just do a 'killall -hup inetd'
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal
#
# these are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#
여러분들도 다 아시다시피 ftp,telnet등은 기본적인 서비스이기 때문에 그것을 막기에는 약간 찜찜한 구석이 있다. 그러나 해킹을 당했을 경우에는 추가적인 해킹의 우려를 방지하기 위하여 과감하게 이 두가지의 서비스도 막을수 있다. telnet를 대신하여 ssh를 사용한다거나 ftp,telnet을 독립적인 데몬으로 서비스 하는 방법도 시스템의 안정에는 좋은 방법이라고 생각한다.(물론, 조금 귀찮기는 하지만...)
# shell, login, exec, comsat and talk are bsd protocols.
#
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp nowait root /usr/sbin/tcpd in.comsat
#talk dgram udp nowait nobody /usr/sbin/tcpd in.talkd
#shell stream tcp nowait root /usr/sbin/tcpd in.rshd
#login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp nowait root /usr/sbin/tcpd in.comsat
#talk dgram udp nowait nobody /usr/sbin/tcpd in.talkd
#ntalk dgram udp wait nobody /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp wait nobody /usr/sbin/tcpd in.dtalkd
#
위의 서비스들은 버그와 원격 로그인이라는 보안의 치명적인 약점들을 가지고 있는 서비스 들이다. 물론, talk가 꼭 필요하다면 어쩔수가 없겠지만 그럴 경우 가능하면 웹채팅과 같은 형태의 조금 안전한 방법을 추천하고 싶다.
# pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
#
pop3는 이메일을 사용하기 위해서 필요한 서비스이지만 imap 같은 녀석은 주석 처리를 하기 바란다.최근에 imap를 이용한 해킹 사고가 많이 보고 되고 있기 때문이다.
# the internet uucp service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico
-l
#
# tftp service is provided primarily for booting. most sites
# run this only on machines acting as "boot servers." do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# finger, systat and netstat give out user information which may be
#
# tftp service is provided primarily for booting. most sites
# run this only on machines acting as "boot servers." do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." many sites choose to disable
# some or all of these services to improve security.
#
#finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat
-f inet
#
위의 서비스들은 네트웍 사용의 편의성을 제공하기 위해서 존재하는 서비스들이다. 즉, finger등의 정보는 내부 네트웍 및 그 사용자들의 현황을 외부 세계에 있는 사람들에게 훤히 들어내 보이는 결과를 초래하는 것이다. 그러하게에 가능하면 공개적으로 운영되어지는 서버의 경우에는 이들을 주석처리하는 것이 바람직하다고 생각되어진다.
# authentication
#
auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
#
# end of inetd.conf
linuxconf stream tcp wait root /bin/linuxconf linuxconf --http
#swat stream tcp nowait.400 root /usr/sbin/swat swat
이상으로로 inted.conf의 설정 파일들에 대해서 알아 보았다.
그외에 몇가지 보안과 관련해서 신경을 써야할 파일을 확인해 보겠다.
아래의 파일은 ftp 접속을 제한하는 유저들의 id이다.
[root@slug /etc]# cat ftpusers |more
root
bin
daemon
adm
lp
sync
shutdown
halt
news
uucp
operator
games
nobody
필요없는 유저의 허가는 삼가하기 바란다.
아래의 내용은 루트가 사용 가능한 가상 콘솔 tty1-8번 까지 기본적으로 들어 있는 파일이다. 원격으로 root의 접근은 반드시 불허해야 한다. su를 이용하여 루트로 login하기를 권장한다.
[root@slug /etc]# cat securetty |more
tty1
tty2
tty3
쉐도우 패스워드를 사용하자!!!
왜? 한마디로 보안을 위해서.... 왜 /etc/passwd 파일을 숨겨야 하는가? 일반적으로 password를 포함한 대부분의 사용자 정보는 /etc/passwd에 보관되어 있다. password는 암호화 되어서 encrypted 저장된다. password는 encode된 형식으로 존재한다. 이유는 crypt를 적용할 때 text는 null로 하고 password를 key로 사용하기 때문이다.
password를 encode 하는데 사용하는 연산방식은 기술적으로는 단방향 hash function 과 같은 방법으로 간주되고 있다. 이것은 순방향으로는 계산하기 편하게 되어 있지만 역방향은 연산이 매우 힘들게 되어 있는 구조를 가지고 있다. 무질서하게 encode된 password를 획득해서 원래의 password를 조합하는 것은 사실 어려운 일이다, 그러나 수많은 사람들이 사용하는 서버에서는 한두개의 password는 일상단어로 이루어져 있을 것이다 바로 이런 헛점을 크랙커들은 노리고 있는 것이다.
즉, 흔히 사용하는 password와 단어를 가능한 가능한 4096가지 salt 값을 사용해서 encrypt을 실행할 것이다. 그 다음에 db에 있는 password와 encodeehls password를 비교할 것이다. 그다음은 여러분의 상상에 맡기기로 하겠다.이것을 일반적으로 dictionary attack이라고 한다.
shadow suite는 password를 다른 파일에 위치시킴으로써 이문제에서 자유로울수 있다. 다시 말해서 /etc/shadow 디렉토리에 위치시킴으로서 모든 유저가 파일에 대한 접근을 할 수 없게 만드는 것이다. 오로지 root만이 이화일을 보고 쓸수가 있다. 이를 통하여 dictionary attack을 감행하는 크랙커들로부터 중요한 시스템을 보호할 수 있는 것이다. 이것이 쉐도우 패스워드 사용의 목적이라고 할 수 있다.
내부 사용자들을 주의하라!!!
많은 크랙킹이 외부에서 이루어지는 것으로 오인하는 경우가 종종 있다. 그러나 항상 그러하지는 않다. 내부 사용자에 의한 공격 또한 주의해서 관찰해야 할 대목이다. 그것이 아니더라도 외부에서 내부 사용자의 id를 얻는 것 이야말로 가장 흔한 크래킹의 경우이다. 내부 사용자들에 대한 보안이 느슨해지면 침입자들은 여러 버그들과 시스템의 약점을 이용해서 일반 id를 획득하여 관리자의 id를 획득할 수있다.
그러하기에 항상 관리자는 주의해야 할 것이 퍼미션에 관계된 문제를 소홀히 다루어서는 안된다는 것이다. 일반유저들에게는 최소한의 권한만을 부여하고 사용자의 로그를 잘 분석 해야하며 필요하다면 과감히 계정을 막아야 할 것이다. 즉, 내부 사용자가 다른 사이트를 통하여 텔넷 접속을 해올 경우 허가를 받아서 사용할수 있도록 한다던가 사용자의 퀘터를 제한 둔다던가 하는 나름대로의 룰을 정하여 거기에 위반이 되지 않도록 하는 방식등을 통해서 내부 사용자에 대한 방어를 해야 할 것이다.
log 분석을 게을리 하지 마라.
/var/log 에 lastlog,message 파일의 분석을 정기적으로 분석하기 바란다. 혹시 전혀 알 수 없는 사이트로부터 접속 시도나 login이 이루어 졌다면 반드시 확인 작업을 하기 바란다. 그들은 여러분의 서버에 스크립트 하나를 깔아서 전체 네트웍을 스캔하고 그를 통하여 다른 서버의 접속을 시도할 것이며 그를 통해서 네트웍에 장난을 칠 것이다. 처음보는 파일이나 디렉토리, 특별히 등록이 안되어 있는 유저가 만들어져 있다면 그것은 대부분이 크랙커의 장난일 수가 있다. 그럴때는 일단 알지 못하는 유저의 id는 죽이고 log를 분석하여 랩퍼로 상대 호스트의ip와 도메인을 막아야 할 것이다. 왜냐하면, 하나의 서버가 뚫렸다면 그 다음은 아주 우습게 루트 권한을 획득할 수 있기 때문이다.
그러하기에 시스템 관리자가 아니라도 자신의 서버가 네트웍에 물려 있다면 자신의 서버를 사랑하고 관심을 가져줘야 할 것이다. 이외에도 보안을 얘기하면 한도 끝도 없을 것 같다. 그외의 부분은 세미나 홈이나 게시판에 자료를 올릴 것이다. 그것을 참고하여 보다 효율적으로 보안을 공부하기 바란다.
보안이 전혀 중요하지 않다고 생각하는 리눅서가 혹여라도 있을지 모르겠다. 클라이언트 사용자에게 무슨 보안?
허나, 보안 문제는 시스템 관리자만의 것이 아니다. 여러분의 pc가 네트웍에 연결이 되어 있다면 그것은 바로 해커의 먹이가 될 수 있다는 사실을 명심하기 바란다. 필자가 네트웍 관리자이기에 교내의 리눅스 박스가 부서지고 깨어지는 모습을 많이 보아왔다. 조금만 보안에 신경을 쓰면 됐을 것을 나중에 데이터가 깨지고 시스템이 망가지고 난 다음에 후회하는 모습을 많이 보아왔다 그래서 보안은 전제인 것이다. 바쁘더라도 최소한 랩퍼와 필요없는 데몬들은 죽이고 사용하시기를 간절히 부탁드린다. 그리고 문제가 생기면 관리자에게 꼭꼭 연락하는 습관을 가지기 바란다. 이상으로 조금은 지루한 보안을 얘기 했다.
내게 할당되어진 원고를 넘은지도 벌써 엄청 흘렀다. 늦게 원고를 보낸것도 미안한데 이렇게 민폐까지 끼치다니 정말 미안할 따름이다. 허나, 모두를 위한 일이라는 믿음으로 이해해 주리라 믿는다.'블라베 IT world > Linux Document' 카테고리의 다른 글
| 리눅스보안스터디 노트 (0) | 2013.02.13 |
|---|---|
| linuxconf 란 (0) | 2013.02.13 |
| 레드햇 리눅스 6.0 설치와 활용 (0) | 2013.02.13 |
| 네트웍에 문제가 발생 했을 때 해결할 수 있는 방법 몇가지 (0) | 2013.02.13 |
| Centos day 02 - commands (0) | 2013.02.13 |
