달력

62020  이전 다음

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  
  •  

리눅스 2.6의 멋진 세상

Joseph Pranevich - jpranevich AT kniggit.net

Translated by Nate Park (박종구) - youlsa AT i-on.net

첫번째 2.4 시스템이 부팅한 것이 엊그제 같은데 시간은 어느덧 흘러 리눅스 2.6이 세상에 나오게 되었다. 이 문서는 i386 플랫폼을 중심으로 리눅스 커널 2.6의 전반적인 면에 대한 설명을 위한 문서이다. 여기에 설명하는 새로운 기능들 중 몇몇은 공식적으로 또는 배포판 관리자들에 의해 커널 2.4로 백포팅(back-porting)된것도 있을 것이다. 그 외에도 커널 2.4의 유지보수 과정에서 추가된 기능들에 대한 설명도 함께 하도록 하겠다.

현재 이 문서는 10여개의 언어에 대한 번역문서가 존재하며 문서의 제일 아랫쪽을 참조해주기 바란다.

지금까지의 이야기들...

리눅스 커널은 리누스 토르발즈가 그의 386 컴퓨터에서 실행가능한 미닉스(minix)와 비슷한 운영체제를 만들기 시작한데서 시작되었다. (처음에 리누스는 운영체제의 이름을 Freax라고 짓고 싶었다고 한다) 싱글 CPU의 i386머신에서만 실행 가능한 리눅스 커널 1.0의 공식 릴리즈는 1994년 3월이었다. 그로부터 1년 후인 1995년 3월에 최초로 i386이 아닌 플랫폼에서 실행가능한 (그러나 여전히 싱글 CPU에서만 동작하는)리눅스 1.2가 릴리즈 되었다. 1996년 6월에 리눅스 2.0이 릴리즈 되었다. 2.0에는 동작 가능한 여러 플랫폼이 추가 되었지만 무엇보다도 다중 CPU를 갖는 머신(SMP)에서 동작하는 최초의 버전이었다. 2.0의 릴리즈 이후 주요 버전의 릴리즈 속도는 다소 늦춰졌다. (리눅스 2.2가 1999년 1월, 2.4가 2001년 1월에 각각 릴리즈 되었다) 하지만 각각의 마이너 버전업은 자주 일어나 지원되는 하드웨어의 범위와 확장성이 개선되어 갔다. (리눅스 2.4는 최초로 ISA 플러그앤 플래이와 USB, PC 카드 등의 기능이 추가되어 최초로 사용자들의 데스크탑에서 쓸만한 버전이었다는 점도 주목할만 하다) 리눅스 2.6은 2003년 12월 17일에 릴리즈 되었다. 2.6은 다양한 추가 기능도 기능이지만 매우 대용량 시스템에서부터 아주 작은 시스템(PDA등)까지 고루 지원한다는 점에 있어서 또 한번의 큰 개선버전이기도 하다.

핵심 하드웨어 지원

리눅스의 가장 강력한 점 중 하나는 그 유연성과 지원 하드웨어의 광범위함에 있다. 이 문서는 i386 기반의 PC에서의 사용에 중점을 맞추고 있기는 하지만 리눅스 2.6의 뛰어난 하드웨어 지원은 짚고 넘어갈만 하다.

축소 - 임베디드 시스템을 위한 리눅스

리눅스 커널 2.6의 중요한 두가지 변화 중 하나는 유씨리눅스(uClinux) 프로젝트를 메인 커널에 병합했다는 것이다. 유씨리눅스 프로젝트는 마이크로 콘트롤러를 위한 리눅스를 제작하는 프로젝트이다. 유씨리눅스는 이미 임베디드 시장에서는 주요 OS중 하나로 인정받고 있기 때문에 메인 커널에 이를 병합 하는 것은 앞으로의 임베디드 시장에서 리눅스의 발전에도 큰 힘이 된다고 볼 수 있다. 일반적인 리눅스 커널과는 달리 임베디드 플랫폼에 사용되는 리눅스 커널은 하드웨어적 제약 때문에 몇가지 제한이 있게 된다. 가장 중요한 점 하나는 MMU(메모리 관리 유닛 - 프로텍티드 모드의 핵심적 기능을 한다)가 없다는 것이다. 물론 그래도 멀티태스킹 운영체제이기는 하다. (메모리 관리 기능이 없을 경우 한 프로세스가 다른 프로세스의 데이타 영역에서 자료를 읽고 쓰거나 심지어는 프로세스 자체를 망가뜨릴 수도 있다) 하지만 이런 경우 멀티 유저 시스템을 구성하기가 곤란해지지만 PDA와 같은 저가형 소형 디바이스들의 경우에는 훌륭한 선택일 수도 있다. 이런 아키텍쳐 변화가 중요한 것은 2.6 이전까지의 리눅스 커널은 사실상 리누스의 초기 작업들이 수행된 인텔 80386 플랫폼의 영향이 상당히 많이 남아 있었다는 점 때문이다.

리눅스 커널 2.6에서 히타치 H8/300시리즈, NEC v850, 모토롤라의 m68k 임베디드 프로세서 등이 추가적으로 지원되기 시작했다. 보통 리눅스 사용자들이 처음으로 사용하는 PDA가 팜 파일럿 계열인 경우가 많기 때문에 모토롤라의 프로세서들은 어느 정도 친숙할 것이다. 모토롤라나 Lineo, Arcturus등의 Dragonball, Cold Fire같은 제품들이 지원된다. 슬프게도 MMU가 없는 예전의 m68k 계열의 CPU들은 지원되지 않는다. (올드맥에 사용되는 CPU이다) 누군가가 취미 프로젝트로 오래된 머신들에 리눅스를 포팅하는 프로젝트를 시작할 수도 있을 것이다.

유씨 리눅스 통합의 일부는 아니지만 리눅스 커널 2.6에는 Axis Communications의 ETRAX CRIS(Code Reduced Instruction Set)가 지원된다. (사실 이 기능은 2.4 릴리즈 이후 유지보수의 과정에서 추가되었다) 이것들은 주로 네트웍 하드웨어에 사용되는 MMU가 포함된 임베디드 프로세서이다. MMU가 포함되지 않은 프로세서에 대한 지원도 외부 프로젝트로 수행되고 있는 것으로 안다.

하드웨어 지원에 덧붙여 메인 커널에 임베디드에 관한 부분을 통합하여 얻게 된 이점들이 여러가지가 있지만 겉으로 보기에는 특별해 보이지는 않지만, 몇몇 변화사항들, 예컨데 스왑 없이도 시스템을 구성할 수 있는 능력 등등이 커널을 더욱 견고하게 만든 점등이 있을 수 있다.

대규모로 -- NUMA와 대규모 기계들

리눅스 커널 2.6의 근본적인 두가지 변화 중 나머지 하나는 아이러니하게도 앞의 것과 정반대 방향으로의 확장이다. 리눅스가 더욱 더 대규모 서버에서 사용 가능하도록 하는 방향이다. (큰 시스템들 중 어떤 시스템은 i386 기반이겠지만 어떤 것은 아니다) 이 방향에서의 리눅스의 가장 큰 변화는 NUMA 서버의 지원이다. NUMA(Non-Uniform Memory Access)의 지원은 멀티 프로세싱에 있어서 SMP에서 한걸음 더 나아간 것으로 많은 CPU를 가진 시스템에서 좀 더 효율적으로 동작할 수 있게 해주는 첫걸음이라고 할 수 있다. 다중 CPU 서버에서는 단일 메모리 버스에 여러개의 CPU들이 동시에 억세스를 하게 되는데 여기에서 병목현상이 발생하게 된다. NUMA 서버에서는 이런 문제를 각각의 CPU에게 다른 메모리보다 가까운 메모리를 지정해주도록 함으로써 해결한다. 기술적으로 정확한 표현은 아니지만, 이렇게 상상하면 쉽다. 시스템이 여러장의 카드로 이루어 졌다고 상상해보자. 각각의 카드들은 각각 자신만의 CPU와 메모리, 입출력 장치들을 가지고 있다. 시스템에 이런 카드들이 많이 있다고 생각하면 각각의 CPU는 (물론 다른 카드의 메모리와 통신을 할수도 있겠지만) 자신과 같은 카드에 있는 메모리가 가장 가깝고 속도도 빠를 것이다. NUMA 아키텍쳐는 이런 식으로 타이트하게 구성된 클러스터라고 생각할 수 있다.

이런 NUMA 머신들을 효율적으로 지원하기 위해 리눅스 커널에서는 몇가지 개선사항을 도입하였다. 우선, 리눅스 커널 내부에서 각각의 프로세서와 메모리들, 입출력 장치들의 관계를 알아낼 수 있도록 위상(topology) API들이 추가되었다. 이를 기반으로 커널의 프로세스 스케쥴러는 최대한 효율적으로 가까운 리소스가 어떤 것인지를 이해하고 활용할 수 있게 된다. 추가적으로 많은 NUMA 머신들은 각 노드가 차지하고 있는 메모리 사이에 구멍이 뚫리도록(어드레스 공간이 연속적이 않다는 뜻) 구현되어 있는데 리눅스 커널에서는 이런 비연속적인 메모리도 제대로 다룰 수 있다. 여기에 언급한 것들 말고도 리눅스 커널에는 대용량의 서버들을 제대로 지원할 수 있는 여러가지 개선사항들이 개선되었고 앞으로도 더욱 많은 개선이 있을 것이다.

서브 아키텍쳐(subarchitecture) 지원

앞서의 두가지 변화사항만큼 큰 변화는 아니지만 리눅스 커널의 새 버전에는 더욱 많은 머신에서 리눅스를 실행시킬 수 있도록 해주는 서브 아키텍쳐(subarchitecture)라는 개념이 구현되었다. 이전 버전까지의 리눅스 커널에서는 CPU의 종류와 아키텍쳐의 종류가 일치한다고 가정해왔다. 예를 들어 CPU가 i386이라면 무조건 PC/AT 아키텍쳐 기반의 PC라고 가정을 했던 것이다. 리눅스 2.4에서 이러한 가정이 깨졌는데 SGI의 Visual Workstation때문이었다. CPU만 인텔의 칩이였고 아키텍쳐가 PC와는 완연히 다른 기계이다. (물론 다른 아키텍쳐에서는 그 전에도 이 가정이 깨지긴 했다. m68k 아키텍쳐에서 Amiga, 매킨토시 등이 동시에 지원되는 등의 예가 있었다.) 하지만 리눅스 커널 2.6에서의 큰 변화는 모든 아키텍쳐에 대해 동일한 방법으로 서브 아키텍쳐를 지원할 수 있도록 표준화 되었다는 것이다.

이런 표준화 덕분에 i386에서도 두개의 새로운 플랫폼이 추가 지원된다. 첫번째는 NCR의 Voyager 아키텍쳐이다. 이것은 32개까지의 486-686 CPU를 지원하는 SMP 시스템이다 (현재의 표준인 인텔 MP 스펙이 나오기 전에 나온 시스템이다). 실제 판매된 갯수는 그리 많지 않고 판매된 모든 기계가 지원되는 것은 아니다. (최초에 판매된 머신들은 지원되지 않는다) 새로 추가된 두번째 플랫폼은 NEC가 개발하여 비교적 최근까지 일본 시장에서 독점적 위치를 차지하고 있던 PC-9800이다. PC-9800은 8086에서 시작하여 펜티엄급과 SMP까지 지원되던 성숙한 플랫폼이었다. (물론 리눅스 커널은 80386이상의 머신에서만 동작한다) 미국에는 전혀 소개되지 않았지만 마이크로 소프트의 윈도우 95까지 이 머신에서 동작하도록 포팅되어 판매된 바 있다. 하지만 그 이후에는 표준 PC가 그 자리를 대치해가고 결국 단종되었다.

이런 "약간만 다른" 하드웨어 타입들을 지원할 수 있는 구조 덕분에 앞으로 스토리지 기기라던가 유명 CPU를 사용하는 머신들에 대한 지원이 손쉬워졌다. 하지만 이것이 만능은 아니다. 이런 서브 아키텍쳐는 IRQ 라우팅과 같이 하드웨어의 최하위 레벨의 콤포넌트가 다른 점을 커버하기 위해서 나온 것이다. PC와 거의 동일하지만 아주 약간만 다른 엑스박스에서 리눅스를 돌리는 것과는 다르다는 점을 명심해야 한다.

하이퍼쓰레딩

리눅스 커널 2.6에서의 또다른 큰 진보 중 하나는 하이퍼 쓰레딩의 지원이다. 하이퍼 쓰레딩은 현재 최신 펜티엄 4에서만 지원되고 있으나 다른 곳에서도 지원할 수 있을것이다. 하드웨어 적으로 하나의 CPU를 두개나 그 이상의 CPU로 보이도록 해주는 기술이다. 이것은 어떤 경우에는 큰 퍼포먼스 향상을 불러오지만 스케쥴링의 복잡성이 증가하는 원인이 되기도 한다. 커널의 개선사항중 하나는 이제는 커널이 전 CPU(실제이건 가상이건)에 걸쳐 부하를 분산하고 최적화를 할 수 있다는 점이다. 이전 버전의 리눅스 커널에서는 전체적인 부하를 계산할 수 없어서 한개의 CPU가 혹사당하는 일이 잦았었다. 대단한 점은 리눅스 커널이 시장에서 이 기능을 제일 깔끔하고 지능적으로 지원하고 있다는 점이다. (윈도우 2000 서버는 가짜 CPU들을 볼 수 있으나 가상 CPU로 이용하려면 추가 CPU 라이센스가 필요했다. 마이크로 소프트가 이 기능을 제대로 지원하게 되는 것은 윈도우 XP 부터이다)

리눅스 내부

확장성의 개선

앞서 나열한 NUMA나 하이퍼쓰레딩과 같은 일반적인 기능들 이외에도 리눅스2.6은 인텔 CPU 기반 서버를 십분 활용하게 해주는 기능들을 가지고 있다. 가장 중요한 개선사항은 PAE(Physical Address Extension)이라고 부르는 인텔 하드웨어의 기능이다. 이것은 최신의 32비트 x86 시스템들이 64GB까지의 RAM을 페이지 모드로 읽을 수 있도록 해주는 기능이다. 멀티 CPU 시스템에서의 APIC 지원 개선을 통한 IRQ 밸런싱 기능도 상당히 개선되었다.

새로운 하드웨어 기능 추가 이외에도 내부적 한계치들이 가능한한 최고 수준까지 높여졌다. 예를 들어 유니크한 사용자와 그룹의 수가 65,000에서 40억으로 늘어(16비트에서 32비트로 늘어난 것이다) 리눅스를 파일서버나 인증서버로 활용하는데 지장이 없도록 개선되었다. 프로세스 ID(PID)의 갯수도 32,000개에서 10억개로 증가하여 uptime이 매우 길고 바쁜 서버에서 새로운 프로세스를 생성하는 퍼포먼스가 향상되었다. 열수 있는 최대한의 파일의 갯수는 늘지 않았지만 이전과 같이 미리 원하는 한계치를 지정하지 않아도 자동으로 늘도록 수정되었다. 마지막으로 리눅스 2.6에서 블럭 디바이스들이 64비트를 지원할 수 있도록 수정되었다. i386과 같은 32비트 플랫폼에서도 마찬가지이다. 그래서 일반적인 하드웨어에서 파일 시스템을 16TB 까지 사용할 수 있게 되었다.

리눅스 커널 2.6의 확장성에 대한 개선사항 중 또다른 중요한 점은 커널 자체가 디바이스의 여러 타입을 지원하는 것 뿐만 아니라 한가지 타입의 여러가지 디바이스의 종류를 지원한다는 사실이다. 지금까지의 리눅스들은(사실은 거의 모든 유닉스가 그러하지만) 시스템의 사용자와 프로그램들이 숫자가 메겨진 디바이스 노드와 통신을 하도록 되어 있다. (/dev 디렉토리의 항목들) 이 디바이스 노드들은 255개의 주 디바이스로 제한되고 각각 255개의 부 디바이스로 제한된다. 예를 들어 /dev/sda2라는 디바이스는 첫번째 SCSI 드라이브의 두번째 파티션이라는 뜻인데 주 디바이스 번호가 8이고(SCSI가 다 그렇다) 부 디바이스 번호가 2이다. 다른 타입의 디바이스들은 각각의 주 디바이스 번호와 부 디바이스 번호를 할당 받는다. 하지만 255개 이상의 디바이스가 필요한 서버에서는 난관에 봉착하게 된다. (대형 스토리지 어레이, 프린트 팜 등) 리눅스 2.6에서는 이러한 제한들이 4096 주 디바이스와 각각에 100만개의 부 디바이스를 가질 수 있도록 확장되었다. 현재 나와 있는 최고 사양의 머신들도 아무런 문제없이 지원할 수 있도록 되었다.

상호작용성과 응답성

확장성과 함께 새 버전의 개발과정에서 중요하게 여겨진 것은 시스템의 응답성이다. 이것은 일반적인 데스크탑 사용자뿐만 아니라 고도의 정확성을 요구하는 응용 프로그램에게도 유용하다. 물론 이런 개선에도 불구하고 리눅스 2.6은 여전히 리얼타임 OS는 아니다. 리얼타임 OS가 되기 위해서는 액션에 대한 응답이 정해진 시간 안에 분명히 보장되어야 하고 예측가능해야 한다. 그럼에도 불구하고 이러한 응답성의 개선은 모든 계층의 리눅스 사용자들에게 호평받을 것이다. (물론 리얼타임 OS의 기능을 제공하기 위한 프로젝트가 존재한다. 이 프로젝트는 다음번 메이저 릴리즈에 공식적으로 공표될 것이다)

리눅스 커널 2.6의 가장 중요한 개선 사항중 하나는 드디어 커널 자체가 선점형으로 동작한다는 것이다. 이전 버전의 리눅스에서 커널 자체가 작업을 하는 동안에는 다른 프로세스를 위한 인터럽트를 허용하지 않아왔다. (물론 다중 CPU인 시스템에서는 CPU당 그렇다) 리눅스 2.6에서는 커널 자체가 작업을 하는 도중에도 인터럽트되어 다른 어플리케이션이 자신의 작업을 해나갈 수 있다. 물론 여전히 커널이 처리하는 도중에 인터럽트 되지 않는 작업이 있기는 하다. 하지만 실제 상황에서 너무나 짧은 시간이라 대부분의 사용자들은 그 딜레이를 거의 눈치채지 못할 것이다. 결국, 시스템에 부하가 많이 걸리는 상황에서도 사용자의 입력에 대해 시스템이 매우 빠르게 동작하는 것을 느끼게 될 것이다.

리눅스의 입출력 서브시스템들에 대폭적인 수정이 가해져서 큰 부하 아래에서도 응답성이 좋아지도록 개선되었다. 이것은 I/O 스케쥴러를 재작성하여 구현되었다. I/O 스케쥴러는 특정 시간에 어떤 프로세스가 디바이스들을 점유할 것인지를 결정하는 역할을 하는 커널 내의 루틴이다. 새로 작성된 스케쥴러는 한 프로세스가 너무 오랫동안 대기하지 않도록 효율적인 배분이 가능하게 해준다.

어플리케이션 측면에서 리눅스용 프로그램들의 응답성이 개선되도록 돕기 위해 새로운 futex(Fast User-Space Mutex)가 지원된다. Futex는 여러 프로세스나 쓰레드들 사이에서의 레이스 컨디션(race condition)을 피할 수 있도록 이벤트들을 시리얼라이즈(serialize)되도록 한다. 기존의 Mutex와는 달리 Futex는 절반 정도는 커널에 기반하고 우선순위가 높은 어플리케이션이나 쓰레드가 리소스에 우선적으로 접근할 수 있도록 한다. 프로그램이 태스크들에 우선순위를 먹여 이를 기반으로 Mutex를 걸도록 함으로써 반응시간을 향상 시킬 수 있는 것이다.

위의 것들에 덧붙여 많은 경우에 응답성을 강화해주는 소소한 개선사항들이 포함되어 있다. 이중 하나는 이른바 "Big Kernel Lock"을 제거했다는 것과 파일시스템 미리 읽기의 최적화, 소규모 파일 처리 등등이 그것이다.

기타 개선 사항들

다른 오픈소스 프로젝트들도 그렇듯이 리눅스는 오픈 스탠다드를 지향한다. 커널 2.6의 주요 개선 사항중 하나는 쓰레드 구조의 변경을 통해 POSIX 쓰레드 라이브러리(NPTL)을 돌릴 수 있다는 것이다. 이것은 많은 쓰레드를 동시에 돌리는 펜티엄 프로나 그 이상의 프로세서에서 큰 퍼포먼스 개선효과를 보여주며, 아마도 엔터프라이즈 시장에서 가장 각광 받을 개선사항일 수 있을 것이다. (사실 레드햇은 이미 이 기능을 2.4로 백포트(backport)하여 레드햇 9와 어드밴스드 서버 3.0에 포함시켰다) 이 변화는 쓰레드 그룹, 각 쓰레드의 로컬 메모리, POSIX 스타일의 시그널 등과 같은 리눅스 쓰레드의 새로운 컨셉들을 포함한다. 한가지 단점은 몇몇 버전의 Sun Java와 같이 예전의 리눅스를 기준으로 작성된 어플리케이션들이 제대로 동작하지 못할수도 있다는 것이다. 하지만 장점이 워낙 크기 때문에 대부분의 문제 어플리케이션들도 결국에는 새 커널을 제대로 지원할 것이다.

모듈 서브시스템과 통합 디바이스 모델

요즘의 운영체제들은 수많은 종류의 내부/외부 버스와 디바이스들을 다루어야만 한다. 새 버전의 리눅스에서 이 점이 대폭 보강된 것도 그리 놀라울 일은 아니다. 모듈 로더뿐만이 아니라 하드웨어에 대한 이해방식 자체도 상당한 변화가 있다. 변화된 부분은 우스울 정도로 간단한 것부터 시작해서 (드라이버 모듈이 이전에는 ".o"확장자를 가졌는데 이제는 커널 오브젝트를 뜻하는 ".ko"로 바뀐 것) 크게는 통합 디바이스 모델(unified device model)의 도입까지이다. 모두 안정성의 개선과 이전 버전의 한계를 극복하기 위한 방향으로 작업이 진행되었다.

모듈 서브 시스템의 안정성을 강화하기 위해 많은 큰 변화사항들이 존재한다. 모듈을 내리는(unload) 경우 모듈이 사용중인 와중에 내리게 되는 경우를 줄었다. 이전에는 대부분 시스템 크래쉬를 유발하는 경우가 많았었다. 안정적으로 돌아가야 하는 서버들을 위해 모듈을 내리는 기능을 아예 꺼버릴 수도 있게 했다. 추가적으로 각 모듈이 자신이 어떤 하드웨어를 지원하는지 알도록 하고 이를 공표할 수 있는 공표하는 표준절차가 마련되었다. 이전 버전의 리눅스에서는 각 모듈이 자신이 지원하는 하드웨어가 무엇인지는 알고 있었지만 이 정보가 모듈 밖에서는 공유되지 못했었다. 이 개선사항 덕분에 레드햇의 kudzu와 같은 하드웨어 관리 프로그램들이 좀 더 지능적으로 개선될수 있게 되었다. 공식적으로는 지원되지 않으나 거의 비슷한 구조를 가진 하드웨어에 대해 드라이버에게 특정 하드웨어에 대해 강제로 동작하도록 하는 것이 가능해졌다.

새 커널 버전에서는 모듈 로딩 이외에도 디바이스 모델 자체가 상당한 변화를 겪었다. 정해진 디바이스를 감지하는 등의 단순한 역할만을 행하는 모듈 로더와는 달리 디바이스 모델은 시스템 내의 하드웨어 전반에 대한 책임을 지는 좀 더 깊은 개념이다. 리눅스 2.2 이전에는 모듈 레벨에서만 모든 것을 판단하는 통합 디바이스 모델의 가장 간단한 서포트만이 존재했었다. 지금까지는 이러한 구조로도 충분했으나 ACPI등 최신 하드웨어 기능들을 모두 이용하기 위해서는 각 디바이스가 사용하는 리소스만 아는 것으로 충분하지 않다. 디바이스가 사용하는 버스의 종류라던가 가지고 있는 부디바이스의 종류나 현재의 전원공급 상태, 충돌시 사용 리소스를 바꾸어야 하는지 여부 등의 여러가지 상태들을 파악하고 있어야만 한다. 심지어는 현재의 디바이스에 알맞은 모듈이 이미 로드되어 있는지 여부도 파악할 수 있어야만 한다. 리눅스 커널 2.4에서 PCI와 PC 카드, ISA, PnP 버스들을 동일한 인터페이스로 묶을 수 있는 통합 인터페이스가 도입되었다. 리눅스 2.6에서는 새로운 형식의 커널 오브젝트(kobject)를 통해 시스템의 디바이스 지원을 한 차원 높이 끌어올리고 있다. 레퍼런스 카운팅이나 전원 관리, 유저 스페이스(user-space)와의 연결 방법 제공 등 더 나은 통합된 인터페이스를 제공한다.

