제 3 회 리눅스 공동체 세미나 o 세션

초보 리눅서가 할 수 있는 설치부터 리눅스 보안까지




서강대학교 리눅스 유저 그룹

최승국 <prometheus@slug.sogang.ac.kr>

리눅스의 철학과 리눅서의 자세

네트웍의 전반적인 이해

리눅스 설치와 x 띄우기-몇가지 tip 활용

리눅스에서의 기본적이지만 중요한 보안

기본적인 활용법

linuxconf의 활용

그외에 몇가지 잔기술

초보 리눅서가 할 수 있는 설치부터 리눅스 보안까지 483

------------------------------------------------------------------------------------------------

1. 들어가면서.

리눅스에 대한 나의 느낌들.

리눅스를 처음 손댄게 3년전의 일입니다. 그때는 리눅스가 이렇게 급속히 사람들 속으로 퍼질 것 이란 생각을 할 수 없었던 때였던 것 같습니다. 리누즈 토발즈 자신조차도 리눅스가 이렇게 성장 하리라고는 상상을 못했다고 하니.

허나, 지금은 리눅스의 성장과 발전에 이의를 다는 사람이 없습니다. 그만큼 리눅스가 힘을 갖게 되었다는 것이죠? 한마디로 엄청나게 커가고 있는 녀석이 바로 리눅스인 것입니다. 그러나 아직껏 리눅스가 넘어야 할 산은 너무도 많이 있습니다. 아직까지 리눅스용 어플리케이션이 부족한 실정이며 일반 사용자들이 사용하기에는 어렵다는 것입니다. 그리고 기술지원을 하고 있는 업체가 적다는 것입니다. 또한 시스템 관리자들의 생각이 아직껏 리눅스는 소형 서버 내지는 파일,프린트 서버 정도로만 인식한다는 사실입니다. 대형 네트웍이나 대형 isp에서 쓰는 서버로는 부적합 하다고 하는 선입견들이 바로 그것입니다,

바로 이러한 문제들을 해결하고 극복하는 것이 우리의 과제인 것입니다.

보다 많은 어플리케이션을 개발하고 보다 많은 테스트를 통해서 리눅스가 중대형 서버에서의 안정성을 검증 받을수 있도록 해야 할 것입니다. 또한 보다 많은 이들이 리눅스를 사용할 수 있도록 많은 자체의 노력이 필요할 것입니다. 이를 통해 보다 많은 리눅서를 배출해내야 할 것입니다.

이것이 우리의 존재 이유이자 우리의 사명인 것입니다.

아울러 리눅스는 한낱 기능적인 측면의 os가 아님을 우리들 자신이 먼저 생각해야 할것입니다. gnu 선언문,성당과 시장 등의 얘기들이 남의 이야기가 아닌 우리들 모두의 출발의 전환점이기를 바랍니다. 리눅스는 형이상학적이며 정신이 존재하는 os인 것입니다.

즉 리눅스는 철학입니다.

리눅서라면 리눅스의 정신을 잃지 않기를 바랍니다. 그리고 나눔과 공유의 정신을 항상 잊지 않기를 더불어 바랍니다. 우리의 만남과 모임이 단순한 만남이 아닌 인간의 따뜻함과 더불어 함께 하는 모습으로 거듭나는 관계이기를 바랍니다. 개인의 만족이나 개인의 실력 향상을 위한 우리의 모임이 아니라는 얘기입니다. 이점은 꼭꼭 강조를 하고 싶습니다.

리눅스의 정신에 내포되어진 공유와 나눔, 더불어 함께하는 정신을 말입니다.

이 글을 쓰고 있는 이 시간 리차드 스티븐스 씨가 돌아가셨다는 소식이 들리는군요 유닉스 그리고 네트웍을 하는 분들이면 모를 수가 없는 분 tcp/ip illustrated, apue, unp.,unp의 2판 전체를 완결짓지 못하고 세상을 떠났군요 리차드 스티븐스 씨의 홈페이지는 http://www.kohala.com/~rstevens 입니다.

다시한번 고인의 명복을 빕니다. 부디 아름다운 곳으로 가시기를 간절히 바랍니다.

모든 리눅서 여러분 건강을 지킵시다. 그래야 더 열심히 리눅싱도 할 수가 있잖아요?

자! 이제부터 여러분과 함께 리눅스의 세계로 들어갑시다.

편안한 강의를 위하여 경어를 쓰지 않겠습니다. 널리 이해를 바랍니다.

2. 네트웍의 이해와 활용

world wide web이 등장한 이후 급속히 우리들의 일상 용어가 되어버린 인터넷. 그 인터넷을 사람들은, 오로지 웹이 전부인양 오해하는 경우가 많이 있다. 물론, 인터넷 주류의 세계를 웹이 많은 부분 장악하고 있는 것 또한 사실이다. 하지만 그러함에도 인터넷은 웹의 것이 아니다. 그런 사람들에게 인터넷이 무엇이며 인터넷이 어떠한 방식으로 운영 되어지고 있는가를 질문할 때 과연 몇 사람이나 그 답을 할 수 있을까? 그건 리눅스,유닉스,윈도우,맥, os2 그외의 다른 운영체제를 사용하는 사람들도 정확히 알지를 못하고 있다. 바로 그 질문에 대한 답을 오늘 강의의 첫 테마로 할까 한다..

인터넷이란 무엇인가?

인터넷은 tcp/ip 프로토콜을 기반으로 한 소규모의 네트웍들의 연합체라고 할 수 있다. 즉, 전세계 네트웍의 연합체라고 말할 수 있을 것이다. 이를 네트웍의 관점에서 얘기하자면 ip address를 가지고 있는 모든 네트웍 장비들로 이루어진 ip 네트웍의 연합체라고 말할 수 있다.

그렇다면 인터넷의 근간이라는 tcp/ip는 무엇인가?

tcp/ip를 알기 위해서는 먼저 tcp/ip의 출생 배경부터 알아야 할 것이다.

tcp/ip의 출현 배경

현재, 인터넷을 석권하고 있는 프로토콜이 무엇인가? 라고 물어보면 그가 전문가이던 초보자이던 상관없이 대부분의 사람들은 한결같이 tcp/ip라고 얘기를 할 것이다. 그럼 이러한 tcp/ip는 언제 누구에 의하여 어떤 목적으로 만들어 졌는가?

원래 tcp/ip 프로토콜의 개발은 1969년 arpa(advanced research projects agency) 즉, 미 국방성의 자금 지원으로 시작된 프로젝트에서 그 출발점을 찾는다. arpa(advanced research projects agency)는 실험적인 패킷 교환 방식의 네트워크를 만들어내기 위하여 arpanet이라 불리우는 네트웍을 설치하였다. 바로 이곳으로부터 현재에 쓰이는 수없이 많은 정보기술들이 이후에 개발이 되었다.

arpanet은 처음 계획되었을 때의 우려를 씻고 안정적이며 성공적으로 정보통신 기술들과 조화를 이루게 되었다. 그것이 1975년경의 일이었다. 이를 계기로 실험적이던 arpanet이 실제 운영하고 사용할수 있는 네트웍으로 전환이 이루어 졌으며 그 일은 dca(defense communication agency)에게 넘어갔다. 그후 실질적인 tcp/ip가 개발이 되어졌다. 그런 tcp/ip가 결정적으로 확장을 할수 있었던 계기는 1983년 미국의 군사용 표준 프로토콜로 채택이 되면서 모든 네트웍에 물려있는 장비들의 새로운 프로토콜로의 변환이 필요한바 이를 용이하게 하기 위하여 darpa(-미국방성안의 부서로 그전에는 arpa로 불림)에서 버클리(bsd) 유닉스에서 tcp/ip를 구현하도록 bbn에 자금을 지원하였으며 이를 계기로 네트웍의 대중적인 프로토콜로 발전을 하게 되었다. 그리고 그 즈음에 인터넷이란 새로운 패러다임이 등장하기 시작했다.

인터넷은, tcp/ip의 개방적이며 어떤 호스트에 대해서도 배타적이지 않은 범용성과 안정성이 매력적 이였으며 그리하여 수많은 업체들은 인터넷의 기하급수적인 발전과 발을 맞춰 tcp/ip를 더욱더 연구,개발 및 지원을 하게 되었다. 왜냐하면 인터넷에 접근을 하기 위해서는 tcp/ip가 필요했기 때문이다. 또한, 인터넷의 기하급수적인 발전과 확산은 업계로 하여금 tcp/ip에 매력을 갖게 하기에 충분한 효과가 있었기 때문이다. 이것이 tcp/ip가 인터넷의 핵심 프로토콜이자 보편적인 프로토콜로 자리를 잡을수 있게 되었던 이유인 것이다.

최근에는 tcp/ip가 인터넷은 물론, 소규모의 네트워크(lan)에서도 엄청나게 사용되어지고 있는 실정이다. 그리고. 일반 사용자들의 pc에도 기본 프로토콜로 자리잡은 것이 tcp/ip 이다. 오래전부터 그래왔지만 현재에도 linux나 unix 운영체제를 쓰고 있는 컴퓨터 시스템들로 구성된 네트워크에서 가장 많이 사용되고 있는 것이 tcp/ip이며 이것은 새로운 밀레니엄 시대에도 여전히 변하지 않을 것이라고 생각한다.(그 시기에 대해서는 글쎄.) 인터넷의 주류 프로토콜로서.

이상으로 간단하게 tcp/ip의 출생 배경에 대해서 알아 보았다. 이제부터는 tcp/ip와 그 안에 숨겨져 있는 osi 7 layer에 대해서 간략히 알아 보겠다.

tcp와 ip는?

tcp/ip는 tcp와 ip라는 두 녀석의 조합에 의하여 이루어진 인터넷 프로토콜의 하나 이다. tcp는 transmission control protocol의 약자로서 신뢰성 있는 연결 지향(connection-oriented) 프로토콜과 서비스를 제공한다.

즉, osi 7계층 중 상위 계층에서 데이터 전송 요구 발생시 '3 way handshake'를 이용해 상대 노드와의 사이에 연결을 설정하고, 전송이 끝나면 연결을 절단해 장비들의 cpu,가상 메모리등의 낭비를 막는다. 또한, 현재의 데이터 처리 버퍼 용량을 상대 노드에 알려 적절히 데이터의 흐름을 조절하며, 데이터의 에러 검출과 재전송 요구 등을 행하는 일들을 하는 것이 tcp의 역할이다.

(osi 7 layer 계층도)

application layer네트워크를 이용하는 응용 프로그램들이 위치

host-to-host transport layer송수신측 말단의 에러 조정과 데이터 전송 관련 서비스를 제공

internet layer 데이터 라우팅과 데이터그램을 정의

physical layer물리적 네트웍 접근에 대한 부분을 구성

ip는 internet protocol의 약어로서 전송하려는 packet의 address와 데이터를 전송하려고 하는 목적지 주소에 정확히 도달할 수 있도록 최적의 경로를 설정하는 역할을 한다. 또한, 상위 계층인 transport 계층에 network 상호간의 데이터그램 서비스를 제공하며, 데이터그램을 분해하고 합침으로써 데이터 링크 계층에서의 데이터 길이 제한을 극복해 커다란 데이터그램을 최소화하여 네트워크에서 전송할 수 있게 한다. 이것이 tcp와 ip의 하는 일이다. 그러나 이것만으로는 사실 이해가 쉽지 않다. 하여 약간은 전문적인 지식이 있어야 하나 네트웍의 가장 기본이라고 할 수 있는 것이 osi 7 layer에 대해서 이야기해 보고자 한다.

계층

기능

7 계층

application layer

-네트워크 애플리케이션을 정의

-전자우편 및 네트워크 유틸리티가 존재하는 계층

6 계층

presentation layer

-애플리케이션이 네트워크로 들어가는 방법과 네트워크 상에서 데이타를 전송하기 위해 생산되고 소비 되는 형태를 번역하는 방법 정의

5 계층

session layer

-애플리케이션에 대해 4 계층에 개념적인 인터페이스 제공

-장비들이 네트워크 주소 대신 이름으로 인식되도록 제공

4 계층

transport layer

-네트워크 상에서 물리적인 위치를 찾는 방법과 노드간의 연결을 확립하고 끊는 방법을 정의

-인증과 패킷 배열(packet squencing)

-tcp, udp, spx 패킷이 어느 경로로 전송되는지 정의(routing)

3 계층

network layer

-네트워크 상의 노드에 전송되는 패킷 흐름을 통제하고 상태 메시지가 네트워크상에서 어떻게 노드로 전송되는가를 정의

-ip, ipx, appletalk, decnet, netbeui, sna,appc -media-independent

2 계층

data link layer

-컴퓨터가 메시지를 주고 받기 위한 프로토콜 정의

-물리적인 연결을 통하여 두 장치간의 신뢰성 있는 정보 전송-packet framing, media-level addressing

-ethernet,tokenring,fddi,atm,ppp(wan protocol)

-media-dependent

1 계층

physical layer

-기계적인 측면(케이블 및 접속 장치)과 전기적인 측면(전압, 신호를 변조하는 기술)을 포함한 컴퓨터와 네트워크 사이의 물리적인 연결 정의

-네트워크 토폴러지 정의

(tcp/ip 프로토콜 계층도)

tcp/ip 구조

* application layer : ftp, telnet, smtp

이 계층은 네트워크를 실제로 사용하는 응용 프로그램으로 이루어진다. 우리가 이미 알고 있는 파일 전송 프로그램 등이 이 계층에 해당되는 프로그램이다. osi 모델에서 보면 애플리케이션 계층과 프리젠테이션 계층이 여기에 해당된다.

* host-to-host transport layer

이 계층의 역할은 도착하고자 하는 시스템까지 데이터를 전송하는 것이다. osi 모델에서 보면 세션 계층과 트랜스포트 계층에 해당하는 역할을 한다. tcp/ip 소켓 부분이 osi 모델의 세션 계층에 해당된다. tcp/ip에서는 시스템의 주소(address)와 포트(port)를 가지고 각 프로세스를 연결해서 통신을 한다. osi 모델의 트랜스포트에 해당하는 부분은 tcp/ip 프로토콜에서 tcp 프로토콜에 해당한다. tcp는 패킷에 에러가 없고, 중복됨이 없이 보내어진 순서대로 상대편이 받을 수 있도록 신뢰성 있는 데이터 전송을 보장하는 프로토콜이다. tcp는 신뢰성이 있는 만큼 헤더에 각종 에러 코드에 대응할 수 있는 각종 정보를 가지고 있다.

* internet layer

이 계층의 역할은 데이터그램을 정의하고 데이터그램을 routing하는 일을 담당한다. 말이 조금 어렵긴 하지만, 이 계층의 역할은 아주 간단한 것이다. 즉 데이터를 정확한 곳에 보내기만 하면 되는 것이다. 이 계층에서는 데이터그램이라는 용어를 사용하는데, 데이터그램이라고 하는 것은 ip 프로토콜에서 다루는 패킷 데이터를 말한다.

데이터그램이 가지고 있는 자료는 보낸 주소(source address), 받을 주소(destination address), 그리고 보내는 데이터, 그외 몇가지 조절 필드(control field)를 가지고 있다. 마치 편지를 부칠 때 보내는 주소, 받을 주소, 받을 사람, 편지 내용을 보내는 것과 유사하다.

인터넷 계층에서는 데이터그램이 가지고 있는 주소를 판독하고 네트워크에서 주소에 맞는 네트워크를 찾아가서 해당되는 호스트가 데이터그램을 받을 수 있도록 데이터그램을 전송한다. osi 모델에서 보면 네트워크 계층과 데이터 링크 계층에 해당한다.

* physical layer

물리적 계층에 대하여 tcp/ip 프로토콜에 따로 정의한 내용은 없다. 단지 ieee가 정해놓은 기존의 하드웨어 표준을 따르고 있다. 보통은 데이터 통신에서 이용되는 (ethernet)을 이용한다. tcp/ip는 유닉스를 비롯해서 윈도우 95, 윈도우 nt에서 기본적으로 제공되며, 가장 널리 쓰이는 프로토콜이고, 그만큼 다양한 서비스를 가지고 있는 프로토콜이기도 하다. 다양한 서비스를 제공하기 위해 버클리 소켓, 윈도우 소켓 등 tcp/ip에 관한 많은 api를 원한다.

실제로는 반드시 tcp/ip 프로토콜을 사용하는 것은 아니다. tcp 대신 udp를 사용할 수도 있으니까. 그런데 왜 그렇게 부르는 것일까? 특별한 이유는 없다. 단지 tcp와 ip를 대표적으로 많이 사용하기 때문에 보통 tcp/ip라 부를 뿐이다.

tcp/ip 주소 체계

tcp/ip 프로토콜로 네트워크가 구축되어 있다면 각 컴퓨터는 자신을 나타내는 주소를 가지고 있어야 한다. 각 컴퓨터에 주소는 하나만 있어야 하고 이러한 컴퓨터들이 연결되어 네트워크가 구성되고 점점 확장되어서 전세계의 수 천개의 다른 네트워크를 연결하는 인터넷이 구성되어진 것이다.

