달력

22025  이전 다음

  • 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

[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 1

OS/LINUX 2004. 6. 4. 12:16

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

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

[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 3  (0) 2004.06.04
[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 2  (0) 2004.06.04
Ftp 서비스  (0) 2004.06.04
[펌] L4 switch  (0) 2004.06.04
cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Posted by 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로 세팅하면 인원 제한을 없애는 것이다.

다음 이전 차례

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

[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 2  (0) 2004.06.04
[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 1  (0) 2004.06.04
[펌] L4 switch  (0) 2004.06.04
cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
Posted by tornado
|

[펌] 정보전략계획(ISP) Roadmap

이것저것/기획 2004. 6. 4. 00:27
 

'이것저것 > 기획' 카테고리의 다른 글

[펌] IT 프로젝트 일정 계획 수립 시 유의사항  (0) 2009.05.15
[펌] 소프트웨어 개발의 전형적인 실수 목록  (0) 2005.06.01
[펌] 브레인 스토밍  (0) 2004.05.13
[펌] 성공적인 프리젠테이션을 위한 7가지 원칙  (0) 2004.05.13
[펌] 기획? 기획자? 기획서?  (0) 2004.05.13
Posted by 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 한다

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

[펌] Nmap 네트워크 점검 도구 및 보안 스캐너 1  (0) 2004.06.04
Ftp 서비스  (0) 2004.06.04
cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
Posted by tornado
|

[펌] Metallica - Master of Puppets

이것저것/낙서장 2004. 5. 29. 11:01

수많은 기타 지망생들을 절망에 빠트렸던

다운 피킹의 대표작 -_ -,,

 

 

Metallica - Master of Puppets

[ Master of Puppets 1986 ]

 


'이것저것 > 낙서장' 카테고리의 다른 글

[펌] 공감 가는 야그*^^*  (0) 2004.06.22
월요일... ㅋㅋ  (0) 2004.06.07
[펌] Coldplay - Trouble  (0) 2004.05.24
[펌] 실수.  (0) 2004.05.20
[펌] 이게 뭐더라?;  (0) 2004.05.20
Posted by tornado
|

톰캣에서 계정 사용자 인식하기..

JAVA/JSP_Servlet 2004. 5. 28. 10:41

<Listener className="org.apache.catalina.startup.UserConfig"
            directoryName="public_html"
            userClass="org.apache.catalina.startup.PasswdUserDatabase"/>

 

 

사용하고자 하는 host 안에  넣어주면 /etc/passwd 안에 들어있는 user 의 이름으로 된

주소를 인식하여 브라우저에 표현해 준다.

 

xxx.com/~계정/   과 같이 접근..

 

 

사이트가 읍어져서리.. 생각나는대로 계속 블로그에 적는중...

'JAVA > JSP_Servlet' 카테고리의 다른 글

[펌] Struts Tips  (0) 2004.07.20
[펌] 블로그 배급·구독 위한 가장쉬운 방법, 'RSS'  (0) 2004.07.09
Commons BeanUtils 에서 RowSetDynaClass 사용시에..  (0) 2004.04.21
apache + tomcat 연동시 Context 문제  (0) 2004.04.16
&lt;html:link /&gt; 태그 중에서 ^^  (0) 2004.04.07
Posted by tornado
|

cronolog 를 이용해서 apache 로그 분리하기..

OS/LINUX 2004. 5. 25. 15:54

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
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] Netstat에 대하여  (0) 2004.05.18
Posted by tornado
|

Linux 에서 rpm db 꼬였을때.. ㅡㅡ

OS/LINUX 2004. 5. 25. 10:01

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

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

 

 

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

이 파일들을 싹 지운다.

 

# rm -f __db*

 

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

 

# rpm --rebuilddb

 

 

 

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

[펌] L4 switch  (0) 2004.06.04
cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] Netstat에 대하여  (0) 2004.05.18
[펌] netstat 사용해서 포트 확인하기  (0) 2004.05.18
Posted by tornado
|

[펌] Coldplay - Trouble

이것저것/낙서장 2004. 5. 24. 11:32

그런 것들이 매일 문제가 될지도 모르지만

 

 

Coldplay - Trouble
[ Parachutes 2000 ]


'이것저것 > 낙서장' 카테고리의 다른 글

월요일... ㅋㅋ  (0) 2004.06.07
[펌] Metallica - Master of Puppets  (0) 2004.05.29
[펌] 실수.  (0) 2004.05.20
[펌] 이게 뭐더라?;  (0) 2004.05.20
[펌] 뻥치기 땡치기...  (0) 2004.05.19
Posted by tornado
|

[펌] 실수.

이것저것/낙서장 2004. 5. 20. 14:29


 

....괜찮다고 말하면서

눈물은 대체 왜 보이는거야.

'이것저것 > 낙서장' 카테고리의 다른 글

[펌] Metallica - Master of Puppets  (0) 2004.05.29
[펌] Coldplay - Trouble  (0) 2004.05.24
[펌] 이게 뭐더라?;  (0) 2004.05.20
[펌] 뻥치기 땡치기...  (0) 2004.05.19
[펌] 성진님의 글.........클릭  (0) 2004.05.04
Posted by tornado
|

[펌] 이게 뭐더라?;

이것저것/낙서장 2004. 5. 20. 14:24

중증 기억상실증에 시달리고 있는 나에겐

한달전에 짰던 코드를 보고 뜯어고치라고 시키라는 건

그냥 새로 짜라는 말과 똑같애.

 

" 대체 이게 뭐란 말이야! "

 

... 내가 만들어 놓은 거지만 내가 봐도 정말 모르겠다; 후우;

그나마 이럭저럭 버틸만한 건 바쁜 일도 힘든 일도 대충 끝나서일까.

'이것저것 > 낙서장' 카테고리의 다른 글

[펌] Coldplay - Trouble  (0) 2004.05.24
[펌] 실수.  (0) 2004.05.20
[펌] 뻥치기 땡치기...  (0) 2004.05.19
[펌] 성진님의 글.........클릭  (0) 2004.05.04
[펌] ♬ 올챙이Ssong ♬  (0) 2004.05.04
Posted by tornado
|

[펌] 뻥치기 땡치기...

이것저것/낙서장 2004. 5. 19. 18:48

뻥치기, 땡치기, 뻥치기, 땡치기...

'이것저것 > 낙서장' 카테고리의 다른 글

[펌] 실수.  (0) 2004.05.20
[펌] 이게 뭐더라?;  (0) 2004.05.20
[펌] 성진님의 글.........클릭  (0) 2004.05.04
[펌] ♬ 올챙이Ssong ♬  (0) 2004.05.04
[펌] 추억의 만화 주제가 모음....  (0) 2004.05.04
Posted by tornado
|

[펌] Tomcat 클러스터링

JAVA/WAS 2004. 5. 19. 18:46

Tomcat 클러스터링

등록일: 2002년 08월 20일
저자: 시암 쿠마르 도다불라(Shyam Kumar Doddavula)

본 기사는 클러스터링이 웹 애플리케이션에 어떤 이익을 줄 것인지, 자바스페이스(JavaSpaces) 기술을 사용한 고도의 확장성, 부하분산(load-balancing), 고가용성(availability)을 제공하는 자카르타 톰캣(Jakarta Tomcat) 서블릿 엔진을 위해 개발한 클러스터링 솔루션에 대해 기술한 글이다.

소개

웹 기반 애플리케이션 사용이 증가함에 따라 성공에 결정적인 영향을 주는 요인으로 확장성과 가용성이 대두되고 있다. 웹 애플리케이션을 수용하는 서버에 클러스터링 솔루션을 구축하는 것은 간단하면서도 비용을 절감시켜주는 솔루션이라 할 수 있다.

자바스페이스 기술은 클러스터링 솔루션을 설계하는데 사용 될 수 있는 분산 공유 메모리 모델을 제공한다. 원격 절차 호출(RPC: remote procedure calling)을 가능하게 하거나 메시지 교환을 반복적으로 실행하는 전형적인 분산시스템 기법과는 달리, 이 기술을 사용하는 솔루션은 오브젝트를 전달하는 능력을 수행한다. 이들 오브젝트는 일반적인 원격시스템에서 작업을 수행하는데 필요한 모든 정보(심지어 소스코드까지)를 연상, 공유, 분산 메모리를 사용하여 운반한다. 자바스페이스는 오브젝트를 스페이스에 추가하고, 오브젝트 복사본을 읽어오고, 스페이스로부터 오브젝트를 가져오는 간단한 쓰기, 읽기, 가져오기 연산 집합을 제공한다.


[그림 1] 자바스페이스를 사용한 분산시스템(Sun Microsystems승인 하에 사용)

자바스페이스는 지니(Jini) 기술 서비스의 핵심이다. 지니 프로그래밍 모델은 리스 모델(leasing model)과 동적 서비스 디스커버리(dynamic service discovery)를 통해 자체적으로 구성되는(self-configuring) 능동적인 분산시스템을 만드는데 필요한 하부구조를 제공한다. 이 기술에 대해 보다 많은 정보는 아래 관련자료를 참고하면 된다.

지니 프로그래밍 모델과 결합된 자바스페이스 기술은 높은 시공완화(spatial and temporal decoupling)를 제공하기 때문에 고도로 확장가능하며, 장애 허용적이고(fault-tolerant), 동적으로 구성할 수 있는 분산시스템 설계를 가능하게 해준다. 본 기사에서는 이와 같은 기술들을 사용하여 서블릿 API 구축에서 각광 받는 오픈 소스인 톰캣 서블릿 엔진(Catalina 4.x)을 위한 간단한 클러스터링 솔루션에 대해 살펴보고자 한다.

왜 클러스터링인가?

클러스터링 솔루션이 일반적으로 제공하는 것은 다음과 같은 것들이다.
  • 확장성(Scalability)
  • 고가용성(High Availability)
  • 부하분산(Load Balancing)
확장성

여기서 핵심질문은 '하나의 요청을 처리하는데 T라는 시간이 소요된다면 N개의 동시 요청을 처리하는 데는 얼마의 시간이 걸릴까?'하는 것이다. 목표는 부하가 증가됨에 따라 컴퓨팅 자원을 증가시켜 가능한 한 T에 가깝게 시간을 가져가는 것이다. 이상적인 솔루션은 수직적(서버의 컴퓨팅 자원을 증가시키는 것) 및 수평적(서버 수를 늘리는 것) 확장을 모두 지원해야 하며 확장은 선형적이어야 한다.

고가용성

여기서의 목표는 오류극복 기능을 제공하는 것이다. 클러스터의 한 서버가 작동이 불가능하게 되면 클러스터 내의 다른 서버가 작업을 대신 수행해야 하며 최종 사용자에게는 가능한 한 투명하게 진행되어야 한다.

서블릿 엔진의 경우 클러스터링 솔루션에 의해 제공되는 전형적인 오류극복 기능이 있으며 이는 다음과 같은 두 단계로 이루어 진다.
  • 요청단계 오류극복(Request-level Failover)
  • 세션단계 오류극복(Session-level Failover)
요청단계 오류극복 클러스터 내 하나의 서버가 작동할 수 없게 되면 모든 후속 요청은 클러스터 내의 정상적인 서버에 재전달 되어야 한다. 일반적인 클러스터링 솔루션에서는 서버의 상태를 지속적으로 추적하고 응답이 없는 서버에는 요청을 전송하지 않는 심장박동 메커니즘(heartbeat mechanism)을 이용하는 것을 포함한다.

세션단계 오류극복 HTTP 클라이언트는 서버에서 관리되는 세션을 가질 수 있다. 따라서 세션단계 오류극복이라는 것은 클러스터의 서버가 작동 할 수 없게 되면 클러스터 내의 다른 서버들이 오류발생 서버가 관리하던 세션의 연속성 상실을 최소화하며 연계하여 작동할 수 있어야 한다는 것이다. 일반적인 클러스터링 솔루션에서는 세션 정보를 클러스터 간(적어도 클러스터 내의 다른 한 서버)에 복제하는 것으로 구현된다.

부하분산

부하분산의 목표는 솔루션이 최종사용자에게 최대한의 응답시간을 제공하기 위해 클러스터 서버 간에 부하를 나눠주어야 한다는데 있다.

일반적인 클러스터링 솔루션에서는 간단한 라운드 로빈 알고리즘(round robin algorithm)이나 서버상의 부하와 가용자원을 지속적으로 추적하여 요청을 분산하는 복잡한 알고리즘 같은 부하분산 알고리즘을 사용하여 구현된다.

제안 솔루션

일반적인 클러스터링 솔루션은 분산 시스템 솔루션 구축하기 위해 클라이언트-서버 패러다임을 사용하는데 확장성에 제한이 있다.

여기서 사용될 스페이스 패러다임에서는 클러스터링이 하나의 서버에서 다른 서버로 오브젝트 이동을 통해서 이뤄지는데 이 오브젝트는 실행되는 현 상태와 바이트코드, 필요하다면 연상, 분산, 공유 메모리를 포함하는 다른 모든 것을 전달한다.

자카르타 톰캣 서블릿 엔진이 어떻게 작동하는지 살펴보자. 이것은 [그림 2]와 같이 요청을 접수하고 수행하기 위해 커넥터(connector)와 프로세서(processor)를 사용한다.


[그림 2] 독립 톰캣 서블릿 엔진의 아키텍처

커넥터는 다른 소스로부터의 요청에서 접수 상세를 추출하며, 프로세서는 요청 수행 상세를 추출한다.

아래 [그림 3]은 제안 클러스터링 솔루션의 아키텍처를 보여준다.


[그림 3] 클러스터링 톰캣 서블릿 엔진의 아키텍처

클러스터 서버 커넥터(Cluster Server Connector)는 클라이언트의 요청을 접수하고 클러스터 서버 프로세서(Cluster Server Processor)는 RequstEntry 오브젝트로 요청을 캡슐화(encapsulate) 하고 자바스페이스에 오브젝트를 기록한다. 클러스터 워커 커넥터(Cluster Worker Connector)는 자바스페이스로부터 이 요청들을 가져오고 클러스터 워커 프로세서(Cluster Worker Processor)는 요청을 수행한다.

이 클러스터 서버와 클러스터 워커들은 복수의 인스턴스로 존재할 수 있으며 여러 대의 기계에 분산될 수도 있다.

RequestEntry는 다음과 같이 정의된다. 
public class RequestEntry extends net.jini.entry.AbstractEntry { private static int ID = 0; public RequestEntry(){ id = String.valueOf(ID++); } public String id; public RemoteSocketInputStream input; public RemoteOutputStream output; }
id 필드는 요청을 식별한다. 입력 필드인 RemoteSocketInputStream 오브젝트형은 원격 기계상의 소켓의 입력 스트림 접속을 제공하고 출력 필드 오브젝트인 RemoteOutputStream은 원격 출력 스트림 접속을 제공한다.

하나의 요청이 접수되었을 때, 소켓의 입출력 스트림은 원격 기계상에서 접속할 수 있는 원격 스트림으로 감싸진다. 요청등록이 이 원격 스트림으로 생성되고 아래의 클러스터 서버 프로세서 코드를 통해 자바스페이스에 기록된다. 
... /** * 이 프로세서에 할당된 소켓에 들어오는 HTTP 요청을 처리한다. * 수행 중 발생한 어떤 예외도 적절하게 흡수, 처리되어야 한다. * * @param socket 클라이언트와 접속하는 소켓 */ private void process(Socket socket) { RemoteSocketInputStream input = null; RemoteOutputStream output = null; try{ // TC 클래스 로더의 쓰레딩 문제로 인해 동기화 되어야 한다. synchronized(this.getClass()){ input = new RemoteSocketInputStreamImpl(socket, connector.getPort()); output = new RemoteOutputStreamImpl(socket.getOutputStream()); } log("socket address = " + input.getSocketAddress() + ", port " + input.getServerPort()); RequestEntry entry = new RequestEntry(); entry.input = input; entry.output = output; requestGenerator.write(entry); }catch(Exception ex){ log("parse.request", ex); } } ...
클러스터 워커 커넥터와 프로세서는 아래 코드에서처럼 이들 엔트리를 가져오고 요청을 수행한다. 
... public void run() { // 셧다운 신호를 받을 때까지 요청을 수행한다 while (!stopped) { log("waiting for entry in JavaSpace..."); RequestEntry requestEntry = null; try{ synchronized(this){ ... requestEntry = (RequestEntry)requestReader.take(); ... } }catch(Exception ex){ log("internal error while getting request entry from JavaSpace", ex); } log("got an entry " + requestEntry); // 요청을 수행한다 if (requestEntry != null) process(requestEntry); } ... } ...
제안 솔루션이 제공하는 것들은?

이 솔루션은 부하가 증가함에 따라 클러스터 워커의 수를 증가시킬 수 있다. 또한 이들 클러스터 워커는 여러 대의 기계에 걸쳐 분산될 수 있으므로 고도의 확장성을 제공한다. 이 외에도 여러 대의 기계에서 동작하는 복수의 자바스페이스 서비스 인스턴스가 존재할 수 있고, 집단을 구성하며, 클러스터 서버가 그 중 하나에 기록을 결정할 수 있기 때문에 네트워크 트래픽을 관리를 할 수 있도록 유지한다.

클러스터 서버와 워커는 구현된 자바스페이스 서비스들을 찾기 위해 지니 서비스 디스커버리 메커니즘을 사용하므로 그들의 위치는 하드코딩될 필요가 없다. 따라서 이 솔루션은 동적으로 설정할 수 있다. 지니 리스 모델을 사용하므로 전체 시스템을 셧다운할 필요 없이 추가적인 자원을 첨부할 수 있다. 마찬가지로 현재 자원도 더 이상 지니 라이센스를 갱신하지 않고 현재 라이센스가 만료된 후에 우아하게 제거할 수도 있다.

클러스터 내의 여러 서버에 분산된 요청은 밀어내기식이 아닌 끌어오기식이므로 동작하지 않는 서버에 요청이 전달되는 일은 전혀 없기 때문에 요청단계 오류극복이 제공되는 것이다.

이 솔루션에서 세션정보는 자바스페이스에 있고 필요할 때마다 HHTP 클라이언트가 제공하는 세션 ID를 이용하여 나중에 검색된다. 따라서 이것은 애초에 세션정보를 생성했던 서버가 더 이상 동작하지 않을 때에도 클러스터 내의 다른 서버들은 계속 세션을 가지고 있기 때문에 세션단계 오류극복을 제공하고 있는 것이다. 왜냐하면 우리는 지니 리스 모델을 사용하고 있으므로 자바스페이스에 등록된 세션을 세션종료기간 후에 만료되도록 설정할 수 있고 만료된 세션 정보를 제거하는 도구를 제공한다.
한빛네트워크 기사
톰캣 사용하기 IV - 자바 애플리케이션에 톰캣 임베딩하기
톰캣 사용하기 III - 톰캣 설치와 설정
톰캣 사용하기 II - 톰캣에 웹 애플리케이션 배치하기
톰캣 사용하기 I - 자바 웹 애플리케이션

오라일리 기사
Using SOAP with Tomcat
Using Tomcat 4 Security Realms


부하분산은 끌어오기 기반이기 때문에 여유 자원이 많은 서버가 더 많은 작업을 끌어오는 식으로 부하분산이 자동적으로 이루어진다.

이 설계는 세션 정보 관리 책임을 자바스페이스에 전가하고, 자바스페이스 서비스 구현은 지속적인 형태와 트랜잭션 형태로 제공되기 때문에 필요하다면 보다 쉽게 지속적인 세션을 제공하는 셈이 된다.

현재 우리는 요청을 담아두는 가방 형태로 스페이스를 사용하고 있으나 Build and use distributed data structures in your JavaSpace에서 기술한 대로 최소한의 수정을 통해 채널형태로 만드는 것도 가능하다. 마찬가지로 요청을 필터하는 필터링 서비스 구현도 할 수 있을 뿐만 아니라 서비스품질(QoS) 기능을 제공하도록 우선권을 부여하는 식의 구현도 가능하다.

제안 솔루션의 한계

클러스터 서버가 하나 이상 존재하는 것이 가능하고 모두 동작하게 하는 데에는 별 차이가 없으나 HTTP 클라이언트는 전형적으로 웹 자원에 접속하는데 URL을 사용하므로 클라이언트는 클러스터를 (서버 유연성 향상을 위해) 하나의 IP 주소를 가진 기계로 볼 수 있도록 해야 한다. 따라서 하나의 클러스터 서버가 필요하다. 하지만 이것이 단일 오류 발생지점(single point of failure)이 될 수 있으므로 이 한계는 하드웨어 부하 분산기를 이용하여 극복될 수 있고(그렇다고 하더라도 바로 이 부하 분사기 자체가 단일 오류 발생지점이 될 수도 있다), 이런 경우에 이 솔루션은 웹 서버 프록시(아브라함 캉(Abraham Kang)이 쓴 J2EE Clustering에 대한 기사) 형태로 사용되거나 하나 이상의 기계가 단일 도메인명을 지원하는 기술을 사용할 수 있다. 그밖에 다른 기술은 'ONE-IP: Techniques for Hosting a Service on a Cluster of Machines'에서 찾아볼 수 있다.

결론

이 솔루션은 다른 소프트웨어 솔루션들과 비교할 때 고도의 확장성, 고가용성, 우수한 부하분산 기능을 제공한다. 동적 자가 설정 기능을 제공하므로 유지보수 노력을 절감할 수 있으며 품질서비스(QoS) 기능 구현이라는 유망성도 보유하고 있다.

이 솔루션과 관련된 소스코드 다운받기

관련자료
시암 쿠마르 도다불라(Shyam Kumar Doddavula)는 Infosys Technologies의 연구개발부서인 SETLabs에서 기술전문가로 근무 중이다.

'JAVA > WAS' 카테고리의 다른 글

아파치 튜닝 정리  (0) 2007.01.19
[펌]아파치 + 톰캣 연동  (0) 2006.09.25
Apache 모듈 중 mod_expires -- 이미지 캐시  (0) 2006.02.22
[펌] [weblogic] 웹로직 문제점 방안  (0) 2006.02.07
[펌]웹 해킹을 통한 악성코드 유포사고 주의  (0) 2006.02.07
Posted by tornado
|

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

OS/LINUX 2004. 5. 18. 10:30
리눅스 시스템 관리자를 위한 보안 지침Ⅰ

 

　

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)를 위시한 보안 전문 컨설팅 사이트와 시스템 벤더 사이트를 정기적으로 방문하여 보안 권고 사항들에 대해서 주의깊게 살펴보며, 새로운 취약성이 발견되면 그에 따른 패치설치 및 보안 권고에 충실히 따르도록 해야 한다.

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

cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] Netstat에 대하여  (0) 2004.05.18
[펌] netstat 사용해서 포트 확인하기  (0) 2004.05.18
[펌] ▶◀ 이상 네트워크 패킷 발생시 조치방안  (0) 2004.05.18
Posted by tornado
|

[펌] Netstat에 대하여

OS/LINUX 2004. 5. 18. 10:24

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(제록스 네트워크 시스템 개요.


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

cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] netstat 사용해서 포트 확인하기  (0) 2004.05.18
[펌] ▶◀ 이상 네트워크 패킷 발생시 조치방안  (0) 2004.05.18
Posted by tornado
|

[펌] netstat 사용해서 포트 확인하기

OS/LINUX 2004. 5. 18. 10:23
시스템 명령어인 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

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

cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] Netstat에 대하여  (0) 2004.05.18
[펌] ▶◀ 이상 네트워크 패킷 발생시 조치방안  (0) 2004.05.18
Posted by tornado
|

[펌] ▶◀ 이상 네트워크 패킷 발생시 조치방안

OS/LINUX 2004. 5. 18. 10:22
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로 할당 해 문제 발생시 문제 시스템을 손쉽게 찾아 해당 시스템의 정보와 수상한 파일을 수집해 백신 회사로 신고하고 해당 시스템의 네트워크 단절 등의 백신 회사가 맡기 어려운 일을 해야 한다.

출처: 안철수 연구소

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

cronolog 를 이용해서 apache 로그 분리하기..  (0) 2004.05.25
Linux 에서 rpm db 꼬였을때.. ㅡㅡ  (0) 2004.05.25
[펌] 리눅스 시스템 관리자를 위한 보안 지침Ⅰ  (0) 2004.05.18
[펌] Netstat에 대하여  (0) 2004.05.18
[펌] netstat 사용해서 포트 확인하기  (0) 2004.05.18
Posted by tornado
|

[펌] 브레인 스토밍

이것저것/기획 2004. 5. 13. 14:43

1.

브레인스토밍 [ brainstorming ]

 
일정한 테마에 관하여 회의형식을 채택하고, 구성원의 자유발언을 통한 아이디어의 제시를 요구하여 발상을 찾아내려는 방법.
 

원리는,
① 한 사람보다 다수인 쪽이 제기되는 아이디어가 많다.
② 아이디어 수가 많을수록 질적으로 우수한 아이디어가 나올 가능성이 많다.
③ 일반적으로 아이디어는 비판이 가해지지 않으면 많아진다.
등의 원칙에서 구할 수 있다. 그러므로 브레인스토밍에서는 어떠한 내용의 발언이라도 그에 대한 비판을 해서는 안 되며,
오히려 자유분방하고 엉뚱하기까지 한 의견을 출발점으로 해서 아이디어를 전개시켜 나가도록 하고 있다. 이를테면, 일종의 자유연상법이라고도 할 수 있다.

회의에는 리더를 두고, 구성원수는 10명 내외를 한도로 한다.

1939년에 미국의 광고회사 부사장 A.F.오즈번이 제창하여 그의 저서 《독창력을 신장하라》(1953)로 널리 소개되었다.

 

출처 : 네이버 백과사전

 

2.

브레인 스토밍에는 다음의 4가지 규칙이 있다.

1. 다른 사람의 발언을 비판하지 않는다.
2. 자유분방한 발언을 환영한다. 몽상도 좋다.
3. 질보다 양을 중요하게 여긴다.
4. 다른 사람의 아이디어에 무임승차한다.

- 가토 마사하루의《내 두뇌에 날개를 달아주는 생각의 도구》중에서 -

 

브레인 스토밍은 완전한 아이디어를 구하는 것이 아닙니다.
파편과 같은 생각들을 하나로 모아가는 작업입니다.
그러므로 번쩍 하는 아이디어를 파바박 말할 수 있어야지,

너무 뜸을 들이거나 이 말을 했다가 창피를 당하지 않을까 걱정하면,

그때는 이미 브레인 스토밍의 자리에서 벗어나게 됩니다.
번쩍, 할 때 자신있게 말하십시오.

 

츨처 : 고도원에서 온 아침편지 中

 

.

.

.

 

브레인 스토밍을 할 때 유의할 점

 
사이트를 어떻게 활성화 시킬 것인가? 같은
 
처음부터 모호한 주제를 던져 놓고 얘기하기 보다는 
 
현재 상황에 대해서 얘기를 풀고
가장 문제가 되는 또는 구체화 된 점을 찾아낸 후
구체적인 목표나 문제를 가지고 브레인 스토밍을 시작하는게 좋습니다.
 
문제가 모호할 경우
아이디어 도출이 막막해지고
문제에 대한 인식이 제각각 틀릴 수 있어
자칫 논쟁이 될 수 있으므로...
 
어느 정도 깊이... 즉, 문제가 어느정도 구체화 되는 수준 까지는
서로 아이디어를 내는 것이 아닌 의식의 공유가 되는 시간을 가진 후
아이디어를 도출시키는 브레인 스토밍을 해야지만이 서로의 아이디어를 비판하기보다는
기존 아이디어에 첨가가 되는 아이디어가 나오는 바람직한 형태의 브레인 스토밍이 되더군요.
 
ps...
브레인 스토밍은 문제를 해결하기 위한 순수 아이디어를 내기 위한 시간이므로
문제점에 대해 개개인의 의견을 묻는 일반적인 회의와는 혼동되어서는 안됩니다.
 
출처 : 명랑기획자의 비밀연구실

'이것저것 > 기획' 카테고리의 다른 글

[펌] IT 프로젝트 일정 계획 수립 시 유의사항  (0) 2009.05.15
[펌] 소프트웨어 개발의 전형적인 실수 목록  (0) 2005.06.01
[펌] 정보전략계획(ISP) Roadmap  (0) 2004.06.04
[펌] 성공적인 프리젠테이션을 위한 7가지 원칙  (0) 2004.05.13
[펌] 기획? 기획자? 기획서?  (0) 2004.05.13
Posted by tornado
|

[펌] 성공적인 프리젠테이션을 위한 7가지 원칙

이것저것/기획 2004. 5. 13. 14:42
지난 주 금요일 있었던 컨퍼런스 중
9FRUITS MEDIA의 김관주 팀장님의 발표 부분 중
리포트로 정리해 회사에 제출할 내용을 발췌했습니다.
 

 

 

 

“현대 마케팅은 Product의 싸움이 아닌 Perception의 싸움이다.”

 

 이 시간에 가장 관심 있게 들었던 부분은 위의 표와 관련된 사항이었습니다. 아무리 본인이 좋은 서비스를 가지고 있다고 하더라도 제대로 표현을 안 한다면 사람들은 보여지는 정도(실체와 표현의 비례관계)만 인식을 한다는 것입니다.

 저희 회사의 경우 일반인들(기회고객)과 내부사용자(회원)들에게 그 동안 PR, 광고, 캠페인 등 보다 적극적이고 전략적인 표현을 안 했기 때문에 실제 가치나 랭킹에 비해 인지의 정도가 낮다는 결론이 나온다고 생각합니다.

 

 

목표는 단일화 해라.

 

 한 AE가 광고주에게 갑자기 ‘이 걸 받아보십시오.’ 하더니 테니스 공 한 바구니를 던졌다고 합니다. 당황한 광고주가 하나도 받지 못하자. ‘그럼 이 걸 받아보십시오.’라고 하더니 공 하나를 차분히 건네줬다고 합니다. 그리고 이렇게 얘기를 했다고 하는군요.

 

“우리는 광고를 통해 고객들이 우리들의 다양한 얘기를 들어주기를 원하지만

 고객은 하나의 메시지를 듣기에도 벅찹니다.”

 

… 그 후 그 AE는 광고주에 의해 짤리지 않았을까 추측해봅니다. ㅡ_ㅡ);

 

 

즉시 결정하는데 따르는 위험  <  결정하지 않아서 초래될 위험

 

 우리는 미래는 급변하니까 비젼이나 명확한 목표를 가지고 갈 필요가 없다고 얘기합니다. 하지만 무언가 목표를 결정하고 가는 것은 결정하지 않았을 때보다 훨씬 더 빠른 대처가 가능합니다. 목표를 가지고 걷는 사람과 목표가 없이 걷는 사람은 행동과 태도에서부터 틀리며 또 다른 목표가 생겼을 때 방향을 수정하기도 훨씬 더 수월합니다.

 

 

<성공적인 프리젠테이션을 위한 7가지 원칙>

 

1. 목표를 뚜렷하게 세워라.

2. 잘 준비하라.

3. 열정과 자신감을 가져라.

4. 커뮤니케이션 스킬을 갈고 닦아라.

5. 비언어적 요소를 적극 활용하라.

6. 비주얼로 감동시켜라.

7. 리허설을 하라.

 

-> 좋은 프리젠테이션은 ‘연습’과 ‘연습’을 통해서만 나온다.

 

 

------

 

김관주 팀장님의 발표는 나비처럼 날아서 벌처럼 쏘는 발표였다고 생각됨. ^^

'이것저것 > 기획' 카테고리의 다른 글

[펌] IT 프로젝트 일정 계획 수립 시 유의사항  (0) 2009.05.15
[펌] 소프트웨어 개발의 전형적인 실수 목록  (0) 2005.06.01
[펌] 정보전략계획(ISP) Roadmap  (0) 2004.06.04
[펌] 브레인 스토밍  (0) 2004.05.13
[펌] 기획? 기획자? 기획서?  (0) 2004.05.13
Posted by tornado
|

[펌] 기획? 기획자? 기획서?

이것저것/기획 2004. 5. 13. 14:41

기획이란?
어떤 목적을 달성하기 위해 진행되어야 할 업무의 이미지를 묘사하고 전체 또는 세부에 걸친 구상을 정리하여 구체화하고 제한하기에 이르는 작업
(기획자는 문제 해결자이다.)

 

 

기획자의 필수 능력
쓰는 능력/ 조사능력/ 분석능력/ 포장능력/ 말하는 능력/ 자신감과 도전의식

 

 

기획서란?
전략과 아이디어를 전달하는 하나의 매개체로, 무형화되어 있는 정보가치와 전략을 설득적이고 효과적인 언어와 이미지, 색채, 기호 등을 이용한 하나의 종합적 커뮤니케이션의 집합체

 

.

.

.

 

지난 4월 29일날 있었던 컨퍼런스에서

플랜업 이정훈 대표님의 발표 부분 중 일부 발췌했습니다.

 

'이것저것 > 기획' 카테고리의 다른 글

[펌] IT 프로젝트 일정 계획 수립 시 유의사항  (0) 2009.05.15
[펌] 소프트웨어 개발의 전형적인 실수 목록  (0) 2005.06.01
[펌] 정보전략계획(ISP) Roadmap  (0) 2004.06.04
[펌] 브레인 스토밍  (0) 2004.05.13
[펌] 성공적인 프리젠테이션을 위한 7가지 원칙  (0) 2004.05.13
Posted by tornado
|

티스토리툴바