디바이스들에 대한 자세한 정보가 커널에 모두 제공되므로 랩탑이나 데스크탑 컴퓨터들에 대한 좀 더 심도 깊은 지원이 가능해졌다. 가장 좋아지는 부분은 PC카드나 USB, Firewire, 핫플러그 PCI등의 핫 플러그(hot plug)기기들에 대한 부분이 될 것이다. 되돌아 생각해보면 리눅스 2.2 이전까지는 이런 종류의 하드웨어 지원이 전무했었다. 근래에는 핫 플러그 방식으로 동작하는 기기가 예외적인 상황이 아니라 일반적인 경우가 되었으므로 새로운 디바이스 관리 시스템에서 기존의 디바이스와 핫 플러그 디바이스의 차이점을 제거하는 것이 꼭 필요했다. 커널의 서브 시스템에서 부팅시에 찾아낸 디바이스와 실행중에 찾아낸 디바이스의 차이점을 차별하지 않음으로써 핫 플러그 방식의 디바이스를 처리하는 방식이 간단해졌다. 이번 버전에서 새로 작성되고 개선된 부분은 전원 관리에 대한 부분이다. 최근에 새로운 표준으로 사용되는 ACPI(Advanced COnfiguration and Power Interface)는 지난 버전에 약간 엉성한 방식으로 지원됐었다. 이전의 표준이었던 APM(Advanced Power Management)와는 달리 ACPI를 사용할 때에는 OS가 모든 디바이스들에게 전원 공급 상태를 바꾸도록 통보해야 한다. 하드웨어 전체에 대한 정보를 모두 파악하고 있지 않다면 커널이 이런 통보 작업을 하는 것이 불가능할 것이다. 이 두가지 예로 든 것들 이외에도 통합의 효과로 이득을 보는 몇몇 분야들이 있다. 하드웨어의 연결시험(auditing)이나 감시 등이 그것이다.

마지막으로 (그리고 가장 중요한지도 모르지만) 시스템 파일시스템가 분화된 것이 중요한 변경사항이다. 시스템 파일 시스템은 "sysfs"라고 부르는데 프로세스는 'proc', 디바이스들은 'devfs', UNIX98 수도터미널(pseudo-terminal)들은 'devpts'이다. /sys에 마운트되는 이 파일 시스템은 커널이 디바이스를 어떻게 보는지 그대로 보여준다. (물론 예외도 있다) 검색된 디바이스의 속성의 갯수를 포함해서 디바이스의 이름과 IRQ, DMA, 전원 공급 상태 등의 사항들을 커널이 어떻게 파악하고 있는지 알 수 있다. 물론 이런 변화는 단기적으로는 혼란을 초래할 수도 있지만 결국에는 잘 이전될 것이다. 약간의 과도기가 있을 것이다.

시스템 하드웨어 지원

리눅스가 주류로 나아가면서 각각의 커널에서 지원하는 디바이스들이 비약적으로 늘고 있다. 비교적 새로운 기술(USB 2.4등)이나 기존의 오래된 기술들(MCA 2.2등)도 포함된다. 커널 2.6이 발표되면서 리눅스가 지원하지 않는 하드웨어는 비교적 적다. 하지만 아직도 지원되지 않는 PC 하드웨어들이 있다. 그렇기 때문에 유연성을 향상시키기 위해 새로운 기능을 추가하기 보다 i386 하드웨어의 지원이 개선되는 것이다.

내장 디바이스

프로세서의 타입과 거의 동일한 수준으로 비슷한 것이 시스템이 어떤 버스를 사용하고 있는지 여부이다. PC 업계에는 예전의 ISA를 비롯하여 현재의 외부 시리얼 장치나 와이러리스 버스에 이르는 필요 이상으로 많은 종류의 버스가 혼재되어 사용되고 있다. 리눅스는 언제나 최신의 버스나 디바이스가 발표되고 인기를 끌게 되면 즉시 이를 차용하여 지원하도록 하고 있지만 비교적 덜 인기가 있는 기술에 대해서는 조금은 느린 대응을 보이고 있다.

리눅스의 시스템 내부 디바이스에 대한 지원은 비교적 공명정대하다. 가장 좋은 예가 ISA 플러그앤 플레이에 대한 지원이다. 리눅스는 커널 2.4 이전까지는 어떠한 PnP에 대한 지원도 제공하지 않았었다. 하지만 이 지원은 PnP BIOS의 지원이 구현되면서 모두 지원되기 시작했다. 디바이스 이름에 대한 데이타베이스나 기타의 호환성에 대한 것들이 변화되면서 그렇게 되었다. 결과적으로는 이제 리눅스는 진정한 플러그앤 플레이 운영체제가 되어 버렸다. 다른 오래된 버스들, 예컨데 MCA나 EISA등이 모두 새로운 디바이스 모델에 포함되어 한꺼번에 구현된 것이다. 커널 2.6에서는 PCI(Peripheral Component Interconnect) 서브 시스템의 개선 사항에 포함하여 몇가지 이슈들이 개선되었다. 핫 플러그 PCI, 전원 관리, 다수 AGP의 지원, 등이다. 마지막으로 이런 버스들과 함께 리눅스 2.6에서는 "legacy" 버스라는 개념을 포함한다. 이것은 각각의 버스에 대해 거의 반드시 있을만한 디바이스에 대한 정보를 미리 가지고 있는 것이다. 예를 들자면 PC에서는 온보드 시리얼 포트, 패러렐 포트, PS/2 포트등이 어떤 버스에나 거의 반드시 포함되어 있는 디바이스들이다. 물론 이런 지원을 하기 위해서는 펌웨어를 억세스 하는 등의 좀 더 복잡한 작업이 수반되지만 일반적으로는 새로운 드라이버 패러다임에 걸맞는 방식으로 모든 디바이스들을 제어하도록 하는 수단이 된다.

외장 디바이스

최근의 개발 과정 동안 약간 오래된 내부 디바이스 버스들에 대한 새로운 기능추가가 좀 덜했던 것은 사실이지만 새로운 외장 하드웨어에 대한 지원은 그렇지 않다. 이쪽으로 가장 중요한 개발 사항 중 하나는 USB 2.0 디바이스에 대한 지원이다. 이들 디바이스들은 고속 USB 디바이스라고 불리는데 480Mbps의 속도가 나와 이전의 12Mbps로 동작하던 USB 디바이스들과 대조를 이룬다. 이것과 관련된 최신 표준인 USB OTG(USB On-the-go)는 현재 리눅스 2.6에서는 지원되지는 않는다. (이것은 PC를 끼지 않고 디지탈 카메라를 프린터에 연결하는 등의 일을 가능하게 해준다) (이에 대한 패치는 존재하지만 아직 메인 커널에는 통합되지 않았다) 이외에도 USB 디바이스들을 파악하는 루틴이 새로 작성되어 동일한 타입의 디바이스가 여러개일 때에도 잘 동작하도록 수정되었다. 이런 큰 변화들 말고도 리눅스 유저들을 위해 USB 디바이스들의 안정성, 호환성이 향상되도록 개발 과정에서 많은 배려가 있었다.

이런 것들과 정반대의 방향에서, 리눅스 2.6에서는 리눅스 시스템이 USB 호스트가 아닌 USB 디바이스로 동작하는 것이 가능하도록 하는 부분이 추가되었다. 예를들어 리눅스 기반의 PDA가 PC에 연결되어 제대로 동작할 수 있도록 하는 등의 일들을 위한 기반이 마련되었다. 임베디드 디바이스에서 리눅스가 제대로 사용되기 위해 꼭 필요한 기능이라고 할 수 있다.

무선 디바이스

최근 몇년간 무선 디바이스들의 사용이 인기를 끌기 시작했다. 어떨 때에는 케이블이라는 것이 과거의 유물이고 몇년 안에 사라질 것처럼 생각되기도 한다. (물론 전원 케이블은 예외이다) 무선 디바이스에는 가장 흔히 쓰이는 네트웍 디바이스 부터 PDA와 같은 기기까지 포함한다.

무선 네트웍 분야에서 디바이스들은 보통 장거리 (아마추어 무선을 통한 AX.25) 디바이스와 단거리 (802.11 등) 디바이스로 나뉜다. 이들 각각의 디바이스들에 대한 지원은 리눅스 커널의 초창기인 1.2 시절부터 시작되었으며 커널 2.6에서 새로 갱신되었다. 가장 큰 변화는 단거리 무선 인터넷 기기들이 모두 "wireless"라는 부 시스템과 API로 통합되었다는 사실이다. 이런 통합은 디바이스의 종류별로 다른 설정을 해주어야 하는 문제를 해결하여 모든 디바이스에 대해 동일한 동작을 하는 사용자 프로그램의 작성을 가능하게 해준다. 이런 통합 이외에도 디바이스의 동작 상태 변경에 대한 통지라던가(로밍과 같은) 무선 디바이스에서 일어나는 주기적인 딜레이에 대한 TCP 차원의 처리와 같은 개선사항들이 포함되었다. 커널 2.4 사용자들로부터 무선 디바이스의 지원에 대한 요구가 많기 때문에 이들 많은 개선사항들이 2.4로 백포트 되어있기도 하다.

일반적인 무선 디바이스 분야에서 IrDA와 같은 디바이스에 대해 전원 관리라던가 커널 드라이버 모델로의 통합과 같은 개선사항이 있다. 그리고, 블루투스 디바이스들에 대한 지원에 비약적 향상이 있었다. 블루투스는 IrDA와 비슷하기는 하나 시거리가 확보되지 않아도 사용 가능한 단거리 저전력형 무선 디바이스 통신 방식이다. 프로토콜로서의 블루투스는 PDA나 핸드폰, 프린터, 자동차용 디바이스들과 같은 어떤 분야에서도 사용될 수 있도록 설계된 프로토콜이다. 프로토콜 자체는 두가지 방식으로 이루어져 있는데 오디오 데이타와 같이 손실 가능성 데이타를 전송하는데 주로 쓰이는 SCO(Synchronous Connection Oriented)방식과 정밀한 데이타 전송이 필요한 부분에 쓰이는 L2CAP(Logical Link Control and Adaptation Protocol)이 그것들이다. L2CAP 프로토콜은 많은 서브 프로토콜(sub-protocol)들을 지원한다. (포인트 투 포인트 네트워킹을 위한 RFCOMM, 이더넷과 같은 네트워킹을 위한 BNEP등) 블루투스를 활용하기 위한 리눅스의 지원은 날이 갈수록 향상되어가고 있고 소비자들이 더 많은 블루투스 디바이스들을 사용하게 되면 될수록 그 지원도 향상될 것이다. 최초의 블루투스 지원은 커널 2.4에서 시작되었다는 점도 특기할 만 하다.

블록 디바이스 지원

스토리지 버스

IDE/ATA(integrated DRive Electronics/Advanced Technology Attachment)나 SCSI(Small Computer System Interface)와 같이 스토리지 전용으로 사용되는 버스들은 커널 2.6 개발 과정에서 메이저 업데이트가 있었다. IDE 서브 시스템에 대한 부분이 가장 중요 한데. 확장성에 대한 문제들을 여러가지 다른 제약점을 해결하기 위해 커널 2.6의 개발 과정에서 완전히 새로 작성되었다. 예를 들어 이제 CD/RW 드라이브들은 이전 버전에서와 같이 SCSI 에뮬레이션을 통해 동작하는게 아니고 직접 디바이스와 통신할 수 있도록 개선되었다. 그리고 150MB/sec의 속도를 갖는 시리얼 ATA(S-ATA)디바이스들에 대한 지원이 추가되었다. SCSI 측면에서는 넓은 지원 범위와 확장성을 위한 여러가지 개선사항이 추가되었다. SCSI-2 멀티패스(multi-path) 디바이스에 하나의 디바이스에 2LUN을 갖는 경우에 같이 예전 방식에 대한 대한 지원도 추가되었다. (SCSI-2는 1994년으로 거슬러 올라가는 SCSI 표준의 이전 표준이다) 그리고 이제 리눅스도 윈도우와 같이 미디어의 교환을 감지해낼 수 있도록 개선되어 완전히 표준을 따르지 않는 디바이스들과도 호환성을 유지할 수 있도록 했다. 이들 기술들이 시간이 흐름에 따라 안정화 되어가기 때문에 이들에 대한 리눅스의 지원도 안정화 되어가고 있다.

물론 그 자체로는 스토리지 버스가 아니지만 리눅스는 EDD(Enhanced Disk Device) BIOS를 직접 지원할 수 있게 되었다. EDD BIOS는 바이오스가 알고 있는 시스템에 연결된 모든 디바이스에 대한 정보를 가지고 있다. (IDE와 SCSI를 모두 포함하여) 게다가 설정사항과 기타 정보들만 가지고 오는 것이 아니라 몇가지 장점들을 더 제공한다. 예를 들어, 새 인터페이스는 리눅스가 부팅할 때 어느 디스크 디바이스를 이용했는지를 알아낼 수 있게 하는 등의 새로운 인터페이스를 제공한다. 리눅스 설치시 어느 부분에 리눅스 부트 로더를 설치할 것이지를 지능적으로 결정하게 해주는 등의 좀 더 지능적인 설치 프로그램을 작성할 수 있게해준다.

이런 변화 사항들 이외에도 모든 버스 디바이스 타입들이 리눅스의 새로운 디바이스 모델 서브 시스템으로 통합 되었다는 점이 중요하다. 어떤 경우에는 이런 통합이 좀 우스워 보일수도 있을 것이고, 또 다른 어떤 경우에는 좀 더 심각한 변화사항들이 있는 경우도 있을 것이다. (예를 들어 디바이스가 수정이 필요한지 등에 대한 감지를 하는 로직 자체도 변화될 필요가 있다)

파일 시스템

리눅스에서 블럭 디바이스 시스템을 사용하는 부분은 당연히 파일 시스템을 얹어서 쓰기 위해서이다. 리눅스 커널 2.4 이후로 많은 부분에서 광범위한 개선이 있었다. 그중 가장 중요한 점들은 확장 속성(extended attribute)의 지원과 POSIX 스타일의 억세스 콘트롤 방법이다.

일반적인 리눅스 시스템에서 ext2나 ext3 시스템을 사용한다. (ReiserFS가 세번째로 많이 쓰인다) 이들이 사용자들이 가장 많이 사용하는 시스템이기 때문에 개발 과정에서도 이들에 대한 개선 사항이 가장 많았다. 이들에 대한 가장 중요한 개선점은 확장속성(또는 메타데이타라고도 부른다)에 대한 지원이었다. 각각의 파일에 대한 속성들을 파일 시스템 내에 저장해 두는 것이다. 이들 속성 중 몇가지는 시스템이나 root 에 의해서만 읽고 쓸수 있도록 된다. 윈도우나 맥 OS와 같은 다른 운영체제들은 이미 이러한 기능을 사용하고 있다. 불행하게도 기존의 유닉스용 프로그램들은 이들 정보를 제대로 인식하거나 사용하지 못하는 경우가 많아 (tar등) 이들을 업데이트 해주지 않으면 안된다. 확장 속성이 이용된 가장 첫번째 분야는 POSIX 스타일의 억세스 콘트롤을 위한 부분이었다. 이것은 유닉스 스타일의 권한 체계보다 좀 더 확장되어 세밀한 권한 설정이 가능하도록 하는 시스템이다. ext3에 대한 이런 변화 말고도 몇가지 변화된 부분들이 있는데 저널링을 사용할 때 커밋(commit)시간을 전원 관리등을 설정해서 사용하는 노트북 유저들을 위해 튜닝될 수 있도록 수정되었다. 이 정보들은 파일 시스템 내에 저장되어 마운트 할 때마다 새로 지정해줄 필요가 없다. 그리고 디렉토리 내부의 파일 검색을 좀 더 빠르게 하기 위해 디렉토리가 인덱스 되었다는 표시를 해둘 수가 있다.

리눅스의 고전적 파일 시스템 이외에도 리눅스 커널은 XFS등과 같이 새로운 파일 시스템에 대한 지원도 포함한다. 이 파일 시스템은 Irix 시스템에서 기본으로 설정되는 XFS 파일 시스템에서 나온 것이고 블럭 레벨에서 호환성이 있다. ext3나 Reiser와 같이 루트 디스크에 쓰일 수 있고 확장 속성이나 ACL과 같은 새로운 기능들을 지원한다. 많은 배포본들이 리눅스 2.4 기반에 이 파일 시스템을 지원하기 시작했다. 하지만 어떤 파일 시스템이 최후의 승자가 될지는 아직 더 지켜봐야 할 것이다.

이외에도 리눅스는 파일 시스템 내부나 외부적으로 독점 운영체제와의 호환성을 개선시키기 위한 많은 개선사항이 있다. 우선 리눅스 2.6은 MS 윈도우의 논리 디스크 매니저(Logical Disk Manager)를 지원한다. 이것은 다이나믹 디스크라고 불리는 기능이다. 윈도우 2000이후 버전의 윈도우에서 파티션의 크기 조정을 자유롭게 하기 위해 새로 도입한 파티션 테이블 방식이다. (물론 리눅스 배포본에서 이 시스템을 사용할 것 같지는 않다) 리눅스 2.6은 또한 NTFS 파일 시스템에 대한 지원 부분을 완전히 재작성 하여 NTFS 볼륨에 대한 읽기 쓰기가 가능해졌다. (물론 쓰기에 대한 부분은 아직은 실험적이고 점진적으로 개선될 것이다.) 마지막으로 리눅스는 FAT12에 대한 지원 부분이 개선되어 몇몇 이 포맷을 사용하는 mp3 플레이어에 생기는 문제점들이 개선되었다. 확장속성 지원이 HPFS 파일 시스템에도 포함되었다. 이전 버전에서도 그랬지만 리눅스는 2.6에서도 다른 운영체제와 잘 섞여 사용할 수 있는 "스위스 군대 칼"과 같은 존재로서의 위상을 강화해 나가고 있다.

이들 변화 사항 말고도 리눅스 파일 시스템에 대한 많은 변화가 있었다. 할당량(Quota) 지원 부분이 좀 더 많은 사용자들을 지원하기 위해 재작성되었고, 각각의 디렉토리들이 동기적으로 동작할 수 있도록 개선되었다. (이것은 메일 시스템이나 디렉토리 기반의 데이타베이스 등의 시스템에 유용한데 디스크가 손상된 경우의 복구에 좋다) CD-ROM 등에 쓰이는 ISO9660 파일 시스템에서 투명한 압축이 지원되며 메모리 기반의 파일 시스템인 hugetlbfs가 새로 추가되어 공유 메모리 데이타베이스에 대한 지원이 강화되었다.

입출력 지원

대부분의 컴퓨터 시스템들은 외부와 연결될 때 그리 중요해 보이지 않는 입출력 장치로 연결된다. 이에는 마우스와 키보드, 사운드 카드, 비디오 카드, 조이스틱과 같은 디바이스들이 포함된다. 리눅스 2.6 개발 과정 중에 많은 기기들에 대한 지원이 추가되었지만 기본적인 디바이스들은 그 이전부터 이미 지원되어 왔고 이미 충분히 안정적이다. 외부 버스 지원과 Bluetooth 지원 등과 같은 부분의 개선 덕분에 디바이스들에 대한 지원이 확장되게 되었다. 많은 부분에서 큰 개선이 있었다.

HID(Human Interface Devices)

커널 2.6의 내부 변화중 가장 큰 것들 중 하나가 바로 휴먼 인터페이스 레이어가 재작성된 것이다. 휴먼 인터페이스 레이어는 리눅스 시스템에 대한 사용자들의 접점을 규정하는 가장 핵심이 되는 부분이다. 커널 새 버전에서는 이 레이어에 대해 이전 버전보다 더 큰 작업이 행해졌고 더 모듈화 되었다. 이제는 디스플레이와 같이 필수적이라고 생각했던 것들이 없어도 시스템 구성이 가능하다. 철저하게 모듈화 되어서 그렇다. 이런 모듈화의 가장 큰 장점은 임베디드 디바이스에 대한 개발이 손쉬워졌다는 것이다. 넣고 싶은 기기를 넣고 빼고 싶은 기기를 뺄 수 있으며 대신 네트웍이나 시리얼 포트를 통해서 제어한다던지 하는 일들이 가능해졌다. 하지만 사용자들의 측면에서는 다른 측면에서의 장점이 생긴다. 예를 들어 PC를 가지고 있다면 무조건 표준 AT(i8042)기반의 키보드가 있어야 한다던지 하는 기본 전제를 무시할 수 있게 된 것이다.

리눅스의 모니터 출력을 지원하는 부분에도 많은 변화가 있었다. 물론 커널 내부의 프레임버퍼 서브 시스템을 사용하는 경우에만 해당되는 경우가 대부분이지만. (인텔 기반의 리눅스 시스템들은 대부분 그렇지 못하다) 필자 개인적 의견으로는, 이 기능의 가장 좋은 점은 부팅 시에 귀여운 팽귄 로고가 24bpp의 해상도로도 지원될 수 있게 된 점이다. 그리고, 콘솔 자체도 리사이즈 되거나 회전할 수 있게 되었고(PDA등에서 유용할 것이다) 좀 더 많은 하드웨어를 지원한다. 마지막으로, 리눅스 커널에 VESA(Video Electronics Standard Association) 모니터들에 대해 그들의 기능에 대한 쿼리를 날릴 수 있다. 물론 이런 일들은 XFree86에서는 이미 하고 있던 일들이기는 하다.

이런 큰 변화점들 말고도 리눅스 2.6은 또한 사용자와 상호작용하는 측면에서 작은 변화들을 많이 포함하고 있다. 예를 들어, 터치 스크린이 이제 지원된다. 마우스와 키보드 드라이버들도 표준화 되어 동일한 디바이스 노드를 가지게 되었다.(예를 들어 마우스는 /dev/input/mouse0) 복잡한 마우스들(휠이 여러개라던가)도 이제 지원된다. PC 키보드 매핑에 대한 부분도 개선되어 표준 윈도우 키보드도 지원된다. XBox 게임패드등 조이스틱에 대한 지원도 많은 드라이버들이 나와주어서 상당히 개선되었다. 포스 피드백 지원도 포함되었다. 마지막으로, Tieman Voyager 브라이유(braille) 점자 TTY 디바이스에 대한 지원이 포함되었다. (이 기능은 리눅스 2.4에도 백포팅 되었을 정도로 중요한 기능이다)

한가지 덧붙이면, 리눅스에는 로컬 키보드를 갖지 않은 시스템을 위한 "시스템 리퀘스트(system request)"인터페이스에 작은 변화가 생겼다. 시스템 리퀘스트(sysrq) 인터페이스는 시스템 관리자가 콘솔에서 디버깅 정보를 얻고 시스템을 리부팅 하고 파일 시스템을 읽기 전용으로 마운트 해서 여러가지 일들을 할 수 있도록 만들어졌다. 리눅스 2.6에서 키보드 등이 없는 시스템을 지원하므로 이들 이벤트들을 /proc 파일 시스템을 통해 발생시키도록 할 수 있게 되었다. (물론 시스템이 멈추거나 한 경우에는 별 도움이 안되겠지만)

오디오 & 멀티미디어

리눅스 2.6으로 넘어오면서 사용자들이 가장 기다렸던 추가 기능 중 하나가 ALSA(Advanced Linux Sound Architecture)이다. 이전의 사운드 시스템인 OSS(Open Sound System)이 그동안 사용되어 왔지만 몇가지 구조적 제약사항들 때문에 대치되게 되었다. 첫번째 개선사항은 기반부터 철저하게 쓰레드와 SMP에 안전하도록 설계되었다는 점이다. 이전에는 데스크탑은 무조건 CPU를 하나만 갖는다는 가정 하에 동작하도록 되어 있었다. 더욱 중요한 점은 대단히 모듈화 되어 새로운 사운드 카드의 지원도 손쉬워 졌다는 점이다. 물론, 내부가 아름다와 졌다고 해도 외부에 보이는 기능 개선이 없다면 사용자 측면에서는 별 의미가 없을 것이다. 새로운 사운드 시스템은 상당히 많은 강력한 기능들을 가지고 있다. 가장 큰 기능들을 꼽아보면 새로운 사운드 디바이스(USB오디오나 MIDI디바이스)들에 대한 지원, 전이중(full-duplex) 재생과 녹음 기능, 하드웨어 믹싱, 사운드 디바이스들의 통합 작동 등등이다. 오디오 기능에 대한 매니아이건 MP3만 듣는 정도의 사용자이건 무척 환영할 만한 기능들이다.