위에서 설명했듯이 tcp/ip에서 ip의 역할은 데이터를 전송하는 것이다. 데이터를 전송시키려면 무엇이 필요할까? 먼저 생각할 수 있는 것이 도착해야 할 시스템의 주소이다. 도착할 시스템 주소가 유일한 것이 아니라면 정말 말도 안되는 일이 벌어질 것이다. 각 컴퓨터의 ip 주소는 전체 네트워크를 통해서 유일해야만 하기 때문에, 주소는 중복될 수 없는 32비트 숫자로 나타내고 있다. ip 주소가 가지고 있는 정보는 네트워크를 나타낼 수 있는 네트워크 정보와 그 네트워크 내에서 특정 컴퓨터를 가리킬 수 있도록 호스트 정보를 나누어 사용할 수 있게 구성되어 있다.

* 네트워크 클래스

class

network id

host id(사용유저수)

a class

126

16,777,214

b class

16,382

65,534

c class

2,097,150

254

ip 주소를 이용할 경우에는 주소가 가르키는 시스템 뿐만 아니라 그 컴퓨터가 속해 있는 네트워크도 전체 네트워크 상에서 유일하게 표현되어야 한다. ip 주소는 3가지, 즉 네트워크를 나타내는 부분과 호스트를 나타내는 부분 그리고 클래스 분류 정보의 세가지로 나누어 질 수 있다. 세계에 퍼져있는 네트워크는 많은 하위 네트워크로 구성되어 있다. 이런 것을 서브네트워크(subnetwork)라 하는데, 각 서브네트워크에는 적게는 하나 아니면 아주 많은 수의 호스트를 가지고 있을 수도 있다.

네트워크마다 컴퓨터 시스템의 개수가 다르기 때문에 이를 효과적으로 이용하기 위해서 네트워크 id와 호스트 id를 구분하는 위치를 바꾸어 가면서 인식하는 방법을 사용하게 된다. 그래서 클래스라는 개념이 생겨나게 되었다. 네트워크 id와 호스트 id는 상대적인 값이다. 네트워크 id가 커지는 만큼 지정할 수 있는 호스트의 개수는 줄어들지만 전체적으로 많은 네트워크 id를 부여할 수 있는 것이다. 반대로 네트워크 id가 작아지면 굉장히 많은 호스트를 가질 수 있게 된다.

이런 기준으로 ip 주소는 클래스로 분류되어 있고 그 기준은 몇 비트나 네트워크 id에 할당하느냐 또는 호스트 id에 할당하느냐에 따라 나누어진다. ip 주소는 5개의 클래스로 나누어지고 일반적인 목적으로 사용하는 것은 클래스 a, b, c이며 클래스 d, e는 다른 용도로 사용할 목적으로 남겨두고 있는 것이다. 각 클래스의 구분은 ip 주소의 처음 몇 비트만 검사해 보면 알 수 있다.

class

상위 4 비트

네트워크 id의 범위

호스트 id의 범위


0

1

2

3

최소값

최대값

최소값

최대값

a

0

-

-

-

0.0.0.0

127.0.0.0

0.0.0

255.255.255

b

1

0

-

-

128.0.0.0

191.255.0.0

0.0

255.255

c

1

1

0

-

192.0.0.0

223.255.255.0

0

255

d

1

1

1

0

224.0.0.0

239.255.255.255

미사용

미사용

e

1

1

1

1

240.0.0.0

255.255.255.255

미사용

미사용

이렇게 ip 주소를 다양하게 정하는 것이 좋지만 사용할 때는 어떻게 이용하는지 의문이 생길 것이다. 누구도 이런 형태의 주소를 하나하나 기억할 수 있는 사람은 없을 뿐만 아니라 그럴 필요도 없다. 실제로 ip 주소는 이런 복잡한 비트로 나타내는 것이 아니고 가운데 점을 기준으로 4개의 십진수로 나타낸다. 여기서 말하는 십진수는 0~255까지의 범위를 갖는 숫자, 즉, 1바이트 값을 말한다. 각 십진수 값은 ip 주소에서 8비트를 나타내고, 이런 8비트 숫자 4개의 값을 모아서 32비트의 ip 주소를 만들어 내는 것이다.

* ip 주소와 이름

사람이 ip 주소 한 두 개를 기억할 수 있을지는 모르지만 그 이상은 힘들다. 이렇게 단지 십진수로만 이루어진 주소 체계는 사람이 기억하거나 한 번 보고 바로 받아들이기 힘든 부분이다. 그래서 이러한 숫자로 ip 주소와 의미있는 문자열을 연결시키는 방법을 찾게 되었다. 네트워크가 연결되어 있는 컴퓨터에는 호스트 파일을 가지고 있다. 이 파일은 단순한 텍스트 파일로 구성되어 있고 호스트 파일의 각 라인을 보면 왼편에는 점을 기준으로 십진수로 표시된 ip 주소가 있고 오른편에는 문자열 이름이 있다. 이 파일 이름은 보통 hosts로 되어 있다. 이러한 구조는 몇 대 안되는 시스템으로 이루어진 네트워크에서는 좋을지 모르지만 많은 호스트를 가지고 있을 경우에는 이 모든 것을 하나의 파일로 다룬다는 것은 무모한 일이다. 이러한 상황에서는 네임 서버(name server)를 이용하게 된다. 네임 서버는 호스트 이름과 ip 주소에 관한 데이터베이스를 가지고 있으면서 원하는 정보를 찾아주는 시스템이라 할 수 있다. 우리가 어떤 호스트 이름을 주고 ip 주소를 얻기를 원한다면 네임서버가 받아서 데이터베이스를 찾아보게 된다. 우리가 이러한 부분을 다 알아서 처리해야 하는 것은 아니다. 뒤에서 소개할 윈속 변환 함수에서 다 처리해 준다.

* 트랜스포트 계층(transport layer)

ip가 데이터그램을 얻은 후 주소를 얻어내고 컴퓨터와 컴퓨터 사이를 이동하는 역할을 한다면 트랜스포트 계층은 데이터가 도착해야 할 컴퓨터로 데이터를 실제로 전송하는 역할을 한다. 이 계층에는 tcp, udp라는 2개의 프로토콜을 가지고 있다. 이 2개의 프로토콜의 차이는 udp는 비연결형(connectionless)으로 데이터그램을 전송하고 tcp는 연결형(connect-oriented)을 지원하면서 스트림 형태의 데이터를 에러없이 전송하도록 지원한다.

tcp는 데이터를 중복과 에러없이 순서대로 보내도록 해주지만 이러한 특성 때문에 몇 가지 헤더가 더 필요하고 시스템 간의 연결을 계속 유지해야 하는 부담을 가지고 있다.

udp는 네트워크에서 최소의 부담으로 데이터를 전송하는데 이용된다. 대신 tcp가 가지고 있는 모든 신뢰성이 무너진다. 즉 패킷이 전송되지 않거나 패킷이 중복되서 전송될 수도 있기 때문에 안정성이 떨어지는 단점이 있다.

* 인터넷 계층(internet layer)

데이터그램을 정의하고 이 데이터들의 routing를 담당한다. ip는 tcp/ip에서 중요한 프로토콜이다. ip는 다른 tcp/ip 프로토콜도 사용하고 데이터의 흐름을 관리하는 역할을 한다.

ip는 비연결형(connectionless) 프로토콜이어서 데이터 전송에 신뢰도가 없다. 그래서 tcp라는 다른 계층에 데이터의 신뢰도를 의존하게 된다. ip에서 다루고 있는 것은 데이터그램이고 이미 말했듯이 데이터그램은 보낼 주소, 받을 주소, 데이터 및 기타 필드를 가지고 있다. 네트워크를 돌아 다니는 데이터는 데이터그램 수준에서 이루어진다. 데이터는 때로 분할(fragmentation)과 조합(resemble) 과정을 거치기도 하는데 이 역할 역시 ip가 해주어야 하는 일이다.

arp(address resolution protocol)는 네트워크 하드웨어가 ip 주소를 이해하지 못하기 때문에 생긴 프로토콜로 arp는 논리적인 ip 주소를 물리적인 주소(mac address; media access control address)와 맞추기 위한 프로토콜이다. ip 주소를 브로드캐스팅 메시지(broadcasting message)로 보내면 해당 ip 주소를 가지고 있는 컴퓨터는 물리적인 하드웨어 주소를 리턴하게 된다. 해당되지 않은 컴퓨터가 이 메시지를 받았을 경우에는 모두 무시하게 된다.

이러한 작업은 모두 로컬 네트워크에서만 이루어진다. 거꾸로 찾아가는 프로토콜인 rarp(reverse address resolution protocol)도 있다.

* icmp(internet control message protocol)

tcp/ip에서 데이터의 흐름 조절, 에러 보고, routing 등 기타 다른 정보를 구하는 기능을 하는데 사용한다. 이러한 icmp를 사용하는 프로그램 중 대표적인 것이 icmp의 에코를 보내고 반응이 오는지 안 오는지를 이용해서 상대편 시스템이 사용 가능한지 알아내는 ping 프로그램이다.

* tcp/ip 응용 계층(application layer)

tcp/ip 프로토콜이라는 말의 의미는 ip를 비롯해서 tcp와 이들을 사용해서 서비스를 제공하는 응용 계층의 프로토콜을 포함하고 있다. tcp/ip의 응용에 해당하는 프로토콜에는 telnet, ftp, smtp, tftp, http 등이 있다. 응용 프로토콜 중에서 일반 사용자가 가장 많이 사용하는 것이 telnet, ftp, smtp 일 것이다.

telnet 프로토콜(telnet 명령으로 실행)은 통신망에서 서로 다른 기종의 컴퓨터에 접속하고 이용할 수 있도록 해주는 프로토콜이다. ftp 프로토콜(ftp 명령으로 실행)은 통신망에서 연결된 다른 컴퓨터에서 파일을 읽고 쓰는 등 파일 전송에 관한 프로토콜이다. smtp(mail 명령으로 실행)는 통신망에서 다른 사용자와 전자 우편을 주고 받는데 사용되는 프로토콜이다. http는 네트웍을 통하여 웹 페이지를 전달하는 프로토콜이다. 이외에도 telnet과 비슷한 역할을 하지만 유닉스 기종 간에 사용하는 rlogin도 있다.

이런 프로토콜을 지원하려면, 서버 컴퓨터에서도 이런 프로토콜을 서버로 대치하는 프로그램이 있어야하는데, 보통 데몬(daemon)이라고 한다. 이 프로그램 뒤에는 d를 덧붙여서 telnetd, ftpd라는 이름을 갖는다.

서비스 이름

포트 번호

프로토콜

별칭

echo

7

tcp


echo

7

udp


discard

9

tcp

sinknull

discard

9

udp

sinknull

systat

11

tcp


systat

11

tcp

users

daytime

13

tcp


daytime

13

udp


netstat

15

tcp


qotd

17

tcp

quote

qotd

17

udp

quote

chargen

19

tcp

ttytst source

chargen

19

udp

ttytst source

ftp-data

20

tcp


ftp

21

tcp


telnet

23

tcp


smtp

25

tcp

mail

이처럼 하나의 서비스를 제공하기 위해서 클라이언트를 기다리고 있는 서버 프로그램 즉, 데몬이 필요하다. 이러한 관계를 클라이언트/서버라고 한다.

* tcp/ip 프로토콜의 이용

tcp/ip 프로토콜을 가장 잘 이용하고 있는 곳이 인터넷이다. 위에서 인터넷의 개념은 여러 가지 의미로 사용되고 있는데, 앞에서 언급했던 바와 같이 tcp/ip를 이용해서 연결되어진 네트워크의 연합체라고 표현하는 것이 맞다. 우리는 인터넷상에서 넷스케이프라든지, ftp를 이용해서 여러 곳을 돌아다니면서 다양한 정보를 얻어오고 있다. 자연스럽게 tcp/ip를 이용하고 있는 것이다. 조금은 다른 이야기가 될지도 모르겠지만 인터넷에 접속하는 방법을 잠깐 살펴보자. 대학이나 연구소, 회사의 경우에는 atm,fddi ,fast ethernet,ethernet등의 다양한 근거리망(lan)을 자체적으로 미리 구축하고 직접 인터넷에 연결하여 사용하는 것이 보통이다. 자기 pc에서 tcp/ip를 구축하고 있으면 ppp를 이용하여 telnet, ftp와 같은 응용 프로그램을 이용해서 외부로 나갈 수 있으며 넷스케이프를 통해서 다른 나라의 웹 사이트를 찾을 수 있게 된다. 만약 집에서 전화선과 같은 시리얼 라인을 이용해서 인터넷에 연결하려면 slip(serial line internet protocol)을 이용하거나 ppp(point-to-point protocol)를 이용해야 한다. 이들은 시리얼 통신에서 tcp/ip를 사용할 수 있도록 만들어진 프로토콜이다. 이렇게 되면, 인터넷에 연결이 가능한 호스트와 연결된 모뎀, ppp만 있으면 집에서도 컴퓨터를 이용해서 인터넷의 세계로 직접 연결이 가능하다.

* 포트 번호(port number)

인터넷에서 두 개의 서로 다른 호스트 사이를 구분할 수 있도록 해 준 것은 각 호스트가 가지고 있는 인터넷 주소이다. 이렇게 원하는 주소로 잘 도착한 데이터가 호스트 내에서 가야할 곳을 정하는 것이 바로 포트 번호이다. 이것은 바로 호스트 내에서 다중 프로세스에 대한 처리이다. 포트 번호를 사용하는 곳은 트랜스포트 계층의 tcp 및 udp이다. tcp와 udp는 포트 번호를 이용해서 전송된 데이터를 해당 프로세스에 정확히 넘겨준다. 하나의 프로세스는 여러 개의 포트 번호를 동시에 사용할 수 있고 때로는 공유하기도 한다. 포트 번호 필드의 길이는 2바이트로 표현되며, 65536까지의 포트 번호를 가지고 있고 같은 포트 번호를 가지고 있더라도 다른 역할을 한다. 잘 알려진 포트 번호는 위와 같다. 우리가 서버를 운영할 때 얘기하는 port라는 것은 이렇듯 osi 7 layer가 그 근간을 이루고 있다는 사실을 알아야 할 것이다. 이렇듯 osi 7 layer는 네트웍의 기본이자 인터넷의 기본이며 서버 운영에 필요한 각종 demon들의 전제가 되는 요소이다. 이상으로 간단하게 osi 7 layer 와 tcp/ip의 구조에 대해서 간단하게 알아 보았다.

네트웍의 형태

lan에 대하여

lan은 local area network의 약어로써 일반적으로 소규모의 네트웍을 지칭할 때 사용하는 용어이다. 랜의 출현은 tcp/ip의 출현과 마찬가지로 그 역사가 있다. 1960,70년대의 컴퓨터 환경은 대용량의 일괄처리 방식이 압도하는 batch processing,time sharing(대화식처리)이 주류를 이루었다. 즉, 대형 컴퓨터가 중심이 되는 컴퓨터 환경이었다. 그러던 것이 70년대 후반 들어서 급속히 보급되기 시작한 저가의 미니 컴퓨터의 등장으로 인하여 기존의 호스트 중심의 연구환경이 보다 다양해지고 사용분야 또한 점차로 늘어나게 되었다. 즉, 클라이언트 환경으로 그 중심이 서서히 이동하기 시작했다.

1980년 이후 이러한 미니급 컴퓨터의 영역은 사회 전 분야에 걸쳐서 확대되기 시작했다. 일반 기업뿐만 아니라 관공서,군,교육기관,일반 사용자들에게 그 범위가 확장되었던 것이다. 이것은 개인용 컴퓨터 환경의 사용자들에게 또다른 요구 사항을 만들어내게 되었다. 그것은 바로 공통의 db에 접근하여 서로의 정보를 공유하고 나눌수 있기를 바로는 요구였다. 이것이 바로 랜의 출현 배경이다. 1982년 ieee에 의해 추진된 lan 표준화 안에 의하여 각 회사마다 제각각이었던 랜 제품들은 호환성을 가지게 되었고 이로부터 랜은 급속히 발전을 하게 되었다.

lan의 종류에 의한 분류

1) 망에 의한 분류

ethernet and ieee 802.3 -

ethernet 과 ieee 802.3은 거의 동일한 lan protocol로 ethernet이라고 부른다. ethernet은 사무실에서 가장 많이 쓰이고 있는 lan protocol로 데이타전송속도는 10mbps 까지 지원된다. 이러한 ethernet은 3가지 형태의 케이블방식이 있으며, 다음과 같다.

o 10base2 (thin ethernet) - lan의 길이가 185 meter 까지 될 수 있다.

- 시스템 접속시 bnc port를 주로 이용한다.

o 10base5 (thick ethernet) - lan의 길이가 500 meter까지 될 수 있다.

- 시스템 접속시 aui port를 주로 이용한다.

o 10baset

- 시스템 접속시 rj45 port를 주로 이용한다. hub라는 장비에 10baset pair cable로 접속하여 이용하는데 이 10baset pair cable의 길이는 100meter 까지 지원된다

.


요즘 10base2와 10base5는 잘 쓰지 않는다. 이유는 시스템을 접속하고자 할때마다 transceiver라는 장비를 케이블에 구멍을 뚫어 꽂고 그곳에 aui cable로 연결해야 하는 불편함과, transceiver와 transceiver사이가 3meter 이상(???)이 유지되어야 하므로 짧은 cable안에 많은 시스템을 접속할 수 없기 때문이다. 그러나 10baset cable은 hub라는 장비에 꽂아 쓰기만 하면 되므로 매우 편리하다. hub는 lan의 주요 구성장비로 10base2 cable나 10base5 cable 역할을 대신하는 것으로 hub 여러개를 매달아 하나의 hub 처럼 이용할 수도 있다. 아래 그림은 위의 thin, thick cable을 없애고 hub만으로 시스템을 연결한 예를 보여준다.