간단한 오디오 재생뿐 아니라 근래의 사용자들이 원하는 기능들은 상당히 다양하다. 웹캠, 라디오 또는 TV 어댑터, 디지탈 비디오 레코더 등도 포함된다. 이 세가지 경우에 대해 리눅스 2.6에서의 지원이 개선되었다. 리눅스에서 이전에도 이미 라디오 카드나 TV 튜너, 비디오 카메라 등을 지원해왔으나 극히 최근의 일이다. Video4Linux(V4L)이라고 불리는 이 시스템에 많은 개선사항이 추가되어 최신버전에서는 API의 정리작업이 수행되었고 좀 더 많은 기능들이 추가되었다. 새로운 API는 이전 버전의 API와 호환되지 않아 이전 버전의 API를 사용하는 응용 프로그램은 새로 업그레이드 해야 한다. 또다른 특기사항을 리눅스 2.6에서는 디지탈 비디오 방송(DVB) 하드웨어에 대한 지원을 포함한다. 셋탑 박스 등에서 사용하는 이런 하드웨어는 리눅스 시스템을 Tivo와 같은 디바이스로 변신시킬 수 있는 기능을 제공한다.

소프트웨어 개선사항들

네트워킹

항상 최신의 네트워킹 지원이 리눅스의 가장 중요한 인기 포인트 중 하나였다. 리눅스는 이미 TCP/IP(v4 & v6), Apple Talk, IPX등과 같이 가장 인기있는 네트웍 프로토콜들을 지원한다. (지원하지 않는 것들 중에는 NetBEUI같은것도 있기는 하다) 다른 서브 시스템들의 변화와 마찬가지로 네트웍 하드웨어에 대한 변화들은 지극히 내부의 일이고 겉에서는 잘 알아차리기 힘들다. 하부 구조들은 디바이스 모델과 디바이스 드라이버들이 새로이 업데이트 된데에서 많은 장점을 얻었다. 예를 들어, 리눅스는 현재 여러 네트웍 디바이스 드라이버들이 사용하던 MII(Media Independent Interface 또는 IEEE802.3u) 서브 시스템을 가지게 되었다. 이 새로운 서브 시스템은 각각의 디바이스들이 조금씩 다르게 다루던 부분들을 모두 수정하게 된다. 다른 변화들은 ISDN 업데이트와 같은 것들이 있다.

소프트웨어 측면에서 가장 큰 변화중 하나는 IPsec 프로토콜의 지원이다. IPsec 또는 IP Security라는 프로토콜은 IPv4와 IPv6에서 네트웍 프로토콜 레벨에서 암호화 보안을 사용 가능하게 해주는 프로토콜의 집합이다. 보안 기능이 프로토콜 레벨에 들어가기 때문에 응용 프로그램들에서는 이것들을 의식해서 새로 작성하거나 할 필요가 없다. 이것은 SSL이나 터널링/보안 프로토콜과 동일한 개념이지만 그보다 좀 더 저수준이다. 현재 커널에서 지원하는 암호화는 SHA(Secure Hash Algorithm)나 DES(Data Encryption Standard)등을 포함한다.

프로토콜의 다른 부분에서는 리눅스는 멀티 캐스트 네트워킹에 대한 지원이 강화되었다. 멀티캐스트 네트웍은 한개의 패킷을 보내면 여러 대의 컴퓨터에서 그 패킷을 받게 되어 있는 네트웍이다. (기존의 포인트-투-포인트 방식의 네트웍과 비교해 생각해보라) 이는 Tibco와 같은 메시징 시스템이나 오디오/비디오 컨퍼런스 소프트웨어에 사용된다. 리눅스 2.6은 MLDv2(Multicast Listener Discovery)와 IGMP3(Internet Group Messaging Protocol)과 같은 몇가지의 SSM(Source Specific Multicast) 프로토콜들을 지원한다. 이들은 Cisco와 같은 하드웨어 네트워킹 벤더들에 의해 지원되는 표준 프로토콜 들이다.

리눅스 2.6은 또한 LLC 스택을 분리구현했다. LLC는 Logical Link Control 프로토콜(IEEE 802.2)인데 NETBeUI나 IPX, Appletalk과 같은 몇몇 일반적인 고수준의 네트웍 프로토콜의 기반을 이루는 저수준 프로토콜이다. 변화의 일부로는 IPX, Appletalk, 토큰 링 드라이버들이 새 서브시스템의 이득을 보기 위해 새로이 작성되었다. 외부 프로젝트로 NetBEUI 프로토콜 스택을 작성하는 프로젝트가 진행되고 있는데 이것이 커널 내부로 병합될지는 두고 봐야 할 것이다.

이것들 이외에도 작은 변화들이 상당히 많다. IPv6에 많은 변화들이 가해졌고 토큰 링 네트워크에서도 동작하게 되었다. 리눅스의 NAT/masquerading 지원은 다중 접속을 필요로 하는 프로토콜들(H.323, PPTP등)에 대해서도 잘 지원하도록 수정되었다. 리눅스에서 VLAN을 설치하는 것은 이제는 더 이상 "실험적"이라고 할 수 없다.

네트웍 파일 시스템

리눅스의 유연한 네트웍 프로토콜 지원의 상단에는 역시나 유연한 네트웍 파일 시스템 지원이 존재한다. 네트웍 파일 시스템을 노출(export)하고 마운팅하는 것은 커널이 직접 관리하는 고수준의 네트웍 동작이다. (역시 비슷하게 응용 프로그램에서 파일처럼 사용하게 되는 네트웍 블록 디바이스들은 2.6에서 그리 큰 변화가 있지 않았다) 그외의 네트웍 동작들은 대부분 사용자 스페이스로 밀려갔고 커널 개발자들의 영역에서 다소 멀어졌다.

리눅스와 유닉스 호환 운영체제의 세계에서 가장 중요한 네트웍 파일 시스템은 NFS(Network File System)이다. NFS는 매우 복잡한 파일 공유 프로토콜이며 유닉스에 깊은 뿌리를 박고 있는 파일 시스템이다 (특히나 썬의 솔라리스에서의 구현은 더 그렇다) NFS는 TCP나 UDP등을 사용할 수 있지만 몇가지 별도의 RPC(Remote Procedure Call)를 기반으로 동작하는 서브 프로토콜들도 필요로 한다. 이것들은 인증을 위한 "mount" 프로토콜과 파일 록킹을 위한 NLM(Network Lock Manager)등을 포함한다. (일반적인 구현 버전들은 대부분 또다른 RPC 기반의 프로토콜인 NIS에 인증등의 기능을 의지한다. NIS와 그 비슷한 것들은 보안상 그리 안정적이지는 않기 때문에 리눅스 머신에서는 일반적으로 많이 쓰이지는 않는다) NFS가 널리 쓰이는 인터넷 프로토콜의 위치를 차지하지 못한 것은 그 복잡함 때문일 것이다.

리눅스 2.6에서는 NFS는 많은 개선이 있었다. 가장 큰 개선이라면 서버나 클라이언트에 새로운 NFSv4 프로토콜을 실험적으로 지원한다는 것이다. (이전 버전의 리눅스에서는 v2나 v3만 지원했었다) 새 버전은 좀 더 강력하고 안전한 암호에 기반한 인증을 지원하며 좀 더 지능적인 록킹(locking)과 가짜 파일 시스템(pseudo-filesystem)을 지원한다. NFSv4의 모든 기능이 아직 구현되지는 않았지만 지원 자체가 제법 안정적이어서 중요한 서버에서도 사용될 수 있을 만큼의 안정성을 보인다. 추가적으로 리눅스의 NFS서버 구현은 좀 더 확장성 있게 설계되었다 (64배 더 많은 동시 사용자와 더 큰 요청 큐를 가진다). 그리고 좀 더 완전하고(TCP와 UDP상에서 동작), 좀 더 유연하며, 좀 더 쉽게 유지보수가 가능하다. (시스템 콜이 아닌 nfsd 파일 시스템을 통해서 가능하다) 별도로 분리된 lockd와 nfsd, 지원되는 인터페이스에 대한 zero-copy 네트워킹 등의 숨겨진 변화들도 많다. NFS는 시스템 관리자가 커널의 lockd 포트 번호를 할당할 수 있도록 하여 비교적 손쉽게 보안을 강화할 수 있도록 하였다. NFS 클라이언트 사이드는 또한 캐쉬 구조와 UDP를 통한 연결 콘트롤, 기타 TCP에 가해진 개선사항등 하부의 RPC 프로토콜에서 이득을 본다. 리눅스에서 NFS 볼륨을 루트 파일 시스템으로 사용하는 것은 (디스크 없는 시스템과 같이) TCP 상의 NFS가 지원되도록 개선되어 가능하도록 되었다.

이와 같은 유닉스 스타일의 네트웍 파일 시스템 이외에도 리눅스 2.6에서는 윈도우 스타일의 네트웍 파일 시스템에 대해서도 많은 개선이 있었다. 윈도우 서버군에서 표준으로 사용하는 공유 파일 시스템인 SMB 프로토콜에 대한 지원이 더 강화되었다. 물론 윈도우 2000에서는 SMB 프로토콜보다 좀 더 개선된 버전인 CIFS(Common Internet Filesystem)이라는 것이 표준화 되었다. 이 업그레이드는 프로토콜 자체가 특정 시점에 엉망이 되는 것을 막고 좀 더 잘 동작하도록 하는데 목표가 있다. (프로토콜 자체가 많이 개량되어 결국 어떤 시점에서부터 윈도우 NT나 윈도우 2000과 윈도우 95/98/ME와 호환이 되지 않게 되었다) CIFS는 그 목적 이외에도 유니코드 지원, 파일 록킹 기능 개선, 하드 링크, NetBIOS에 대한 의존성 제거, 그리고 윈도우 사용자들을 위한 몇몇 기능 개선이 추가되었다. 그래서 한동안 리눅스 사용자들은 CIFS와 제대로 공유할 수 없었으나 리눅스 2.6부터는 CIFS에 대한 지원이 완전히 재 작성되어 완벽하게 호환이 된다. 리눅스 2.6에는 SMB와 CIFS 프로토콜의 확장인 SMB-UNIX 익스텐션에 대한 지원이 추가되어 Samba와 같은 SMB서버에 윈도우 파일 타입이 아닌 파일 타입(디바이스 노드나 심볼릭 링크 등)을 지원할 수 있게 되었다. 근래에는 드물게 리눅스는 노벨 넷웨어에 대한 지원도 빼먹지 않았다. 리눅스 2.6에서는 내장된 NCP(Netware Core Protocol) 파일 시스템 드라이버를 통해 256개 까지의 공유를 마운트 할 수 있다.

리눅스 2.6은 하나의 로지컬 볼륨에 존재하는 파일들이 여러개의 노드들에 분산되어 있을 수 있는 비교적 새로운 종류의 분산 네트워크 파일 시스템을 지원한다. 리눅스 2.4에서 지원이 시작된 CODA 파일 시스템 이외에도 AFS와 InterMezzo에 대한 지원이 추가되었다. AFS는 Andrew Filesystem(CMU에서 개발되어 이름이 저렇다)은 아직은 매우 제한적이고 읽기 전용으로 밖에 동작하지 않는다. 두번째 새로 지원되는 파일 시스템인 InterMezzo(역시 CMU에서 개발되었다)는 리눅스 2.6에서 지원되기 시작했는데 비접속 기능(로컬에서 동작하도록 하는)과 같은 높은 수준의 기능들의 동작이 가능하며 반드시 디스크의 공간이 존재해야만 하는 종류들의 응용 프로그램에 사용될 수 있다. 물론 여러대의 시스템, 노트북이나 PDA 또는 데스크탑 컴퓨터 등에서 서로의 파일 내용을 싱크할 수 있는 기능도 내장되어 있다. 새로운 파일 시스템을 지원하기 위한 프로젝트들이 존재한다.

기타 기능들

보안

리눅스 2.6에서 새로 부각된 부분이지만 주목을 많이 못받고 있는 분야가 보안 관련 분야이다. 가장 기본적으로 근래에는 커널 기반의 보안(유닉스에서의 root 사용자의 권한) 자체도 모듈화 되어서 여러가지 보안 모델 중 하나가 되어 버렸다. (어쨌거나 현재까지 기본적으로 제공되는 모델이고 새로운 모델에 대해서는 어떻게 만들 수 있는지 보여주는 것에 불과하다) 이런 변화중 하나로 커널의 모든 부분이 대단히 세부적인 억세스 콘트롤 기반을 기초로 사용하도록 수정되었다. 물론 대부분의 리눅스 시스템들은 이러한 root 기반의 보안 모델을 계속 사용하겠지만 이런 기본적인 부분들이 없이도 시스템이 구성될 수 있다. 또 다른 보안 관련 변화 중 하나는 바이너리 모듈(하드웨어 개발 업체에서 제공하는 드라이버와 같은)들이 더 이상 시스템의 시스템 콜 테이블을 수정하여 시스템 콜을 오버로딩할 수 없도록 수정되었다는 점이다. 이것은 오픈 소스가 아닌 모듈들이 커널이나 기타 GPL 기반의 소프트웨어에 보안상의 헛점을 만드는 것을 더 이상 용납하지 않는다는 점에서 보안이 한층 강화됨을 뜻한다. 또 하나의 보안 관련 변화 사항은 리눅스 커널이 이전에 사용되던 하드웨어 변동에 기반한 엔트로피 풀 방식의 랜덤 넘버 제네레이터 대신 하드웨어 랜덤 넘버 제네레이터를 사용할 수 있게 되었다는 것이다. (몇몇 프로세서에 내장되기 시작했다)

리눅스의 가상화

리눅스 2.6의 가장 재미있는 새 기능중 하나는 유저 모드(user-mode) 아키텍쳐를 채용하기 시작했다는 것이다. 이것은 리눅스를 리눅스 자체로 포팅해서 리눅스 상에서 리눅스가 실행된다는 의미이다. 리눅스의 새 인스턴스는 완전히 보통의 응용 프로그램인 것 처럼 실행되게 된다. 응용 프로그램 내부에서 가짜 네트웍 인터페이스나 파일 시스템, 호스트의 디바이스와 통신하도록 만들어진 특수한 디바이스 드라이버를 통해 디바이스를 지원할 수 있게 된다. 이것은 (profiling등) 개발을 위해서나 보안 분석을 위해서 대단히 바람직한 것으로 밝혀졌다. 물론 상당수의 사용자들은 이런 기능을 필요로 하지 않겠지만 대단히 멋진 기능임에 틀림이 없다. (친구들을 감동시켜 보라!)

랩탑 지원

앞서 이야기 한 일반적인 지원들(APM, ACPI, 무선 네트웍 지원등) 이외에도 리눅스는 랩탑 사용자들을 위해 두가지의 분류하기 어렵지만 유용한 새로운 기능들을 제공한다. 첫번째는 소프트웨어 서스펜드 기능 기능(software-suspend-to-disk)이다. 아직은 약간의 버그가 남아 있지만 많은 경우 별다른 문제 없이 사용이 가능한 수준이다. 또 하나의 기능은 시스템 전원이 연결 되어 있는지 여부에 따라 프로세서의 속도를 자동으로 바꾸어 주는 기능이다.

설정 관리(Configuration Management)

리눅스 2.6은 몇몇 작은 기능 개선을 가지고 있다. 주로 개발자들이 커널의 문제에 대해 디버깅을 할 때 큰 도움을 받을 기능이지만 여러대의 서버를 관리해야 하는 관리자들을 위해서도 유용한 기능이다. 간단하게 이야기 해서 커널에 커널 파일 자체의 설정 파일을 내장시킬 수 있다. 여기에는 커널 설정의 각종 옵션들에 대한 정보들이 함께 기록되며, 어떤 컴파일러가 사용되었는지와 기타 동일한 커널을 컴파일 하기 위해 필요한 여러 환경들을 담고 있다. 이 정보들은 /proc 인터페이스를 통해 살펴볼 수 있다.

기존 응용 프로그램 지원

리눅스 커널 2.6이 메이저 업그레이드이긴 하나 사용자 응용 프로그램에서 변화시켜야 할 부분의 거의 없는 것이나 마찬가지이다. 하나의 예외는 쓰레딩에 대한 부분이다. 어떤 응용 프로그램들은 2.4나 2.2에서는 허용되었으나 그 이후에는 허용되지 않는 작업을 하는 경우가 있을 수 있다. 이것들은 어쨌거나 예외적으로 취급해야 한다. 물론 모듈 유틸리티와 같은 저수준에서 동작하는 프로그램들도 동작하지 않을 것이다. 추가적으로, /proc과 /dev에 존재하는 몇몇 파일들과 그 형식이 변화되어 여기에 의존적으로 작성된 응용 프로그램들은 제대로 동작하지 않을 가능성이 있다. (새로운 /sys 버추얼 파일 시스템으로 많은 부분들이 옮겨져서 그렇기도 하다. 호환성을 위해서 /dev 디바이스 이름들도 쉽게 설정할 수 있기는 하다)

이런 것들에 추가적으로 많은 부분이 변경되었다. 첫번째로 리눅스 2.0 이나 그 이전에 만들어진 스왑 파일들은 새로 포맷을 해야 한다. (스왑 파일에는 별다른 중요한 내용이 저장되지는 않기 때문에 대부분의 경우 문제가 되지는 않을 것이다) 아파치나 Zeus등의 웹서버들이 커널 수준의 속도에 접근 할 수 없도록 막는 병목이 제거 되었으므로 커널이 웹 페이지를 직접 서비스 할 수 있는 kHTTPd 데몬이 제거 되었다. Dos/윈도우에서 대용량 하드디스크의 사용을 위한 OnTrack이나 EzDrive등의 디스크 매니저에 대한 자동 감지 기능이 제거 되었다. 마지막으로 플로피 디스크에서 부팅을 하기 위한 특수한 형태의 커널 부트 섹터가 제거되었다. 이제는 SysLinux를 사용해야 한다.

마치며

이 문서는 BitKeeper의 changelog와 소스 여기 저기를 뒤져보고 메일링 리스트의 내용들을 검토하고 Google과 Lycos의 검색 결과를 이리저리 뒤져보아서 작성한 문서이다. 그래서 혹시 잘못된 내용이 포함되어 있거나 중요한 내용이 빠져있거나 필자가 오해하고 있는 부분이 있을 수 있다. 혹시라도 잘못된 내용을 찾게 된다면 필자의 이메일인 jpranevich at kniggit.net 으로 메일을 보내어 수정해주기 바란다.

이 문서의 새 버전은 항상 http://kniggit.net/wwol26.html 에 올려놓고 있다.

번역

이 문서는 영어 이외에도 아래와 같이 여러가지 언어로 번역되어 있다.

Posted by Tornado tornado

댓글을 달아 주세요

늙어서 자꾸 까먹네...

 

/etc/sysconfig/network 파일에서 입력한다...

Posted by Tornado tornado

댓글을 달아 주세요

다. nmap 탐지결과 분석

nmap의 실행 결과는 일반적으로 스캔되어진 호스트의 포트 리스트이다. nmap는 포트들의 "well known" service name, number, state, protocol 등을 알려준다. state는 'open', 'filtered' 'unfiltered'로 정의된다. Open은 호스트의 포트로 accept() 접속이 가능함을 의미한다. Filtered는 방화벽이나 필터, 또는 다른 네트웍 장비가 포트를 보호하고 있거나, 포트가 open 되어 있는지에 관해 nmap이 결정할 수 없음을 의미한다. Unfiltered는 closed 상태이고 firewall/filter가 없음을 의미한다. 대부분의 포트가 Unfiltered 포트이므로 'unfiltered'는 state에는 프린트되지 않는다.

<예제1>

nmap의 기본 옵션을 가지고 스캔하면 다음과 같다. 여기에 -v 옵션을 사용하면 좀더 자세한 정보를 알 수 있다.

Nmap은 타겟을 설정함에 있어 매우 유연한 동작을 보인다. 하나의 호스트 스캔은 물론이고 연속되지 않은 여러 개의 호스트 스캔, 연속되는 여러 개의 호스트 스캔, 클래스 단위의 스캔 등 다양하게 타겟을 설정할 수 있다. 특히 "/mask"를 사용하면 클래스 단위로 스캔을 할 수가 있다.

▶연속되지 않은 여러 개의 호스트를 스캔할 경우 : 호스트 사이에 "," 입력
▶연속되는 여러 개의 호스트를 스캔할 경우 : 첫 번째 호스트와 마지막 호스트 사이에 "-" 입력
▶클래스 단위 스캔 : "/mask" 이용( B class : /16, C class : /24 ), "*" 이용, "-" 이용

예로 B class를 스캔하고 할 때는 172.16.0.0/16 또는 172.16.*.* 또는 172.16.0-255.0-255로 정의해 주면 된다.

<예제2> 만약 inetd.conf 파일에 2222번 백도어 포트가 설정되어 있다면 결과값은 다음과 같이 나온다. 기본 옵션으로 검색하면 2222번 포트가 보이지 않지만 -p 옵션을 사용하여 점검하면 2222번 포트가 open되어 있음을 알 수 있다.

<예제3>

각각의 포트가 누구의 권한으로 실행되고 있는지를 알기 위해서는 -I 옵션을 추가하면 되고, OS 추정 및 TCP Sequence Number의 규칙성을 알기 위해서는 -O 옵션을 추가하면 된다.

<예제4> 호스트가 살아있는지를 알기 위해서는 -sP를 사용한다.

up으로 나오면 호스트가 살아있음을 의미하고, down으로 나오는 호스트가 죽어있거나 방화벽에 의해 차단되어 있음을 의미한다.

<예제5> UDP 포트에 대해 점검을 원하면 -sU를 사용한다.

라. 편리한 X 윈도우 버전 nmapfe

nmapfe은 nmap의 사용을 편리하게 하기 위해 만들어진 X Window System (GTK+) front end이다.

3. 참고자료

http://www.insecure.org/nmap

Posted by Tornado tornado

댓글을 달아 주세요

1. 개요

 

Nmap(Network Mapper)은 네트워크 보안을 위한 유틸리티로, 대규모 네트워크를 고속으로 스캔하는 도구이다. Nmap은 raw IP 패킷을 사용하여 네트워크에 어느 호스트가 살아있고, 그들이 어떠한 서비스(포트)를 제공하며, 운영체제(OS 버전)가 무엇이며, filter/firewall의 패킷 타입이 무엇인지 등 네트워크의 수많은 특징들을 점검할 수 있다.

Nmap의 주요 특징을 살펴보면 다음과 같다.

 

Flexible

IP 필터, 방화벽, 라우터 등으로 구성되어 있는 네트워크를 점검하기 위한 도구로, 포트 스캐닝 메카니즘(TCP & UDP), OS 검색, pings sweeps 등을 점검할 수 있다.

Powerful

Nmap은 수천 수백 개의 호스트를 가진 거대한 네트워크를 고속으로 스캔할 수 있다.

Portable

Linux, Open/Free/Net BSD, Solaris, IRIX, Mac OS X, HP-UX, Sun OS 등 대부분의 운영체제에서 사용할 수 있다.

Easy

Nmap은 사용자들에게 강력하면서도 다양한 set을 제공함에도 불구 하고 "nmap -O -sS targethost"와 같이 아주 간단하게 사용할 수 있다. 또한 command line 및 graphical (GUI) 버전 모두를 지원한 다.

Free

Nmap의 주요 목적은 좀더 안전한 인터넷을 만드는데 도움을 주고 자 하는 것과 administrators/auditors에게 그들의 네트워크를 점검 하기 위한 보다 강력한 도구를 제공하기 위한 것이다. Nmap은 http://www.insecure.org/nmap에서 무료로 다운받을 수 있으며, GNU General Public License(GPL)하에 모든 사람이 자유롭게 사용할 수 있다.

Popular

현재 네트워크 스캔 툴 중에서 가장 많이 이용되고 있는 툴이다.

Nmap에서 사용되는 대부분의 기술은 호스트의 어떤 포트가 listening 되고 있는지를 스캔하기 위해 사용된다. 이 포트들은 통신 가능한 채널로 이들 포트들에 대한 매핑은 호스트에 대한 정보 교환을 용이하게 한다. 따라서 nmap은 시스템 관리자는 물론이고 해커를 포함한 네트워크 환경을 점검하기를 원하는 모든 사람에게 매우 유용한 도구로 사용된다.

Nmap은 방대한 네트워크를 점검하기 위한 강력한 포트 스캐너로 다음과 같은 것을 지원한다.

o Vanilla TCP connect() scanning,
o TCP SYN (half open) scanning,
o TCP FIN (stealth) scanning,
o TCP ftp proxy (bounce attack) scanning,
o SYN/FIN scanning using IP fragments (bypasses packet filters),
o UDP recvfrom() scanning,
o UDP raw ICMP port unreachable scanning,
o ICMP scanning (ping-sweep), and Reverse-ident scanning.

 

 

참조 : CERTCC-KR

Posted by Tornado tornado

댓글을 달아 주세요

2. 설치 및 운영

가. nmap 설치

nmap은 http://www.insecure.org/nmap에서 구할 수 있다. nmap의 설치 방법은 매우 간단하다. 많은 critical 커널 인터페이스들이 루트 권한을 요구하듯이 nmap 또한 가능하면 루트권한으로 운영되어야 한다.

▶ linux에 설치하기

"*.tgz" 형식과 "*.rpm" 모두를 다운로드 할 수 있다. 여기에서는 Linux 2.2.5-22에 설치하였다.

① rpm 파일로 받기

# rpm -vhU http://www.insecure.org/nmap/dist/nmap-2.53-1.i386.rpm

설치가 정상적으로 끝났다면 /usr/bin에 nmap 실행파일이 복사될 것이다.

② tgz 파일로 받기

최신버전으로 다운로드 받은 후 압축을 푼다. 여기에서는 nmap-2.53 버전으로 설치했다.

# gzip -cd nmap-2.53.tgz | tar xvf -

archive를 풀면 nmap-2.53이라는 디렉토리가 생성되는데 이 디렉토리로 이동한다.

# cd nmap-2.53

INSTALL 파일을 읽어보면 설치요령이 설명되어 있는데 다음과 같이 하면 특별한 에러 없이 설치가 된다.

# ./configure
# make
# make install

▶Sun OS에 설치하기

최신버젼을 다운받아 다음과 같이 하면 에러 없어 설치된다.

# gzip -cd nmap-2.53.tgz | tar xvf -
# cd nmap-2.53
# ./configure
# make
# make install

나. nmap 실행

nmap의 사용방법은 다음과 같다. scan type 및 option에 대해서는 nmap의 man page에 자세히 나와있다.

USAGE : ./nmap [Scan Type(s)] [Options]

Scan Type

-sT

TCP connect() scan : TCP scanning의 가장 기초적인 형태로 connect() 함수를 사용해서 모든 포트에 대해 스캔하는 방식이다. 만약 포트가 listening 상태라면 connect()는 성공할 것이고, 그렇지 않으면 reachable 되지 않는다.

-sS

TCP SYN scan : full TCP 접속을 하지 않으므로 "half-open" 스캐닝이라 한다. 하나의 SYN 패킷을 보내어 SYN|ACK 응답이 오면 그 포트는 listening 상태임을 나타내며, RST 응답이 오면 non-listener임을 나타낸다. 이 기술은 하나의 패킷을 보내어 SYN|ACK 응답을 받으면 그 즉시 RST 패킷을 보내서 접속을 끊어버린다. 이렇게 하면 접속이 이루어지지 않은 상태에서 접속을 끊었기 때문에 로그를 남기지 않는 경우가 대부분이다. custom SYN packet을 만들기 위해서는 루트 권한이 필요하다.

-sF
-sX
-sN

Stealth FIN, Xmas Tree, Null scan : 이들은 SYN 패킷을 막아놓은 방화벽이나 패킷 필터 또는 Synlogger와 Courtney 같은 스캔을 탐지하는 프로그램들을 무사히 통과할 수 있다. open 포트로 FIN 패킷을 보내면 이 패킷을 무시하고, closed 포트로 보내면 RST 패킷이 온다. 이들 스캔은 주로 유닉스계열 OS에서만 사용 가능하며, 루트권한이 필요하다.

-sP

Ping scanning : 네트워크의 어느 호스트가 살아있는지를 알고 싶을 때 사용한다. nmap은 명시한 네트워크의 모든 IP 주소로 ICMP echo request packet을 보내어 이것을 행한다. 호스트가 살아 있다면 응답을 보낸다. 하지만 microsoft.com 같은 일부 사이트는 echo requst packet을 방해한다. 따라서 nmap은 포트번호 80(default) 으로 TCP ack packet을 보낸다. 만약 RST back을 받았다면 이 시스템은 살아있는 것이다.

-sU

UDP scans : 이것은 호스트의 어떠한 UDP 포트가 open 되어 있는지를 결정하기 위해 사용된다. 이 기술은 시스템의 각 포트에 0 바이트의 udp 패킷을 보낸다. 만일 ICMP port unreachable 메시지를 받았다면 이 포트는 closed 상태이며, 다른 경우라 open 상태라고 할 수 있다. 일부에서는 UDP 스캐닝이 무의미하다라고 말한다. 하지만 최근의 Solaris rcpbind hole을 보면 Rpcbind가 32770 이상의 정의되지 않은 UDP 포트에서 발견되고 있다. 이것은 111 포트가 방화벽에서 차단되어지는 것과는 별개의 문제이다. 따라서 UDP 스캐너로 30,000번 이상의 high 포트들이 listening 상태인지를 점검해봐야 한다. 이것은 루트만이 실행가능하다.

-sA

ACK scan : 이 방법은 방화벽의 룰셋을 정밀하게 계획하기 위해 사용된다. 특히 방화벽이 stateful한지 아니면 단순히 들어오는 SYN 패킷을 차단하는 패킷필터인지를 점검하는데 도움이 된다. 포트에 ACK 패킷을 보내어 RST 응답을 받으면 그 포트는 "unfilterd"이며, 아무런 응답이 없으면 "filtered" 이다. nmap은 "unfilterd" 포트는 프린트하지 않는다.

-sW

Window scan : TCP Window 크기의 변칙 때문에 filtered/nonfiltered 뿐만 아니라 open 포트도 스캔할 수 있다는 점을 제외하면 ACK scan과 매우 유사하다.

-sR

RPC scan : 이 스캔 방법은 nmap의 다양한 포트 스캔 방법을 조합해서 이루어진다. 이것은 열려져있는 TCP/UDP 포트에 대해 그들이 RPC 포트인지, 서비스를 제공하는 프로그램은 무엇이며, 버전은 무엇인지 등을 확인하기 위해 SunRPC program NULL commands를 계속 보내게 된다. 따라서 호스트의 portmaper가 방화벽(또는 TCP wrapper)안에 있다 하더라도 'rpcinfo -p'와 같은 정보를 얻을 수 있다.

-b

FTP bounce attack : 익명 FTP 서버를 이용해 그 FTP 서버를 경우해서 호스트를 스캔한다. 이를 FTP 바운스 스캔이라 한다.

 

 

Options

 

-P0

이것은 방화벽에 의해 ICMP echo requests (or responses)를 막아놓은 네트워크의 스캔을 가능하게 한다. ping을 막아놓은 호스트를 스캔하기 위해서는 -P0 나 -PT80을 사용해야 한다.

-PT

어느 호스트가 살아 있는지를 알기 위해 TCP "ping"을 사용한다. 이것은 ICMP echo request 패킷을 보내고 응답을 기다리는 대신에, 네트워크에 TCP ACK를 보내어 응답이 오기를 기다린다. RST 응답이 오면 호스트는 살아 있는 것이다. 이 옵션은 ping 패킷을 차단하는 네트워크나 호스트을 스캔하는 동안은 호스트가 살아 있는 것과 같다. -PT를 사용 하며, 디폴트 포트는 80이다.

-PS

이 옵션은 루트사용자를 위해 ACK 패킷 대신에 SYN (connection request)을 사용한다. 호스트가 살아 있다면 RST (or, rarely, a SYN|ACK)로 응답 한다.

-PI

이 옵션은 오리지날 ping (ICMP echo request) packet을 사용한다. 이것은 살아있는 호스트를 찾으며 또한 네트워크의 subnet-directed broadcast addresses를 찾는다. 이들은 들어오는 IP 패킷을 컴퓨터의 서브넷으로 브로드케스트하기 위한 IP 주소이다. 따라서 denial of service attacks (Smurf is the most common) 가능성이 있다면 이들은 제거되어야 한다.

-PB

이것은 ping 기본 형태로 ACK (-PT)와 ICMP (-PI) 모두를 사용한다.

-O

이것은 TCP/IP fingerprinting을 통해 리모트 호스트를 확인하는데 사용된다 다시 말해 리모트 시스템의 운영체제를 점검해 준다. 루트권한이 필요하다.

-I

RFC 1413에 정의되어 있는 ident 프로토콜을 사용해 open되어 있는 포트가 어떤 사용자에 의해 열려 있는지 검사한다.

-v

verbose mode : interactive한 사용에 매우 유용한 옵션이다.

-h

nmap의 'quick reference'이다.

-p

점검하고자 하는 포트를 지정하는 옵션이다. 예로 23번 포트를 점검하려면 '-p 23' 하면 된다. 또한 '-p 20-30,139,60000-'은 20에서 30사이의 포트와 139번 포트, 60000번 이상의 포트에 대해 스캔하라는 뜻이다.

-F

nmap-services에 나열된 포트만 스캔한다.

-n / -R

DNS lookup을 하지 않는다. / DNS lookup을 한다.

-S

패킷의 source 주소를 지정한다.

-e

네트워크의 인터페이스를 지정한다.

-g

패킷의 source 포트번호를 지정한다.

-oN

스캔한 결과를 로그 파일에 남긴다(사람이 읽기 편한 포맷).

-oM

스캔한 결과를 로그 파일에 남긴다(컴퓨터가 읽기 편한 포맷).

Posted by Tornado tornado

댓글을 달아 주세요

Ftp 서비스

OS/LINUX 2004. 6. 4. 11:06
다음 이전 차례

4. FTP 서비스

FTP는 TCP/IP의 아주 중요한 부분으로 남아있는 서비스이다. 웹의 등장으로 조금 무기력해진 것같이 보여도 대량 파일 전송에는 역시 FTP 서비스가 최고이다. 그리고 FTP는 사라지기보다는 웹 브라우저 안으로 통합되는 양상을 띠고 있다. FTP 서비스는 크게 두 가지로 나눌 수 있는데 서버 시스템에 등록한 사용자들을 위한 일반적인 FTP와 익명의 모든 사용자들에게 개방하는 익명 (Anonymous) FTP가 있다. 등록 사용자에 대한 FTP 서비스는 텔넷과 비슷하게 사용자명과 패스워드를 입력받고 자기 권한만큼 파일에 접근해서 받아갈 수 있으며 자신의 홈 디렉토리 같은 곳에는 업로드도 가능하다. 약간의 주의를 요하는 것이 바로 익명 FTP이다. 일단은 여러분이 갖고 있는 대부분의 소규모 FTP에 그렇게 많은 접속이 이루어지지는 않을지 모르나 커다란 FTP 사이트를 건설하려고 한다면 정말로 엄청난 시스템이 아니면 안될 것이다.

4.1 익명 FTP 서비스 준비사항

한 마디로 텔넷과 마찬가지로 리눅스 설치와 함께 FTP 서비스는 기본으로 이루어진다. 여러분의 리눅스 머신이 이미 네트워크에 존재한다면 여러분도 모르는 사이에 누군가 이미 여러분의 컴퓨터를 익명 FTP로 사용하고 있는지도 모른다. FTP 서비스 또한 수퍼 서버 inetd에 의해 관리된다. 빠른 반응 시간을 갖기 위해서는 ftpd를 그냥 띄워도 괜찮다.

4.2 새로운 FTP 데몬의 설치

/usr/sbin 디렉토리로 가보도록 하자.

freeyong:/usr/sbin# ls -l *ftpd-rwxr--r--   1 root     root         8528 Sep  9 14:14 in.tftpd*-rwxr-xr-x   1 root     bin         77444 Dec  6  1995 wu.ftpd*

위에서 보는 바와 같이 wu.ftpd가 없다면 네트워크 키트를 받아다가 설치해 주는 것이 좋다. 기본 설정치이다. 워싱턴 대학에서 만든 뛰어난 ftp 데몬이며 거의 모든 유닉스 계열 사이트에서 찾아 볼 수 있을 것이다. 우리가 설치할 ftp 데몬은 바로 워싱턴 대학의 wu.ftpd이다.

4.3 익명 FPT의 보안 점검

익명 FTP는 특히 안전성이 중요하다. 항상 악의를 가진 사람들이 존재한다는 식으로 생각하는 것은 좋지 않다. 보안을 하는 이유는 크랙커를 막겠다는 것보다는 시스템의 핵심부를 타인에게 드러내지 않음으로써 예기치 않은 일들을 막고자 하는 것이다. 그럼 점검을 해보자.

ftp:*:404:1::/home/ftp:/bin/bash

/etc/passwd를 보면 위와 같이 되어 있는 것을 볼 수 있을 것이다. 패스워드 필드에 애스터리스크 문자만 있으므로 ftp라는 로그인명으로는 텔넷 접속같은 것은 할 수 없도록 되어 있다. 접속 자체가 불가능하기는 하지만 안전하게 하기 위해서 셸도 /bin/bash 같은 걸로 지정하는 것보다는 그냥 /bin/false같은 것으로 지정해두는 것도 좋다. 슬랙웨어, 알짜웨어 등 모든 경우에 있어서 ftp라는 사용자는 위에서 보면 1번 그룹에 속하는 것으로 나와있는데 1번 그룹은 bin 그룹이다. 보통은 anonymous라는 그룹을 새로 만든 후에 그 그룹의 멤버로 설정하면 좋을 듯 하다.

4.4 익명 FTP 홈 디렉토리

익명 FTP의 홈 디렉토리는 위에서처럼 /home/ftp이다. 자, 잠시 여러분이 어떤 익명 FTP에 들어갔을 때를 생각해보자. 그러면 전형 적으로 다음과 같은 디렉토리가 보일 것이다. 만약 여러분이 cd / 라는 명령으로 시스템의 루트 디렉토리로 가려고 해보았자 여러분이 원하는 디렉토리로 가는 것이 아니라 실제로는 전체 시스템에서 /home/ftp에 해당하는 곳에 머무를 뿐이다. 이것이 익명 FTP와 일반 사용자들의 FTP가 다른 점이다. 익명 FTP의 경우에는 ftp 사용자에게 있어 /home/ftp가 마치 / 처럼 작동하도록 되어 있다. 내부적으로 chroot라는 것이 작동하여 /home/ftp라는 디렉토리를 루트 디렉토리처럼 인식하도록 하니까 /home/ftp 이하의 모든 디렉토리들은 접근을 할 수 없도록 한 것이다. 각 디렉토리를 점검해보도록 하자.

drwxr-xr-x    8 root  wheel   1024 Aug 23 20:30 .drwxr-xr-x     8 root  wheel   1024 Aug 23 20:30 ..drwxr-xr-x     2 root  wheel   1024 Aug 23 20:30 bindrwxr-xr-x     2 root  wheel   1024 Aug 23 20:30 etcdrwxrwxrwx   3 root   wheel   1024 Oct 11 16:21 incomingdrwxr-xr-x     2 root  wheel   1024 Nov 17  1993 libdrwxr-xr-x     2 root  wheel   1024 Aug 23 20:30 pubdrwxr-xr-x     3 root  wheel   1024 Aug 23 20:30 usr-rw-r--r--     1 root  root     312 Aug  1  1994 welcome.msg

우선 /home/ftp 즉  ftp 디렉토리는 ftp라는 사용자가 소유하고 있어야 한다. 그리고 다른 사람들은 쓰기 퍼미션을 가져서는 안된다.  ftp/bin 즉 /home/ftp/bin에는 ls라는 실행파일이 적어도 하나 들어있어야 하며 소유권은 수퍼 유저, 루트가 가지고 있으며 ls의 퍼미션은 111이다.  ftp/etc는 수퍼 유저의 소유이며 쓰기 금지가 되어 있어야 한다. 내용을 보면 passwd와 group 파일이 있는데 실제로는 시스템 전체의 패스워드와 그룹 파일과는 다른 파일이다. 이 파일이 있는 이유는 dir 했을 때 숫자가 아니라 사용자명 그룹명이 나오도록 하기 위함이다. 잘 보면 패스워드 같은 건 아예 없다는 것을 알 수 있다. 이 파일을 지우면 온통 사용자명과 그룹명이 숫자로만 나올 것이다.  ftp/pub는 일단 읽기만 되어야 한다. 업로드 파일은  ftp/incoming을 이용하라. 배포판들에서 incoming 디렉토리의 소유자가 잘못되어 있는데 소유자는 루트가 아니라 ftp여야 한다. 루트 권한으로 들어가서 chown ftp  ftp/incoming이라고 하면 된다. 단지 ftp 사용자에게만 쓰기 권한이 있어도 업로드를 할 수 있도록 되어 있다. ftp 사용자에게만 쓰기 권한이 있도록 조정한다. 일단 한 번 올린 파일에 대해서는 지울 수 없다. 사람들에게 파일만 올릴 것이 아니라 설명서도 꼭 올려주도록 부탁한다. 관리자는 정기적으로 incoming 디렉토리를 보고 pub 디렉토리 밑에다 알맞게 범주로 나누어서 다시 사용자들이 다운로드만 할 수 있게 해준다.

4.5 사용자 환영 메시지

/home/ftp 디렉토리를 보면 welcome.msg 파일을 볼 수 있다. 그곳에다 사용자들에게 알려야 할 사항을 적어주면 된다. 시스템 정기 점검, 업그레이드 소식 등 또는 새로운 자료 소식을 항상 올려주면 좋을 것이다. 각 디렉토리로 들어갈 때마다 간단한 안내를 해주는 경우가 있다. 이 때는 .message라는 파일을 각 디렉토리에 만들어서 화면에 표시하고 싶은 내용을 적으면 된다. 피리어드(.) 문자로 시작하는 파일임에 유의하라.

4.6 시디롬 내용을 제공하려고 할 때

시디롬을 마운트시켜서 그 내용을 제공하는 것도 안전한 방법 중의 하나라고 생각한다. 그리고 하드디스크 용량을 절약할 수 있기 때문에 아주 좋다. 그런데 많은 사람들이 시디롬 내용을 익명 FTP로 제공하려고 할 때 약간의 어려움을 겪고 있는 것 같다. 여러분이 원하는 곳에 마운트를 했다고 생각하거나 또는 기존에 /cdrom으로 마운트된 것을 /home/ftp 하위 디렉토리에서 링크하면 되지 않을까 생각해도 전혀 시디롬이 있는 디렉토리를 찾지 못하기 때문이다. 왜 그럴까? 바로 익명 FTP는 /home/ftp 를 chroot 명령으로 강제로 루트(/) 디렉토리처럼 보도록 만들었기 때문이다. 따라서 여러분이 무심코 /home/ftp 밖에 있는 디렉토리를 접근하려고 하거나 링크하려고 하면 찾을 수 없다고 나온다. 따라서 시디롬을 보통은 /home/ftp 디렉토리에 .1 처럼 도트로 시작하는 디렉토리를 만든 후에 다음과 같이 해준다.

mount -t iso9660 /dev/cdrom /home/ftp/.1

그리고 /home/ftp 안에서는 모두 다 /.1을 기준으로 시디롬의 각 디렉토리를 링크해두면 된다. 일단 /home/ftp/.1이라는 디렉토리에다가 마운트를 하고 익명 FTP로 들어가게 되면 그 디렉토리는 chroot 명령에 의하여 이제부터는 /.1로만 인식된다. 그것은 FTP 클라이언트나 서버에게도 마찬가지이다. 따라서 만약에 시디롬의 slakware라는 디렉토리를 /pub/slakware라는 디렉토리로 서비스하고 싶다면 다음과 같이 한다.

cd /home/ftpcd publn -s /.1/slakware slakware ( 절대로 /home/ftp/.1이 아니다. )

또 다른 고용량 하드디스크를 마운트해서 사용하려고 한다면 마운트를 꼭 읽기 전용으로 해두기 바란다. -o ro 옵션을 꼭 붙이기 바란다.

4.7 링크 주의!

보안에서 정말로 중요시해야 할 것이 있다. 바로 링크의 문제이다. 물론 /home/ftp 라는 디렉토리 구조 밖의 디렉토리를 /home/ftp 안쪽에다 링크해보았자 아무런 소용이 없다. 앞서 말한 바와 같이 익명 FTP 세션에서 chroot가 호출되면 /home/ftp 밖의 디렉토리에 대한 보호가 이루어지기 때문이다. 그래서 위와 같이 특정 파티션을 /home/ftp 안 쪽에 마운트하는 방법을 사용하는데 그러한 파티션은 꼭 익명 FTP 용으로만 쓰기 바란다. 만약 익명 FTP가 아니라 다른 일반적인 용도로 사용하게 된다면 링크를 따라 올라가다 내려오는 순간 우연치 않게 여러분이 원하지 않는 디렉토리를 보여줄 수도 있게 된다. 예를 들어 필자는 알짜웨어 시디롬을 익명 FTP로 제공하기 위해 우선 시디롬을 /home/ftp/.1 이라는 디렉토리에 마운트하였다. 그리고 pub 디렉토리에 가서 다음과 같이 했다고 치자.

ln -s /.1/rootdsks rootdsks

자, 확인을 하기 위해서 익명 FTP로 들어가보자.

cd pubcd rootdskscd ..

여기서 우리는 다시 pub로 돌아오는 것이 아니라 .1이라는 디렉토리로 들어가게 된다.

4.8 FTP 서비스의 선전

FTP 서비스의 약점을 하나 들라면 필자는 바로 선전 가능성이라고 말하고 싶다. 각광받고 있는 웹 서비스보다는 자기 자신을 화려하게 선전할 방법을 갖지 못하는 처지이기 때문이다. 따라서 훌륭한 FTP 서비스에 대해서는 웹 페이지를 이용하여 선전을 잘 해주기 바란다. 그래야 사용자들이 많이 이용할 수 있다. 웹 페이지에서 FTP 사이트로 링크를 해주는 것도 좋은 방법이다. 이렇게 하면 웹 서비스와 FTP 서비스가 조화를 이룰 수 있다.

4.9 익명 FTP 접근 권한 세팅

접근 권한에 대한 세팅은 /etc 디렉토리의 ftpusers, ftpgroups라는 파일을 통해 서 한다. ftpusers라는 파일의 내용을 한 번 살펴보자.

# The entire line gets matched, so no comments or extra characters on# lines containing a username.#rootuucpnews# End of ftpusers.news

위에서 나열한 root, uucp, news라는 사용자에 대해서는 FTP 접근 자체를 불 허한다. 즉 ftpusrs에 등록된 사용자는 접근 권한을 받는 것이 아니라 접근 권한을 제한 받는다는 것이다. 이들 열거한 사용자들이 너무도 강력하기 때문에 커다란 문제를 일으킬 소지가 크다. 동시 사용자 제한에 대해서 알아보자. 익명 FTP를 무한정 모든 사람들이 사용할 수 있게 할 수는 없다. 여러분의 서버 성능과 대역폭에 따라 세팅을 해야 할 것이다. 지역(local)사용자는 대역폭을 크게 요구하므로 더욱 적은 인원으로 제한해야 하며 원격(remote) 사용자는 전송률이 비교적 상당히 떨어지므로 훨씬 많은 인원을 수용할 수 있을 것이다. 그것을 설정하는 파일이 바로 /etc/ftpaccess 이다.

limit   local   20  Any                  /etc/msgs/msg.toomanylimit   remote  100 SaSu|Any1800-0600   /etc/msgs/msg.toomanylimit   remote  60  Any          /etc/msgs/msg.toomany

우선 첫줄을 보면 지역 사용자는 어느 때든 (Any) 20명으로 제한한다. 그리고 사람이 너무 많아서 접근을 거부할 때는 /etc/msgs/msg.toomany라는 파일 내용을 보여준다. 두 번째 줄의 경우 원격 사용자의 경우 SaSu 즉 토요일 (Saturday), 일요일(Sunday) 또는 어느 날이든 18시부터 06 시까지는 100명으로 제한한다. 이 조건을 만족하지 않으면 60명으로 제한된다. 조건식에 있어서 첫 번째 조건식이 유효하면 그것만 적용한다는 사실을 기억하기 바란다. 두 번째 줄이 원격 사용자에게 적용되면 세 번째 줄은 처리하지 않는다. 사용 인원을 -1로 세팅하면 인원 제한을 없애는 것이다.


다음 이전 차례
Posted by Tornado tornado

댓글을 달아 주세요

[펌] L4 switch

OS/LINUX 2004. 6. 4. 00:26
Layer-4 Switching 개념이해(1)

LAN에서는 현재 각종 스위칭 기법들이 범람하고 있어서 춘추 전국시대를 방불케 하고 있다. 예를 들면, 3계층 스위칭, 4계층 스위칭, 무 계층(Layerless) 스위칭, 태그(Tag) 스위칭, IP 스위칭, 네트워크 계층 스위칭, 멀티레이어 스위칭, MPLS(MultiProtocol Label Switching) 등등. 이런 기법들이 미래 네트워킹 솔루션의 중요한 부분들이 될 것은 확실하다. 한마디로 말하면, 이런 스위칭 기법들의 대부분은 네트워킹 요소 중의 라우팅 측면에 대해 업체 또는 단체 고유의 해답을 제시하고 있으며 이런 방안들을 통해 네트워크가 이전에 비해 더 나은 성능을 제공하게 하여 네트워크의 확장성을 제고하는데 그 목적을 두고 있다고 말할 수 있다.