ethernet에 접속되어 있는 시스템들은 데이타를 보내고자 할때, 우선 다른 시스템이 ethernet을 통해 frame을 보내고 있는지 확인하며, 어느 시스템도 frame을 보내고 있지 않으면, 자신의 frame을 보내는 방식을 취한다. 그런데 동시에 두 시스템이 frame을 보내게 되는 경우가 발생할 수 있다. 이 경우 frame이 ethernet 에서 충돌하게 되며, frame을 보낸 시스템은 충돌을 감지하고 jam (충돌) 신호를 모든 시스템에게 전달한다. 그러면 모든 시스템들은 잠시 기다렸다가, 각각 임의의 시간뒤에 다시 frame을 보내려는 시도를 하기 시작한다. 이러한 전송방식을 csma/cd (carrier sense multiple access with collision detection) 방식이라고 한다.

ethernet 은 조그만 사무실 혹은 시스템들이 적거나, 데이타 송수신이 적은 경우에는 frame간의 충돌이 많이 발생하지 않아 데이타를 빠른 시간안에 송수신할 수 있다. 그러나 시스템들 사이에 데이타의 송수신이 많을 경우에는 많은 충돌이 발생하게 되고, 따라서 frame을 다시 보내려는 신호가 빈번하게 되어 전송효율이 많이 저하되는 단점이 있다.

token-ring and ieee 802.5

token ring은 ibm에서 발표한 lan protocol로 ieee 802.5와 거의 동일하며, 일반적으로 token ring이라고 하면, ibm의 token ring과 ieee 802.5를 함께 말하는 것이다.

token ring에 있는 시스템들은 token 1개를 차례로 전달해 가며, frame을 송신하려고 하면, token을 가지고 있는채 frame을 송수한다. 그리고 frame 송신을 마친뒤 token을 다음 시스템으로 전달한다. 따라서 token을 가진 시스템만이 frame을 송신하므로 결코 frame 송신시 충돌이 일어나지 않는 장점이 있으며, token이 언제 자신의 시스템에 전달되는지 파악할 수 있으므로 frame의 전송에 걸리는 시간을 예측할 수 있다.

token ring은 16mbps 까지의 전송속도를 제공한다.

fddi (fiber distributed data interface)

fddi는 ansi (american national standards institute)에서 1987년 발표한 것으로 광케이블로 이루어진 2개의 token ring으로 이루어진 lan protocol (dual token ring protocol)이다. 지원되는 속도는 100mbps이다. (ethernet 및 token-ring은 동축케이블을 매체로 한다) 현재 ansi는 동축케이블을 이용해 100mbps를 지원하는 dual token ring protocol을 개발중에 있다고 한다. fddi는 dual token ring 이므로 1개의 ring이 끊어질 경우 끊어진 곳 옆의 시스템들이 내부에서 링을 형성하여 전체적으로 하나의 링이 되도록 만든다. 따라서 장애 발생시 유리한 점이 있어서 90년대 초반이후에 급속히 퍼졌으나 최근에는 atm과 fast ethernet에 밀려서 서서히 그 시장성이 줄어들고 있는 실정이다.

giga bit ethernet

현재의 이더넷 네트웍은 10mbps 또는 100mbps에서 사용할 수 있다. 기가비트 네트워킹은 대역푹에서 10배까지 증대시키며 1000mbps의 속도를 낼 수 있다. 기존의 fast ethernet과는 100% 호환성을 가지며, 쉽게 기가비트 네트웍 아키텍쳐로 업그레이드 할 수있다. 이새로운 아키텍쳐는 csma/cs 프로토콜을 지원하며 광섬유,동축케이블 utp에서도 이용 가능하다.

atm(asynchronous transfer mode)

atm은 광대역 isdn에 대한 통신 표준으로 제안 되었다. atm은 lan과 wan 네트웍에서 모두 사용되는 매우 높은 성능을 가진 솔류션이다. atm은 광섬유(수신용으로 한 라인 송신용우로 한 라인)를 사용하며, 컴퓨터를 서로 접속하는 데에 특별한 고속의 스위치를 이용한다. atm은 또한 음성,데이타,영상을 하나의 네트웍에서 동시에 전송할수 있도록 해준다.

wan

lan protocol은 고속의 전송속도를 제공하는 broadcasting 방식의 전송 protocol이나, wan protocol은 상대적으로 lan보다는 저속의 전송속도를 제공하며 두 지점을 잇는 protocol이다. wan protocol로는 sdlc, hdlc, lapb, frame relay, atm, ppp 등이 있다. sdlc, lapb 등은 56kbps 정도의 전송속도를 제공하고, frame relay 는 수십 mbps, atm은 수 gbps 까지 지원한다.

현재 인터넷에서 라우터와 라우터를 전용회선으로 연결할때 가장 많이 이용되고 있는 protocol은 ppp로, ppp는 ietf에 의해 발표되었다. frame relay 및 atm은 백본의 효율적인 이용과, 장거리 구간 연결시 비용을 절감하고자 할 경우 ppp대신 많이 쓰인다.

다음의 그림은 인터넷이 어떠한 형식으로 움직이는가를 나타내주는 그림이다.

아래의 그림은 인터넷이 어떠한 라우팅 테이블 구조를 가지고 움직이는지를 표현한 그림



wan 교환방식

lan + wan

isdn의 접속방법

네트웍 장비의 종류


이외에도 네트웍의 형태에 따른 분류등이 있으나 지면 관계상 네트웍의 형태는 여기에서 줄이도록 하겠다. 이상으로 간략하게나마 네트웍의 기본적인 내용을 다루었다. 다음은 네트웍을 관리하는 관리자의 입장에서 가장 효율적으로 네트웍을 관리할 수 있는 방법을 알아보도록 하겠다.

국제표준화기구(iso: international organization for standar dization)에서는 네트웍 관리에 대한 기본적인 다섯가지의 정의를 하고 있다.

(1) 네트워크 구성관리 - 네트워크 구성의 현상태를 감시하거나 보수 유지하는 기능.

(2) 네트워크 장애관리 - 네트워크에서 발생한 장애 등의 이상상태를 발견해서 장애가 발생한 장소와 발생하지 않은 장소를 분별하는 기능.

(3) 네트워크 보안관리 - 사용자 권한 설정 등의 접근 관리나 접근 권한을 관리 하는 기능.

(4) 성능관리 - 네트워크 기기의 용량이나 부하를 감시해서 성능을 일정 수준 으로 관리하는 기능.

(5) 계정관리 - 네트워크 사용자의 자원이용 상황에 관한 정보를 수집해서 네트워크 사용자의 사용료를 부과하는 기능. 이렇게 다섯가지를 기본 사항으로 정의를 하고 있다.

이를 실제적으로 네트웍을 관리하는 입장에서 생각해 본다면

1. 과학적인 시스템의 관리가 필요하다

2. 네트웍의 장애를 재빨리 파악할 수 있는 다양한 툴의 확보가 필요하다

패킷 스니퍼 s/w,nms tool....

3. 전문적인 네트웍 관리자의 양성이 필요하다.

4. 정기적인 네트웍의 보안 및 패킷의 흐름을 분석하여 데이터 베이스화 한다.

5. 최소한 1대 이상의 백업 장비를 가지고 있어야 한다.

6. 백업이 최고,최후의 무기임을 명심해야 한다.

7. 버그 관련 사항이 발생하면 빠른 시간안에 패치를 시켜야 한다.

8. 정기적으로 보안 관련 사이트의 내용들을 확인하는 것을 게을리 하지 말아야 한다.

이외에도 기술하지는 못했지만 관리자로서 챙겨야 할 사항은 너무나 많이 있다. 필자 또한 네트웍 관리자 이면서도 사실 위의 내용들을 항상 그리고 잘 챙기지 못하고 있는 실정이다. 허나 경험적으로 느끼는 것인데 그럴 때 네트웍에는 문제가 발생하는 것을 느낄 수 있었다. 네트웍도 관심과 애정이 많이 필요하다는 것이다. 네트워크 감시에 대한 내용과 네트워크 관리 프로토콜에 대해 살펴보겠다.

네트워크 결함 발견하기

사실 잘 쓰던 네트워크가 갑자기 다운되었을 때 그 원인을 판단하는 것은 그다지 어려운 일이 아니다. 네트워크가 완전히 다운된 경우는 다음의 몇 가지 원인을 파악해 보면 그 이유를 알 수 있다.

(1) 게이트웨이 혹은 라우터 시스템이 다운된 경우

일반적으로 이럴경우에는 라우터의 하드웨어적인 문제를 먼저 확인해 보아야 할 것이다. 그리고 라인과 프로토콜이 정상적으로 운영이 되어지고 있는지 확인해야 할 것이다. 종종 코넷과 연결되어진 전화국 사이에서 라인 down이 발생하는 경우가 있다. 그것이 아니라면 코넷에서 다른 작업을 하고 있는지 확인을 해야 한다. 이도 아니라면 라우팅 정보에 문제가 있는지 확인을 해보아야 할 것이다. 또는 csu,dsu를 체크해 보아야 할 것이다.

(2) 도메인네임 시스템(dns)이 다운된 경우

대부분의 유저들도 많이 들어서 알고 있겠지만 네임서버가 다운이 되는 경우에 ip나 또다른 네임서버를 통하여 접속이 가능하지만 내부 네트웍의 속도 자체가 너무 느려서 사실 사용한다는 것이 만만치 않다, 라우팅 테이블이 꼬이는 경우에도 종종 이런 경우가 있는데 그럴때는 네임 데몬을 떨어뜨렸다 다시 올리는 것이 바람직하다.

(3) lan 선이 어디선가 끊긴 경우

최근에는 네트웍의 최종 말단에 있는 하드웨어들의 질 자체가 그렇게 나쁘지는 않다. 그만큼 널리 그리고 광범위하게 사용이 되어지고 있기 때문에 크게 문제가 되지는 않다는 것이다. 허나 아직까지 이더넷을 쓰고 있는 경우에는 이더넷에 물려 있는 tr과 동축케이블 그리고 그 길이의 제한을 염두해 두어야 할 것이다. 랜선의 문제는 대부분이 노화와 물리적인 충격에 의하여 발생하는 경우가 대부분이다. 또, 사용자의 부주의 랜선이 살짝 꼽혀 있는데 네트웍이 안된다고 하는 경우가 있기 때문이다. 그외에는 랜카드의 에러나 문제가 그 원인이 될 수 도 있다.

네트웍에 문제가 발생 했을 때 해결할 수 있는 방법 몇가지

1. ping 명령으로 연결 확인

ping 명령은 한마디로 얘기해서 상대 호스트의 up,down 상태를 확인하는 명령어이다. 아주 간단한 명령이지만 어떤 호스트의 다운여부나 네트워크 불능여부를 파악하는 데는 이 보다 좋은 명령어가 없을 것이다. ping은 실질적으로 icmp의 echo request 기능을 이용하는 것이다. 그러나 ping은 단지 네트웍상에서 상대 호스트가 살았는지 죽었는지만을 확인하는 명령어 이기에 이것 만으로는 네트웍의 문제점을 찾아 내기란 어려운게 사실이다. 이런 경우는 dns 혹은 nfs 등의 서비스를 테스트해서 부수적인 정보를 더 얻을 필요가 있다.

[root@slug /root]# ping ccs

ping ccs.sogang.ac.kr (163.239.1.1): 56 data bytes

64 bytes from 163.239.1.1: icmp_seq=0 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=1 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=2 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=3 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=4 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=5 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=6 ttl=255 time=0.9 ms

64 bytes from 163.239.1.1: icmp_seq=7 ttl=255 time=0.9 ms

2. traceroute 명령의 사용

ping이 상대 호스트의 up,down 상태를 점검하는 것이라면 traceroute는 보다 구체적으로 패킷의 경로를 추적해 주는 똑똑한 녀석이다. 즉, 외부망으로의 접속이 차단되거나 라우터 단에서 문제가 발생했을 때에는 라우팅 경로를 확인하면서 어느 호스트에서 패킷이 차단되는지를 점검해야 할 것이다.바로 이러한 기능을 해주는 도구가 traceroute 인 것이다. 다음의 예는 정상적으로 네트워크가 동작하는 경우의 결과를 보인 것이다. 목적지까지 패킷이 제대로 전달됨을 볼 수 있다. 참고로 도메인 이름이 아닌 ip주소로 나타난 호스트는 dns에 등록이 되지 않았다는 의미이다.

[/slug]# traceroute www.kornet.nm.kr

traceroute to www.kornet.nm.kr (168.126.63.18), 30 hops max, 40 byte packets

1 sogang-fddi-1 (163.239.1.10) 1.044 ms 2.671 ms 1.072 ms

2 168.126.59.77 (168.126.59.77) 8.609 ms 3.248 ms 168.126.47.193 (168.126.47

.193) 3.202 ms

3 168.126.16.121 (168.126.16.121) 5.645 ms 5.053 ms 6.427 ms

4 www.kornet.nm.kr (168.126.63.18) 5.489 ms 12.361 ms 4.291 ms

이제 다음의 예를 보자. 3번째 호스트 혹은 라우터에 ‘!n’이 표시된 것을 볼 수 있을 것이다. 이는 ‘network unreachable’을 의미하는 것으로 pado-inha.kreonet.re.kr 호스트의 라우팅 테이블에 문제가 있어 패킷을 전달시키지 못하는 것을 말한다.

[/slug]# traceroute www.lg.co.kr

traceroute to www.lg.co.kr (165.243.5.37), 30 hops max,

40 byte packets

1 165.246.10.250 (165.246.10.250) 1 ms 1 ms 1 ms

2 165.246.15.1 (165.246.15.1) 2 ms 1 ms 1 ms

3 pado-inha.kreonet.re.kr (134.75.181.1) !n !n !n

다음의 예는 그리 흔한 예는 아니지만 멀티플렉싱 라우터의 예이다. 즉 아래의 호스트중에 5번의 taejon-seoul-t3.kreonet.re.kr 호스트는 kfddi3.kreonet.re.kr과 mix-serial4-1.sanfrancisco.mci.net 두군데로 패킷을 동시에 전송하는 것이다.

일반적인 경우.

[root@slug /root]# traceroute www.oracle.com

traceroute to v-www.us.oracle.com (205.227.44.16), 30 hops max, 40 byte packets

1 sogang-fddi-1 (163.239.1.10) 2.202 ms 1.554 ms 0.930 ms

2 168.126.47.193 (168.126.47.193) 4.945 ms 168.126.59.77 (168.126.59.77) 3.4

64 ms 168.126.47.193 (168.126.47.193) 21.727 ms

3 apgateway3-noc.kornet21.net (168.126.16.75) 16.272 ms 13.969 ms 3.701 ms

4 210.183.28.65 (210.183.28.65) 4.045 ms 3.569 ms 10.228 ms

5 203.234.255.210 (203.234.255.210) 198.941 ms 193.242 ms 199.559 ms

6 main3-249-192.sjc.above.net (209.249.192.4) 197.496 ms 200.980 ms 195.862

ms

7 core1-main3.sjc.above.net (209.249.0.53) 202.879 ms 192.557 ms 193.170 ms

8 mae-west-core1-oc12.sjc.above.net (207.126.96.246) 192.456 ms 194.697 ms

195.558 ms

9 mae-west-core1-oc3-2.maew.above.net (209.133.31.182) 195.194 ms 200.176 ms

194.591 ms

10 s2-1-0.sanjose1-cr2.bbnplanet.net (4.0.85.6) 270.570 ms 266.020 ms 240.87

8 ms

11 p2-1.sanjose1-nbr2.bbnplanet.net (4.0.3.197) 228.333 ms 235.643 ms 237.29

7 ms

12 p1-0.sanjose1-nbr1.bbnplanet.net (4.0.5.85) 242.226 ms 262.068 ms 243.828

ms

13 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) 239.771 ms 231.898 ms 242.323

ms

14 p9-0-0.paloalto-br1.bbnplanet.net (4.0.1.221) 233.567 ms 242.865 ms 236.5

04 ms

15 f0-0.paloalto-cr11.bbnplanet.net (131.119.0.211) 271.271 ms 231.349 ms 23

2.981 ms

16 h2-0.oracle2.bbnplanet.net (4.0.43.218) 232.256 ms 237.982 ms 232.040 ms

17 v-www.us.oracle.com (205.227.44.16) 242.197 ms 233.464 ms 234.834 ms

특이한 경우

[/slug]# traceroute www.oracle.com

traceroute to inet07-1.us.oracle.com (192.86.154.111), 30 hops max,

40 byte pacs

1 165.246.10.250 (165.246.10.250) 2 ms 2 ms 2 ms

2 165.246.15.1 (165.246.15.1) 2 ms 2 ms 1 ms

3 hongneung-nca-t3.kreonet.re.kr (134.75.27.1) 16 ms 8 ms 17 ms

4 gurum.kreonet.re.kr(134.75.28.1) 9 ms 14 ms 6 ms

5 taejon-seoul-t3.kreonet.re.kr(134.75.3.1) 10 ms 9 ms 31 ms

6 kfddi3.kreonet.re.kr (134.75.20.3) 68 ms 23 ms 16 ms

mix-serial4-1.sanfrancisco.mci.net (204.189.216.181) 298 ms

520 ms 545 ms

traceroute 명령의 결과에 ‘*’ 표시가 나타나는 경우가 있다. 이는 게이트웨이가 제대로 동작하지 않음을 의미하는 것이다. 즉 패킷을 제대로 처리하지 못함을 의미한다. 이러한 ‘*’ 표시가 계속적으로 보이면 그 라우터에 문제가 있거나 회선상의 단절이 발생한 것일 것이다.

그리고 산발적으로 보이는 경우는 네트워크의 패킷 흐름양이 너무 많아져 게이트웨이가 늦어져서 그러는 경우와 라우팅 테이블이 꼬였을 경우에 생기는 결과이다.

다음이 그 예이다.

[root@slug /root]# traceroute -q 4 www.yahoo.com

traceroute: warning: www.yahoo.com has multiple addresses; using 204.71.200.67

traceroute to www.yahoo.com (204.71.200.67), 30 hops max, 40 byte packets

1 sogang-fddi-1 (163.239.1.10) 1.032 ms 0.895 ms 1.321 ms 0.889 ms

2 168.126.47.193 (168.126.47.193) 6.737 ms 168.126.59.77 (168.126.59.77) 3.7

37 ms 10.318 ms 168.126.47.193 (168.126.47.193) 40.684 ms

3 apgateway3-noc.kornet21.net (168.126.16.75) 4.758 ms 9.192 ms 6.471 ms

14.804 ms

4 210.183.28.65 (210.183.28.65) 5.724 ms 3.737 ms 3.924 ms 3.843 ms

5 203.234.255.210 (203.234.255.210) 198.024 ms 207.542 ms 192.772 ms 198.9

27 ms

6 main3-249-192.sjc.above.net (209.249.192.4) 193.939 ms 216.425 ms 192.676

ms 205.461 ms

7 core1-main3.sjc.above.net (209.249.0.53) 202.330 ms 234.493 ms 198.564 ms

194.141 ms

8 pao-sjc-oc12.pao.above.net (209.133.31.150) 198.832 ms 229.429 ms 195.057

ms 193.342 ms

9 fe1-0-0.br1.pao.globalcenter.net (206.251.8.122) 212.004 ms 195.591 ms 26

7.010 ms 214.233 ms

10 pos4-1-155m.cr2.pao.globalcenter.net (206.132.254.153) 164.988 ms 201.973

ms * 192.052 ms

11 pos5-3-155m.cr2.snv.globalcenter.net (206.132.254.213) 242.607 ms 212.896

ms 180.360 ms 202.198 ms

12 pos1-0-2488m.hr8.snv.globalcenter.net (206.132.254.41) 190.198 ms 176.827

ms 180.186 ms 223.997 ms

13 bas1r-ge3-0-hr8.snv.yahoo.com (208.178.103.62) 201.429 ms 174.161 ms 185.

353 ms 169.829 ms

14 * www2.yahoo.com (204.71.200.67) 191.594 ms 194.505 ms *

위의 예에서 옵션 ‘-q’에 이어지는 4는 각 호스트마다 4개의 패킷을 보내어 확인하라는 의미이다. 이 경우

pos4-1-155m.cr2.pao.globalcenter.net (206.132.254.153) 164.988 ms 201.973 ms * 192.052

14 * www2.yahoo.com (204.71.200.67) 191.594 ms 194.505 ms *

사이의 네트워크 전송 부하가 크며 호스트는 문제가 있다고 보면 무난하다. 하지만 당부하고 싶은 것은 여러 이유로 인해 위의 리스트를 보고 예측한 것이 틀릴 수도 있다는 점이다. 그러므로 최종적인 확인은 각각의 호스트로의 ping 명령을 통해 확인해야 한다.

3. netstat로 네트웍의 문제를 파악하자!!!

* netstat 명령어

일반적으로 netstat 명령어는 네트워크와 관련된 상태정보를 보여준다. 다음은 보여줄 수 있는 상태의 종류이다.

(1) 네트워크의 연결 상황을 보여준다( 옵션 없이 사용 ).

(2) 인터페이스 설정 정보를 검사한다( -i 옵션 ).

(3) 라우팅 테이블을 조사한다(-n, -r 옵션, 여기서 -n 옵션은

호스트의 주소를 숫자로 표시하라는 옵션).

(4) 여러 네트워크 프로토콜에 대한 운용 상태 정보를 보여준다 (-s 옵션).

[root@slug /root]# netstat

active internet connections (w/o servers)

proto recv-q send-q local address foreign address state

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1307 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1306 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1305 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1304 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1303 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1302 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1301 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1300 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1299 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1298 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1297 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1296 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1295 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1294 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1293 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1292 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1291 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1290 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1289 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1288 time_wait

tcp 0 0 slug.sogang.ac.kr:www slug2.sogang.ac.kr:1287 time_wait

tcp 0 1066 slug.sogang.ac.k:telnet ccsadm25.sogang.ac:1182 established

tcp 0 0 slug.sogang.ac.k:telnet cspclab40.sogang.a:1088 established

active unix domain sockets (w/o servers)

proto refcnt flags type state i-node path

unix 1 [ ] stream connected 307684 @00016c05

unix 1 [ ] stream connected 443 @0000001d

unix 1 [ ] stream connected 306986 @00016bc9

unix 1 [ ] stream connected 307047 @00016bd2

unix 1 [ ] stream connected 736 @00000032

unix 1 [ ] stream connected 513 @00000024

unix 1 [ ] stream connected 531 @00000025

unix 0 [ ] stream connected 131 @00000014

unix 1 [ ] stream connected 307685 /dev/log

unix 1 [ ] stream connected 307048 /dev/log

unix 1 [ ] stream connected 306987 /dev/log

unix 1 [ ] stream connected 737 /dev/log

unix 1 [ ] stream connected 555 /dev/log

unix 1 [ ] stream connected 554 /dev/log

unix 1 [ ] stream connected 444 /dev/log

인자없이 쓰는 경우 활성화된 tcp 와 udp 포트의 상황을 볼 수 있다. 또한 -a 옵션을 쓰면 연결을 기다리는 비활성화 된 서버도 볼 수 있다.

* 게이트웨이 혹은 라우터에 이상이 없는데 특이하게도 특정 컴퓨터나 혹은 몇개의 컴퓨터만이 네트워크가 매우 느리거나 하는 경우가 있다. 이 경우netstat 명령을 통해 확인한다.

우선, 다음의 예를 보자. ‘-i’ 옵션은 네트워크 인터페이스(카드)의 상태를 보여주는 것이다.

[root@slug /root]# netstat -i

kernel interface table

iface mtu met rx-ok rx-err rx-drp rx-ovr tx-ok tx-err tx-drp tx-ovr flg

eth0 1500 0 20989404 614 0 630 870886 0 0 0 bru

lo 3924 0 48462 0 0 0 48462 0 0 0 lru

앞에서 보면 ‘eth0’이 받은 패킷 수는 20989404 이며 입력 에러 수는 614개, 출력 패킷 수는 870886개이며 출력에러가 없다는 것을 알 수 있다.

여기서 입출력 에러의 비가 지나치면 어떠한 문제가 있다는 얘기이다. 만약 특정 컴퓨터 하나에서만 이런 결과가 나온다면 그 컴퓨터의 네트워크 카드에 문제가 있다는 것이므로 네트워크 카드의 교체를 검토해야 할 것이다. 주위의 다른 컴퓨터들에서도 같은 결과가 나온다면 이는 이들 컴퓨터 사이에 연결된 선로에 문제가 있다는 것을 의미한다. 이런 경우 선로를 교체해야 할 것이다. 아래는 다양한 netstat 의 명령 옵션이다. 참조해서 활용하기 바란다.

[root@slug /root]# man netstat

usage: netstat [-veennccf] [<af>] -r netstat {-v|--version|-h|--help}

netstat [-vnncaeol] [<socket> ...]

netstat { [-veennac] -i | [-cnne] -m | -s }

-r, --route display routing table

-i, --interfaces display interface table

-g, --groups display multicast group memberships

-s, --statistics display networking statistics (like snmp)

-m, --masquerade display masqueraded connections

-v, --verbose be verbose

-n, --numeric dont resolve names

-n, --symbolic resolve hardware names

-e, --extend display other/more information

-p, --programs display pid/program name for sockets

-c, --continuous continuous listing

-l, --listening display listening server sockets

-a, --all, --listening display all sockets (default: connected)

-o, --timers display timers

-f, --fib display forwarding information base (default)

-c, --cache display routing cache instead of fib

<socket>={-t|--tcp} {-u|--udp} {-w|--raw} {-x|--unix} --ax25 --ipx --netrom

<af>=use '-a <af>' or '--<af>' default: inet

list of possible address families (which support routing):

inet (darpa internet) ax25 (ampr ax.25) netrom (ampr net/rom)

ipx (novell ipx) ddp (appletalk ddp)

* nslookup

이 명령어는 자신이 ip를 알고 있는데 도메인을 모를 경우나 반대로 도메인은 알고 있는데 ip를 모를 경우에 사용하는 명령어이다.

[root@slug /root]# nslookup

default server: ccs.sogang.ac.kr

address: 163.239.1.1

nslookup을 실행시키면 위와같은 꺽새 프롬프트가 떨어진다. 여기에다 자신이 궁금해 하는-자신이 알고 있는 것이 도메인명이고 알고자 하는 것이 ip address라면 도메인명을 친다. 아래와 같이.

[root@slug /root]# yahoo.com

server: ccs.sogang.ac.kr

address: 163.239.1.1

non-authoritative answer:

name: yahoo.com

addresses: 204.71.200.245, 204.71.200.243

반대로 자신이 알고자 하는 것이 도메인명이라면 아래와 같이 ip address를 입력하면 자신이 원하는 정보를 얻을수 있다.

[root@slug /root]# 210.120.129.180

server: ccs.sogang.ac.kr

address: 163.239.1.1

name: chollian.net

address: 210.120.129.180

간혹가다 이런 경우도 있을 것이다. ip나 도메인명을 올바로 입력했는데 찾아주지 못하는 경우가 있을 것이다. 이는 네임서버나 호스트 화일에 등록이 되어 있지 않거나 올바른 주소가 아니기 때문에 발생하는 에러일 것이다.

[root@slug /root]# 166.145.10.4

server: ccs.sogang.ac.kr

address: 163.239.1.1

*** ccs.sogang.ac.kr can't find 166.145.10.4: non-existent host/domain

nslookup은 외부로부터 들어오는 다양한 형태의 접속 시도를 확인할 수 있는 좋은 프로그램이다. 이것은 /etc/resolv.conf 의 네임서버에서 시작한다.

네트웍의 관리란 시스템의 자원을 어떻게 잘 활용하는가와 맥락이 같을 수 있어서 중요한 프로그램 하나를 소개하고자 한다. 아래는 top을 실행시킨 후의 결과치이다.

[root@slug /root]# top

10:17am up 11:43, 2 users, load average: 1.01, 1.02, 1.00

65 processes: 61 sleeping, 4 running, 0 zombie, 0 stopped

cpu states: 23.3% user, 76.6% system, 0.0% nice, 0.0% idle

mem: 63200k av, 61584k used, 1616k free, 31316k shrd, 21836k buff

swap: 68508k av, 8528k used, 59980k free 17848k cached

pid user pri ni size rss share stat lib %cpu %mem time command

4872 root 15 0 12236 7756 3828 r 0 99.0 12.2 573:41 netscape-com

15451 root 2 0 1028 1028 828 r 0 0.9 1.6 0:05 top

1 root 0 0 164 116 92 s 0 0.0 0.1 0:04 init

2 root 0 0 0 0 0 sw 0 0.0 0.0 0:00 kflushd

3 root 0 0 0 0 0 sw 0 0.0 0.0 0:00 kpiod

4 root 0 0 0 0 0 sw 0 0.0 0.0 0:00 kswapd

5 root -20 -20 0 0 0 sw< 0 0.0 0.0 0:00 mdrecoveryd

111 root 0 0 68 0 0 sw 0 0.0 0.0 0:00 apmd

260 bin 0 0 244 216 160 s 0 0.0 0.3 0:03 portmap

307 root 0 0 240 172 128 s 0 0.0 0.2 0:00 syslogd

318 root 0 0 448 164 136 s 0 0.0 0.2 0:00 klogd

332 daemon 0 0 152 112 68 s 0 0.0 0.1 0:00 atd

346 root 0 0 176 120 76 s 0 0.0 0.1 0:00 crond

364 root 0 0 140 72 44 s 0 0.0 0.1 0:00 inetd

378 root 0 0 1044 464 300 s 0 0.0 0.7 0:00 named

392 root 0 0 100 0 0 sw 0 0.0 0.0 0:00 lpd

409 root 0 0 92 0 0 sw 0 0.0 0.0 0:00 rpc.statd

각 프로세스들의 cpu,메모리 점유율등이 일목 요연하게 나타나는 편리한 프로그램이다.

네트워크 관리 프로토콜

과거 네트워크가 그다지 보급되지 않은 시절에는 관리하는 네트워크 기기의 수가 얼마 되지 않았다. 그래서 관리자는 이 기기들을 파악하여 문제가 발생할 때 경험과 직관으로 해결하였었다.

하지만 오늘날 네트워크가 대중화되어 그 기기의 수는 기하급수적으로 늘어났을 뿐만 아니라 이에 대한 관리는 때로는 기업의 이익과 직결된다고 보아도 틀린 말은 아닐 것이다. 이렇게 무수히 늘어난 네트워크 기기로 구성된 네트워크의 관리는 인터넷의 본고장인 미국에서 tcp/ip의 보급이 급속히 진전되면서 네트워크 관리 프로토콜의 개발로 이어졌다. 최초로 고안된 것이 sgmp(simple gateway monitoring protocol)이다. 이것은 이름 그대로 네트워크 기기 중에서도 게이트웨이를 감시하기 위한 프로토콜이었다. 이외에도 여러 가지 프로토콜들이 고안되었으나 iab(internet architecture board)가 이러한 여러 프로토콜들의 장점을 모아 새로운 네트워크 관리 프로토콜을 만들었다. 이것이 tcp/ip를 기반으로 sgmp를 계승한 snmp(simple network management protocol)이다.

한편, 국제표준화기구(iso)에서는 osi를 기반으로 한 네트워크 관리 프로토콜인 cmis/cmip(common mana gem ent information service/protocol)의 표준화를 진행시키고 있었다. 당초 snmp는 osi를 사용한 네트워크 관리 프로토콜이 실용화되기 전까지의 잠정적인 것이었으나 장치가 간단하다는 장점 때문에 많은 회사 기기에 장착되어 현재에 이르고 있다. osi 기반의 cmis/cmip는 실용적으로는 그다지 보급되지 못한 상황이기에 현시점에서 표준적인 네트워크 관리 프로토콜은 snmp라고 할 수 있다.

(the simple network management protocol)

snmp는 일종의 클라이언트/서버 모델인 매니저(manager)/에이전트(agent)구조이다. 각각의 에이전트들은 네트워크 장비나 호스트를 나타내는데 이들은 자신의 네트워크에 대한 정보를 가지며 보통 snmpd라는 데몬을 수행한다. 그래서 매니저가 자신의 네트워크 정보에 대한 질의를 해오면 이에 대답하는 구조를 가진다.

tcp/ip의 네트워크 구성요소는 다음의 세 가지이다.

(1) management information base(mib)

- 에이전트가 어떤 정보를 가져야 하는지 정의

(2) structure of management information(smi)

- mib의 변수값을 참조할 때 사용되는 계층구조

(3) simple network management protocol(snmp)

- 매니저와 에이전트사이의 통신 프로토콜

* 사실 네트웍을 이야기하면서 dns 관련 사항을 얘기하지 않는다면 그건 진정한 의미의 네트웍 관련 강의가 아니라고 생각한다. 이 부분은 추가적으로 리눅스 공동체 세미나 자료실에 추가로 올릴 것이다. 참고 하시고 네트웍의 공부에 도움이 되시기를 바랍니다. 이상으로 네트웍 관련된 사항은 마치기로 하고 다음으로 넘어갈까 합니다.






3. 레드햇 리눅스 6.0 설치와 활용

현재 나와있는 대부분의 한글 배포판은 레드햇 리눅스 6.0을 기반으로 하고 있다. 여기서는 리눅스를 처음 설치하시는 분들을 중심으로 가장 중요한 내용들을 주로 이야기 하겠다..

1. 설치하기

1) 설치를 위한 부팅하기

여러분의 컴퓨터가 비교적 근래에 나온 똘똘한 녀석이라면 cd-rom으로 부팅이 가능할 것이다. 그렇다면 설치를 위한 부팅은 너무도 간단하다. 컴퓨터를 cd-rom으로 부팅이 가능하도록 cmos설정을 바꿔주신 후에 리눅스 cd를 넣고 부팅하기만 하면 된다. 만약 cd-rom부팅이 안되는 컴퓨터라면 부팅디스크를 만든다.

* 부팅디스크 만들기

리눅스 시디의 /dosutils 디렉토리의 rawrite 프로그램을 이용한다.

디스켓을 a 드라이브에 넣은 후 다음과 같이 실행하면 부팅디스크를 만든다.

d:\dosutils>rawrite

enter disk image source file name: ..\images\boot.img ?

enter target diskette drive: a: ?

please insert a formatted diskette into drive a: and press --enter-- : ?

부팅디스크가 만들어졌으면 a: 드라이브에 넣고 부팅을 합니다.

2) 첫 화면이 뜨면 영어로 쭈욱~ 적힌 환영과 안내 화면이 나오고 제일 밑에 펑션키 메뉴와 boot: 라고 나오고 커서가 깜박인다. 이때 그냥 엔터를 쳐주면 된다. 그럼 뭔가 시작하죠?