우선, 이러한 여러 가지 스위칭 기법들의 등장 배경인 라우터의 한계에 대해 알아보고 각종 스위칭 기법들에 대해 살펴보기로 하자.

라우터의 한계 (Layer-4 Switch의 등장배경)

지난 수년간 라우터에는 많은 기능들이 부가되었다. 라우터는 멀티프로토콜을 지원하며 LAN과 WAN을 연결해주고 구성 파라메터들도 수백 개로 늘어나 세련된 패킷 필터링이 가능하게 되었으며 네트워크에 대해 과거에 비해 상당한 제어력도 제공해주고 있다. 고속의 프로세서와 메모리 덕분에 라우터의 성능을 저해하지 않고 많은 기능을 제공할 수 있었다. 하지만, 네트워크에서 갈수록 더 많은 트래픽을 처리하게 되자 모든 패킷의 헤더를 처리해야만 하는 라우터에서 정체 현상이 빈번하게 발생하기 시작했다. 설상가상으로 라우터에서 정체가 발생하면, 라우터는 패킷을 폐기하기 시작하고 이는 다시 출발지의 재전송을 초래하여 상황은 더욱 악화되기도 한다. 물론, 이에 대한 각종 큐잉 기법이나 캐싱 기법들이 있기는 하지만 근본적인 해결 방안은 되지 못하고 있다. 또한, 확장성이 매우 뛰어난 라우터도 있으나 문제는 가격이 만만치 않다.


그렇다면, 어떻게 이 문제를 해결할 수 있을까? 답을 찾기 위해 잠시 시장에 들르기로 하자. 시장에서는 손님이 살 물건을 가져오면 주인이나 점원이 가격을 계산하고 돈을 지불하면 물건을 준다. 하지만, 손님이 많고 손님들이 구매한 물건의 종류가 늘어나면 계산대에는 줄이 늘어선다. 손님이 늘고 물건 종류가 늘어날수록 줄은 더 길어진다. 또한, 줄 중간에 신용카드나 수표로 지불하는 사람이 있으면 상황은 더 악화되어 대기 시간이 더 늘어난다.


최근 몇 년 동안 갑자기 수가 늘어난 양판점이나 대형 슈퍼마켓에서는 이에 대한 해답을 제공하고 있다. 슈퍼마켓에서는 손님이 물건을 가져오면 계산대의 점원이 바코드 리더로 물건에 붙어있는 바코드를 읽는다. 그러면 가격이 아주 신속하게 계산된다. 또한, 수표나 신용 카드 구매자들과 현금 구매자들은 서로 다른 계산대를 이용한다.


즉, 슈퍼마켓에서는 최소의 비용으로 사용자의 대기 시간을 최소화하고 서비스를 개선하기 위해서 바코드를 도입하였고 사용자 유형별로 별도의 계산대를 마련하고 있으며 계산대의 수도 시장의 점포보다 많이 가지고 있다. 또한, 점원들도 386 세대가 아닌 586 세대가 주류를 이루고 있다. 한마디로 말하면, 최근의 대형 매장에서는 바코드(라벨), 바코드를 기반으로 한 가격 계산(라벨 스위칭), 더 빠른 점원(라우터)과 늘어난 계산대(대역폭)를 모두 갖추고 있는 셈이다.

Layer-4 Switch 선택시 고려 사항

4계층 스위치는 트래픽 플로우에 따라 더 한층 정밀한 네트워크 튜닝(Tuning)과 우선 순위 부여 기능을 통해 2/3계층 스위칭을 한 차원 끌어올린 장비라 할 수 있다. 2계층 스위치는 MAC(Media Access Control) 어드레스를 사용하여 스위칭 기능을 수행하고 3계층 스위치는 IP 같은 네트워크 어드레스를 기반으로 라우팅을 하며 4계층 스위치는 4계층 프로토콜의 헤더 정보를 이용하여 정책 기반의 라우팅을 수행한다.


또한, 4계층 스위치는 어플리케이션에 따라 트래픽에 대한 우선 순위부여 기능도 수행한다. 이 기능은 네트워크 관리자들에게 어플리케이션을 제어할 수 있는 능력을 제공한다. 그리고 4계층 스위치는 네트워크 전반에 대한 CoS(Class of Service) 구현 방법을 제공한다.


4계층 스위치를 도입할 경우에는 다음 몇 가지 사항을 사전에 고려해야만 한다.


▶ 포트에 대한 우선 순위 부여 방안

어떤 어플리케이션이 어떤 포트를 사용하고 있는가? Well-known 포트 이외의 포트 번호를 사용하고 있는 어플리케이션의 포트 번호를 정확하게 파악하고 있어야만 Mission-critical Application에 상응하는 우선 순위를 부여할 수 있다. 또한, 포트 번호가 동일한 어플리케이션을 여러 명의 사용자가 동시에 사용하고 있다면 무엇을 기준으로 우선 순위를 부여할 것인가? 또한, 시시각각으로 포트 번호가 바뀌는 어플리케이션에 대해서는 어떤 방식으로 우선 순위를 부여할 것인가?


▶ 표준화 작업

아직까지는 복합(Heterogeneous) 네트워크 환경에서의 4계층 스위칭에 대한 표준이 없다. 즉, 여러 제품 공급업체들 간의 우선 순위 부여 방식이나 처리 방식이 서로 달라서 상호 운용성 (Interoperability)이 떨어진다.


▶ 중복 기술

IEEE 802.1p 표준도 트래픽에 대한 우선 순위 부여 기능을 가지고 있으며 4계층 스위치도 우선 순위 부여 기능을 가지고 있다. 이 경우, 언제 어떤 기술을 사용할 지를 결정해야 한다.


4계층 스위치는 어플리케이션 기반의 트래픽 우선 순위 부여 분야에서 많은 가능성을 가지고 있으나 네트워크 관리자는 4계층 스위치가 제공하는 고급 기술을 사용하기에 앞서 전술한 사항에 대한 준비를 갖추고 있어야 할 것이다.




Load Balancing(부하 분산) 기능


현재 많이 사용되고 있는 네트워크 장비들 즉, 2/3계층 스위치들이 네트워크 자체의 성능 개선을 통한 확장성 개선에 초점을 두었다면, 최근 등장하고 있는 4계층 이상을 지원하는 스위치는 사용자들에게 제공되는 서비스에 초점을 둔 장비들이라고 할 수 있다.


이런 스위치들은 게이트웨이(Gateway)와 마찬가지로 사용 목적에 따라 접두어가 붙는 경우가 많다. 즉, TCP/IP 네트워크와 IBM 호스트를 연동하기 위해 사용하는 게이트웨이를 3270 게이트웨이나 SNA 게이트웨이 혹은 SNA 서버라고 부르는 것처럼 부하 분산 스위치 또는 웹 스위치처럼 사용 목적에 따라 이름을 붙이는 경우가 많다.


인터넷의 보급 확산으로 기업과 단체는 물론이고 개인들도 웹을 통해 인터넷을 많이 사용하고 있다. 예를 들면, 웹 기반의 인트라넷, 쇼핑 몰, 검색 엔진, 사이버 주식 조회/거래, 사이버 스쿨 등이 널리 이용되고 있으며 앞으로는 더욱 더 많이 이용될 전망이다. 이런 서비스들의 특징은 다수의 사용자들이 동일한 내용(Content)에 동시에 액세스한다는 것이다.


사용자가 많지 않을 경우에는 단지 1 ~ 2대의 서버를 두고 캐싱 기술을 사용하여 어느 정도 원활한 서비스를 제공할 수 있으나, 사용자의 수가 늘어감에 따라 동시 접속 사용자 수도 늘어나게 되어 정체 현상이 발생하게 된다. 이럴 때는, 여러 대의 서버를 부하 분산 스위치에 연결하여 동시 접속 사용자들의 요청(Request)을 여러 대의 서버에 고르게 분산시켜서 원활한 서비스를 제공한다.

참고 : TCP 포트 번호
* TCP 포트 번호 0 ~ 1023은 네트워크 전체에서 어플리케이션이 사용하는 등록된 Well-known 포트 번호이다.
** ---- 에플리케이션층 프로토클 / 포트 번호 -----
----FTP / 20(데이타), 21(컨트롤)
----Telnet / 23
----SMTP / 25
----HTTP / 80
----NNTP / 119
----SNMP / 161, 162(SNMP 트랩)

Layer-4 Switching 개념이해(2)

Server Load Balancing(서버 부하 분산) 지원

서버 부하 분산
Internet을 기반으로 한 Network 환경이 날이 갈수록 복잡해지고 무거워지고 있다. 사용자들 client들은 예를 들어 HTTP라는 하나의 서비스를 받기 위해 Internet 어느 공간상의 실제 HTTP 서버에 접속하여 원하는 서비스를 받게 된다. 즉 서버가 Internet이라는 Network 환경에 붙어만 있다면 사용자들은 그것의 실질 적이며 물리적인 위치나 주소는 문제가 되지 않고 서비스를 받을 수 있다.
그러나 서버의 입장에서는 사용자들 client들의 입장보다 더 복잡한 문제를 갖는다. 사용자의 입장에서와 같이 서버도 Internet의 어느 한 공간에 접속되어 있다면 사용자에게 서비스를 제공하는 방법적인 문제에는 다를 것이 없으나, 서비스를 안정적으로 그리고 지속적으로 아주 많은 사용자들에게 제공하기 위해서는 서버 자신이 서비스를 처리할 수 있는 능력이 아주 강해야만 한다. 더 많은 사용자에게 정확한 서비스를 하기 위해서는 지금보다 더 강력한 성능의 서버 - 처리 능력이 우수한 - 로의 업그레이드가 거의 유일한 해결책이 되어 왔다. 그러나 현실적으로 무한정 서버를 업그레이드할 수는 없다.

위와 같은 문제를 해결하기 위하여 많은 방법들이 개발되었고 시도되었다. Cache Server를 두어 자주 참조되는 서비스를 WAN Traffic이 아닌 저장된 Local Traffic으로 처리하는 방법이나, 여러 개의 서비스, 예를 들어 HTTP, FTP, SMTP, POP3, NNTP 등를 각기 다른 서버에 두는 방법, 그리고 같은 기능을 하는 동급 수준의 서버를 여러 대 두어 전체 트래픽의 일부분만을 담당하게 하는 방법이 그것이다.


마지막 방법은 기존의 서버보다 아주 고성능의 서버 한대를 구입하는 것보다 동급 수준의 서버를 여러 대 두고, DNS에 같은 URI에 서로 다른 서버의 IP 주소를 할당함으로써 URI 참조시 각기 다른 서버에 서비스를 접속시켜주는 방법으로 서버 한대가 모든 서비스를 주관할때 보다 가격대 성능비로 우수한 효과를 낼 수 있다. 그러나 DNS에 의한 서버 부하 분산 방법은 IP 할당시 Round-Robin 방법이 사용하기 때문에 특정 서버의 장애나 경로상의 문제가 발생할 때는 원래의 목적했던 부하 분산을 하지 못할 수 있게 된다.


4계층 서버 부하 분산 Server Load Balancing (이하 SLB)이란 DNS에 의존하지 않고 다수의 서버들을 하나의 VIP (가상 IP 주소)로 묶어 사용자들에게는 VIP 만을 알려주고 SLB 제어를 통하여 IP address 뿐만아니라, 4계층의 TCP/UDP Port 로도 어떠한 서버의 장애에도 서버들간에 올바른 부하 분산을 할 수 있게 해주는 방법이다.

4계층 스위칭과 서버 부하 분산
▶ 4계층 프로토콜 유형(Type) 별로 트래픽 스트림(Stream) 구분
⊙ TCP 또는 UDP Port 번호
⊙ 나머지 Traffic Stream은 TCP 만을 사용하거나 별로 많지 않음
⊙ Well Known Socket Type - 예를 들면, FTP, HTTP, POP3, NTTP 등
⊙ 사용자 정의 Socket Type - 4004, 4500, 8001 등
⊙ 세션(Session)을 다음과 같이 정의할 수도 있다.
⊙ 목적지 IP + TCP/UDP 목적지 Port 번호 + 출발지 IP + TCP/UDP 출발지 Port 번호

▶ 4계층 필터링(Filtering)
⊙ 서비스 차단(Deny Service) - 특정 IP 주소에 대한 FTP 트래픽을 허용하지 않음

▶ 4계층 QoS - Hi Priority 또는 Normal Queuing
⊙ 스태커블 장비는 High Queue와 Normal Queue 구현
⊙ BirIron은 4개의 Priority Queue 구현

▶ 4계층 서버 부하 분산
⊙ TCP/UDP port Type을 기준으로 부하 분배
⊙ Hot Standby Redundancy - 서버와 스위치에 대해 Failover 기능 제공

Layer-4 Switching 개념이해(3)

서버 부하 분산
⊙ 사용자들은 하나의 VIP (가상 IP 주소)로 접속을 하지만 실지로는 다수의 물리적인 서버들이 서비스 제공
⊙ Traffic은 4계층 (이하 L4) Type에 따라 특정 서버로 전달

(보기)
⊙ HTTP 트래픽은 서버 1과 2로
⊙ FTP 트래픽은 서버 2와 3으로
⊙ 그리고, Email은 서버 4로

3가지 접속(Connection) 분산 정책
⊙ Round Robin - 차례대로 서버에 연결
⊙ Least Connections - Connection 갯수가 가장 적은 서버로 연결 (가장 최근의 접 속 요청 시점을 기준으로 함)
⊙ Weighted Distributions - 백분율(%)을 기준으로 부하 분배
⊙ 실제 서버 당 최대 접속 수를 설정, 집행
⊙ 서버의 용량 초과 문제를 없앰
⊙ 다른 유형의 트래픽은 초기 구성된 대로 실제 서버에 연결

서버/서비스 장애 복구
▶ 수차에 걸쳐 연속적으로 접속 장애가 감지되면 해당 서비스는 사용할 수 없는 것으 로 간주한다.
(사용자가 정의 가능하며 디폴트 값은 2)
⊙ 동일한 서비스를 제공하기 위해 사전에 구성된 다음 서버로 Failover (즉, HTTP, FTP, POP3, NTTP, 사용자 프로그램 등)
⊙ 그림에서, 서버 #2 상의 HTTP 서비스에 장애가 발생했으나 FTP 서비스는 여전히 동작 중임
⊙ 다른 서비스 포트(서비스 Port)들은 분배 정책(Round Robin, Least Connection, Weighted)에 대한 Pool이 된다.

▶ 장애가 발생했던 서비스가 복구되었는지를 주기적으로 검사한다 (검사 간격은 사용자 가 정의할 수 있으며 디폴트는 매 30 초)
▶ 서버 전체를 다운 시키지 않고 특정 서 비스 (HTTP)만 다운 시킬 수 있으므로 다른 서비스는 계속 운용할 수 있다.

▶ 유지보수를 위해 서버를 대체/수리 한 뒤에 서버 팜 (서버 팜) Pool에 다시 넣을 수 있다.

스위치 장애 복구(Failover) - 탁월한 가용성
▶ 전용 Synchronization Link
⊙ 1초 이내에 주(Primary) 스위치의 장애를 감지
⊙ 케이블 장애에 대비하여 최대 4 회선의 트렁크 그룹(Trunk Group)을 사용할 수 있 음
▶ 다음에 대한 공통 도메인 필요(Common Domains)
⊙ 스위치들과 실제(Real) 서버들
⊙ 스위치들에 대한 이중 접속(Dual-connect) 서버들을 연결(Hub)

▶ 두 스위치가 동시에 트래픽을 “청취”
⊙ 주(Active) 스위치는 클라이언트의 트래픽을 실제 서버로 전달
⊙ 백업(Standby) 스위치도 Network Address Translation (NAT) Table을 구축하나 대기 (Standby) 상태일 경우에는 어떤 그래픽도 전달 하지 않음

▶ 두 스위치 모두 동일한 MAC 주소로 지정 (대개는 Primary 스위치의 MAC 주소)
⊙ 백업 스위치 주소를 찾기 위해 ARP를 다시 하지 않음 (이유 - Primary와 동일하므로)
⊙ 클라이언트들은 백업 스위치가 활성화(Active) 상태에 있다는 것을 전혀 감지하지 못함
⊙ 백업 스위치가 활성화 상태로 되면 이를 알리기 위해 SNMP Trap을 생성

▶ 스위치에 장애가 발생할 경우 …
⊙ Sync Trunk는 초 당 10회 폴링(Polling)
⊙ 주 스위치가 백업 스위치와 통신에 실패하기 전까지의 동기화 된 세션 정보는 그대로 유 지됨
⊙ 장애가 발생하면 Backup 스위치가 “Active” 상태로 되어 제어권을 행사
⊙ 서버에 대한 클라이언트의 접속은 주 스위치에서 백업 스위치로의 Failover 동안에도 유 지됨.
⊙ 망실된 패킷(Packet)에 대한 재시도는 클라이언트/서버가 재개

▶ 주 클라이언트나 하위의 라우터는 ARP를 할 필요가 없음
⊙ 두 스위치는 동일한 MAC 주소로 구성되어 있음
⊙ 장애동안, 백업 스위치는 “Active” 스위치로 동작하여 트래픽이 흐르게 됨

▶ 서버 팜이 운용되는 중에 Primary 스위치를 교체할 수 있음
백업 스위치는 주 스위치가 Sync Link에 연결되었음을 감지하여 다시 “비활성(Inactive)” 상태로 Fallback 한다
Posted by Tornado tornado

댓글을 달아 주세요

http://cronolog.org/download/index.html  에서 cronolog 를 다운로드 받아서


암데나 압축을 푼다..


압축 푼 디렉토리에서 컴파일~


# ./configure

# make

# make install



헐... 끝~!



프로그램은 /usr/sbin/ 안에 보면 cronolog 라는게 있다...


이제 httpd.conf 파일의 Custom Log 부분을 고치기만 하면 된다.


보통 common 로그 패턴으로 되어있는데... 남기고 싶은 로그 타입으로 설정하거나

여러개 설정해도 된다.



CustomLog "|/usr/local/sbin/cronolog /usr/local/apache2/logs/%Y/%m/access_log.%Y%m%d" common


라고 입력한다..


이러면 아래와 같은 형태로 로그가 저장된다.


/usr/local/apache2/logs/2004/05/access_log.20040524 와 같은 형태가 된다.



이제 웹 얼라이져 같은 툴로.. 로그를 분석하면 된다.


위 사이트를 잘 읽어보면... 좋은 방법이 많이 나올듯~


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

언제 사이트 관리 고수가 될지 캬캬



'OS > LINUX' 카테고리의 다른 글

Ftp 서비스  (0) 2004.06.04
[펌] L4 switch  (0) 2004.06.04
cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] Netstat에 대하여  (0) 2004.05.18
Posted by Tornado tornado

댓글을 달아 주세요

rpm 설치 또는 삭제, 조회시에 db가 꼬였네~ 어쩌네 하는 메세지가 나올때가 있는데,

이럴때는 아래와 같은 방법으로 해결할 수 있다.

 

 

/var/lib/rpm 디렉토리에 보면 __db 로 시작하는 파일 이름들이 있는데..

이 파일들을 싹 지운다.

 

# rm -f __db*

 

이렇게 파일을 삭제하고 나서... rebuilddb 를 해주면 rpm 이 제대로 작동한다.

 

# rpm --rebuilddb

 

 

 

Posted by Tornado tornado

댓글을 달아 주세요

리눅스 시스템 관리자를 위한 보안 지침Ⅰ

 

 

CERTCC-KR

 

전병기 (bkjeon@certcc.or.kr) 2001. 03. 29

 

1. 리눅스 서버 운영체제의 Security Risk

 

리눅스는 지난해 세계 서버 OS시장 점유율이 27%로 전년(25%)에 비해 증가세를 나타냈다. 이는 1999년 가장 성장속도가 빠른 OS로 기록된 리눅스가 지난해에도 꾸준한 성장세를 유지했음을 의미한다. 이와 관련, MS의 스티브 발머 CEO는 최근 리눅스가 윈도에 대한 최대의 위협요소라고 말했다.

국내에서도 리눅스를 탑재한 중소형 서버가 꾸준히 증가하는 추세이다.

이는 벤처를 포함한 국내 중소기업과 초중고등학교등을 포함한 교육기관등이 전산망 구축을 위해 상대적으로 저렴한 리눅스 서버를 채택하면서 증가세를 부추기고 있는 것으로 풀이된다. 이런 추세라면 리눅스 서버는 엔터프라이즈급 서버에서 MS를 누르고 정상을 차지할 날도 머지않다고 본다.

리눅스 OS가 이렇게 인기가 좋은 이유중 하나는 저렴하다는 것과 쓰임새에 있어 강력하다는 것일 것이다. 그러나 강력한 시스템인 동시에 관리하기 어렵고, 그에 따른 Security Risk도 크다는데 문제가 있다. 리눅스 시스템은 본질적으로 취약성을 지니고 있는데, 이런 취약성을 이용한 악의적인 공격이 날로 증가하는 추세이다.

리눅스 서버의 보급이 확대됨에 따라, 악의적인 공격자(해커)에 의한 시스템 침입, 정보 변조 및 유출등 침해 사고가 잇따르고 있다. 이에 리눅스 서버에 대한 보안 문제가 크게 대두되고 있는 실정이다. 이에 시스템 관리자는 단순한 시스템 관리뿐만 아니라 시스템 보안까지도 염두해 두어야 한다.

본문은 리눅스 시스템 관리자에게 있어 기본적이면서 일반적인 보안 가이드를 설명한 문서로서, 침해사고대응팀내 사고 처리시 피해 기관 관리자에게 구체적이면서 일반적인 보안 가이드로 제공가능한 문서이다. 본문은 또한 RedHat 6.0 기준으로 설명하고 있지만 다른 리눅스 시스템에도 적용 가능하다.

 

2. 리눅스 시스템의 일반적인 보안 지침

 

1) 시스템 설치

시스템의 안전에 있어, 최상의 시점은 설치 시점이다.
설치함과 동시에 보안 조치를 취하지 않으면 공격자의 표적이 되기 십상이기에 시스템의 안전을 위해 설치 시점에서부터 보안을 고려하여 관리해야 한다.
시스템을 고립된 네트워크에 위치시켜 한시도 이 시스템을 네트워크에 연결하거나 연결 가능한 위험에 노출시켜서는 안된다. 그래서 중요한 파일과 패치를 받기 위해서는 중간에서 중계를 해줄 또하나의 시스템이 필요하다.
이 두 번째 시스템은 인터넷으로부터 필요한 파일을 다운받아 CDROM에 저장하거나 외부와 차단된 네트워크에 연결해 파일을 전송하는 등의 방법으로 필요한 파일을 전달한다.
일단 고립된 네트워크에 위치시키고 나면 설치할 준비는 끝난다.
첫 번째 단계는 로드할 OS 패키지를 선택하는 것이다. 레드햇 6.0은 Workstation, Server, Custom의 3가지 옵션이 있는데 디폴트로 Custom이 설정되어 있다.
Custom을 선택하기를 권하는데, 그래야 실행하고자 하는 서비스를 선택할수 있고 시스템 파티션의 설정도 자신이 선택할수 있다.
잠재적인 보안 취약점을 줄이면서 최대의 효과를 보기 위해 최소한의 패키지만을 설치한다.
옵션을 선택하였다면, 매뉴얼 페이지와 HOWTO 문서를 필히 추가하도록 한다.
온라인 매뉴얼과 문서들은 주요한 보안 자원이다.

Top

2) 파티션 구성

Custom 옵션을 선택하였으면, 파티션 구성 화면이 나타난다.
루트 파티션은 가능한 크게 만들고 모든 것은 루트 파티션에 설치한다.
또한 시스템 로그와 e-mail이 저장되는 /var 파티션 분할을 권장한다.
루트 파티션만이 존재하면 시스템 로그와 e-mail등의 데이터들에 의해 루트 파티션이 가득차서 서비스 거부 상태가 될 수 있으므로 /var 파티션을 분할 사용해야 한다. 용량은 대체로 400MB 정도로 한다.
그런데 특정 어풀리케이션을 위해 또는 사용자가 많은 경우 /home 파티션을 별도로 운영하든지, 로그 파일만 따로 저장하기 위해 다른 파티션도 고려할수도 있다.

 

3) 패치 설치

설치후 시스템이 재시동되고 나면 패치를 설치한다.