3) 두 번째 화면 역시 환영과 함께 안내 메시지다.

4) 그 다음은 설치시 사용하는 언어를 고르는 화면이다. english를 선택한다.

5) 이번엔 키보드 선택이다. 역시 us를 고르면 된다.

6) 다음은 인스톨 수단(installation method)이다. 대부분이 cd-rom에 담긴 리눅스 배포판을 이용할테니 local cdrom을 고른다.

7) 리눅스 시디를 넣으라네요. 이미 넣어 뒀죠? 그냥 엔터...o.k.

8) 새로 설치할 것인가? 기존에 깔린 리눅스를 업그레이드 할 것인가? 처음 리눅스를 설치한다면 당연히 새로 설치( install ), 기존에 설치되어 있는 리눅스가 있어도 가급적이면 그냥 새로 설치한다. ^^; 이미 설치되어 있는 리눅스가 옛날 버전의 리눅스일 경우 라이브러리 호환 문제가 생길 수도 있기 때문이다.

9) installation class라고 나오죠? 리눅스를 어떤식으로 설치할 것인가를 묻는것인데. 잘 모른다면 그냥 custom을 선택할 것을 강조 또 강조한다. workstation의 경우 기존의 리눅스 파티션을 지워버리고 스스로 알아서 다시 나누어 설치하고, server의 경우 한 컴퓨터를 몽땅 리눅스 전용 컴퓨터로 만들어버린다.(물론 기존에 있던 윈도우98 같은 것도 깨끗이 지워 버린다. ) windows와 같은 다른 운영체제와 같이 쓰려면 custom을 선택하는 것이 정신건강에 좋다.

10) scsi 어댑터가 있는가 묻고 있다. 있으면 yes, 없으면 no.

11) 이제부터 가장 어렵다고 생각되는 파티션을 나누는 부분이다.(사실 별로 어려울 것도 없

다.) 우선 맘에드는 도구를 선택한다. disk druid가 fdisk보다 조금 간편하다. fdisk를 쓰고 싶다면 어쩔 수 없지만 우리는 disk druid를 쓰기로 하자.

<여기서 잠깐!> 파티션을 실제로 나누기 전에 파티션에 관한 꼭 필요한 내용을 이야기하고 가자. 아주 쉽게 얘기해서 파티션을 나눈다는 것은 하나의 하드디스크에 여러개의 공간을 만든다고 생각하면 된다. 따라서 리눅스 파티션을 만드는 것은 windows와는 다른 리눅스만의 공간을 만드는 것이다. 만일 기존에 사용하고 있는 windows같은 운영체제가 하나의 하드디스크를 통째로 사용하고 있다면 좀 더 수고를 해야한다. 그렇지 않고 예를 들어 6.4g의 하드를 4g, 2g씩 나누어 사용하고 있다면 별 수고 없이 리눅스를 설치할 수 있다. 특별한 용도(예를 들면, 서버운영)가 아니라면 1.5g정도의 용량이면 리눅스를 설치하기에 충분하다.

* 위에서 언급했듯이 다른 운영체제가 하드디스크를 통째로 사용하고 있다면 fips라는 유틸리티를 이용하여 기존의 하나로 되어있는 파티션을 나누어 주어야 한다. 이 fips라는 유틸리티는 리눅스 시디의 /dosutils 라는 디렉토리에 있으며 자세한 사용법은 /dosutils/fipsdocs 라는 디렉토리에 있다.

* 파티션에 관한 자세한 설명은 아래 페이지를 참고하시기 바랍니다.

http://kldp.org/howto/mini/html/partition/partition.html

12) 핫..좀 복잡한 화면이 떴죠? 파티션에 관한 정보를 보여주고 고치는 부분이다.

화면이 위, 아래 두분으로 나누어져 있습니다. 윗부분은 파티션에 관한 정보를 보여주는 화면이고 아랫부분은 하드디스크의 정보를 보여주는 화면이다. 기본적인 용어를 정리해보면

mout point : 마운트할 위치

device : 파티션 이름이라고 보면 된다. hda1은 첫 번째 하드디스크의 1번 파티션을 말한다.

scsi하드의 경우 sda1과 같은 식으로 나타난다.

requested: 사용자가 요구한 용량

actual: 실제로 할당된 용량

type: 파일 시스템의 종류.

여기서 우리가 해야할 일은 리눅스를 설치하기 위해 linux native 파티션과 linux swap 파티션을 만들어 주는 일이다. 예를 들어 설명하겠다. 만약 기존에 하나의 하드디스크를 c와 d로 나누어 사용하였다면 아마도 화면의 윗부분은 hda1과 hda2 두줄로 이루어져 있을 것이다. 이때 기존의 c드라이브에 windows를 그대로 두고 d드라이브에 리눅스를 설치하고 싶다면 일단은 hda2에 파란색 막대(?)가 오도록 한 후 f4키를 눌러(혹은 tab키로 이동해서) 파티션을 삭제한다. 그 다음 f1키를 눌러서 파티션을 추가한다. edit new partition 이라는 새로운 창이 뜰 것이다. 일단 마운트 포인트는 비워 놓은 후 size로 커서를 옮겨 100정도로 적어준다(왜 꼭 100이어야 하는가? 아니어도 된다. 하지만 하드 용량에 다소 여유가 있다면 100정도로 잡으면 된다.). 그 다음 type으로 옮겨 linux swap을 선택한다. allowable drives(파티션을 설치할 드라이브를 선택하는 것이다. 두 개일 경우 두 개다 * 체크된 채로 두면 스스로 알아서 처리한다.)는 *체크된채로 둔다. o.k. 그러면 다시 돌아온 화면에서 새롭게 생성된 파티션을 볼 수 있을 것이다. 하나 더 만들자. add! 이번엔 마운트 포인트에 / 를 적는다. size 남은 용량을 대충 계산해서 적는다. grow to fill disk? 여기에 * 로 체크해준다. 그러면 남은 용량을 알아서 전부 채워준다. 이번에는 type을 linux native로 선택한다. allowable drives는 역시 *로 체크된채로 둔다. o.k. 하나가 더 만들어졌죠? 이제 리눅스를 위한 공간 마련은 끝났습니다. o.k.로 넘어간다.

13) active swap space라고 나오죠? 스왑 파티션에 스왑 영역을 만들어 준다. 위에서 만든 스왑 파티션이 hda2라면 다음과 같이 나온다.

device size (k)

[*] /dev/hda2 10xxxxx

[ ] check for bad blocks during format

아래 내용은 스왑 영역을 만들면서 하드디스크에 배드 섹터를 검사할 것인지를 물어보는 것이다. 윗 부분은 반드시 * 체크 해줘야 하며 아랫 부분은 배드 섹터가 없는 게 확실하다면 체크 안해도 된다.(체크할 경우 시간이 좀 오래 걸린다.) o.k.

14) 이번에는 위와 비슷한 방법으로 linux native 파티션을 포맷하는 부분이다. 역시 위와 같은 방법으로 설정하고 넘어간다.




15) 설치할 패키지를 고르는 화면이다. 어느 정도 각각의 패키지의 용도에 대하여 알고 있고 하드 용량이 부족하다면 자신이 원하는 패키지만을 선택한다. 그렇지 않으면 제일 끝부분에 있는 everything을 선택하여 전부 설치한다. 아랫부분의 select individual packages를 선택하면 더 자세하게 선택할 수 있다. everything 으로 선택했다고 하고 그냥 넘어가기로 한다.


16) 설치과정에서의 기록들이 /tmp/install.log 에 기록되어 있음을 안내해 주고 있다. 한번 읽어보고 넘어가자.



17) 아~ 드디어 머리아픈 시간이 가고 조금 쉴 여유가 생겼군요. 파일시스템을 만들고 거기에 프로그램을 설치하기 시작한다.

18) 별 문제없이 파일시스템 만들기와 파일 복사가 끝났다면 마우스 설정 화면이 나올 것이다. ps/2 마우스의 경우 대부분 알아서 인식해준다. 아니라면 화면에서 자신이 갖고 있는 마우스 종류를 선택한다. 시리얼 마우스의 경우 마우스 포트 설정 화면이 나올 수 있다. 역시 자신의 마우스가 꼽혀있는 포트를 확인하고 선택해준다

.

19) 이번엔 랜카드의 설정이다. 랜카드가 없으면 no를 선택하여 넘어가고 랜카드가 있으면 yes를 선택한다. 랜카드가 없으면 21)번 과정으로 넘어가자.

20) 대부분의 랜카드는 자동으로 인식한다. 그렇지 않을 경우 랜카드에 해당하는 모듈을 선택하는 메뉴가 나오는데 자신이 가지고 있는 랜카드를 고르면 된다. 다음에 나오는 모듈 옵션은 autoprobe로 하면 무난하다. 이번엔 boot protocol을 고른다. 일반적인 경우 static ip address를 고른다.(bootp와 dhcp에 관한 자세한 내용은 관련 howto문서를 참조하라.) 다음은 tcp/ip설정이다. 자신의 네트웍에 맞게 설정한다. 다음은 도메인 이름, 호스트 이름, 네임서버주소와 같은 네트웍 일반 설정이다. 역시 자신의 네트웍에 맞게 설정한다. 잘 모를 경우 자신이 속해있는 네트웍 담당자에게 문의하라.


21) 시간 설정이다. 거의 대부분의 경우 hardware clock set to gmt는 선택하지 말아야 한다. 시간은 rok나 asia/seoul을 선택한다.

22) 부팅시 자동으로 실행되는 대몬(daemon)들을 고른다. 원하는 것만 선택하고 잘 모를 경우 그대로 두고 넘어간다.o.k.

23) 프린터 설정이다. 프린터가 있으면 yes 없으면 no. 있다하더라도 리눅스를 설치한 컴퓨터에 프린터가 연결되어 있다면 기본 설정을 유지한채 계속 넘어가면 된다. 물론 프린트 모델을 고르는 부분에서는 자신이 가지고 있는 모델을 선택한다. 기타 삼바 등을 통한 네트웍 프린터 설정에 관한해서는 http://kldp.org의 문서들을 참조하기 바란다.

24) 시스템 관리자(root)의 패스워드를 입력하는 부분이다. 보안에 신경을 써서 적당한 것을 입력하면 된다.


25) 이번에 나오는 화면은 network information system(nis)과 쉐도우 패스워드, md5 패스워드에 관한 설정이다. 일반 사용자들은 기본 설정을 유지하고 넘어간다. o.k.

26) 리눅스 박스에 문제가 생겼을 때 복구를 위해 부팅디스켓을 만들 것인지를 만들고 있다. 안만들어도 별 문제는 없지만 하나 만들어 두는것도 나쁘진 않다.

27) 중요하다!!! 부팅을 관리해주는(여러 운영체제를 선택해서 부팅해 주거나, 여러 커널을 선택적으로 부팅해주는 등의 기능이 있다.) lilo를 설치할 영역을 선택한다. 반드시 master boot record로 선택을 해준다.

28) lilo의 옵션을 적어준다. 대부분의 경우 빈칸으로 두고 넘어간다.

29) 드디어 x-window의 설정이다. 제일 먼저 그래픽 카드다. 자동으로 인식되는 경우도 있고 자신의 카드를 골라줘야 하는 경우도 있다. 카드를 골라주면 해당 x 서버를 설치한다.

30) 이번엔 모니터다. 자신이 가지고 있는 모니터가 목록에 있을 경우엔 선택한다. 없다면 custom을 선택하여 자신의 모니터에 맞는 설정을 해주어야 한다. 모니터의 사양은 모니터 매뉴얼을 참조한다. 모니터를 설정하면 검사를 할 것인지를 묻는다. probe를 선택한다. 두세번 깜박이고 검사가 끝나면 적절한 해상도와 색상수를 보여준다. 그냥 주어진 default 값으로 설정하는 것이 무난하다. 그렇지 않을 경우 자신이 원하는 색상에 따른 해상도를 골라준다.

31) x 설정이 제대로 되었나 시험을 하겠냐는 질문이다. yes를 선택하면 x 서버를 동작시키고 제대로 화면이 출력되는지를 묻는다. 그 다음 질문은 부팅시 x환경으로 부팅할 것인지 콘솔환경으로 부팅할 것인지를 묻는 것이다. 원하는 대로 설정하라.

32) 드디어 길고 긴 리눅스 설치의 과정이 끝났다. 축하 메시지가 나타난다. 자동으로 시스템을 리부팅 해준다.

2. x-window 설정하기

첫번째는, x를 설정하기 편하고 시각적으로 쉽게 접근 할 수 있도록 xconfigurator라는 툴을 이용하여 x를 설정하는 방식과, 두번째는, 예전의 텍스트 모드로써 보여주는 xf86config가 있다. 나는 내가 자주 쓰는 xf86config만 설명하겠다. xconfigurator가 조금 더 그래픽적이며 xf86config로 설정을 할수 있다면 xconfigurator로도 충분히 할수 있을거라 본다.

xf86config 로 설정하기

이 방식은 위에서도 언급했듯이 텍스트 모드로써 x 를 설정하는 방법이다. 콘솔에서나 x interfaces에서 설정 할 수 있는 방식이다. 그럼, 아무데서나 xf86config를 실행하기 바란다.

# xf86config

this program will create a basic xf86config file, based on menu selections you make.the xf86config file usually resides in /usr/x11r6/lib/x11 or /etc/x11. a sample xf86config file is supplied with xfree86; it is configured for a standard vga card and monitor with 640x480 resolution. this program will ask for a pathname when it is ready to write the file. you can either take the sample xf86config as a base and edit it for your configuration, or let this program produce a base xf86config file for your configuration and fine-tune it. refer to

/usr/x11r6/lib/x11/doc/readme.config

for a detailed overview of the configuration process.

for accelerated servers (including accelerated drivers in the svga server), there are many chipset and card-specific options and settings. this program does not know about these. on some configurations some of these settings must be specified. refer to the server man pages and chipset-specific readmes. before continuing with this program, make sure you know the chipset and amount of video memory on your video card. superprobe can help with this. it is also helpful if you know what server you want to run.

press enter to continue, or ctrl-c to abort.

xf86config의 도입부분이다. 계속하려면 엔터, 중단한다면 ctrl-c를 누르면 된다. 엔터를쳐서 계속 진행을해보자.

the directory '/usr/x386/bin' exists. you probably have an old version of xfree86 installed (xfree86 3.1 installs in '/usr/x11r6' instead of '/usr/x386'). it is important that the directory '/usr/x11r6' is present in your search path, *before* any occurrence of '/usr/x386/bin'. if you have installed x program binaries that are not in the base xfree86 distribution in '/usr/x386/bin', you can keep the directory in your path as long as it is after '/usr/x11r6'. your path is currently set as follows:

/sbin:/usr/sbin:/bin:/usr/bin:/usr/x11r6/bin:/opt/kde/bin:/root/bin:/usr/x11r6/bin:/opt/kde/bin:/root/bin

note that the x binary directory in your path may be a symbolic link. in that case you could modify the symbolic link to point to the new binaries.

example: 'rm -f /usr/bin/x11; ln -s /usr/x11r6/bin /usr/bin/x11', if the link is '/usr/bin/x11'.

make sure the path is ok before continuing. press enter to continue, or ctrl-c to abort.

현재 xfree86 버전이 설치된 패스를 확인하는 절차이다. 역시 계속 하려면 엔터를 치고 넘어가면 된다.

first specify a mouse protocol type. choose one from the following list:

1. microsoft compatible (2-button protocol)

2. mouse systems (3-button protocol)

3. bus mouse

4. ps/2 mouse

5. logitech mouse (serial, old type, logitech protocol)

6. logitech mouseman (microsoft compatible)

7. mm series

8. mm hittablet

9. microsoft intellimouse

if you have a two-button mouse, it is most likely of type 1, and if you have a three-button mouse, it can probably support both protocol 1 and 2. there are two main varieties of the latter type: mice with a switch to select the protocol, and mice that default to 1 and require a button to be held at boot-time to select protocol 2. some mice can be convinced to do 2 by sending a special sequence to the serial port (see the cleardtr/clearrts options).

enter a protocol number:

자신의 시스템에 부착된 마우스의 종류를 선택하는 부분이다. ps/2 마우스는 4번, 일반적인 시리얼 마우스를 가지고 있는 사용자는 1번을 선택하고 넘어가면 된다.

if your mouse has only two buttons, it is recommended that you enable emulate3buttons. please answer the following question with either 'y' or 'n'. do you want to enable emulate3buttons?

일반적인 2버튼 사용자라도 양쪽 버튼을 가지고 마치 3버튼 마우스처럼 가상 에뮬레이트 해주는 기능을 선택할 것인지 묻는 항목이다. 2버튼 마우스를 3버튼 마우스처럼 사용하려면 yes로 설정하고 넘어가기 바란다.

now give the full device name that the mouse is connected to, for example /dev/tty00. just pressing enter will use the default, /dev/mouse.

mouse device:

마우스의 시스템디바이스를 결정하는 부분이다. 디폴트로는 /dev/mouse로 되어있다. 엔터를 치고 넘어가면 된다.

beginning with xfree86 3.1.2d, you can use the new x11r6.1 xkeyboard extension to manage the keyboard layout. if you answer 'n' to the following question, the server will use the old method, and you have to adjust your keyboard layout with xmodmap. please answer the following question with either 'y' or 'n'.

do you want to use xkb?