패치는 OS별로 제공되어지는데 참고로 레드햇 리눅스는 다음 사이트를 참조하기를 바란다.

 

▶ 레드햇 리눅스 패치 사이트

http://www.redhat.com/support/errata/

 

이 패치들을 적용하지 않으면 시스템은 쉽게 침해당할 것이다.

또한 리눅스 시스템은 고립된 네트워크에 연결된 채 중계 서버를 통해 패치되어야 함을 잊지말도록 한다.

레드햇의 경우 rpm 파일을 다운받으면 다음의 명령어를 통해 쉽게 설치할수 있다.

rpm -Uvh wu-ftpd-2.6.0-l.i386.rpm : wu-ftpd 패치하는 명령어

 

네트워크에 연결된 시스템이라면 ftp를 이용해 다음과 같이 설치할수도 있다.

rpm -Uvh ftp://updates.redhat.com/5.2/i386/wu-ftpd-2.6.0-l.i386.rpm

 

레드햇 6.1의 경우 'up2date'라는 패치 유틸리티가 있는데 이 툴을 사용할 것을 강력하게 추천한다. 이툴을 로컬 시스템에서 실행하면, 업데이트되어져야 할 rpm 파일이 어떤 것인지 결정하고 레드햇 웹사이트에서 찾아 스스로 다운로드 받고 설치할 정도로 사용하기 쉽다.

Top

4) 서비스 제거

리눅스 시스템을 보안 위험으로부터 보호하는데 있어, 제일 처음으로 하는 작업이 바로 불필요한 서비스의 제거하는 것이다. 이는 주로 불필요한 서비스를 제거하고 로깅을 추가하며, 몇 개의 파일 수정 및 SSH 또는 TCP Wrapper를 설정하는 작업이다.

리눅스 시스템은 디폴트로 여러 유용한 서비스를 설정하고 실행하도록 되어있다.

그러나 이서비스들의 대부분은 필요하지 않으며 보안측면에서 볼 때, 잠재적인 위험을 지니고 있다.

먼저 /etc/inetd.conf 파일을 보자. 이화일에는 디폴트로 여러 다양한 서비스들이 설정되어 있으나 대부분 ftp와 telnet만이 필요하다. 다른 불필요한 서비스들은 코멘트(#)로 처리하여 제거하도록 한다.

 

예)

# ...
# ....
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
#gopher stream tcp nowait root /usr/sbin/tcpd gn
#smtp stream tcp nowait root /usr/bin/smtpd smtpd
#nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd

 

pop, imapd, rsh과 같이 inetd에 의해 실행되는 많은 서비스들이 보안 취약점에 노출되어 있다. 다음 명령어를 이용하면 코멘트 처리된 서비스들을 확인할수 있다.

이 명령어는 코멘트 처리되지 않은 서비스들을 보여 준다.

grep -v "^#" /etc/inetd.conf

 

▶불필요한 서비스 제거를 위한 단계별 명령어 순서

① [root/]#chmod 600 /etc/inetd.conf : 소유자(root)만이 읽기/쓰기가 가능하도록 퍼미션을 바꿔준다.

 

② [root/]#stat /etc/inetd.conf : 소유자가 root인지 보증한다.

 

③ inetd.conf 파일을 위와 같이 코멘트 처리 및 편집한다. 편집이후에는 다음처럼 시그널을 보내야 한다.

[root/]#killall -HUP inetd

Top

④ [root/]#chattr +i /etc/inetd.conf : super-user만이 이 파일에대해 접근할수있도록 ‘inetd.conf’파일을 셋팅하는 것으로 일단 셋팅되면 수정, 삭제 또는 rename할수 없다. 셋팅은 super-user만이 할수 있다.

나중에 inetd.conf 파일을 수정하고자하면 플래그를 -i로 바꿔주면 된다.
다음은 init 프로세스에 의해 어떤 서비스가 시작될지 결정하는 .rc 스크립트들이다.
레드햇의 경우 이스크립트들은 /etc/rc.d/rc3.d에 있다.
자동으로 Gnome이나 KDE등의 GUI 환경으로 부팅되도록 설정되어 있다면 /etc/rc.d/rc5.d에 있다. 시동되도록 되어 있는 것을 멈추게 하려면 소문자 s를 대문자 S로 바꾼다.
또 원한다면 레드햇의 유틸리티를 사용할수 있다. 명령행에서 “/usr/sbin/setup”라고 쓰고 “System Services”를 선택하면 부트 프로세스중에 구동시킬 스크립트를 선택할수 있다.
다른 방법은 대부분의 배포판엣 볼수 있는 ‘chkconfig’를 사용하는 것이다.
다음의 스크립트들은 디폴트로 설치되는 것들이나 시스템에서 주요한 기능은 하지 않는 것들이다. 필요하지 않다면 시동되지 않도록 설정한다.

 

스크립트
설 명
S05apmd
laptop에만 필요
S10xntpd
Network Time Protocol
S11portmap
NIS, NFS같은 rpc 서비스가 있을때만 필요함
S15sound
사운드 카드 설정 저장
S15netfs
nfs client, nfs 서버에서 파일시스템을 마운트할 때 사용
S20rstatd
r 서비스 실행을 하지 않도록 함, 원격 사용자에게 너무 많은 정보를 제공함.
S20ruserd
 
S20rwhod
 
S20rwalld
 
S20bootparamd
디스크가 없는 클라이언트에서 사용
S25spuid
프락시 서버
S34yppasswdd
NIS 서버에만 필요함, 아주 취약한 서비스
S35ypserv
NIS 서버에만 필요함, 아주 취약한 서비스
S35dhcpd
dhcpd 서버 데몬을 구동함
S40atd
크론과 비슷한 at 서비스에 이용
S45pcmcia
laptop에만 쓰임
S50snmpd
SNMP 대몬, 시스템 관련 정보를 원격사용자에게 보냄

Top

이름에 포함된 숫자들은 초기화되는 순서를 결정하는 요소로서, 이것은 어떤 배포판인지 어떤 버전인지에 따라 달라진다. 이미 구동되고 있는 서비스를 중단시키기 위해서는 대문자S대신에 대문자 K를 사용한다.

 

 

스크립트
설 명
S55named
DNS 서버, 사용한다면 최신으로 업데이트한다.http://www.isc.org/bind.html
S55routed
RIP, 정말 필요한 경우가 아니면 실행하지 않는다.
S60lpd
프리팅 서버
S60mars-nwe
Neteware file과 프린터 서버
S60nfs
NFS 서버에 사용, 꼭 필요하지 않으면 실행하지 않는다.
S72amd
AutoMount 대몬, 원격 파일시스템 마운트에 사용
S75gated
OSPF와 같은, 다른 라우팅 프로토콜 구동에 사용
S80sendmail
이 스크립트를 정지시키더라도 여전히 email를 보낼 수 있으며, 단지 수신이나 중계는 불가능할 것이다.
S85httpd
아파치 웹서버, 가장 최신 버전으로 업데이트할 것을 권고한다.http://www.apache.org
S87ypbind
NIS 클라이언트라면 필요함
S90xfs
X 폰트 서버
S95innd
News 서버
S99linuxconf
브라우져를 통해서 리눅스 시스템을 원격으로 구성하는데 사용

 

부팅시 스크립트를 변경하기 전에 얼마나 많은 서비스들이 실행되고 있는지 알려면 다음 명령어를 사용한다.

ps aux | wc -l

 

조정후 확인하기 위한 명령어는 다음과 같다.

netstat -na --ip

Top

5) Logging과 option 조정

가능한 많은 서비스들을 제거하며, 서비스에 대한 로깅을 설정해야 한다.
모든 시스템은 /var/log에 로그를 남긴다. 디폴트로 리눅스는 ftp를 제외하고는 훌륭하게 로그를 남긴다.
ftp 로깅을 하려면 두가지 방법이 있다.
/etc/ftpaccess 파일을 설정하는것과 /etc/inetd.conf 파일을 수정하는 것이다.
/etc/inetd.conf 파일을 수정하는 것이 더 간단하기 때문에 이 방법을 권한다.
FTP 세션에 대한 모든 것을 로깅하기 위해서는 /etc/inetd.conf 파일을 다음과 같이 수정한다.

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o

 

-l 옵션을 사용하면 각 ftp 세션이 syslog 파일에 기록된다. -L 옵션은 ftp 서버가 시동되자 마자 커멘드 로깅이 시작된다. 즉 사용자가 ftp 접속시 사용하는 모든 명령어가 syslog에 남게 된다. -i 옵션은 ftpd에 의해 파일을 받으면 xferlog(5)에 로그를 남긴다.
-o 옵션은 ftpd(8)에 의해 파일이 전송되면 xferlog(5)에 로그를 남긴다.

 

다음은 옵션 조정인데, 이것은 파일 관리와 관계가 있다.

첫 번째는 /etc/passwd 파일을 안전하게 하는 것이다.

우선 시스템이 /etc/shadow를 사용하는지 확인한다.

이것은 모든 사용자의 패스워드를 root만이 접근 할수 있는 파일에 해쉬형태로 안전하게 저장한다는 것을 의미한다. 또한 해커들이 제일 먼저 노리는 패스워드가 손쉽게 접근되고 크랙되는 것을 방지한다. 쉐도우 패스워드 파일을 사용하는 것이 레드햇 6.0의 디폴트이지만 확인을 해야 한다.

 

다음 명령어를 실행하면 자동으로 패스워드 파일을 /etc/shadow 파일로 변환해 준다.

pwconv

이것이 시스템을 안전하게 하는 주요한 조치들중의 하나라고 여겨진다.

 

두 번째는 /etc/passwd 파일에서 대부분의 디폴트 시스템 계정들을 제거하는 것이다.

리눅스는 이런 계정들을 불필요할지도 모르는 시스템 작업을 위해 제공한다.

필요하지 않다면 제거해야 한다. 계정을 많이 가지면 가질수록 침입될 가능성은 높아진다.

“news” 계정이 그 한예이다. 뉴스그룹 서버로 사용하기 위해 nntp를 서비스하는 경우가 아니면 이 계정은 불필요하다. 익명 ftp 접속에 사용되는 “ftp”계정도 삭제해야 한다.

ftpd 인증은 다음의 규칙에 따른다.

/etc/passwd 파일에 ftp 계정이 있어 익명 ftp 접속이 허용되어 있고 사용자 ID가 ‘anonymous’나 ‘ftp’이면 이 경우 어떤 패스워드라도 로그인이 허용된다. 관례상 접속자의 host명을 패스워드로 사용하기도 한다.

 

▶/etc/passwd 파일의 시스탬 계정 예

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
mail:x:8:12:mail:/var/spool/mail:
uucp:x:10:14:uucp:/var/spool/uucp:
nobody:x:99:99:Nobody:/:

 

/etc/ftpusers 파일도 수정해야 한다.

Top

▶/etc/ftpusers 파일의 예

root
bin
daemon
adm
lp
mail
uucp
nobody

 

이파일에 기록된 계정은 ftp를 사용해서 이 시스템에 접속할수 없다.

이것은 root, bin과 같은 공통의 시스템 계정을 사용해 ftp로 연결하는 것을 제한한다.

리눅스는 디폴트로 이파일을 가지고 있다. root 권한으로 이 시스템에 ftp를 통해 접속하는 것을 막으려면 이 파일에 root가 포함되어 있는지 확인한다.

ftp 접속시 사용할 계정은 이 파일에 포함되면 안된다. 또 root로는 시스템에 telnet 접속을 못하도록 한다. 자기의 계정으로 접속한뒤 su를 사용해 root로 전환하도록 한다.

/etc/securetty 파일에 어떤 가상의 터미널이 root로 접속할수 있는지 설정한다. tty1, tty2와 같은 것만 이 파일에 리스트되도록 한다. 이것은 root로 접근하는 것이 로컬 접속일때만 가능하도록 제한하는 것이다. ttyp1, ttyp2는 원격에서 root가 시스템에 접근하는 것을 허용하는 임의의 터미널이다.

 

/etc/securetty 파일의 예

#
#
# WARNING : You must have specific authorization to acess
# this machine. Unauthorzed users will be logged.
# monitered, and then shot in sight!
#

 

이 법적 경고문은 어떤 사용자가 로그인을 시도할때마다 보여지게 된다.

디폴트로 리눅스는 부팅될 때마다 새로운 /etc/issue 파일을 생성하기 때문에 똑 같은 내용의 /etc/issue 파일을 계속 사용하려면 /etc/rc.d/init.d/S99local 파일을 수정한다.

Top

6) 서버 접속

원격지에서 서버를 관리하려면 안전하고 통제가 가능한 접속 방법을 찾는 것이 중요하다.

가끔 원격지에서 서버를 관리하기 위해 또는 파일을 업로드하기 위해 서버에 접속할 필요가있는데 이 통신은 안전해야 한다. 여기서는 ssh와 TCP Wrapper 두가지에 대해서만 설명할 것이다.

 

(1) SSH

사용자와 시스템과의 모든 통신을 암호화하는 ssh를 권장한다.

TCP Wrapper는 스니핑으로부터 네트워크 트래픽을 보호하지 못하며 패스워드를 포함한 키 스트로크를 캡쳐할수 있다. 이 시스템으로의 통신을 캡쳐하는 것을 우려한다면 telnet/ftp를 ssh로 대체하라. ssh는 서버로의 모든 통신을 암호화하여 안전하게 원격관리와 파일 업로드를 할수 있게한다. ssh는 고유의 로깅 레이어를 가지고 있으며, 서버로 접속할수 있는 대상을 제한할수 있다는 점에서 TCP Wrapper와 유사하다. 보다 많은 정보는 다음을 참조하기 바란다. http://www.ssh.org/download.html

ssh 2.x는 라이센스가 있으므로 버전 1.2.x를 권장한다. ssh의 또 다른 버전은 Openssh이 있고 참조 사이트는 다음과 같다. http://www.openssh.org/ 이다.

 

Ÿ 권고 사항

ssh을 인스톨하기전에 시스템상의 파일 리스트를 만들고, 이후에 무슨 파일이 어디에 위치되어 있는지 알기위해 ‘diff’ 명령어를 사용해서 인스톨전 파일 리스트와 이후 파일 리스트를 비교한다.

 

인스톨이전 파일 리스트는 다음 명령행으로 만들어진다.

find / * > ssh1

 

인스톨이후 파일 리스트는 다음 명령행으로 만들어진다.

find / * > ssh2

 

리스트 비교는 다음 명령행으로 실행된다.

diff ssh1 ssh2 > ssh : 바뀌어진 파일 리스트를 얻는다.

 

Ÿ 컴파일 및 설치

① SSH 홈페이지에서 압축 파일 다운로드

http:// www.ssh.fi/ ssh-1.2.27.tar.gz 다운로드

 

② 압축 해제

[root/]#cp ssh-1.2.27.tar.gz /var/tmp
[root/]#cd /var/tmp
[root/tmp]#tar xzpf ssh-1.2.27.tar.gz

Top

③ 컴파일 및 최적화

새로 생성된 ssh 디렉토리로 가서 다음 명령어들을 타이핑한다.

 

 

CC="egcs"\
CFLAGS="-09-funroll-loops-ffast-math-malign-double-mcpu=pentinmpro-
march=pentiumpro-fomit-frame-pointer-fno-exceptions"\
./configure\
--prefix=/usr\
--without-idea\
--with-etcdir=/etc/ssh\
--enable-warnings\
--without-rsh\
--with-libwrap\
--disable-server-port-forwardings\
--disable-client-port-forwardings\
--disable-server-x11-forwardings\
--disable-client-x11-forwardings\
--disable-suid-ssh

 

 

이것은 특정 하드웨어에 setup시키기 위해 SSH1 그자체로 setup 시키는 것으로 다음은 필드별 설명이다.

 

- 상업적 이용에서 특허문제를 피하기 위해서이다.
- gcc/egcs를 사용한다면 the-Wall(warning) 옵션을 enable 해야한다.
- 어떠한 조건하에서도 rsh를 사용하지 말아라.
- libwrap(tcp_wrappers) 지원으로 컴파일해라.
- X11은 제외하고 서버내 모든 포트 포워딩은 disable 해라.
- X11은 제외하고 클라이언트내 모든 포트 포워딩은 disable 해라.
- 서버내 X11 포워딩은 disable 해라.
- 클라이언트내 X11 포워딩은 disable 해라.
- suid bit 없이 ssh 인스톨해라.

 

다음은 불필요한 파일들을 지우는 작업이다.

 

[root/ssh-1.2.27]#make clean

: 어떠한 실수라도 피하기 위해 이전 모든 컴파일 trace를 지운다.

[root/ssh-1.2.27]#make

: 모든 소스 파일들을 실행가능한 바이너리 파일들로 컴파일한다.

[root/ssh-1.2.27]#make install

: 적합한 위치에 바이너리 파일들과 지원 파일들을 인스톨한다.

[root/]#cd /var/tmp

[root/tmp]#rm -rf ssh-1.2.27/ssh-1.2.27.tar.gz

: 컴파일과 인스톨에 사용된 소스 파일들을 제거한다.

또한 tmp 디렉토리내 압축 파일도 지운다.

Top

④ 구성화일 설정

우선 서버 구성 파일 압축화일을 다운로드한다.

http://pages.infinit.net/lotus1/opendocs/floppy.tgz

그리고 적당한 디렉토리에 복사한다.

즉, sshd_conf 파일을 “/etc/ssh/”디렉토리에 복사한다.

 

Ÿ ssh_config 파일 편집 (vi /etc/ssh/ssh_config)

구성화일은 클라이언트 프로그램의 운영을 수정하기 위해 옵션을 셋팅해야 한다.

파일은 라인별로 키워드와 값, 한쌍을 포함하고 있는데, 여기서는 중요 키워드에 대해서만 셋하고 완전한 키워드 리스트는 파일내 man 페이지를 참조하기를 바란다.

다른 다양한 옵션은 디폴트로 두고 필요하다면 수정, 추가한다.

 

Host *

ForwardAgent no
ForwardX11 no
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
TISAuthentication no
PasswordAuthentication yes
FallBackToRsh no
UseRsh no
BatchMode no
Compression yes
StrictHostKeyChecking no
IdentityFile ~/.ssh/identity
Port22
KeepAlive yes
Cipher blowfish
EscapeChar ~

Top

Ÿ sshd_config 파일 편집 (vi /etc/ssh/sshd_config)

 

데몬의 운영을 수정한다.

파일은 라인별로 키워드와 값, 한쌍을 포함하고 있는데, 여기서는 중요 키워드에 대해서만 셋하고 완전한 키워드 리스트는 파일내 man 페이지를 참조하기를 바란다.

다른 다양한 옵션은 디폴트로 두고 필요하다면 수정, 추가한다.

 

Port 22

ListenAddress 211.252.150.1 --> 네트워크 인터페이스의 IP 주소(예는 ‘ns.certcc.or.kr’)

HostKey /etc/ssh/ssh_host_key
RandomSeed /etc/ssh/ssh_random_seed
ServerKeyBits 1024
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin no
IgnoreRhosts yes
StrictModes yes
QuietMode no
X11Forwarding no
FascistLogging no
PrintMotd yes
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication yes
RSAAauthentication yes
PasswordAuthentication yes
PermitEmptyPasswords no
AllowUsers admin

AllowHosts 172.16.2.123 --> 호스트 IP 주소 (예는 가상 주소임)

Top

(2) TCP Wrapper

TCP Wrapper 는 암호화는 지원하지 않지만 로그와 서버로의 접근을 제한한다.

TCP Wrapper는 telnet 또는 ftp와 같은 inetd 서비스를 둘러싸는 실행화일이다.

TCP Wrapper를 실행시키면 시스템은 inetd 커넥션들에 대한 wrapper를 실행하고 모든 접속 시도를 기록하고 접속 제어 리스트에 위배되는 접속 시도가 있는지 감시한다.

만일 접속이 허용되면 TCP Wrapper는 그 커넥션을 telnet 과 같은 적절한 실행화일로 넘겨준다. 접속 제어 리스트에 의해 접속이 거절되면 그 커넥션은 drop된다.

 

다행히도 TCP Wrapper가 이미 설치되었다면 /etc/hosts.allow 파일과 /etc/hosts.deny파일을 수정하기만 하면 된다. 이 파일들은 서버에 접속을 허용하지 않을 대상을 결정한다.

TCP Wrapper는 베너, spawn, safe_finger 과 같은 부가적인 프로그램을 제공한다.

사용법은 비교적 간단하다. /etc/hosts.allow 파일에 접속을 허용할 IP나 네트워크를 기록한다. /etc/hosts.deny 파일에 접속을 금지할 IP나 네트워크를 기록한다. 디폴트로 리눅스는 모두에게 접속을 허용하므로 이 파일을 수정할 필요가 있다.

TCP Wrapper를 사용할 때의 2가지 권고 사항이다.

 

Ÿ 권고사항

1. 시스템 이름이나 도메인 이름을 사용하지말고 IP 주소를 사용한다.

2. /etc/hosts.deny을 deny ALL로 설정한 후 접속을 허용할 주소만 /etc/hosts.allow 파일에 기록한다.

Ÿ allow 파일과 deny 파일 설정 예

문법

Service:Source (IP 주소, 네트워크 또는 이름):<option>:ALLOW 또는 DENY

 

/etc/hosts.allow 예

in.telnetd:192.168.1.0/255.255.255.0:banners/etc/bannerfile:ALLOW

in.ftpd:192.168.1.30:ALLOW

imap:ALL:spawn(/usr/local/bin/ids.sh %d %h %H %u)

 

/etc/hosts.deny 예

ALL:ALL DENY

 

Top

Ÿ 파일 설정 단계별 명령어 순서

① hosts.deny 파일을 편집한다.(vi /etc/hosts.deny) 다음 행을 추가한다.

 

 

 

Access id denied by default.

#Deny access to everyone.

ALL:ALL@ALL, PARANOID

 

 

마지막 행은 모든 서비스, 모든 지역을 의미하는 것으로, allow 파일내 엔트리에 의해서 접속이 허용될지라도 명시적으로 허용되지 않은 어떠한 서비스도 block된다.

 

② hosts.allow 파일을 편집한다. (vi /etc/hosts.allow) 다음 예처럼 행을 추가한다.

명시적으로 승인된 host는 allow 파일에 저장되어있다.

 

 

 

sshd:211.252.150.1 ns.certcc.or.kr

 

 

211.252.150.1는 IP 주소이고 ns.certcc.or.kr는 sshd 사용시 허용된 클라이언트중의 한 host 이름이다.

 

③ tcpd wrapper 구성화일을 검사하는 'tcpdchk' 프로그램을 실행시킨다.

이것은 tcp wrapper 구성화일을 시험해서, 찾을수 있는 모든 잠재적이고 실제적인 문제점들을 보고한다.

 

[root/]#tcpdchk

: 구성이 끝난 후에 tcpdchk 프로그램을 실행시킨다.

 

TCP Wrapper와 관련된 보다 상세한 정보는 다음을 참조하기 바란다.

http://www.enteract.com/~lspitz/ids.html

 

7) 계정관리 보안 조치 사항

우선 wheel 그룹을 만든다. wheel 그룹은 /bin/su 와 같은 명령어를 실행시킬수 있는 특별한 권한을 필요로 하는 사용자들로 이루어진 그룹이다. 이런 종류의 명령어를 실행시킬수 있는 사용자들을 제한함으로써 시스템의 보안성을 향상시킬수 있다. 그룹을 생성하기 위해 /etc/group 파일을 vi로 열어 wheel 그룹을 추가하고 시스템 관리자를 wheel 그룹에 추가한다. 그리고 /bin/su 와 같은 시스템 실행 파일을 구별해 group 소유권을 wheel로 바꾸어 소유자와 그룹에 실행권한만을 준다. 특정 파일의 경우 suid와 guid에 대해서도 주의한다.

 

Top

/bin/su 파일에 대해 설정할 경우 명령어 에

/bin/chgrp wheel /bin/su

/bin/chmod 4750 /bin/su

 

두 번째는 .rhosts, .netrc, /etc/hosts.eqiv 파일을 잠근다.

r 명령들이 시스템에 접근할 때 이파일들을 사용한다. 이파일들을 잠그기 위해서 각 파일에 대해 touch를 실행하고 permission을 0으로 변경한다.

이러면 아무도 이 파일을 만들수도 없고, 수정할수도 없다.

 

작업 실행 예 :

/bin/touch/root/.rhosts/root/.netrc/etc/hosts.eqiv

/bin/chmod 0/root/.rhosts/root/.netrc/etc/hosts.eqiv

 

세 번째는 /etc/shdow가 crypt(3) 함수 대신 MD5 해쉬를 사용토록 설정한다.

이러면 암호화된 패스워드 파일이 해독되기가 보다 어려워진다.

이러한 작업은 PAM 모듈을 수정함으로서 이루어진다.

PAM(Pluggable Authentication Modules)은 어떻게 어풀리케이션들의 인증방법을 선택할 수 있게 하는 라이브러리의 집합이다. PAM 모듈에 대해 상세한 정보는 다음을 참조한다. ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html

 

과거에는 MD5 해쉬를 사용하려면 수동으로 PAM을 수정했으나 레드햇 6.0 이상의 버전에서는 셋업 유틸리티에서 선택하기만 하면 된다.

즉 명령행에서 setup을 실행시키고 “authentication configuration”을 선택한다.

그러면 MD5 해쉬를 선택할수 있다. 그런데 사용자가 자신들의 패스워드를 다시 입력하지 않으면 새로 적용된 MD5 해쉬는 아무런 효과가 없음에 유의하여야 한다.

셋업 유틸리티가 지원되지 않는 버전의 사용자는 다음을 참조하여 수동으로 설정할수 있다. http://www.enteract.com/~lspitz/lx_example.html#G

 

bash 사용자들은 .bash_history 파일을 내켜하지 않는데 이는 내가 사용한 명령어들을 다른사람들이 알게되기 때문이다. 그래서 .bash_profile에 다음을 추가한다.

Top

HISTFILESIZE=0

 

이러면 .bash_history 파일에 아무런 기록이 남지 않는다. 이렇게 해도 HISTSIZE라는 환경변수가 있기에 키스트로크에 대한 히스토리 관리는 유지된다. 단지 .bash_history 파일에 저장되지 않을 뿐이다.

 

마지막으로 할수 있는 것은 물리적인 접근으로부터 시스템을 보호하는 것이다.

이것은 주로 BIOS에 대해 패스워드를 설정하는 작업으로 구성된다.

/etc/lilo.conf 파일에 password=xxx 와 같이 패스워드를 설정함으로써 부팅프로세스가 진행되는 동안 시스템을 보호할수 있다. 싱글 유저모드로 부팅할 때 패스워드를 물어보게 되며 lilo.conf 파일 수정후에 ‘lilo -v’를 실행해야 수정된 사항이 적용된다. 일단 물리적으로 시스템에 접속하게 되면 시스템을 보호할 방법은 없다는 것을 명심해야 한다.

 

8) IPChain 보안 공개 도구

IPChain은 커널 2.2.x 이상에서 지원하는 패킷필터링 S/W이다. 레드햇 6.0 이상을 사용하면 리눅스 설치 킷에 포함되어있다. IPChain은 시스코 라우터의 ACL과 비슷하고 리눅스가 설치된 서버를 통과하는 패킷을 제어할수 있다.

기본적으로 방화벽처럼 사용될수 도 있으며, 스탠드 얼론으로 사용되는 리눅스 서버에서도 보안을 강화하기 위해 사용될수 있다. 스텐드 얼론 시스템을 안전하게 하기 위해서, 이 시스템에서 시작된 TCP 연결만을 허용하도록 설정한다. 다른 곳에서 어떤 TCP 연결을 시도해도 거부된다. 그러나 UDP나 ICMP 연결은 허용한다.

또한 모든 거절된 커넥션을 로깅한다. Broadcast, Multicast 트래픽의 경우, 양이 너무 많기에 ‘거부’하지만 로깅하지는 않는다.

 

Top

간단한 IPChain 설정 예(Standalone 경우) :

bash# ipchains -L
Chain input (policy DENY):
target prot opt source destination ports
DENY all ------ 0.0.0.0 anywhere n/a
DENY all ------ anywhere 255.255.255.255 n/a
DENY all ------ anywhere BASE-ADDRESS.MCAST.NET/8 n/a
ACCEPT tcp !y---- anywhere anywhere any -> any
ACCEPT udp ----l- anywhere anywhere any -> any
ACCEPT icmp ----l- anywhere anywhere any -> any
DENY all ----l- anywhere anywhere n/a
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

 

참고 사이트

http://www.enteract.com/~lspitz/lx_example.html#H

http://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAIN-HOWTO

 

3. 결론

 

레드햇 리눅스를 기반으로 리눅스 시스템을 안전하게 하기 위한 기본적인 조치사항들을 살펴 보았다. 중요한 것은 최소한의 소프트웨어를 설치하고 SSH나 TCP Wrapper, IPChain, Shdow password 와 같은 보안 조치 사항들을 설정하는 것이다.

tripwire, swatch 같은 추가적인 도구도 있다. 자동으로 새로운 리눅스 시스템을 단계적으로 안전하게 해주는 펄 스크립트인 Bastille linux(http://www.bastille-linux.org/)도 권고한다.

100% 안전한 시스템은 없지만 여기서 기술된 것만 적용해도 리눅스 시스템의 안전성은 상당히 높아 질 것이다.

시스템의 안전한 보호를 위해서는 지속적으로 보안 사항들을 살펴보아야 한다.

또한 CERT 홈페이지(http://www.certcc.or.kr)를 위시한 보안 전문 컨설팅 사이트와 시스템 벤더 사이트를 정기적으로 방문하여 보안 권고 사항들에 대해서 주의깊게 살펴보며, 새로운 취약성이 발견되면 그에 따른 패치설치 및 보안 권고에 충실히 따르도록 해야 한다.

Posted by Tornado tornado

댓글을 달아 주세요

netstat 명령
목적
네트워크 상태를 보여 줍니다.

구문
각 프로토콜이나 라우팅 표 정보에 대한 활동 중인 소켓을 표시하는 경우
/bin/netstat [ -n ] [ { -A -a } | { -r -i -I Interface } ] [ -f AddressFamily ] [ -p Protocol ] [ Interval ] [ System ]

네트워크 데이타 구조의 내용을 표시하는 경우
/bin/netstat [ -m | -s | -ss | -u | -v ] [ -f AddressFamily ] [ -p Protocol ] [ Interval ] [ System ]

통신 서브시스템을 통해 패킷 계수를 표시하는 경우
/bin/netstat -D

네트워크 버퍼 캐시 통계를 표시할 경우
/bin/netstat -c

데이타 링크 제공자 인터페이스 통계를 표시할 경우
/bin/netstat -P

관련된 통계를 지우려면
/bin/netstat [ -Zc | -Zi | -Zm | -Zs ]

설명
netstat 명령은 활성화된 연결에 대한 여러 네트워크 관련 데이타 구조의 내용을 상징적으로 표시합니다. Interval 매개변수는 초로 지정되며, 구성설정된 네트워크 인터페이스에서의 패킷량에 관한 정보를 계속 표시합니다. Interval 매개변수는 플래그를 사용하지 않습니다. System 매개변수에는 현재 커널에서 사용하는 메모리를 지정합니다. 덤프 파일의 경우를 제외하고, System 매개변수는 /unix입니다.

플래그
-A 소켓과 연관된 모든 프로토콜 제어 블록의 주소를 보여 줍니다. 이 플래그는 디폴트 표시장치로 이용되며 디버깅 목적에 사용됩니다.
-a 모든 소켓의 상태를 표시합니다. 이 플래그가 없으면, 서버 프로세스에 의해 사용된 소켓은 표시되지 않습니다.
-c 네트워크 버퍼 캐시의 통계를 표시합니다.
네트워크 버퍼 캐시는 네트워크로 전송될 수 있는 데이타 오브젝트를 포함하는 네트워크 버퍼의 리스트입니다. 네트워크 버퍼 캐시는 데이타 오브젝트가 추가 또는 제거되면서 동적으로 커집니다. 네트워크 버퍼 캐시는 네트워크 I/O의 성능 향상을 위해 일부 네트워크 커널 인터페이스에서 사용됩니다. netstat -c 명령은 다음의 통계를 인쇄합니다.

Network Buffer Cache Statistics:
Current total cache buffer size: 0
Maximum total cache buffer size: 0
Current total cache data size: 0
Maximum total cache data size: 0
Current number of cache: 0
Maximum number of cache: 0
Number of cache with data: 0
Number of searches in cache: 0
Number of cache hit: 0
Number of cache miss: 0
Number of cache newly added: 0
Number of cache updated: 0
Number of cache removed: 0
Number of successful cache accesses: 0
Number of unsuccessful cache accesses: 0
Number of cache validation: 0
Current total cache data size in private segments: 0
Maximum total cache data size in private segments: 0
Current total number of private segments: 0
Maximum total number of private segments: 0
Current number of free private segments: 0
Current total NBC_NAMED_FILE entries: 0
Maximum total NBC_NAMED_FILE entries: 0
주: -c 플래그는 AIX 버전 4.3.2 이상에서만 유효합니다.
-D 통신 서브시스템에서 수신, 전송, 단절된 패킷의 수를 표시합니다.
주: 통계 출력에서, 필드 값에서의 N/A는 계수가 해당되지 않는 경우를 의미합니다. NFS/RPC 통계의 경우, RPC를 패스한 수신 패킷의 수는 NFS를 패스한 패킷과 같기 때문에 이 수는 NFS/RPC Total 필드에서 계산되지 않습니다. 그러므로 N/A에 해당합니다. NFS에는 NFS 및 RPC에 고유한 송신 패킷이나 패킷 송신 단절 지수가 없습니다. 따라서, 개별 계수에는 필드 값 N/A가 표시되며, 누적 계수는 NFS/RPC Total 필드에 저장됩니다.
-f AddressFamily 통계 보고서나 주소 제어 블록을 AddressFamily 변수에 의해 지정된 항목에 제한합니다. 다음의 주소 패밀리가 인식됩니다. inet AF_INET 주소 패밀리를 나타냅니다.
inet6 AF_INET6 주소 패밀리를 나타냅니다.
ns AF_NS 주소 패밀리를 나타냅니다.
unix AF_UNIX 주소 패밀리를 나타냅니다.

-i 구성설정된 모든 인터페이스의 상태를 표시합니다.
주: 이더넷 인터페이스의 충돌 계수는 지원되지 않습니다.
-I Interface Interface 변수에 의해 지정된 구성설정된 인터페이스의 상태를 표시합니다.
-m 메모리 관리 루틴에 의해 기록된 통계를 표시합니다.
-n 네트워크 주소를 숫자로 표시합니다. 이 플래그를 지정하지 않으면, netstat 명령은 주소를 해석하여 가능한 곳에 기호로 표시합니다. 어떠한 포맷으로도 이 플래그를 사용할 수 있습니다.
-p Protocol Protocol 변수에 대해 지정된 값, 즉 프로토콜에 대한 잘 알려진 이름이나 별명의 통계를 표시합니다. 일부 프로토콜 이름과 별명은 /etc/protocols 파일에 나열되어 있습니다. 널(null) 응답은 보고할 숫자가 없음을 의미합니다. 통계 루틴이 없는 경우 Protocol 변수에 대해 지정된 값의 프로그램 보고는 제공되지 않습니다.
-P 데이타 링크 제공자 인터페이스(DLPI)의 통계를 표시합니다. netstat -P 명령은 다음과 같은 통계를 인쇄합니다.
DLPI statistics:
Number of received packets = 0
Number of transmitted packets = 0
Number of received bytes = 0
Number of transmitted bytes = 0
Number of incoming pkts discard = 0
Number of outgoing pkts discard = 0
Number of times no buffers = 0
Number of successful binds = 0
Number of unknown message types = 0
Status of phys level promisc = 0
Status of sap level promisc = 0
Status of multi level promisc = 0
Number of enab_multi addresses = 0
DLPI이 로드되지 않았을 경우, 다음과 같이 표시됩니다.

can't find symbol: dl_stats
주: -P 플래그는 AIX 버전 4.3.2 이상에서만 유효합니다.
-r 라우팅 표를 표시합니다. -s 플래그와 함께 사용된 경우, -r 플래그는 라우팅 통계를 표시합니다.
-s 각 프로토콜에 대한 통계를 표시합니다.
-ss 모든 0이 아닌 프로토콜 통계를 표시하고 세밀한 화면을 제공합니다.
-u 도메인 소켓에 대한 정보를 표시합니다.
-v CDLI 기준 통신 어댑터의 통계를 표시합니다. 이 플래그는 netstat 명령이 entstat, tokstat 및 fddistat 명령에 대해 통계 명령을 수행하도록 합니다. 이러한 장치 드라이버 명령을 위해서는 플래그를 수행하지 않습니다. 통계 출력에 대한 설명은 특정 장치 드라이버 통계 명령을 참조하십시오.
-Zc 네트워크 버퍼 캐시 통계를 지웁니다.
-Zi 인터페이스 통계를 지웁니다.
-Zm 네트워크 메모리 할당자 통계를 지웁니다.
-Zs 프로토콜 통계를 지웁니다. 특정 프로토콜의 통계를 지우려면, -p 를 사용하십시오. 예를 들어, TCP 통계를 지우려면, netstat -Zs -p tcp를 입력하십시오.

디폴트 표시장치
활동 중인 소켓에 대한 디폴트 표시 장치는 다음 항목을 표시합니다.

국지 및 원격 주소
수신 및 송신 대기행렬의 크기(바이트)
프로토콜
프로토콜의 내부 상태
소켓 주소가 고유의 호스트 주소 없이 네트워크를 지정한 경우, 인터넷 주소의 형식은 host.port나 network.port입니다. 네트워크 주소가 /etc/networks 파일에 따라서 기호로 표시되는 반면, 그 주소가 기호 호스트 이름으로 해석될 수 있는 경우, 호스트 주소는 기호로 표시됩니다.

NS 주소는 12바이트 길이 즉, 4바이트의 네트워크 번호, 6바이트의 호스트 번호 및 2바이트의 포트 번호로 이루어져, 모두 네트워크 표준 형식으로 저장됩니다. VAX 시스템의 경우, 이것은 역구성된 단어 및 바이트입니다. Sun 시스템의 경우에는 역구성되지 않습니다.

호스트에 대한 기호 이름을 모르거나 -n 플래그가 사용된 경우, 주소는 주소 패밀리에 따라서 숫자로 인쇄됩니다. 지정되지 않은 주소와 포트는 *(별표)로 나타납니다.

인터페이스 표시(netstat -i)
인터페이스 표시 형식은 다음의 항목에 대하여 누적 통계표를 제공합니다.

Errors
Collisions
주: 이더넷 인터페이스에 대한 충돌 계수는 지원되지 않습니다.
Packets transferred
인터페이스 표시장치는 최대 전송 단위(MTU) 외에도 인터페이스 이름, 번호 및 주소를 제공합니다.

Routing Table Display (netstat -r)
라우팅 표 표시장치 형식은 사용가능한 라우트 및 그 상태를 표시합니다. 각 라우트는 목적지 호스트나 네트워크 및 패킷을 전송하는데 사용되는 게이트웨이로 이루어집니다.

라우팅 표는 다음 10개의 필드를 포함하고 있습니다.

Flags 라우팅 표의 flags 필드는 다음과 같은 라우트 상태를 표시합니다. U Up.
H 네트워크가 아닌 호스트로의 라우트입니다.
G 게이트웨이로의 라우트입니다.
D 라우트는 재지정에 의해 동적으로 작성됩니다.
M 라우트가 재지정에 의해 수정되었습니다.
L 링크 레벨 주소는 라우트 항목에 존재합니다.
c 이 라우트에 액세스하면 복제된 라우트가 작성됩니다. 이 필드는 AIX 버전 4.2.1 이상 버전에만 적용됩니다.
W 이 라우트는 복제된 라우트입니다. 이 필드는 AIX 버전 4.2.1 이상 버전에만 적용됩니다.
1 고유한 프로토콜의 라우팅 플래그 #1.
2 고유한 프로토콜의 라우팅 플래그 #2.
3 고유한 프로토콜의 라우팅 플래그 #3.
b 라우트는 브로드캐스트 주소를 나타냅니다.
e 바인딩 캐시 항목이 있습니다.
l 라우트는 국지 주소를 나타냅니다.
m 라우트는 멀티캐스트 주소를 나타냅니다.
P 고정된 라우트.
R 범위 밖의 호스트 또는 네트워크.
S 수동으로 추가되었습니다.
u 사용가능한 라우트.

국지 호스트에 접속된 각 인터페이스에 대해 직접 라우트가 작성됩니다.

Gateway 이 항목에 대한 gateway 필드는 전송 인터페이스의 주소를 표시합니다.
Refs 라우트에 대해 현재 활동하고 있는 사용의 번호를 제공합니다. 연결 중심 프로토콜은 연결이 지속되는 동안 하나의 라우트를 고수합니다. 반면에 연결되지 않은 프로토콜은 동일한 목적지에 송신하는 동안 라우트를 확보합니다.
Use 해당 라우트를 사용하여 송신된 패킷 계수를 제공합니다.
PMTU PMTU(5로 최대 전송 단위)를 제공합니다. 이 필드는 AIX 버전 4.2.1 이상 버전에만 적용됩니다.
Interface 라우트에 활용된 네트워크 인터페이스를 나타냅니다.
Exp 라우트가 만료되기 전에 남은 시간(분)을 표시합니다. 이 필드는 AIX 버전 4.2.1 이상 버전에만 적용됩니다.
Groups 해당 라우트와 연관된 그룹 ID의 리스트를 제공합니다. 이 필드는 AIX 버전 4.2.1 이상 버전에만 적용됩니다.
Netmasks 시스템에 적용된 네트마스크를 나열합니다.
Route Tree for
Protocol Family 기존 라우트에 활동 중인 주소 패밀리를 지정합니다. 이 필드에 지원되는 값은 다음과 같습니다. 1 UNIX 주소 패밀리를 지정합니다.
2 인터넷 주소 그룹을 지정합니다(예를 들어, TCP 및 UDP).
6 Xerox 네트워크 시스템(XNS) 주소 패밀리를 지정합니다.

기타 주소 패밀리에 대한 자세한 정보는 /usr/include/sys/socket.h 파일을 참조하십시오.


Interval 매개변수에 값이 지정된 경우, netstat 명령은 네트워크 인터페이스와 관련하여 수행 중인 통계 계수를 표시합니다. 이 화면에는 1차 인터페이스에 대한 열(자동 구성설정 중에 발견된 첫번째 인터페이스) 및 모든 인터페이스에 대한 정보를 요약하는 열의 두 열이 있습니다.

-I 플래그를 사용하여 1차 인터페이스는 다른 인터페이스로 대체될 수도 있습니다. 각 정보 화면의 첫번째 행은 시스템이 마지막으로 재시동된 이후로 축척된 통계의 요약을 포함하고 있습니다. 출력의 후속 행은 간격별로 누적된 값을 표시합니다.

Inet 예제
인터넷 인터페이스에 대한 라우팅 표 정보를 표시하려면, 다음과 같이 입력하십시오.
netstat -r -f inet
이로써 다음과 같은 출력이 작성됩니다.

Routing tables
Destination Gateway Flags Refs Use PMTU If Exp Groups
Netmasks:
(rootnode)
(0)0 ffff f000 0
(0)0 ffff f000 0
(0)0 8123 262f 0 0 0 0 0
(rootnode)

Route Tree for Protocol Family 2:
(rootnode)
default 129.35.38.47 UG 0 564 - tr0 -
loopback 127.0.0.1 UH 1 202 - lo0 -
129.35.32 129.35.41.172 U 4 30 - tr0 - +staff
129.35.32.117 129.35.41.172 UGHW 0 13 1492 tr0 30
192.100.61 192.100.61.11 U 1 195 - en0 -
(rootnode)

Route Tree for Protocol Family 6:
(rootnode)
(rootnode)
-i -f inet 플래그는 구성설정된 모든 인터넷 인터페이스의 라우팅 표 정보 대한 요청을 나타냅니다. 네트워크 인터페이스는 Interface 열에 나열됩니다. en는 표준 이더넷 인터페이스를 의미하고 반면에 tr은 토큰링 인터페이스를 의미합니다. 게이트웨이 주소는 점분리 십진수 형식입니다.

인터넷 인터페이스에 대한 인터페이스 정보를 표시하려면, 다음과 같이 입력하십시오.
netstat -i -f inet
AIX 4.2를 사용할 경우, 다음과 같은 출력이 작성됩니다.

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 1536 4 0 4 0 0
lo0 1536 127 loopback 4 0 4 0 0
en0 1500 96 0 67 0 0
en0 1500 192.100.61 nullarbor 96 0 67 0 0
tr0 1500 44802 0 11134 0 0
tr0 1500 129.35.32 stnullarb 44802 0 11134 0 0
This produces the following output if you are using AIX 4.3:

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 Link#1 5161 0 5193 0 0
lo0 16896 127 localhost 5161 0 5193 0 0
lo0 16896 ::1 5161 0 5193 0 0
en1 1500 Link#2 8.0.38.22.8.34 221240 0 100284 0 0
en1 1500 129.183.64 infoserv.frec.bul 221240 0 100284 0 0
-i-finet 플래그는 구성설정된 모든 인터넷 인터페이스의 상태에 대한 요청을 의미합니다. 네트워크 인터페이스는 Name 열에 나열됩니다. lo는 루프백 인터페이스를 의미하고, en는 표준 이더넷 인터페이스를 의미하며 반면에, tr은 토큰링 인터페이스를 의미합니다.

각 프로토콜에 대한 통계를 표시하려면, 다음과 같이 입력하십시오.
netstat -s -f inet
이로써 다음과 같은 출력이 작성됩니다.

ip:
:
44485 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 packets reassembled ok
44485 packets for this host
0 packets for unknown/unsupported protocol
0 packets forwarded
0 packets not forwardable
0 redirects sent
1506 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 IP Multicast packets dropped due to no receiver
0 successful path MTU discovery cycles
0 path MTU rediscovery cycles attempted
0 path MTU discovery no-response estimates
0 path MTU discovery response timeouts
0 path MTU discovery decreases detected
0 path MTU discovery packets sent
0 path MTU discovery memory allocation failures
0 ipintrq overflows

icmp:
0 calls to icmp_error
0 errors not generated 'cuz old message was icmp
Output histogram:
echo reply: 6
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
echo: 19
6 message responses generated

igmp:defect
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with invalid field(s)
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 membership reports sent

tcp:
1393 packets sent
857 data packets (135315 bytes)
0 data packets (0 bytes) retransmitted
367 URG only packets
0 URG only packets
0 window probe packets
0 window update packets
170 control packets
1580 packets received
790 acks (for 135491 bytes)
60 duplicate acks
0 acks for unsent data
638 packets (2064 bytes) received in-sequence
0 completely duplicate packets (0 bytes)
0 packets with some dup. data (0 bytes duped)
117 out-of-order packets (0 bytes)
0 packets (0 bytes) of data after window
0 window probes
60 window update packets
0 packets received after close
0 discarded for bad checksums
0 discarded for bad header offset fields
0 connection request
58 connection requests
61 connection accepts
118 connections established (including accepts)
121 connections closed (including 0 drops)
0 embryonic connections dropped
845 segments updated rtt (of 847 attempts)
0 resends due to path MTU discovery
0 path MTU discovery terminations due to retransmits
0 retransmit timeouts
0 connections dropped by rexmit timeout
0 persist timeouts
0 keepalive timeouts
0 keepalive probes sent
0 connections dropped by keepalive

udp:
42886 datagrams received
:
0 incomplete headers
0 bad data length fields
0 bad checksums
0 dropped due to no socket
42860 broadcast/multicast datagrams dropped due to no

socket
0 socket buffer overflows
26 delivered
106 datagrams output
ip는 인터넷 프로토콜을 지정하고, icmp는 정보 제어 메세지 프로토콜을 지정하고, tcp는 전송 제어 프로토콜을 지정하고, udp는 사용자 데이타그램 프로토콜을 지정합니다.

장치 드라이버 통계를 표시하려면, 다음과 같이 입력하십시오.
netstat -v
netstat -v 명령은 업 상태의 각 CDLI 기본 장치 드라이버에 대한 통계를 표시합니다. 이 명령에 대한 샘플 출력을 열람하려면, tokstat 명령, entstat 명령 또는 fddistat 명령을 참조하십시오.

멀티캐스트를 작동가능하게 하는 인터페이스에 관한 정보를 표시하고 그룹 멤버쉽을 열람하려면, 다음과 같이 입력하십시오.
netstat -a -I interface
예를 들어, 802.3 인터페이스가 지정된 경우, 다음의 출력이 산출됩니다.

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
et0 1492 0 0 2 0 0
et0 1492 9.4.37 hun-eth 0 0 2 0 0
224.0.0.1
02:60:8c:0a:02:e7
01:00:5e:00:00:01
-I interface 대신에 플래그 -i가 지정될 경우, 구성설정된 모든 인터페이스가 나열됩니다. 네트워크 인터페이스가 이름 열에 나열되고, lo는 루프백 인터페이스를 의미하고, et는 IEEE 802.3 인터페이스를 의미하고, tr는 토큰링 인터페이스를 의미하고, fi는 FDDI 인터페이스를 지정합니다.

주소 열은 다음과 같은 의미를 갖습니다. 각 인터페이스의 기호 이름이 표시됩니다. 이 기호 이름 아래에, 그 인터페이스에서 결합된 멀티캐스트 그룹의 그룹 주소가 표시됩니다. 그룹 주소 224.0.0.1은 모든 멀티캐스트 인터페이스가 속해 있는 특수 all-hosts-group입니다. 인터페이스의 MAC 주소(콜론 표기법)는 특정 인터페이스에 대해 IP 멀티캐스트를 대신하여 사용 가능해진 다른 MAC 레벨 주소의 리스트를 포함하여 그룹 주소 다음에 옵니다.

통신 서브시스템의 패킷 계수를 표시하려면, 다음과 같이 입력하십시오.
netstat -D
다음의 출력이 산출됩니다.

Source Ipkts Opkts Idrops Odrops
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
tok_dev0 720 542 0 0
ent_dev0 114 4 0 0
- - - - - - - - - - - - - - - - - - - - - - - - -
Devices Total 834 546 0 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
tok_dd0 720 542 0 0
ent_dd0 114 4 0 0
- - - - - - - - - - - - - - - - - - - - - - - - -
Drivers Total 834 546 0 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
tok_dmx0 720 N/A 0 N/A
ent_dmx0 114 N/A 0 N/A
- - - - - - - - - - - - - - - - - - - - - - - - -
Demuxer Total 834 N/A 0 N/A
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IP 773 767 0 0
TCP 536 399 0 0
UDP 229 93 0 0
- - - - - - - - - - - - - - - - - - - - - - - - -
Protocols Total 1538 1259 0 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
lo_if0 69 69 0 0
en_if0 22 8 0 0
tr_if0 704 543 0 1
- - - - - - - - - - - - - - - - - - - - - - - - -
Net IF Total 795 620 0 1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NFS/RPC Client 519 N/A 0 N/A
NFS/RPC Server 0 N/A 0 N/A
NFS Client 519 N/A 0 N/A
NFS Server 0 N/A 0 N/A
- - - - - - - - - - - - - - - - - - - - - - - - -
NFS/RPC Total N/A 519 0 0
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Note: N/A -> Not Applicable)
XNS(Xerox 네트워크 시스템)의 예제
XNS 인터페이스에 대한 네트워크 정보를 표시하려면, 다음과 같이 입력하십시오.
netstat -i -f ns
이로써 다음과 같은 출력이 작성됩니다.

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 ns:6EH 2608C2EA9F7H 281 0 3055 0 0
et1 1492 ns:78H 2608C2EA9F7H 44 0 3043 0 0
nsip0 1536 ns:1H 2608C2EA9F7H 0 0 0 0 0
-i -f ns플래그는 구성설정된 모든 XNS 인터페이스의 상태에 대한 요청을 나타냅니다. 네트워크 인터페이스는 Name열에 나열되고, en은 표준 이더넷 인터페이스를 의미하고, et는 IEEE 802.3 이더넷 인터페이스를 의미합니다. Network 열에 있는 ns:는 XNS 그룹 주소를 의미합니다. 모든 네트워크 및 주소 번호는 번호의 끝에 문자 H가 추가된 16진수입니다.

nsip0는 인터넷 캡슐화 XNS 패킷입니다. 캡슐화에 사용되는 인터넷 목적지 주소는 ifconfig 명령에 있는 ipdst필드에 지정됩니다.

XNS 인터페이스에 대한 라우팅 표 정보를 표시하려면, 다음과 같이 입력하십시오.
netstat -r -f ns
이로써 다음과 같은 출력이 작성됩니다.

Routing tables
Destination Gateway Flags Refcnt Use Interface
Route Tree for Protocol Family 6:
(rootnode)
1H.2608C2EA394H 1H.2608C2EA9F7H UH 1 0 nsip0
18H.* 78H.2608C2EA9F7H UG 0 0 et1
6EH.* 6EH.2608C2EA9F7H U 1 0 en1
78H.* 78H.2608C2EA9F7H U 1 0 et1
(rootnode)
-r -f ns 플래그는 구성설정된 모든 XNS 인터페이스의 라우팅 표 정보에 대한 요청을 표시합니다. 네트워크 인터페이스는 Interface 열에 나열되고, en는 표준 이더넷 인터페이스를 의미하며 et는 IEEE 802.3 이더넷 인터페이스를 의미합니다. Interface 열에 있는 nsip0는 XNS를 인터넷 캡슐화 인터페이스로 의미합니다. Destination 및 Gateway 주소 번호는 그 번호 끝에 문자 H가 추가된 16진수입니다. Destination 열에 있는 *(별표)는 네트워크가 지점 대 지점 네트워크가 아님을 나타냅니다.

관련 정보
atmstat 명령, entstat 명령, fddistat 명령, iostat 명령, tokstat 명령, trpt 명령, vmstat 명령.

hosts 파일 형식, networks 파일 형식, protocols 파일 형식, services 파일 형식.

AIX Versions 3.2 and 4 Performance Tuning Guide에 있는 통신 I/O 모니터링 및 조절.

AIX Version 4.3 System Management Guide: Communications and Networks에 있는 게이트웨이, 명명, TCP/IP 주소 지정, TCP/IP 네트워크 인터페이스, TCP/IP 프로토콜 및 TCP/IP 라우팅.

AIX Communications Programming Concepts의에 있는 프로그래밍용 XNS(제록스 네트워크 시스템 개요.


Posted by Tornado tornado

댓글을 달아 주세요

시스템 명령어인 netstat 를 사용하는 방법

#netstat -nap (열려 있는 모든 포트)
#netstat -l 또는 netstat -nap | grep LISTEN (LISTEN 되는 모든 포트)
#netstat -nap | grep ESTABLISHED | wc -l ( 모든 서비스 동시 접속자 수)
#netstat -nap | grep :80 | grep ESTABLISHED | wc -l ( 웹 동시 접속자 수)


포트스캔 명령어로 확인 하는 방법

# TCP 포트 확인 방법
nmap -sT -p 1-65535 localhost
# UDP 포트 확인 방법
nmap -sU -p 1-65535 localhost
# 네트워크에 열린 포트 확인
nmap -sX -p 22,53,110 211.239.111.*


lsof 명령어로 확인 방법

# 모든 네트워크 소켓 확인
lsof -I

Posted by Tornado tornado

댓글을 달아 주세요

2003년 1월 25일 SQL_Overflow 웜(슬래머 웜)에 의해 발생한 '1.25 인터넷 대란' 이후 안철수연구소로 이상 네트워크 패킷(이하 이상 패킷)이 발생해 문의하는 경우가 많아졌다. 모든 이상 패킷이 웜 등의 악성 코드에 의해 발생하지는 않지만 최근 웜 등이 네트워크를 통해 전파되며 네트워크를 통한 공격 기능을 갖게 되면서 악성 코드에 의해서도 많이 발생하고 있다.

악성 코드에 의한 이상 패킷 증가는 크게 자기 복제를 하면서 네트워크 패킷을 대량으로 발생하는 경우와 악성 IRC봇(Malicious IRCBot)으로 대표되는 네트워크 공격 기능을 가진 웜, 트로이목마 때문에 발생하는 경우로 나눌 수 있다. 많은 기업, 학교 등의 전산 관리자는 이상 패킷이 발생하면 이상 패킷이 발생하니 해결해 달라는 문의를 많이 한다.

하지만, 이상 패킷은 악성 코드뿐 아니라 기기 장비, 소프트웨어 충돌 등에서도 발생하며 이상 증세 만으로는 정확한 원인을 파악하기 어려우므로 악성 코드에 의해 이상 패킷이 발생 할 때 관리자가 조치 해야 할 사항을 정리해 보겠다.

1. 이상 네트워크 패킷 유형

현재 발생하는 이상 패킷은 크게 두 가지로 나눌 수 있다.

1) 네트워크 트래픽 증가
2) 비정상적인 패킷 발생