키보드의 언어 매핑을 지정하는 부분이다. 대부분 no를 선택한 후 다음의 키보드에서 선택하기 바란다.

if you want your keyboard to generate non-ascii characters in x, because you want to be able to enter language-specific characters, you can set the left alt key to meta, and the right alt key to modeshift.

please answer the following question with either 'y' or 'n'. do you want to enable these bindings for the alt keys?

이것은 왼쪽과 오른쪽 alt 키를 다르게 지정 할것 인지에 대한 항목이다. 사용자의 선택에 달렸다.

now we want to set the specifications of the monitor. the two critical parameters are the vertical refresh rate, which is the rate at which the the whole screen is refreshed, and most importantly the horizontal sync rate, which is the rate at which scanlines are displayed. the valid range for horizontal sync and vertical sync should be documented in the manual of your monitor. if in doubt, check the monitor database /usr/x11r6/lib/x11/doc/monitors to see if your monitor is there.

press enter to continue, or ctrl-c to abort.

모니터 설정에 앞서 모니터의 수평 동기 주파수와 수직 동기 주파수를 확인하기 바란다. 모니터를 설정하려면 엔터를 치고 넘어간다.

you must indicate the horizontal sync range of your monitor. you can either select one of the predefined ranges below that correspond to industry-standard monitor types, or give a specific range. it is very important that you do not specify a monitor type with a horizontal sync range that is beyond the capabilities of your monitor. if in doubt, choose a conservative setting.

hsync in khz; monitor type with characteristic modes

1 31.5; standard vga, 640x480 @ 60 hz

2 31.5 - 35.1; super vga, 800x600 @ 56 hz

3 31.5, 35.5; 8514 compatible, 1024x768 @ 87 hz interlaced (no 800x600)

4 31.5, 35.15, 35.5; super vga, 1024x768 @ 87 hz interlaced, 800x600 @ 56 hz

5 31.5 - 37.9; extended super vga, 800x600 @ 60 hz, 640x480 @ 72 hz

6 31.5 - 48.5; non-interlaced svga, 1024x768 @ 60 hz, 800x600 @ 72 hz

7 31.5 - 57.0; high frequency svga, 1024x768 @ 70 hz

8 31.5 - 64.3; monitor that can do 1280x1024 @ 60 hz

9 31.5 - 79.0; monitor that can do 1280x1024 @ 74 hz

10 31.5 - 82.0; monitor that can do 1280x1024 @ 76 hz

11 enter your own horizontal sync range

enter your choice (1-11):

이 부분은 자신이 가지고 있는 모니터의 수평 동기 주파수를 설정하는 방식이다. 먼저, 자신의 모니터의 매뉴얼에서 수평 동기 주파수 대역을 확인한 후에 찾아보고 없다면 11번을 선택하여 자신의 주파수 대역을 적어주면 된다. 1-10번 사이를 설정한 사용자를 제외한 11번을 선택하여 직접 수평 동기 주파수를 설정하려는 사람은 다음 장면을 잘 확인하기 바란다.

please enter the horizontal sync range of your monitor, in the format used in the table of monitor types above. you can either specify one or more continuous ranges (e.g. 15-25, 30-50), or one or more fixed sync frequencies.

horizontal sync range:

11번을 선택하여 나타난 부분이다. 자신의 수평 동기 주파수 대역을 (horizontal sync range: ) 이 부분에 적어주면된다. 예를 들어서 자신의 수평 동기 주파수 대역이 30-65 사이라면

ex) horizontal sync range: 30-65

이런식으로 설정을 해주면 된다. 설정을 다 했다면 다음 수직 동기 주파수를 설정하는 부분으로 이동해 보자.

you must indicate the vertical sync range of your monitor. you can either select one of the predefined ranges below that correspond to industry-standard monitor types, or give a specific range. for interlaced modes, the number that counts is the high one (e.g. 87 hz rather than 43 hz).

1 50-70

2 50-90

3 50-100

4 40-150

5 enter your own vertical sync range

enter your choice:

모니터의 수직 동기 주파수를 설정하는 부분으로써, 자신의 모니터의 매뉴얼에서 수직 동기 주파수 대역을 확인을 한 후에 설정하기 바란다. 자신의 모니터의 수직 동기 주파수 대역을 자세히 아는 사용자라면 5번 항목에서 정확한 모니터 주파수 대역을 적어주는 것을 권장한다. 5번을 선택한 후에 수직 동기 주파수 대역을 설정 하는 방법이다.

vertical sync range: 50-110

여기서 수직 동기 주파수 대역을 50-110 이라고 설정해주었다. 필자 모니터의 수직 동기 주파수 대역이다. 다 되었으면 엔터를 치고 다음으로 넘어가보자.

you must now enter a few identification/description strings, namely an identifier, a vendor name, and a model name. just pressing enter will fill in default names. the strings are free-form, spaces are allowed. enter an identifier for your monitor definition:

모니터의 모델 이름을 묻는 항목이다. 적지 않아도 상관없다.

enter the vendor name of your monitor:

역시 이름을 묻는 항목이다.

enter the model name of your monitor:

적어주지 않아도 된다.

다음은 그래픽 카드를 선택하는 부분이다.

now we must configure video card specific settings. at this point you can choose to make a selection out of a database of video card definitions. because there can be variation in ramdacs and clock generators even between cards of the same model, it is not sensible to blindly copy the settings (e.g. a device section). for this reason, after you make a selection, you will still be asked about the components of the card, with the settings from the chosen database entry presented as a strong hint. the database entries include information about the chipset, what server to run, the ramdac and clockchip, and comments that will be included in the device section. however, a lot of definitions only hint about what server to run (based on the chipset the card uses) and are untested. if you can't find your card in the database, there's nothing to worry about. you should only choose a database entry that is exactly the same model as your card; choosing one that looks similar is just a bad idea (e.g. a gemstone snail 64 may be as different from a gemstone snail 64+ in terms of hardware as can be).

do you want to look at the card database?

이 부분은 그래픽 카드를 선택하는 부분이다. yes 로 설정하고 엔터하고 넘어가 보자.

0 2 the max maxcolor s3 trio64v+ s3 trio64v+

1 928movie s3 928

2 agx (generic) agx-014/15/16

3 alg-5434(e) cl-gd5434

4 asus 3dexplorer riva128

5 asus pci-av264ct ati-mach64

6 asus pci-v264ct ati-mach64

7 asus video magic pci v864 s3 864

8 asus video magic pci vt64 s3 trio64

9 at25 alliance at3d

10 at3d alliance at3d

11 ati 3d pro turbo ati-mach64

.

. (중략)

.

412 winfast s200 et4000/w32(i/p)

413 winfast s430 s3 968

414 winfast s510 s3 968

415 xga-1 (isa bus) xga-1

416 xga-2 (isa bus) xga-2

417 miro miromedia 3d s3 virge

enter a number to choose the corresponding card definition.

press enter for the next page, q to continue configuration.

xfree86 3.3.2 에서는 많은 비디오 카드가 지원되기 시작했다. 특히, 이번 버전부터는 agp 비디오 카드가 시험적으로 도입이 되었다. 부가적인 설명을 하자면 왼쪽에 있는 것은 비디오 카드 모델명이고, 오른쪽에 있는 것은 비디오 카드의 칩셋이다. 리눅스 상에서의 비디오 카드는 비디오 카드 칩셋에 따라 x 설정이 많이 좌우하게 된다. 목록에서 자신의 비디오 카드를 선택하였다면 다음과 같은 메시지 가 나타날 것이다.

your selected card definition:

identifier: matrox mystique

chipset: mga1064sg

server: xf86_svga

do not probe clocks or use any clocks line.

press enter to continue, or ctrl-c to abort.

xfree86 3.3.2 에서 추가로 지원되는 비디오 카드 목록은 나중에 보여줄 것이다. 엔터를 치고 넘어가면 다음과 같은 메세지가 나타날 것이다.

now you must determine which server to run. refer to the manpages and other documentation. the following servers are available (they may not all be installed on your system):

1 the xf86_mono server. this a monochrome server that should work on any vga-compatible card, in 640x480 (more on some svga chipsets).

2 the xf86_vga16 server. this is a 16-color vga server that should work on any vga-compatible card.

3 the xf86_svga server. this is a 256 color svga server that supports a number of svga chipsets. on some chipsets it is accelerated or supports higher color depths.

4 the accelerated servers. these include xf86_s3, xf86_mach32, xf86_mach8, xf86_8514, xf86_p9000, xf86_agx, xf86_w32, xf86_mach64, xf86_i128 and xf86_s3v.

these four server types correspond to the four different "screen" sections in xf86config (vga2, vga16, svga, accel).

5 choose the server from the card definition, xf86_svga.

which one of these screen types do you intend to run by default (1-5)?

위의 비디오 카드 항목에서 선택을 하였으면 5번을 선택하지만, 만약, 자신의 비디오 카드가 목록에 없을 경우에는 1-4번 항목을 선택할 수 있다.

1번 항목은 흑백 모드로 x 를 설정하도록 하는 항목이다.

2번 항목은 mono(즉, 16컬러) 모드로 x 를 설정하도록 하는 항목이다.

3번 항목은 256 컬러 svga 모드로 x 를 설정하도록 하는 항목이다. 시스템에 있는 비디오 카드가 목록에 없을 경우에 svga 모드로 x 설정할 경우이다.

4번 항목은 accelerated 기능이 있는 비디오 카드를 선택하는 항목이다. 리눅스에서 가장 x 설정하기 쉬운 비디오 카드를 지원하는 항목이다.

the server to run is selected by changing the symbolic link 'x'. for example,

'rm /usr/x11r6/bin/x; ln -s /usr/x11r6/bin/xf86_svga /usr/x11r6/bin/x'

selects the svga server.

please answer the following question with either 'y' or 'n'.

do you want me to set the symbolic link?

이 항목은 선택된 x서버를 /usr/x11r6/bin/x 로 링크를 시키는 항목이다. yes로 설정하고 다음으로 넘어가보자.

now you must give information about your video card. this will be used for the "device" section of your video card in xf86config. you must indicate how much video memory you have. it is probably a good idea to use the same approximate amount as that detected by the server you intend to use. if you encounter problems that are due to the used server not supporting the amount memory you have (e.g. ati mach64 is limited to 1024k with the svga server), specify the maximum amount supported by the server.

how much video memory do you have on your video card:

1 256k

2 512k

3 1024k

4 2048k

5 4096k

6 other

enter your choice:

이 항목은 시스템에 부착된 비디오 카드의 메모리를 선택하는 부분이다. 자신의 비디오 카드의 메모리를 살펴보기 바란다.

you must now enter a few identification/description strings, namely an identifier, a vendor name, and a model name. just pressing enter will fill in default names (possibly from a card definition). your card definition is matrox mystique. the strings are free-form, spaces are allowed. enter an identifier for your video card definition:

이 항목은 비디오 카드의 회사명을 적어주는 곳이다. 써주지 않아도 상관없다.

you can simply press enter here if you have a generic card, or want to describe your card with one string.

enter the vendor name of your video card:

이 항목은 비디오 카드의 모델명을 적어주는 항목이다. 써주지 않아도 상관없다.

enter the model (board) name of your video card:

이 항목도 마찬가지이다.

the ramdac setting only applies to the s3, agx, w32 servers, and some drivers in the svga servers. some ramdac's are auto-detected by the server. the detection of a ramdac is forced by using a ramdac "identifier" line in the device section. the identifiers are shown at the right of the following table of ramdac types:

1 at&t 20c490 (s3 and agx servers, ark driver) att20c490

2 at&t 20c498/21c498/22c498 (s3, autodetected) att20c498

3 at&t 20c409/20c499 (s3, autodetected) att20c409

4 at&t 20c505 (s3) att20c505

5 brooktree bt481 (agx) bt481

6 brooktree bt482 (agx) bt482

7 brooktree bt485/9485 (s3) bt485

8 sierra sc15025 (s3, agx) sc15025

9 s3 gendac (86c708) (autodetected) s3gendac

10 s3 sdac (86c716) (autodetected) s3_sdac

11 stg-1700 (s3, autodetected) stg1700

12 stg-1703 (s3, autodetected) stg1703

13 ti 3020 (s3, autodetected) ti3020

14 ti 3025 (s3, autodetected) ti3025

15 ti 3026 (s3, autodetected) ti3026

16 ibm rgb 514 (s3, autodetected) ibm_rgb514

17 ibm rgb 524 (s3, autodetected) ibm_rgb524

18 ibm rgb 525 (s3, autodetected) ibm_rgb525

19 ibm rgb 526 (s3) ibm_rgb526

20 ibm rgb 528 (s3, autodetected) ibm_rgb528

21 ics5342 (s3, ark) ics5342

22 ics5341 (w32) ics5341

23 ic works w30c516 zoomdac (ark) zoomdac

24 normal dac normal

enter a number to choose the corresponding ramdac.

press enter for the next page, q to quit without selection of a ramdac.

비디오 카드의 ramdac을 설정하는 항목이다. 주로 s3 계열의 비디오 카드가 선택 항목에 들어간다. s3 계열의 비디오 카드 이외의 비디오 카드라면 24번의 normal dac 을 선택하던지 q를 선택해서 빠져 나오기 바란다.모르겠으면 무조건 q를 누르고 나온다.

a clockchip line in the device section forces the detection of a programmable clock device. with a clockchip enabled, any required clock can be programmed without requiring probing of clocks or a clocks line. most cards don't have a programmable clock chip.

choose from the following list:

1 chrontel 8391 ch8391

2 icd2061a and compatibles (ics9161a, dcs2824) icd2061a

3 ics2595 ics2595

4 ics5342 (similar to sdac, but not completely compatible) ics5342

5 ics5341 ics5341

6 s3 gendac (86c708) and ics5300 (autodetected) s3gendac

7 s3 sdac (86c716) s3_sdac

8 stg 1703 (autodetected) stg1703

9 sierra sc11412 sc11412

10 ti 3025 (autodetected) ti3025

11 ti 3026 (autodetected) ti3026

12 ibm rgb 51x/52x (autodetected) ibm_rgb5xx

just press enter if you don't want a clockchip setting.

what clockchip setting do you want (1-12)?

비디오 카드의 클럭 칩셋을 선택하는 부분이다. 주로 s3 계열의 비디오 카드가 이 항목에 들어간다. 비디오 카드의 매뉴얼 을 보아서 자신의 클럭 칩이 여기에 없다면 엔터를 치고 넘어간다.

for most configurations, a clocks line is useful since it prevents the slow and nasty sounding clock probing at server start-up. probed clocks are displayed at server startup, along with other server and hardware configuration info. you can save this information in a file by running 'x -probeonly 2>output_file'. be warned that clock probing is inherently imprecise; some clocks may be slightly too high (varies per run).

at this point i can run x -probeonly, and try to extract the clock information from the output. it is recommended that you do this yourself and add a clocks line (note that the list of clocks may be split over multiple clocks lines) to your device section afterwards. be aware that a clocks line is not appropriate for drivers that have a fixed set of clocks and don't probe by default (e.g. cirrus). also, for the p9000 server you must simply specify clocks line that matches the modes you want to use. for the s3 server with a programmable clock chip you need a 'clockchip' line and no clocks line. you must be root to be able to run x -probeonly now. the card definition says to not probe clocks.

do you want me to run 'x -probeonly' now?

x 설정에 있어서 모니터의 주파수 대역을 선택한 비디오 카드의 클럭 칩과의 상관관계를 맞추어주는 부분입니다. 만일 맞지 않는다면 에러 메시지를 보여주게 됩니다. 자신의 모니터 설정과 비디오 카드가 맞는지 확인해 보기 위해서 yes 로 설정하고 맞는지 확인해 보시기 바랍니다.

the card definition says to not probe clocks. do you want me to run 'x -probeonly' now? y

it is possible that the hardware detection routines in the server will somehow cause the system to crash and the screen to remain blank. if this is the case, do not choose this option the next time. the server may need a ramdac, clockchip or special option (e.g. "nolinear" for s3) to probe and start-up correctly.

press enter to continue, or ctrl-c to abort.

yes 로 설정을 하였다면 다음과 같은 메세지가 나온다. 엔터를 치고 넘어가면 몇 번 정도 화면이 깜빡이면서 주파수 대역을 찾아내게 된다. 만약, 에러가 난다면 다음과 같은 메세지가 나오게 된다.

running x -probeonly -pn -xf86config /tmp/xf86config.tmp. x -probeonly call failed. no clocks line inserted.

press enter to continue, or ctrl-c to abort.

엔터를 쳐서 해상도 설정을 해보자.

for each depth, a list of modes (resolutions) is defined. the default resolution that the server will start-up with will be the first listed mode that can be supported by the monitor and card. currently it is set to:

"640x480" "800x600" "1024x768" "1280x1024" for 8bpp

"640x480" "800x600" "1024x768" "1280x1024" for 16bpp

"640x480" "800x600" "1024x768" "1280x1024" for 24bpp

"640x480" "800x600" "1024x768" for 32bpp

note that 16, 24 and 32bpp are only supported on a few configurations. modes that cannot be supported due to monitor or clock constraints will be automatically skipped by the server.

1 change the modes for 8pp (256 colors)

2 change the modes for 16bpp (32k/64k colors)

3 change the modes for 24bpp (24-bit color, packed pixel)

4 change the modes for 32bpp (24-bit color)

5 the modes are ok, continue.

enter your choice:

자신이 원하는 컬러수를 고르는 항목이다.

select modes from the following list:

1 "640x400"

2 "640x480"

3 "800x600"

4 "1024x768"

5 "1280x1024"

6 "320x200"

7 "320x240"

8 "400x300"

9 "1152x864"

10 "1600x1200"

11 "1800x1400"

12 "512x384"

please type the digits corresponding to the modes that you want to select. for example, 432 selects "1024x768" "800x600" "640x480", with a default mode of 1024x768.

which modes?

자신이 원하는 컬러수에 대한 해상도를 설정하는 항목이다.

you can have a virtual screen (desktop), which is screen area that is larger than the physical screen and which is panned by moving the mouse to the edge of the screen. if you don't want virtual desktop at a certain resolution, you cannot have modes listed that are larger. each color depth can have a differently-sized virtual screen please answer the following question with either 'y' or 'n'.

do you want a virtual screen that is larger than the physical screen?

x 화면에서의 가상화면을 선택할 수 있도록 하는 항목이다. 가상화면을 사용하고 싶으면 yes 로 설정하고, 필요없으면 no 로 설정하고 넘어가기 바란다. 만일, yes 로 설정을 하였다면 다음과 같은 메세지가 나올 것이다.

for each depth, a list of modes (resolutions) is defined. the default resolution that the server will start-up with will be the first listed mode that can be supported by the monitor and card. currently it is set to:

"640x480" "800x600" "1024x768" "1280x1024" for 8bpp

"1280x1024" for 16bpp

"640x480" "800x600" "1024x768" "1280x1024" for 24bpp

"640x480" "800x600" "1024x768" for 32bpp

note that 16, 24 and 32bpp are only supported on a few configurations.

modes that cannot be supported due to monitor or clock constraints will

be automatically skipped by the server.

1 change the modes for 8pp (256 colors)

2 change the modes for 16bpp (32k/64k colors)

3 change the modes for 24bpp (24-bit color, packed pixel)

4 change the modes for 32bpp (24-bit color)

5 the modes are ok, continue.

enter your choice:

가상화면의 컬러수를 선택하는 부분인데, 자신이 선택하였던 컬러수와 같은 컬러수를 선택해야만 한다.

select modes from the following list:

1 "640x400"

2 "640x480"

3 "800x600"

4 "1024x768"

5 "1280x1024"

6 "320x200"

7 "320x240"

8 "400x300"

9 "1152x864"

10 "1600x1200"

11 "1800x1400"

12 "512x384"

please type the digits corresponding to the modes that you want to select.

for example, 432 selects "1024x768" "800x600" "640x480", with a

default mode of 1024x768.

which modes?

해상도를 설정하는 부분이다.

you can have a virtual screen (desktop), which is screen area that is larger than the physical screen and which is panned by moving the mouse to the edge of the screen. if you don't want virtual desktop at a certain resolution, you cannot have modes listed that are larger. each color depth can have a differently-sized virtual screen please answer the following question with either 'y' or 'n'.

do you want a virtual screen that is larger than the physical screen?

가상 화면을 이용할 것인가를 묻는 화면이다. 가상화면을 사용하고자 한다면 yes로 설정하면 되고, 그렇지 않다면 no로 설정하고 넘어가기 바란다.

for each depth, a list of modes (resolutions) is defined. the default resolution that the server will start-up with will be the first listed mode that can be supported by the monitor and card.

currently it is set to:

"640x480" "800x600" "1024x768" "1280x1024" for 8bpp

"1280x1024" for 16bpp

"640x480" "800x600" "1024x768" "1280x1024" for 24bpp

"640x480" "800x600" "1024x768" for 32bpp

note that 16, 24 and 32bpp are only supported on a few configurations.

modes that cannot be supported due to monitor or clock constraints will

be automatically skipped by the server.

1 change the modes for 8pp (256 colors)

2 change the modes for 16bpp (32k/64k colors)

3 change the modes for 24bpp (24-bit color, packed pixel)

4 change the modes for 32bpp (24-bit color)

5 the modes are ok, continue.

enter your choice:

컬러수와 해상도를 다 설정한 유저는 5번을 선택하고 다음으로 넘어가기 바란다.

i am going to write the xf86config file now. make sure you don't accidently overwrite a previously configured one. shall i write it to /etc/x11/xf86config?

지금까지의 x 설정을 /etc/x11/xf86config 파일에 저장을 할 것인지 묻는 항목이다. yes 로 설정하고 xf86config 를 마치면 x 설정은 끝나게 된다.

3. 리눅스 시스템의 기본 활용

1. 파일 다루기

어떤 운영체제를 사용하더라도 가장 먼저 배우게 되는 것이 아마도 파일의 복사와 이동, 저장, 생성 등에 관한 것일 것이다. 사실 리눅스에서 사용하는 기본 파일에 관한 명령어들은 유닉스 시스템에서 사용하는 명령어와 거의 다를바가 없기 때문에 유닉스 시스템을 경험해본 사람이라면 쉽게 이용할 수 있을 것이다. 여기서는 유닉스를 경험해보지 못한 초보 사용자를 위하여 리눅스에서 파일을 다루는 기본 명령어를 간단하게 살펴보고 몇가지 중요한 사항을 짚고 넘어가고자 한다.

% cd - directory를 이동합니다.

ex.) cd /usr/doc (절대경로)

cd usr (상대경로)

cd ~ (홈 디렉토리로 이동, 간단히 cd 라고만 입력해도 결과가 갈다.)

cd .. (상위 디렉토리로 이동)

cd / (루트 디렉토리로 이동)

*루트 디렉토리: /root 디렉토리가 아닌 최상위 디렉토리를 말한다.

*절대 경로: 루트 디렉토리부터 시작한 모든 경로

*상대 경로: 현재 디렉토리부터 시작한 경로

한가지 주의할 점은 ms-dos에서는 디렉토리의 경로명을 나타낼 때 \(역슬래쉬)를 사용하지만 리눅스의 경우 /(슬래쉬)를 사용한다는 것에 주의하기 바란다.

* 기타 디렉토리 관련 명령어

mkdir (디렉토리만들기), rmdir (디렉토리지우기), pwd(현재 위치를 보여준다.)

% ls - dos의 dir과 같은 명령어, 화일 혹은 디렉토리 정보를 출력합니다.

ex.) ls -l /usr (/usr directory의 내용을 상세히 출력합니다.)

기타 옵션: -f (파일의 속성 출력) -a (모든파일출력)

--color=yes,auto,no( 컬러 사용여부 선택)

% cp - 파일을 복사합니다.

ex.) cp ~/babo ~/babo2

% mv - 파일이나 디렉토리를 옮깁니다. 아래와 같이 파일의 이름을 바꾸기 위해서도 사용합니다.

ex.) mv ~/babo ~/babo2

% rm - 파일을 지웁니다.

ex.) rm ~/babo

% more - 주어진 파일의 내용을 한 페이지씩 보여줍니다.

ex.) ls /usr | more

* more 실행시 : b (한화면 뒤로) space bar (한화면 앞으로) q (종료)

여기서는 파이프를 사용하여 ls를 통한 표준 출력을 more에 표준 입력으로 보냈다.

이처럼 파이프를 통하여 여러개의 명령어를 조합해서 쓰는 것이 가능하다.

% cat - 표준입력으로 받아 표준출력으로 보낸다.

ex.) cat /etc/inittab

간단한 파일을 화면에 출력하거나 파일로 만들 때 자주 쓰인다.

ex.) cat > babo.txt babo.txt라는 텍스트파일 생성

cat < babo.txt babo.txt라는 파일의 내용을 화면에 보여준다.

% echo - 주어진 인수를 화면에 그대로 보여준다.

ex.) echo "hello world"

% grep - 주어진 파일 혹은 표준입력에서 특정 패턴에 맞는 줄을 출력합니다.

ex.) rpm -qa | grep hangul

% find - 파일을 검색한다.

ex.) find 경로명 -name 파일 이름

% touch - 파일의 수정일을 변경합니다.

ex.) touch babo (바보라는 파일의 날짜를 바꿉니다.)

% tr - 특정 문자열을 치환 한다.

ex.) tr babo notbabo < mylife

* mylife 라는 파일에 babo 라는 글자를 babo2 로 치환한다.

% df - 파일시스템의 정보를 보여줍니다. 현재 마운트되어 있는 모든 시스템에 대한 확인이 가능합니다.

* -h (메가바이트 단위로 출력한다.)

% du - 파일 혹은 디렉토리의 사용 공간을 출력합니다. 즉 각각의 파일들이 점유하고 있는 디스크의 용량을 표시합니다.

2. file permission의 변경

* 파일 퍼미션의 해석

---------------------------------

:속 성 : 소유자 : 그 룹 : 타 인 :

---------------------------------

: d : r w x : r w x : r w x :

---------------------------------

속성: d (디렉토리), l (링크), b (block device), c (character device)

% chmod - 파일 퍼미션을 변경합니다.

ex.) chmod u+rwx babo

chmod {a,u,g,o}{+,-}{r,w,x} 파일명

chmod 755 babo ( 4:read 2:write 1:excute )

3. 파일 링크하기

% ln - 파일이나 디렉토리를 링크합니다.

ex.) ln -s /dev/cua2 /dev/modem

% mount - 특정 file system을 특정 위치에 마운트 시킵니다.

ex.) mount -t iso9660 /dev/cdrom /mnt/cdrom

* umount ( 마운트를 해제합니다. )

4. 계정(account) 만들기

% adduser - 새로운 사용자 계정을 만듭니다.

ex.) adduser altair

% passwd - 패스워드를 새로 지정합니다.

ex.) passwd altair

5. 프로세스의 제어

% ps - 작동중인 프로세스를 출력합니다.

ex.) ps -x

% kill - 프로세스를 종료시킵니다.

ex.) kill %1

% bg, fg - 실행중인 작업을 각각 background, foreground로 전환합니다.

ex.) bg(fg) %1

6. 파일 묶고 압축하기

% tar - 여러개의 파일을 묶고 풀어줍니다.

ex.) tar cvf backup.tar /etc

tar xvf backup.tar

tar tvf backup.tar

% gzip - 파일을 압축하는데 사용합니다.

ex.) gzip -9 backup.tar

*gunzip (압축을 풀어줍니다.)

* 종합

% tar cvf - /etc | gzip -9c > backup.tar.gz

gunzip -c backup.tar.gz | tar xvf -

7. rpm의 설치 및 제거

% rpm -ivh <패키지명>

rpm -e <패키지명>

rpm -qa




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

mail

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가 네트웍에 연결이 되어 있다면 그것은 바로 해커의 먹이가 될 수 있다는 사실을 명심하기 바란다. 필자가 네트웍 관리자이기에 교내의 리눅스 박스가 부서지고 깨어지는 모습을 많이 보아왔다. 조금만 보안에 신경을 쓰면 됐을 것을 나중에 데이터가 깨지고 시스템이 망가지고 난 다음에 후회하는 모습을 많이 보아왔다 그래서 보안은 전제인 것이다. 바쁘더라도 최소한 랩퍼와 필요없는 데몬들은 죽이고 사용하시기를 간절히 부탁드린다. 그리고 문제가 생기면 관리자에게 꼭꼭 연락하는 습관을 가지기 바란다. 이상으로 조금은 지루한 보안을 얘기 했다.

내게 할당되어진 원고를 넘은지도 벌써 엄청 흘렀다. 늦게 원고를 보낸것도 미안한데 이렇게 민폐까지 끼치다니 정말 미안할 따름이다. 허나, 모두를 위한 일이라는 믿음으로 이해해 주리라 믿는다.
























5. play with linuxconf !!! - 서강리눅스 유저그룹 노태영

이 문서에 대한 질문은 teguri@slug.sogang.ac.kr 로 해주시길... 이 문서는 알짜 6.0 배포판에 깔려 있는 gnome-linuxconf 1.14 를 기준으로 설명합니다.

1. 들어가며 - linuxconf 란?

linuxconf 는 리눅스 운영체계의 복잡한 설정파일들을 한 곳에 모아, 시스템 관리자들이 쉽고 빠르게 서버의 전체 설정을 할 수 있게 하기 위하여 만들어진 프로그램이다. 그러나 리눅스의 사용자가 증가하고 사용자층이 시스템 관리자 뿐 아니라 일반사용자들까지 확대됨에 따라, 주요한 유틸리티로 자리매김할 전망이다.

알짜 레드햇 6.0 판에 포함된 버전은 1.14이고 최신 버전은 1.16r3 로 다운로드 하려면

http://www.solucorp.qc.ca/linuxconf/download.hc 로 가면 된다.

2. linuxconf 의 인터페이스 :

linuxconf 의 user interface 에는 4가지가 있고 이중 3가지는 완료된 상태이다.

- 택스트 기반

: x 윈도우 시스템 하가 아닐 때 콘솔 상에서 동작하는 인터 페이스이다. 외부에서 telnet 등으로 접속했을시 유용하게 사용할 수 있다.

- 웹 인터페이스