네트워크 트래픽은 일상적인 컴퓨터 사용 중에도 발생 할 수 있지만 어떤 원인으로 크게 증가하여 컴퓨터나 네트워크 장비 등에 무리를 줄 수 있다. 예를 들어 메일로 급속히 전파되는 웜이 사내의 많은 컴퓨터를 감염 시켰을 때 감염된 컴퓨터들이 일제히 메일 발송을 시도한다면 메일 발송 관련 25번 포트의 트래픽이 증가하게 된다. 대량으로 메일을 발송하는 웜, 바이러스로 인해 메일 서버가 다운된 보고는 많이 있다.

이외 평상시에는 잘 사용되지 않지만 특정 포트로 트래픽이 증가하는 경우도 있다. 악성 IRC봇은 IRC 포트(보통 6667번 포트)를 이용해 다른 시스템을 공격하기 위해 대량의 네트워크 트래픽을 발생 시킬 수 있다.

패킷이 외부로 나가기 위해서는 라우터 등의 장비를 거치므로 사내 망의 많은 컴퓨터가 감염되어 동시에 공격을 위해 트래픽을 발생 시킬 경우 네트워크 관련 장비 등이 과부하로 다운 될 수도 있다. 다운되지 않더라도 불필요한 내용을 처리해야 하므로 전반적인 네트워크 속도가 느려 진다.

최근에 문제되고 있는 악성 IRC봇 류는 포트 번호, 데이터 양 등을 공격자가 임의로 정할 수 있다. 예전에는 IRC 포트인 6667번 포트를 사용했지만 최근에는 포트 번호도 임의로 지정되는 경우가 많다.


[그림1] 다수의 시스템이 특정 IP로 공격하는 화면


2. 관리자가 파악해야 할 내용

네트워크 관리자는 비정상적인 네트워크 트래픽 발생시 감지 할 수 있다. 하지만, 보통 이상 패킷의 증가만 파악되고 원인은 모르는 경우가 많다. 이상 패킷 증가가 사용하는 프로그램 문제, 장비 불량 등일 수 있지만 바이러스와 웜 등의 악성 코드가 발생하는 경우도 많다.

보통 이상 패킷이 발생하면 백신 업체에 연락하는 경우가 많지만 발생 현상이나 패킷만 가지고 어떤 웜이나 트로이목마 등에서 발생했는지 알기 힘들다. 또한 기술지원 시에도 이상 패킷 발생 자체로는 큰 도움을 줄 수 없으며 관리자가 다음 내용을 파악 후 안철수연구소에 알려줘야 한다.

1) 이상 패킷 내용 파악 (패킷 캡쳐, 발생 시스템 수, 문제 상황 등)
2) 이상 패킷 발생 시스템 파악
3) 이상 패킷 발생 시스템에서 정보 수집
4) 이상 패킷 발생 시스템에서 샘플 수집


이상 패킷이 발생할 경우 패킷 내용을 캡쳐 해 백신 회사로 보내야 한다. 이때 아래와 같이 IP 어드레스나 포트 번호와 같은 간단한 내용으로는 문제를 파악하기 힘들므로 상세한 내용을 캡쳐 해야 한다.

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/0 xx.xx.xxx.xxx Null xx.xxx.xxx.xx 01 0000 0800 1

단, 패킷 만으로는 대부분의 경우 정확한 원인을 파악하지 못하므로 이상 패킷 발생 시스템을 파악할 필요가 있다. IP 어드레스(IP Address)와 맥 어드레스(Mac Address)를 통해 이상 패킷을 발생하는 시스템을 확인 할 수 있다. 단, IP 어드레스나 맥 어드레스는 위조가 가능하며 보통 IP 어드레스가 위조된다. IP 어드레스가 위조되었을 때는 맥 어드레스로 찾아야 한다. 맥 어드레스는 네트워크 장비를 거치며 바뀌므로 네트워크 장비를 종료해 범위를 좁혀가며 문제의 시스템을 찾아야 한다.

이상 패킷을 발생하는 것으로 추정되는 시스템을 찾으면 해당 시스템에서 이상 패킷을 발생하는 원인 프로그램을 찾아 안철수연구소로 분석 의뢰해야 한다. 수상한 파일을 찾기가 어렵다면 패킷 캡쳐 파일과 시스템의 정보를 파악해 주는 안 리포트, 포트 상태를 알려주는 FPort, TCPView 등의 프로그램을 이용해 해당 시스템의 정보를 안철수연구소 바이러스 신고 센터로 보내야 한다.

3. 툴 사용법

이상 패킷을 발생하는 시스템에서 이상 패킷을 발생하는 원인 프로세스를 찾는 건 쉬운 일은 아니지만 다음과 같은 툴을 사용하면 수상한 파일을 찾는 시간을 줄일 수 있다. 최소한 이들 프로그램의 리포트만 내용만 알려줘도 안철수연구소에서 분석 후 수상한 파일을 요청할 수 있다.

문제 파일/프로세스를 찾는데 도움을 주는 툴은 다음과 같다.

1) 안리포트 - 시스템의 전반의 정보 파악
2) FPort - 이상 패킷 발생 포트와 프로그램 파악
3) TCPView - 이상 패킷 발생 포트와 트래픽 양, 발생 프로그램 파악


1) 안리포트(AhnReport)

안철수연구소에서 제공하는 안리포트는 사용자의 시스템 정보를 수집하는 역할을 수행하는 프로그램으로 이를 통해 문제 원인과 신종 악성 코드를 추적하는 목적으로 사용된다. 안철수연구소 고객지원혹은 기업고객지원에서 파일을 다운로드 받을 수 있다.

수집하는 정보는 다음과 같다.

- 시스템 사양 및 운영체제(OS)
- 설치된 제품 및 파일 목록
- 레지스트리 정보 중 제품 관련 정보
- 백신이 설치되어 있는 경우 이벤트 기록
- 윈도우 부팅 과정에서 참조하는 파일(WIN.INI, SYSTEM.INI) 내용
- 윈도우 부팅 과정에서 실행되는 프로그램의 이름
- 현재 실행중인 프로세서(실행중인 프로그램) 목록
- Uninstall 정보 등

사용 방법은 다음과 같다.

1. [Ahnreport Download] 버튼을 클릭해 파일을 임의의 폴더에 저장한다.

2. 저장한 Ahnreport.exe 파일을 실행한다. 이때 가급적 불필요한 프로그램이나 서비스는 종료해 원인이 되는 프로세스를 손쉽게 찾을 수 있도록 한다.

3. 주의 창이 뜨고 확인을 누르면 시스템에서 수집한 정보를 확인 할 수 있다.


[그림2] 안리포트 실행 화면


4. [저장] 혹은 [파일] →[저장]을 선택하면 지원 담당자 정보, 사용자 정보, 상세 사항 등의 내용을 입력하는 창이 뜬다.


[그림3] 추가 정보 입력 창



5. 필요한 사항을 입력하고 확인을 누르면 관련 정보를 ZIP 파일로 저장하는 창이 뜬다. 적절한 이름의 파일로 저장한다.(예: mypc01.zip)

6. 저장된 내용을 패킷 내용, 기타 정보, 수상한 파일과 함께 바이러스 신고 센터로 신고 한다.

바이러스 신고센터는 [안철수연구소 홈페이지] →[고객지원] →[바이러스신고] 혹은 다음 주소에서 할 수 있다.

- 개인 고객 바이러스 신고센터
- 기업 고객 바이러스 신고센터

 

2) FPort

네트워크 상태 정보를 알려주는 NETSTAT.EXE는 해당 시스템의 열려있는 포트 상태만 알 수 있고 어떤 프로그램이 해당 포트를 사용하는지 알 수 없다. Foundstone 사에서 제공하는 공개 프로그램인 FPort는 현재 시스템의 열려있는 포트와 해당 포트를 사용하는 프로그램을 알려준다. FPort는 여기에서 다운로드 받을 수 있으며 이 프로그램은 윈도우 NT 계열(2000/XP)에서만 실행 가능하다. 윈도우 NT 에서는 psapi.dll 파일이 같은 폴더나 윈도우 시스템 폴더에 존재해야 하며 윈도우 2000 이상에서는 기본으로 존재한다.

FPort를 통해서는 포트 번호와 해당 포트를 사용하는 프로세스를 알 수 있다. 즉, 아래 그림에서는 135번 포트는 svchost.exe가 1032 포트는 MSTask.exe가 사용 중임을 알 수 있다. 인터넷 관련 프로그램을 가급적 종료하면 웜이나 트로이목마 등의 악성 코드만 실행되므로 의심스러운 파일을 확인한 후 해당 파일을 찾아 바이러스 신고 센터로 보낸다.


[그림4] FPort 실행 화면


사용자가 어떤 프로그램이 수상한지 알 수 없는 경우에는 결과 내용을 파일로 저장할 필요가 있다. 결과 내용을 파일로 저장할 때는 "fport > 파일명"을 이용한다. 예를 들어 결과 내용을 result.txt로 저장하기 위해서 fport > result.txt를 입력한다. 결과 파일도 신고시 첨부한다.


[그림5] FPort 결과 저장


3) TCPView

FPort는 사용중인 포트와 프로그램만 알려줘 현재 이상 패킷을 발생 시키는 프로그램을 파악하기 어렵다. TCPView는 프로그램 목록뿐 아니라 프로그램의 패킷 양까지 보여줘 현재 패킷을 발생시키는 파일을 찾기 쉽게 도와준다. TCPView는 여기에서 다운로드 받을 수 있다. 현재 이상 패킷이 발생하고 있다면 트래픽 양에 따라 색깔로 표시되므로 트래픽을 많이 발생하는 파일을 모아 보내주면 된다.


[그림6] TCPView 실행 화면


문제 시스템을 확인 할 때 이상 패킷이 발생하지 않을 수 있다. 이상 패킷은 공격자(웜 혹은 트로이목마 제작자)가 원할 때 공격 명령을 내리므로 다음 공격까지 이상 패킷이 기다리거나 실행 중인 파일을 수집해 안철수연구소로 보내주면 된다.


4. 사례

다음은 모 회사에서 발생한 이상 패킷의 원인을 찾는 과정이다. 최종 확인 결과 Win32/Randex.worm의 변형이 발견되었고 이 웜이 이상 패킷을 발생 시킨 것으로 추정되었다. 이때 나타나는 현상은 크게 두 가지이다.

(1) 특정 목적지(destination)로 패킷이 나가는 현상

이상 패킷은 방화벽 로그를 확인한 결과 여러 개의 IP에서 고정된 목적지로 임의의 포트로 나가고 있었다. 발송 IP 자체가 회사 내에 존재하지 않는 임의의 주소이기 때문에 IP 주소로는 더 이상의 분석은 불가능한 상황이다. 캡쳐 된 패킷을 분석한 결과 해당 패킷은 Win-Trojan/MircPack, Win32/Agobot.worm, Win32/Randex.worm 등의 악성 IRC봇(IRCBot)류로 추정되었다.

악성 IRC봇에서 흔히 사용되는 외부에서 6667번, 928번 등의 포트를 이용해 들어온 흔적을 찾아보았으나 전혀 없었다. 따라서, 본 건에 대해서는 재발시 백본 스위치(Backbone Switch)에서 MAC 어드레스(MAC Address)를 찾아서 해당 컴퓨터를 찾아 원인을 좁혀 나가는 것으로 잠정 결론 내렸다.

(2) 445번 포트를 검색하는 컴퓨터

방문시 특정 IP 어드레스의 컴퓨터가 계속해서 445번 포트를 검색하는 것을 IDS에서 감지됨에 따라 확인 요청을 받았다. 다행히 해당 컴퓨터가 파악되어 있는 상태여서 확인이 가능했다. 해당 컴퓨터는 사용자 계정에 대한 비밀번호(password)는 존재하지만, 관리자(Administrator) 계정에 대한 비밀번호는 엔터(없음)였다.

Netstat -an으로 확인해 본 결과 445번 포트로 SYN_SENT된 패킷이 수십개씩 보였다. 최신 버전의 V3로 검사 했지만 감염 파일은 존재하지 않아 신종 웜 등으로 의심되어 안리포트(AhnReport.exe)로 시스템 정보를 얻어 의심스러운 프로세스인 netd32.exe 파일의 존재를 확인했다.

안리포트로 확인된 실행중인 프로세스 정보를 보면 다음과 같았다.

실행중인 프로세스
c:\ahnreport.exe 1844 5, 0, 4, 29
c:\progra~1\ahnlab\v3\monsvcnt.exe 624 5, 0, 0, 160
c:\program files\ahnlab\smart update utility\ahnsd.exe 1080 5, 3, 0, 14
c:\program files\ahnlab\smart update utility\ahnsdsv.exe 464 5, 3, 0, 150
c:\program files\ahnlab\v3\monsysnt.exe 1748 5, 0, 0, 142
c:\program files\msn messenger\msnmsgr.exe 1116 6.0.0602
c:\winnt\explorer.exe 884 5.00.3700.6690
c:\winnt\system32\cmd.exe 752 5.00.2195.6656
c:\winnt\system32\conime.exe 256 5.00.2195.6655
c:\winnt\system32\csrss.exe 168 5.00.2195.6601
c:\winnt\system32\internat.exe 1112 5.00.2920.0000
c:\winnt\system32\lpagent\lpauupdt.exe 540 2.0.1001.565
c:\winnt\system32\lpagent\lpisactv.exe 956 2.0.1.983
c:\winnt\system32\lpagent\lpisagnt.exe 612 2.0.1001.1011
c:\winnt\system32\lpagent\lpv3agnt.exe 900 2.0.1001.343
c:\winnt\system32\lsass.exe 228 5.00.2195.6695
c:\winnt\system32\mstask.exe 680 4.71.2195.6704
c:\winnt\system32\netd32.exe 1092 N/A -> 수상한 프로세스 확인
c:\winnt\system32\regsvc.exe 664 5.00.2195.6701
c:\winnt\system32\services.exe 216 5.00.2195.6700
c:\winnt\system32\smss.exe 144 5.00.2195.6601
c:\winnt\system32\spoolsv.exe 436 5.00.2195.6659
c:\winnt\system32\svchost.exe 484 5.00.2134.1
c:\winnt\system32\svchost.exe 784 5.00.2134.1
c:\winnt\system32\svchost.exe 408 5.00.2134.1
c:\winnt\system32\taskmgr.exe 280 5.00.2195.6620
c:\winnt\system32\wbem\winmgmt.exe 736 1.50.1085.0100
c:\winnt\system32\winlogon.exe 188 5.00.2195.6714
c:\winnt\system32\wuauclt.exe 1144 5.4.3790.14 built by: lab04_n

수상한 netd32.exe 파일을 안철수연구소에서 확인한 결과 Win32/Randex.worm의 변형으로 확인되었다. 이 웜에 대한 진단/치료(삭제) 기능이 추가된 최신 엔진이 나오기 전에 응급 조치로 해당 프로세스를 죽이고 net32.exe 파일을 삭제 후 해당 컴퓨터의 Administrator 계정의 비밀번호를 변경했다.

이상이 패킷 발생부터 문제 컴퓨터 파악, 수상한 파일 수집, 백신 회사에 샘플을 보내는 과정이며 보다 빠른 문제 해결을 위해서는 발생 패킷 캡쳐, 문제 시스템의 안리포트 실행 결과, 수상한 파일, 네트워크 상태 등의 정보를 수집해주면 좋지만 문제의 시스템을 파악해서 안리포트 결과만이라도 안철수연구소로 보내면 수상한 파일에 대한 요청을 안철수연구소에서 할 수 있어 보다 빨리 문제가 해결될 수 있다.

5. 정리

최근 이상 패킷 발생으로 문의하는 네트워크 혹은 보안 관리자가 많다. 이때 단순히 몇 번 포트로 이상 패킷 발생과 같은 내용으로는 원인 파악 및 문제를 해결하기 어려우므로 다음과 같은 정보를 보내야 한다.

1) 상세한 이상 패킷 내용 (패킷 캡쳐, 발생 시스템 수, 문제 상황 등)
2) 이상 패킷 발생 시스템의 안리포트 실행 결과
3) 이상 패킷 발생 시스템의 Fport나 TCPView 실행 결과
4) 이상 패킷 발생 시스템에서 수집한 수상한 파일

적어도 이상 패킷을 발생하는 시스템을 파악해 안리포트 실행 결과라도 보내줘야 안철수연구소를 포함한 백신 업체에서 문제를 해결 할 수 있다.

최근 등장하는 대부분의 웜, 바이러스가 네트워크를 통해 전파되므로 이상 패킷을 발생시키는 악성 코드의 수는 계속 증가할 것으로 보인다. 이에 대한 대처로 관리자는 사내 컴퓨터를 고정 IP로 할당 해 문제 발생시 문제 시스템을 손쉽게 찾아 해당 시스템의 정보와 수상한 파일을 수집해 백신 회사로 신고하고 해당 시스템의 네트워크 단절 등의 백신 회사가 맡기 어려운 일을 해야 한다.

출처: 안철수 연구소

Posted by Tornado tornado

댓글을 달아 주세요