: 관리자가 웹을 통해서 원격으로 서버 관리를 할 수 있도록 만든 인터페이스이다. 자세한 것은 linuxconf홈페이지 (http://www.solucorp.qc.ca/linuxconf/) 를 참조하라.

- 그래픽 인터페이스

: gui 는 두가지 방식으로 만들어졌는데 하나는 자바 언어로 씌여져 브라우저에서 사용되는 것이고 하나는 x 윈도우 시스템에서 동작하도록 만들어진 것이다. 우리가 오늘 공부하고자 하는 gnome linuxconf가 후자에 속한다.

- 명령어 방식

: 콘솔상에서 명령어로 입력된다.

linuxconf --help 해보면 그 전모를 알 수 있다.

3. linuxconf 활용

linuxconf는 오른쪽 그림과 같은 메뉴들을 가지고 있다.

그러나 이 중에서 초보자들이 자주 쓸만한 것은 많지가 않다. 아래에서는 지면관계상 모든 메뉴들을 설명할 수 없기 때문에, 초보자들에 맞는 메뉴만을 중심으로 설명하도록 하겠다.

3.1. 네트웍 관련 설정

먼저 리눅스 박스로 할 수 있는 일중 가장 흥미로운 부분인 네트워크 관련 설정이 눈에 띈다. 네트웍 관련 설정은 클라이언트쪽의 설정과 서버쪽의 설정 두가지로 나뉘어 있다.

3.1.1. tcp/ip 관련 설정 (config-networking-clienttask-basichostinformation)

- 왼쪽의 그림과 같이 자신의 시스템에 맞는 호스트 네임을 입력한 후,

- adoptor 택을 선택하여

 

 

,

- 각각의 랜카드에 맞는 ip 설정을 해준다.

(랜카드는 네 개까지 설정이 가능하다. )

- enabled 에 체크되어 있는지 확인 하고,

- config mode를 선택하고

(거의 대부분의 경우 manual을 선택해야 한다. dhcp와 bootp는 서로 짝이되어 서버가 클라이언트에 동적으로 ip를 할당해주는 프로토콜이다. 이에 대해 자세한 것은 kldp 사이트의 네트워크 부분을 참조하라.)

- 그리고 primary name + domain에 호스트네임을 써 주고,

- ip 어드레스를 입력하고

- 디바이스명을 선택하고 (랜카드가 하나인 시스템의 경우, eth0 라고 하면 무방하다.)

- kernel module 부분은 네트웍 디바이스의 제품명과 동일한, 혹은 호환되는 모듈명을 선택해 주면 된다.

<위의 설정은 kernelcfg로 렌카드를 인식시키고 netcfg로 네트웍 관련 설정을 하는 것과 동일한 효과를 낼수 있다.>

[ 관련 설정 파일 : /etc/hostname , /etc/hosts , /etc/sysconfig/network ]

3.1.2. 도메인 네임서버 설정

(config-networking-clienttask-nameserverspecification)

- 도메인 네임 서버란 글자로 되어있는 도메인 네임으로 원래의 ip 넘버를 찾아내어 긴 숫자를 입력하지 않고도 원하는 곳에 연결할 수 있도록 해준다.

- 그러므로 자신이 가입한 isp 의 도메인 네임서버의 주소를 알아서 입력해 두어야만 긴 ip 넘버를 기억해야 하는 수고를 덜 수 있다.

- 시스템이 물려있는 isp의 도메인서버의 ip number를 왼쪽의 그림과 같이 써주면 된다.

<이 부분도 netcfg/names로 가능하다.>

[ 관련 설정 파일 /etc/resolv.conf ]

 

 

 

3.1.3. 라우팅 설정

라우팅에는 5가지 메뉴가 있지만 고쳐 주어야할 부분은 많지 않다. 게이트웨이만 설정하면 된다. 물론 초보자가 아닌 관리자의 경우는 알아야 하겠지만 ...

게이트웨이 설정은

network-clienttask-routingandgateway-default 부분에서 할 수 있다.

- 오른쪽 위그림에서 defaultgateway에 알맞는 게이트웨이 주소를 적어주고 라우팅 가능 옵션은 그대로 둔다.

<마찬가지로 이부분도 netcfg로 할 수 있다.>

3.1.4. nis(network information system)

nis는 네트워크에 물린 시스템들 사이에 정보를 공유하기 위한 시스템이다. nis server에서 사용자 계정/패스워드/홈디렉토리/그룹정보 등을 가지고 있으면 nis client설정이 되어 있는 컴퓨터에서 똑같은 계정과 패스워드로 로그인 할 수 있고 server와 동일한 정보를 공유할 수 있다. 이는 서버의 데이터베이스에 담겨 있는 정보를 클라이언트들이 계속해서 가져오고 갱신함으로써 가능해진다. linuxconf에서 nis 설정을 하려면

network-clienttask-networkinformationsystem에서 하면된다.

필자도 nis를 직접 해본 적이 없어서 상세한 설명을 적고 싶지만 여기서... 죄송...

[ 관련 설정 파일 : /etc/yp.conf , /etc/ypserv.conf ]

3.1.5. ppp 연결 설정

클라이언트에서 전화접속을 통해 가상적으로 tcp/ip 연결이 가능하게 해 준다. 여러분이 ppp 서비스를 제공하는 isp를 이용하고 있다면 linuxconf에서 다음의 메뉴를 조정하여 ppp 연결을 자동화 할 수 있다.

network-clienttask-ppp/slip/plip 메뉴룰 실행하면 다음과 같은 메뉴가 뜬다.

- 아무 설정도 하지 않은 상태에선 당연히 비어 있다.

- add를 누르면, 오른쪽의 선택화면이 나타난다.

- ppp를 선택하고 accept 하면 아래의 화면이 나타나는데, 연결할 전화번호와 모뎀 포트를 적어 넣고,

- 그 아래 있는 pap authentification 항목은 아이디와 패스워드를 연결시에 묻지않고 자동적으로 처리해 주는 방식이다.

- costomize를 선택하면 모뎀과 관련한 자세한 설정을 할 수 있다. 모든 설정이 끝나면 accept를 누른다.

<ppp 설정도 netcfg 명령으로 동일하게 실행할 수 있다.>

[ 관련 설정 파일 : /etc/ppp/* ]

지금 부터는 서버 측면의 네트워트 설정 메뉴들이다. 아직까지 많은 부분에 있어서 완성되지 않은 메뉴들을 가지고 있지만 서버를 운영하는 관리자라면 관심을 가지고 지켜볼만하다.

3.1.6. dns server 운영 (network-servertask-domainnameserver)

dns는 앞서 말한 바와 같이 도메인네임과 ip 넘버를 이어주는 역할을 하는 서버이다. 그러나 많은 수의 클라이언트를 가진 네트워크 운영자가 아니라면 사실 dns를 운영할 이유가 없을 것이다. isp나 대학, 대기업 등의 대규모 네트워크의 dns를 이용하면 되기 때문이다. 그러나 혹시 도전해 보고픈 마음이 생기는 분이 있다면 dns howto 등의 문서를 살펴본 후, linuxconf를 이용할 수 있다. linuxconf에 많은 관련 메뉴를 찾아볼 수 있을 것이다.

3.1.7. nfs server

윈도우에 익숙한 사용자라면 "공유"라고 설명할 수 있는 것이겠다. 한 시스템의 파일을 다른 시스템에서 마운트하여 사용할 수 있도록 만들어 준다.

아래의 그림은 network-servertask-exportedfilesystem을 선택한 후, add를 클릭하면 나오는 상자로 공유할 서버와 클라이언트, 그리고 권한을 설정할 수 있는 메뉴가 있다.

- path to export에 공유할 디렉토리명을 적고,

- client name에 클라이언트의 주소를 써준 후,

- 쓰기, root 권한등의 옵션을 체크해 준다음

- 시스템을 재부팅하거나 nfs 서버데몬인 rcp.nfsd 와 rcp.mountd를 재실행한다.

- 그림에는 하나의 클라이언트만을 정해주는 것처럼 보이지만 여러개를 설정할 수가 있다.

- 그리고 나서 위에 정해준 클라이언트에서 mount -t nfs slug3:/home /mountpoint 와 같이 하면 된다.

[ 관련 설정 파일 : /etc/exports ]

3.1.8. ip aliasing(network-servertask-ipaliasesforvirtualhost)

하나의 렌카드가 설치된 시스템에서 여러개의 ip를 써서 virtual hosting을 하고 싶을 때 사용한다.

3.1.9. apache web server 운영

아파치 서버 설정 메뉴를 실행하면 몇가지 에러가 발생하는 것을 볼수 있다. 걱정하지는 말라. 여러분의 문제가 아니라 아마도 아직까지 아파치 서버의 설정파일을 완벽히 linuxconf에서 읽어내지 못하는 때문으로 보인다.

그러나 그런 에러메세지에 대해 ok 버튼으로 몇번만 응수해 주면, 아파치 설정파일을 그대로 옮겨 놓은 linuxconf의 모양을 볼수 있다. 물론 몇가지 빠진 것들이 있기는 하다. 아파치 설정에 관해 여기서 깊게 다루는 것은 강의의 목적에 맞지 않을지도 모르나, 기본적인 것들에 대해 소개하면 다음과 같다.

- listen on port: 웹서버의 포트 번호를 설정한다.

- hostname lookups: 선택된 경우, n 로그파일에 dns lookup 하여 호스트네임으로 기록한다.

- administrator email : 웹서버 관리자 e-mail 주소 기입

- errorlog: error 로그가 기록될 파일의 경로

- transferlog: 웹서버 접근에 대한 모든 기록을 남길 경로

- pidfile: 서버의 process id 를 기록할 파일

- timeout: 클라이언트 요청에 서버가 기다려야 할 시간 (초단위)

- minimum(maximum) of spare servers: 각 클라이언트의 접속에 대해 생성되는 서버의 최소수와 최대수

- startservers: 서버 시작시에 동작할 서버의 개수를 나타낸다.

- maxclients: 웹 서버에 접근할수 있는 클라이언트 개수를 제한

- cgi script alias: cgi 스크립트가 있을 디렉토리 경로

- serversideincludes: 체크하면 ssi 실행이 허용된다.

- includesnoexec: ssi 명령 중 몇가지를 제외하고 허용.

- may excute cgi: cgi 실행을 가능하게 한다.

- may follow symlinks: 심볼릭 링크를 가능하게 한다.

linuxconf 에서는 virtual web server 설정도 할 수 있으며, 각 디렉토리마다 다른 옵션을 적용해 줄 수도 있다.

< comanche라는 아주 잼있는 gui 아파치 설정 파일도 나와 있으니 꼭 살펴보도록 하자. >

[ 실제 아파치 서버 설정파일에는 이보다 더 많은 옵션들을 정해줄 수 있다.

아파치 서버 설정 파일은 알짜 6.0 배포판 기준으로

/etc/httpd/conf/httpd.conf 에 하나로 합쳐져 있다. ]

3.2 사용자 계정 설정

사용자 계정 설정은 네부분으로 이루어져 있는데, 기본 사용자설정, 특수사용자설정, 이메일 alias, 사용자 정책이 그것이다.

3.2.1. 기본 사용자설정 (config-useraccount-normal)

기본 사용자 설정에서는 사용자들의 정보, 권한, 메일 alias 등을 변경하거나, 사용자를 추가/삭제 하고 루트아이디의 패스워드를 변경하는 부분이 있다. 이 부분은 상당히 직관적으로 되어 있으므로 자세한 설명은 하지 않겠다.

 

 

 

 

 

 

 

 

다만 뭐가 있는지만 보자.

- 왼쪽의 그림은 현재 사용자들의 리스트이다.

- 각각의 사용자를 클릭하면 상세정보를 볼 수 있고

- add를 클릭하면 새로운 사용자를 등록할 수 있는 폼이 생긴다.

- 왼쪽그림은 사용자 상세정보이다. < comanche라는 아주 잼있는 gui 아파치 설정 파일도 나와 있으니 꼭 살펴보도록 하자. >

- base info엔 아이디와 그룹, 홈디렉토리, 셸 종류등이 선택된다.

- param엔 사용자 계정 만기 일자 등을 정할 수 잇는데.. 특수한 경우 아니면 건들 필요가 없다.

- mail aliases에서는 메일 포워딩과 aliasing을 할 수 있다.

- privileges 에서는 기본 사용자에게 주어지지 않는 특수한 권한을 지정할 수가 있다.

- 마찬가지로 그룹정보도 왼쪽과 같은 화면으로 볼수가 있고 상세정보와 추가, 삭제가 가능하다.

마지막으로 아래그림과 같이 루트 패스워드도 고칠 수 있다.




[ 관련 설정 파일 : /etc/passwd , /etc/shadow ]

3.2.2. 특수 사용자설정 (config-useraccount-specialaccounts)

기본 사용자 이외에 ppp, slip, uucp, pop3(mail only) 사용자를 설정해 줄 수가 있다.

3.2.3. email aliases

(config-useraccount-emailaliases)

이 기능은 메일링 리스트를 만들고자 할 때 유용하게 이용될 수 있다.

add를 클릭하면 오른쪽과 같이 나오는데, alias 이름을 적고 리스트파일을 적어준다. 그리고 나서 slug-list 앞으로 메일을 보내면, 리스트 파일에 적혀 있는 메일 주소들로 각각 메일이 보내진다.

[ 관련 설정 파일 : /etc/aliases ]

3.2.4. 사용자 정책 (config-useraccount-policies)

다중 사용자가 가능한 리눅스에서 공통적으로 적용되는 사용자 정책이 필요하다. 이 메뉴에서는 패스워드 관련 정책, 사용자 홈 디렉토리, 퍼미션, 셸 추가 등등을 할 수가 있다. message of the day 항목을 건드려 보라... 로그인 할 때 메시지를 띄울수 있다.

[ 관련 설정 파일 : /etc/shells , /etc/motd , /etc/default/useradd ]

3.3. file system (config-filesystem)

파일시스템과 관련된 부분이다. 장치를 마운트 할 수 있으며 각각의 장치에 따라 옵션을 부여할 수 있다.

각각의 드라이브를 선택하면 세부사항이 나타나고 옵션을 바꿀 수 있다. 물론 추가도 가능하다. nfs 드리이브도 마운트시키는 메뉴가 있다. set qouta default 메뉴에서는 사용자계정 공간의 한계를 설정할 수도 있다.

[ 관련 설정 파일 : /etc/fstab, /etc/mtab ]

3.4. 초기 run level 설정 (config-miscellaneousservices-initialsystemservice)

리눅스에는 run level이 일곱 가지가 있는데, 각각은 다음과 같다.

0 - halt

1 - 단일사용자모드

2 - nfs를 제외한 다중사용자모드

3 - 완전한 다중사용자모드

4 - 사용되지 않음

5 - x 윈도우

6 - reboot

이 일곱가지중 다섯까지(1-5)를 디폴트로 사용할 수 있는데, 그 선택을 linuxconf에서 할 수 있다.

< tksysv 라는 명령으로 run level을 더욱 자세하게 편집할 수 있다. >

[ 관련 설정 파일 : /etc/inittab ]

3.5. lilo 관련 설정 (config-bootmode-lilo)

왼쪽 그림에서 보이듯이, lilo 관련 설정을 할 수 있다. 부팅 시의 옵션 변경과 부트 섹터, 암호걸기 등이 가능하다.

이것 외에도 다른 파티션에 윈도우를 설치했을 때의 설정 메뉴와 새로운 커널을 컴파일하여 그 커널로 부팅 시키는 메뉴도 있다.

[ 관련설정 파일 : /etc/lilo.conf ]

3.6. 그외의 것들

나머지 것들은 다 자잘한 메뉴들이다. 한번 쭉 튐어 보기만 한다.

3.6.1. shutdown/reboot (control-controlpanel-shutdown/reboot)

linuxconf에서 shutdown 과 reboot을 실행할 수가 있다. 그러나 별 쓸모가 있나 싶다.

3.6.2. cron 등록 (control-controlpanel-configuresuperuserschedule)

일정한 시간마다 백업 등의 작업을 자동으로 실행하도록 해놓는 것이 cron이다.

[ 관련 설정 파일 : /etc/crontab ]

3.6.3. 리눅스 설정파일 리스트를 보고 싶다면

(control-controlfilesandsystem-configureallconfigurationfile)

3.6.4. 여러개의 시스템 설정을 만들어 두고프다면 ?

(control-controlfilesandsystem-configuresystemprofile)

3.6.5. 시간과 날짜 고치기 (control-dateandtime) ^^;

< timetool 이라는 것을 써도 동일한 기능을 할 수 있다. >

3.6.6. 키보드 셋과 색깔... (control-features)

[ 관련 설정 파일 : /etc/sysconfig/keyboard ]

이상으로 linuxconf 의 메뉴들을 살펴보았다. 아직은 작성되지 않은채로 남아 있는 부분도 있고, 불안정한 부분들도 있지만, 매력적인 프로그램임에는 틀림이 없는 것 같다. 좀더 사용자에게 필요한 기능들을 추가시키고, 성능을 개선 시킨다면 하는 마음으로 최신 버전을 다운 받아 설치해보고 발전한 점을 소개하는 것으로 이 강의록을 마칠까 한다.

4. linuxconf 최신버전 맛보기

4.1. 구하기 : linuxconf 최신 버전은 1.16r3 로 다운로드 하려면

http://www.solucorp.qc.ca/linuxconf/download.hc 에 가면 된다.

그곳에서 redhat 6.0을 클릭하고 rpm 파일을 다운 받자.

4.2. 설치하기 : 설치 과정은 매우 쉽다.

rpm -uvh linuxconf-1.16r3-1.i386.rpm 명령으로 설치하라.

4.3. 살펴보기

- 악 !!! 한글화가 되었다... 약간 어설프긴 하지만 도움말 파일까지 한글화가 되었다.

- 네트워크 서버태스크에 삼바와 센드메일 관련 설정이 완성되었다.

(스팸메일 방지 설정도 있네요.)

- 아파치 관련 메뉴가 더 늘었다. (모듈과 ssi 관련)

- 방화벽 관련 설정이 생겼다.

- 시스템 상황보기 메뉴가 생겼다.

- 이외에도 많은 부분의 소소한 것들이 고쳐졌다.

- 근데 아무래도 전보다 시스템 자원을 많이 먹는다.

4.4. 마지막으로 그림을 보면서 이 강의록을 마칠까 합니다

다음장은 linuxconf 최신버전 캡쳐화면입니다.




그럼 이만 강의를 마칩니다. 끝까지 들어주셔서 감사합니다. 다음번 공동체 세미나때도 다시 linuxconf를 붙잡게 될 것 같다는 강 한 예감을 느끼면서...




6. 참고자료

쌍용정보통신 네트웍 자료

한국정보보호센타 사례집

7. 후기.

처음에 계획하였던 초보자를 위한 강의가 원고를 쓰다보니 네트웍과 보안에 너무 많이 할애되어서 결론적으로 제대로 기술하지도 못했다.(지면의 문제도 많이 있었지만.). 혹, 그런 강의를 듣고자 왔던 리눅서 였다면 이 자리에서 정말 미안함을 전하고 싶다.

그러나 조만간 준비했던 나머지 자료들도 세미나 홈에 등록을 할테니 그 점을 감안하시고 너그럽게 이해해 주시기를 바란다. 질문 또한 언제든지 기꺼운 마음으로 응할 용의가 있으니까.

갑자기 한꺼번에 여러 가지의 일들이 겹치는 바람에 원고를 쓸 시간이 너무 없었다. 그래서 며칠을 밤새고 이제서야 원고를 마무리한다. 이건 다 게으름에 대한 대가라고 생각한다.

다음번 세미나때는 정말 미리미리 준비를 할 수 있도록 해야 할 것 같다. 그리고 내용 또한 보다 리눅스적인 것을 가지고 강의를 할 생각이다. 지금처럼 딱딱하고 재미없는 얘기들이 아니라.

별것이 아닌 내용을 쓰면서 너무 말이 많은 것 같지만 그래도 나의 이 작업에 도움을 준 많은 사랑하는 이들이 있다. 그들에게 고마움을 전하고 싶다. ^.^ ............

슬러그의 대표이자 레드햇 리눅스 완벽가이드의 저자인 사랑하는 아우 창훈이와 이쁜 웹팀의 기둥 태구리(고맙다 태구라!) 그리고 설치에 대한 부분을 작업해준 착한 현미녹차 종근이, 랩과 유머가 가득한 하워드 형국,생활 전선에서 열심히 살고 있는 홍권이,도균 세미나 장소 관계로 고생한 경호 그리고 보기만 해도 든든한 호민,이쁜뽀,버그종민,욱규,호철,지웅,영근,용호,서영,근호,준형 그외의 우리 이쁜 슬러그의 아우들과 solux의 성미,경란,승미,미경,영남,경화,효정 그외의 숙대 친구들 모두에게 고마움을 전한다.

그리고 언제나 고마운 나의 사수이자 시스템 관리자의 자세를 일깨워준 김추곤 선생님과 사수를 잘못 만난 덕에 고생만 하는 효철과 신환에게도 고마움을 전한다.-철아 진심으로 결혼 축하한다. 행복하게 살아라!!! ^.^.............

언제나 든든한 나의 동료 제훈씨와 불란서에서 수도 생활을 하고 계실 꼴베 수사님에게도 안부와 함께 고마움을 전하고 싶다.

아울러 끝까지 원고를 기다려준 너무나 착하고 순진한 청년 아트실리 상현이와 낙엽 상완, 이전도사님,공동체 회장 송영휴씨,고생하고 계실 김기태씨에게도 진정 고마움을 전한다.

끝으로 내가 정말 사랑하는 이세상 무엇과도 바꿀수 없는 나의 아내 금원과 원고 쓴다고 제대로 놀아주지도 못한 나의 사랑하는 아들 최영과 세린이에게 아빠의 사랑을 전한다.

최후로 나를 새로운 세상으로 이끈 리눅스와 리눅스를 사랑하게 만든 gnu 정신의 발원지인 자유소프트웨어 재단에게 감사를 드린다.