1장-실무 환경을 고려한 엔터프라이즈 리눅스 운영체제 설치
1. 실무 환경을 고려한 엔터프라이즈 리눅스 운영체제 설치
시스템 엔지니어링 분야의 시작과 끝이 있다면 그것은 운영체제 관련 분야입니다.
운영체제의 설치 자체 기술은 엔지니어 분야의 시작 시 다루는 기술이지만 실제
운영체제의 설치 의미는 설치 자체에 있기 보다는 운영체제를 설치 하는 시스템의
서비스 성격과 운영 정책을 사전에 고려 하여 운영체제 설치 계획을 세워야 합니다.
운영체제의 설치는 그 설치 방식에 따라 성능, 보안, 안정성, 시스템 가용성등의
시스템 전체 성능이 좌우 됩니다. 기초 설치 문서나 서적에 의해 설치를 한다면
실제 서비스 자체 환경 구현은 가능 하겠지만, 최적의 성능이나 시스템 보안 레벨
시스템 회복 능력, 시스템 관리상의 효율성등에서 실무 서비스 환경을 고려한
운영체제와는 큰 차이를 보일것입니다.
여기서는 실무 환경에 맞는 운영체제 설치를 하는데 고려 해야 할 사항과 실제
운영체제 설치 이후 설치 방식에 따라 이후 관리에 어떤 차이가 있는지, 그리고
안정적인 시스템 환경 유지를 위해 설치 이후 어떤 작업등이 필요한지에 대해
설명하도록 할 것입니다.
1.1 설치 전 고려 사항
– 파티션 정책
자동파티션 설치를 선택하면 기본적으로 /boot , / , swap 3개의 파티션으로 자동
활당되어진다. 하지만 정식 서비스를 위해서는 가지고 있는 하드디스크를 계산하여
성능 및 보안등을 고려하여 현 서비스에 가장 적절한 정책을 세워야 한다.
리눅스의 대표 파티션들은 모두 보안적인 측면이나 성능적인 측면에서 의미를 부여
하고 있다. 리눅스의 대표적인 파티션을 살펴 보면 다음과 같다.
/boot
/
/etc
/home
/usr
/usr/local
/tmp
/var
swap
각 대표적인 모든 파티션을 다 나누어 설치를 하게 되면 가장 안정적일수 있지만
제한된 하드디스크로 모든 파티션을 나누게 되면 각 파티션에서 사용할 수 있는
용량이 고정되어 버리기 때문에 실제 서비스 도중 특정 파티션에 용량이 초과할
경우 추가 하드 디스크를 사용해야 하는 경우가 발생하기 쉽다.
뿐만 아니라 많은 파티션을 나누어 놓게 되면 성능면에서는 Disk i/o 를 분산 시
킬수 있어 바람직 할수 있지만 관리 측면을 고려 해 본다면 필요에 의한 적절한
파티션 분배가 이루어 져야 할것이다.
각 파티션별로 그 의미에 대해 알아보자.
/boot :
/boot 파티션은 리눅스 부팅에 관련된 파일이나 이미지들이 모여 있는 파티션
이다. 만일 /boot 파티션을 나누어 놓은 경우는 크게 세 가지 의미가 있다.
첫째는 안정성이다. 실제 /boot 파티션을 나누지 않고 그냥 / 에 포함 시킬 경우
시스템이 과도한 사용이나 해킹등의 이유로 / 파티션이 망가질 경우 실제 / 포함
된 /boot 디렉토리의 booting image 들 역시 깨어질 위험성이 크다. /boot 가 나
누어져 있을 경우 / 가 망가지더라도 새로운 / 파티션을 만들고 /boot 에 있는
부팅 이미지를 가지고 어느 정도 까지는 복구가 가능하다.
둘째는 기능성(?)이라 볼수 있다. 실제 /boot 에 들어 있는 kernal image 가 즉
리눅스 OS 라 볼수도 있다. 만일 당신이 개발자나 리눅스 전문 엔지니어라서 여
러개의 배포판을 설치 할 경우 각 배포판 마다 /, swap 등의 파티션을 별도로
나누어서 설치해야 하는 어리석음을 갖지 말길 바란다. 실제 배포버전별로
/boot 파티션을 나누어 준다고 하면 각각의 다른 리눅스 배포판을 설치 하고도
실제 /etc /usr/local 등에 있는 설정이나 패키지를 통합해서 관리 할수가 있다.
셋째는 리눅스 OS의 부트로더의 기능적인 제한때문에 /boot 를 나누는 경우가
많다. 리눅스의 대표적인 부트로더로 Lilo 가 있는데 이는 실제 1024 실린더
밖에 설치 될 경우 치명적인 에러가 발생한다. 그래서 대부분이 하드디스크의
MBR 영역에 설치를 하게 되는데 만일 MBR 에 다른 부트 로더를 설치하고 Lilo
는 리눅스 파티션의 첫번째 파티션에 설치를 한다고 할때 /boot 파티션을 첫
번째 파티션으로 만들어 이곳에 Lilo를 설치 할수 있다.
/ :
루트 파티션은 실제 리눅스 파티션의 최 상위 파티션으로 실제 / 파티션과 Swap
파티션만으로도 리눅스를 설치 하여 서비스를 할 수도 있다. 하지만 이렇게 설치
를 하게 되면 앞에서 언급하였고 뒤에서 설명하는 바와 같이 부적절한 상황을
초래하기 쉽다. 일단 커널 이미지에서 실제 / 파티션을 찾아서 / 파티션을 최상
위로 해서 하위의 파티션들을 찾기 때문에 / 파티션이 없으면 리눅스를 부팅 시
킬수 없게 된다. 아래에서 설명하는 바와 같이 여러개의 파티션을 나눌 경우 실
제 별도의 파티션을 나누지 않는 상위 디렉토리들이 모두 이 / 파티션안에 포함
되게 될것이다.
/etc :
/etc 는 리눅스 시스템의 모든 설정 파일이 모여 있는 디렉토리이다. 만일 /etc
를 / 파티션에 포함한 경우 변수에 의해 / 파티션이 깨어진 경우 별도의 백업이
없으면 관리자로써 상당히 난처한 상황에 빠지게 딘다.
즉 아무리 데이터를 백업을 하고 있다 하더라도 설정 파일이 없으면 서비스를
구동 할수 없게 된다. 그렇기 때문에 /etc 를 별도의 파티션으로 나누는 것도
고려해야 할것이다. 하지만 /etc 의 용량은 매우 작기 때문에 백업만 적절히
한다고 하면 굳이 나눌 필요는 없다. 파티션이 너무 많이 나누어 지면 관리측면
에서 부적절 할수도 있다.
/usr :
/usr 는 실제 레드헷 리눅스의 RPM 패키지가 설치되는 파티션이다. 이 파티션을
나누는 이유는 크게 성능과 패키지 관리 측면에서 볼수 있다.
일단 레드헷 리눅스의 모든 프로그램이 이곳에 설치가 된다고 볼수 있다.
즉 서비스 구동 시에 프로그램 성능에 가장 큰 영향을 주는 파티션인 만큼 다른
Disk i/o 과 많은 다른 파티션과 동일 파티션으로 구성하면 성능에 많은 지장을
주게 된다.
관리 측면으로 보면 최근 배포판 버전으로 업그레이드를 하고자 할때 /usr 파티션
이 나누어져 있을 경우 설치 시 /usr 파티션만 새로 포맷하고 새 패키지를 설치
하면 실제 redhat 7.3 에서 redhat 9 로 업그레이드를 한다고 해서 서버의 모든
자료를 백업하고 새로 OS 설치 후 복구하는 수고를 들수 있다.
/usr/local :
/usr/local 는 응용프로그램을 Source 로 설치 할 경우 파일이 위치 하는 디렉토리
이다. 기본적으로 배포판의 패키지는 기본적이 서버 구성에 해당하는 패키지만 설
치 하고 나머지는 모두 Source 설치 하는걸 권장 한다. 리눅스 배포판의 패키지를
무분별하게 설치 할 경우에는 보안/ 관리 측면에서 상당히 부적절 할 수 있다.
그러므로 최소 설치 후 필요한 프로그램을 Source 로 설치 하는 것을 권장하는 바
이다. 즉 Source 로 설치하는 프로그램을 관리하는 파티션이다. /usr 과 같은 의미
를 가진다. 성능과 패키지 관리 측면이다. 만일 / , /usr 등의 문제로 인해 다시
설치 할 경우 /usr/local 파티션이 / , /usr 에 속해 있으면 재 설치 할때 마다..
일일이 Source 설치도 다시 해야 한다. 하지만 /usr/local 이 별도로 나누어져 있
으면 OS를 다시 깔아도 실제 서비스 프로그램을 다시 깔 필요는 없게 된다.
/var :
/var 는 시스템 log 파일이 저장 되는 곳이다. /var 파티션을 분리하는 이유는
실제 log 를 기록 하면 그만큼 많은 Disk i/o 병목이 시스템에 발생하게 된다.
실제 서비스가 이루어 지는 / 혹은 /usr 와 사용자 데이터가 저장되는 /home
등과 같은 파티션이 존재 하게 되면 /var 에 일어나는 병목으로 인해 시스템의
성능이 저하되게 될것이다. 이를 방지하기 위해 /var 파티션을 별도로 활당하던
지 네트워크 드라이브를 이용하여 원격디스크를 활용하는 방법을 사용한다.
( log 서버와 같이..)
/var 는 로그 및 메일 큐등이 쌓이는 곳이기 때문에 해커들이 고의적으로 시스템
에 나쁜 코드를 심어 놓거나 mail 서버의 spam를 무수히 보냄으로 해서 /var의
디스크 용량이 무지커지는 경우가 발생한다. 이때 /var의 파티션이 나누어 있지
않는 경우 실제 / 파티션의 disk 용량이 가득차게 되고, 이로 인해 / 파티션의
중요한 파일들이 손상을 입게 된다. 이런 일들을 방지 하기 위해서도 /var 파티션
을 나누는 것을 권장한다.
이밖에 해커들이 / 파티션을 공격하여 시스템을 깨어버린다 하더라도 실제 /var
파티션이 나누어져 있으면 이런 해커의 작업등이 시스템 로그에 남게 됨으로
시스템은 망가졌지만 이후 /var 의 로그를 이용하여 시스템에 무슨 문제가 있었
는지를 확인할 수도 있다.
/tmp :
/tmp 는 실제 시스템 서비스가 가동될때 임시 파일이나 세션 파일들이 생기는 곳
이다. 보통 nobody 권한의 파일들이 생김으로 해서 보안이 약한 곳이라 볼수 있
는데 해커들이 주고 이 /tmp 를 통해 원격지에서 시스템을 공격하는 경우가 많다.
그러므로 해서 해커의 공격을 받더라도 /tmp 디렉토리만 영향을 받게 하기 위해
파티션을 분리하는것을 권장한다.
swap :
은 물리적인 메모리가 부족한 경우 하드디스크를 메모리 처럼 사용할 수 있게
하는데 이용되는 파티션이다.
보통 시스템의 물리적인 메모리의 1.5배에서 2배로 잡는것이 정석이다.
시스템의 주요 사용 용도 중에 매우 큰 용량의 파일을 다루는 작업일 경우
보통 swap 을 크게 잡아야 한다. 대표적으로 Oracle 의 경우 보통 DB file 하나
가 작게는 500M 에서 크게는 2Gbyte 정도 하는 실제 DB 엔진에서 메모리에 이
큰 파일을 올려 놓고 작업을 하게 되는데 실제 물리적 메모리가 1.5 G 일 경우
swap 이 없는 경우에는 작업을 할수 없게 되거나 페이징이 일어나 성능이 급속
도록 떨어지게 된다. 이를 방지하기 위해서 서비스에 이용되는 메모리 수치를
예상하여 swap 을 잡으면 된다. swap 은 상황에 따라서 여러가지 방법으로 추가
할수 있기 때문에 초기에는 권장방법대로 1.5배에서 2배 정도로 잡으면 된다.
– 최신 하드웨어 드라이브 패치
하드웨어의 발전 속도가 운영체제의 발전 속도를 앞서 나간지는 벌써 몇 해가 되어가고
있다. 그러므로 운영체제 배포 CD에는 이후 출시된 하드웨어 인식 드라이브가 누락되어
최신 하드웨어를 가진 시스템에 운영체제 설치 시 문제가 발생하는 경우가 종종 발생한다.
이런 대표적인 문제를 발생하는 하드웨어로 SCSI Controllor 와 Network Ethernet Card
들 들수 있다. 배포 CD로 운영체제를 설치 시 Network Ethernet Card 의 경우에는 크게
문제가 되진 않지만 SCSI Controllor 의 경우에는 실제 운영체제를 설치할 하드디스크를
인식하지 못하여 운영체제 설치가 안되는 경우가 발생한다.
이런 경우 리눅스 운영체제에서는 설치 시 추가 하드웨어 드라이브를 인식하여 설치하도록
하는 방법이 제시되어 있다.
아래는 실무에서 흔히 발생하는 Adaptec SCSI Controllor 문제를 해결하는 방법에 대해
설명한다.
최신 Ultra320 SCSI Controllor 의 경우 기본 레드헷 지원 드라이버를 사용하면
i/o error 를 발생 하는 경우가 있다. 대표적인 제품으로 Adatec 의 AIC-29320
제품의 경우 그러함. 설치 시에 그냥 설치 하면 SCSI 장치 인식 중에 멈처 버리는
증세가 발생함.
boot : linux apic
와 같은 방식으로 부팅하면 장치는 인식하지만 레드헷 기본 커널에 있는 드라이버
로 서비스 가동 시에 조금 과도한 Disk Access 작업을 할 경우 kernel panic 상태
가 된다.
이에 설치 전에 각 장치 공급사의 홈페이지에서 최신 드라이버를 다운 받아서
설치 시에 최신 드라이버를 인식하도록 해주어야 한다.
http://www.adaptec.com/ 에서 최신 드라이버를 다운 받을 수 있음
먼저 각 하드웨어 공급사의 최신 드라이브를 다운 받은 후 설치 시 적용할 수
있는 이미지 디스켓을 만든다.
==========================================================================
# fdformat /dev/fd0
# dd if=aic79xx-2.0.2-i686-rh90.img of=/dev/fd0 bs=1024
==========================================================================
그런후 설치 CD 로 부팅 후 boot prompt 가 뜨면 < linux dd > 란 command 로
설치 시 추가 드라이브를 적용 시킨다.
==========================================================================
boot : linux dd
==========================================================================
그럼 설치 CD 의 커널 이미지로 부팅을 진행하면서 하드디스크 혹은 기타 장치를
인식하기 전에 추가 드라이브 디스켓을 삽입하라는 메세지가 뜬다. 이때 위에서
만든 드라이브 디스켓을 삽입한다.
그러면 설치 CD 에 있는 장치 드라이브를 이용하는것이 아니라 다운 받은 최신
드라이브로 장치를 인식하여 설치를 하게 된다.
1.2 Redhat Linux 운영체제 설치
서버용으로 설치를 할 경우 앞에서 설명한 바와 같이 이 서버가 서비스할 서비스
내역을 충분히 이해 한 후 반드시 필요한 패키지 만을 설치 하는 것을 권장한다.
사용하지 않는 패키지를 설치 할 경우 사용하지 않는 패키지의 보안적 문제가 생
겼을때 관리자는 이를 신경쓰지 않게 되고, 이 패키지를 통한 해킹의 위험을 가
지게 된다.
기본적은 설치 과정에 대한 설명은 생략 하고 파티션과 패키지 구성에 대한
정책만을 설명하겠다. 이는 저의 개인적인 견해를 설명한것이니 이가 완변한 설치
정책이라 말하지는 않겠다.
– 파티션 정책
실제 서비스를 대상으로 하는 서버를 설치 할 경우에는 전 기본적으로 아래와 같이
파티션을 나눈다.
/boot
/
/usr
/usr/local
/var
/tmp
/home
swap
/boot : 100M ~ 200M
/ : 1G
/usr : 3G
/usr/local : 2G
/var : 2G ~ 3G
/tmp : 500M
/home : 필요한 만큼
swap : 물리적인 메모리의 2배
여기서 /boot /tmp 는 그 용량이 작기 때문에 적절한 백업을 할 경우에는 관리상의
이유로 / 에 포함하는 경우도 많다.
/usr/local 역시 관리상의 이유로 /usr 에 포함하는 경우도 많다.
대신 이와 같이 포함하는 경우에는 반드시 포함 시키는 파티션의 크기에 신경을 써야
한다.
/var 파티션의 경우 로그의 중요성이 낮거나 메일 서비스등을 하지 않는 경우에는
관리상의 이유로 하여 / 에 포함하는 경우도 많다. 하지만 메일 서버등을 중점으로
하는 서비스에서는 반드시 /var 의 파티션을 나누어 주고 용량도 충분히 주길 바란다.
/home /usr/local 의 파티션을 별도로 나눌 경우 성능을 고려 한다면 설치 시 파티션
을 지정 하지 말고 기본 OS 설치 후 fdisk 를 통해 수동으로 파티션을 나눈 후 레드헷
기본 파일 시스템인 ext3 대신 reiserfs 혹은 xfs 파일 시스템을 사용하는 것을 권장
한다. ext3 에 비해 reiserfs 나 xfs 파일 시스템이안정성에서 우수함을 인증 받은
상태이고 성능에서도 30% 정도의 성능 향상을 가져 올수 있다.
( hdperm 으로 디스크 성능을 체크 해 보면 ext3 의 경우 초당 40M 정도의 read buffer
의 성능을 나타내지만 reiserfs 의 경우 초당 55M 의 성능을 발휘한다. )
/home 이나 /usr/local 파티션의 성격 상 디스크 사용량이 많거나 실제 사용하는
프로그램이 설치 되는 곳인만큼 시스템의 Disk I/O 성능의 영향을 많이 받는 곳이기에
보다 안정스럽고 좋은 성능의 파일 시스템을 사용하는게 좋다.
swap 역시 oracle 과 같은 큰 파일을 다루는 서버라고 하면 1G 용량으로 여러개의
swap 파티션을 잡아 두는 것을 권장한다.
( 그냥 큰 용량으로 swap을 잡지 않고 적절한 용량으로 나누어 여러개를 잡는 이유는
swap 파티션의 크기 역시 일반 IA32 시스템에서는 2G 제한이 있고 2G의 스왑파티션
보다는 1G의 스왑파티션 2개가 I/O 분산으로 인해 성능이 좋기 때문이다.
OS 의 설치는 초보 엔지니어나 경력 엔지니어나 다 기본으로 하기 마련이다.
하지만 시스템 엔지니어의 시작이 OS 설치 라고 하면 마지막 역시 OS 설치라고 말
할수 있는 만큼 자신만의 설치 방법을 세워 두길 바란다.
– 패키지 정책
실제 OS 구동에 필요한 기본 프로그램 ( 부팅관련 프로그램, 라이브러리 )은 배포판에
있는 패키지를 선택하지만 서비스에 필요한 프로그램은 대도록이면 Source 로 직접
설치 하는 것을 권장한다.
이는 패키지 관리 및 보안성격상에도 큰 의미를 가지고 있지만 시스템 성능에 미치는
영향도 크다
실제 배포판은 대표적인 아키텍처에 해당하는 시스템에서 해당 프로그램을 build 하여
패키지를 만들어 놓은 것이다. 유사한 아키텍처를 가진 시스템에서 사용하는데는 지장
이 없지만 그래도 자기 시스템에 최적화된 프로그램을 사용하기 위해서는 실제 Source
로 해당 시스템에서 직접 설치 하는 것이 좋다.
( 이와 같은 패키지 관리를 한다고 하면앞에서 설명한 바와 같이 /usr/local 파티션을
별도로 나누어 관리하는 것이 시스템 문제 발생하여 재 설치 시 오랜 시간이 소요되는
Source rebuiling 작업을 생략할 수 있게 된다. )
레드헷 리눅스에서의 패키지 선택은 기본적으로 패키지 선택 단계에서
/ 편집기 / DNS 서버 / 네트워크 서버 / 개발 도구 / 커널 개발 /시스템 도구
정도를 기본 설치 하고 기타 서비스 관련 프로그램 및 기타 관리 도구는 필요한 프로
그램만을 수동으로 설치 하면 된다.
기본적으로 설치가 완료 된 후 부팅이 정상적으로 되는지와 부팅 시 에러 내용이 있는
지, 파티션이 정책대로 적용이 되었는지 등을 확인 합니다.
# dmesg -> 부팅 메세지 확인
# df -h -> 파티션별 용량 확인
1.3 Redhat Linux 운영체제 설치 후 추가 작업
정해진 버전의 배포 CD 로 운영체제를 설치 하고 나면 몇 가지 추가 작업이 필요하다.
흔히 설치 시에는 별다른 문제가 없었는데 설치 이후 정상적인 부팅이 되지 않거나
부팅이 되더라도 시스템이 불안한 경우가 종종 발생한다. 이런 문제가 발생하는 경우
대부분이 실제 하드웨어 환경과 운영체제 설치 환경이 최적화 되지 않아서 발생하는
문제들이다. 여기서는 리눅스 설치 이후 주요 발생하는 문제를 해결하는 방법과 안정적인
운영체제 환경을 유지 하기 위한 추가 작업들에 대해 설명하도록 한다.
1.3.1 설치 이후 주요 발생 문제 해결 방법
설치 직후 주요 발생하는 문제로는 당연 Boot Loader 에서 발생하는 문제를 들수 있다.
Boot Loader 란 운영체제의 버전을 관리하는 대표적인 프로그램으로 리눅스에서는 주로
LILO 와 GRUB을 사용한다. Boot Loader 에서는 시스템에 설치 되어져 있는 여러 운영체제
나 커널 버전을 관리하여 해당 운영체제나 커널버전에 맞는 부팅 이미지로 부팅을 시켜
주는 역활을 한다.
이런 Boot Loader 에서 발생하는 문제의 주요 원인으로는 하드웨어의 BIOS상의 정보와
설치된 운영체제의 환경이 맞지 않아 발생하는 경우가 그에 해당한다.
– LILO Bootloader 로 부팅 시 문제 발생 했을때 해결 방법
LILO 상에 발생하는 주요 문제로는 흔해 “LI” 문제를 들수 있다. 이는 리눅스 Boot Loader
의 고전적인 문제로 Boot Loader 가 실제 하드디스크의 1024 실린더 안에 설치가 되지 않으
면 발생하는 문제이다.
예를 들어 리눅스 운영체제를 설치할 때 / 파티션을 하드디스크의 초기 8GByte 범위 밖에
설치 하면 위와 같은 문제가 발생할 수 있다.
하지만 이런 경우는 리눅스의 LILO 버전이 발전함에 따라 개선되어 지금의 배포판 환경에서
는 거의 나타나진 않는다. 하지만 실무에서는 항상 최신 OS 환경을 유지한다는 보장이 없기
때문에 이런 문제에 대해 사전에 알아두는 것이 좋다. 이와 같이 LILO 상에 문제가 발생하면
실제 해당 시스템의 하드디스크에 설치된 부팅이미지로 부팅을 할수 없기 때문에 다른 부팅
이미지를 통해 긴급 부팅을 하여 문제를 해결해야 한다. 아래는 긴급 부팅을 통해 부팅하여
문제를 해결하는 방법에 대해 설명한 것이다.
– LILO Boot Loader 사용 환경에서는 긴급 부팅 방법
리눅스설치CD로 부팅해서 rescue 모드로 부팅을 시도한다.
boot : linux rescue
df 쳐 보니 /dev/hda2 가 /mnt/sysimage 에 mount 되어 있다.
하드디스크에 있는 lilo.conf 는 /mnt/sysimage/etc/lilo.conf 에 잘 있다.
이제 이 파일을 잘 고쳐서 lilo 를 실행하면 된다. rescue 모드에서도 vi는 실행된다.
# vi /mnt/sysimage/etc/lilo.conf
/mnt/sysimage/etc/lilo.conf 를 수정 후
/etc 에 복사한다
# cp /mnt/sysimage/etc/lilo.conf /etc
여기까지만 하고 lilo 를 실행시키면 에러가 난다.
/etc/lilo.conf 에서 /boot 라고 되어있는 곳을 /mnt/sysimage/boot 로 바꾸고 저장한다.
이제 lilo 를 실행시킨다.
# /mnt/sysimage/sbin/lilo
/boot/chain.b 를 못 찾는다는 메시지가 나타나면,
# cp /mnt/sysimage/boot/chain.b /boot/ 한 다음에
#/mnt/sysimage/sbin/lilo
혹은
# chroot /mnt/sysimage
# /sbin/lilo
하면 된다.
참고로 LILO 로 SCSI 와 IDE 를 병행 할때 sda 가 첫번째 디스크가 아니라는 에러가
발생 하는 경우가 있다.
이는 LILO라는 부트로더는 실제 BIOS 의 장치에 관련된 정보를 참조 하지 않기 때문에
발생하는 문제이다.
디스크에 관련해서 이런 문제가 발생하면..
lilo.conf 에 다음 내용을 추가해 주면 된다.
disk=/dev/sda
bios=0x80
disk=/dev/hda
bios=0x81
위의 설정 내용은 SCSI 가 첫번째 하드라는 것을 LILO 에서 인식하도록 해주는 것이다.
이렇게 해야 부팅시 정상적으로 LILO 가 띄워 질 것이다.
– Grub Boot Loader 사용 환경에서의 긴급 부팅 방법
Grub Boot Loader 를 설치 한 경우 Boot Loader 에 문제가 발생하면 LILO 처럼 시스템이
Panic 상태로 빠지는 것이 아니라 grub boot prompt 상태로 부팅이 되어진다.
Grub 은 LILO 의 단점을 개선한 Boot Loader로서 최신 버전의 리눅스에서는 대부분 LILO
보다는 Grub 을 선호하여 사용한다.
긴급시 grub 으로 부팅을 시키는 과정입니다.
grub >
먼저 root 지정을 해 줍니다.
grub > root (hd0,0)
-> 실제 /boot 파티션의 위치를 지정한다. 만일 별도의 /boot 파티션
이 없는 경우에는 / 위치를 지정합니다.
grub > kernel /vmlinuz-2.4.20-8smp ro root=/dev/sda2
-> 실제 / 파티션 위치를 적어 줍니다.
grub > initrd /initrd-2.4.20-8smp.img
-> SCSI 하드인 경우 initrd 이미지가 없으면 하드 인식을 못함.
grub > boot
하면 부팅 됩니다.
그런 후 /etc/grub.conf 를 수정하거나 쉽게 LILO 를 수정하여 다시 적용하고 실행
하면 된다.
1.3.2 운영체제 설치 후 주요 서비스 파티션 구성 및 파일 시스템 설정
앞의 파티션 정책에서 설명 했듯이 주요 서비스 파티션 중 데이터 관련 파티션인
/home 과 서비스 프로그램 관련 파티션인 /usr/local 을 구성해야 하고 이 두개의
파티션을 안정성 및 효율이 높은 reiserfs 혹은 xfs 로 파일 시스템을 설정 하는
하도록 한다.
Redhat Linux 의 기본 채택 파일 시스템은 ext3 파일 시스템이다. 리눅스 파일 시스템
의 종류에 따라 시스템 성능과 안정성의 차이가 있기 때문에 서비스 성격에 따라 최적
의 파일 시스템으로 구성을 하면 시스템의 DISK I/O 성능 및 안정성에 큰 효과를 볼수
있다.
# fdisk /dev/sda
-> /usr/local : 3G
-> /home : 나머지 전부 활당
# mkfs.reiserfs /dev/sda8 -> /dev/sda? 에는 해당 파티션의 디바이스명을 적어준다.
# mkfs.reiserfs /dev/sda9
# vi /etc/fstab
=================================================================================
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/tmp /tmp ext3 defaults 1 2
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
/dev/sda6 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
# 아래를 추가해줌
/dev/sda8 /usr/local reiserfs defaults 1 2
/dev/sda9 /home reiserfs defaults 1 2
=================================================================================
# tar czvf local.tgz /usr/local -> /usr/local 의 디렉토리 구조를 백업해 둠
# cp local.tgz /
# mount -a
# cd /
# tar xzvf local.tgz
실제 파티션과 파일 시스템 구성이 정상적으로 되었는지를 확인 한다.
# df -h
=================================================================================
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 981M 121M 811M 13% /
/dev/sda1 198M 15M 173M 8% /boot
none 1009M 0 1009M 0% /dev/shm
/dev/sda7 487M 8.1M 454M 2% /tmp
/dev/sda5 2.9G 898M 1.9G 33% /usr
/dev/sda3 2.9G 58M 2.7G 3% /var
/dev/sda8 2.9G 33M 2.8G 2% /usr/local
/dev/sda9 22G 33M 22G 1% /home
=================================================================================
1.3.3 시스템 구성 정보 확인
마지막으로 현재 시스템의 H/W, S/W 구성 정보를 확인 및 기록 해 두도록 합니다.
이는 현재 시스템 장치가 재대로 인식을 하는지 확인과 동시에 이후 유지 관리를 위한
시스템 정보를 기록하는 의미를 가지고 있습니다. 이는 시스템의 정보를 확인 하는 방
법으로 이후 관리 시에 큰 도움이 될것입니다.
– booting message 확인
# dmesg
– CPU 정보
# cat /proc/cpuinfo
– 메모리 정보
# cat /proc/meminfo
– SCSI 정보 HDD 정보
# cat /proc/scsi/scsi
– SCSI controllor 정보
# cat /proc/scsi/aic7xxx/0
– IDE 하드 정보
# cat /proc/ide/hda/model
# cat /proc/ide/hda/setting
– 네트워크 정보
# ifconfig
# route -n
이로써 대략적인 설치 과정이 완료 되었습니다.
다음 장에서는 설치 이후 설치 된 패키지의 최신 패키지 업데이트 및 기타 하드웨어의
최신 드라이브 업데이트에 대한 설명을 하겠습니다.
1.3.4 운영체제 추가 Package Update
– S/W Package Update
리눅스 시스템은 Open 된 OS 인 만큼 보안에 대한 취약점이 있다고 생각할 수 있지만
이와 달리 Open 된 시스템인 만큼 보안의 취약점을 미리 사전에 파악하여 패치 함으로
관리자의 관심만 유지되면 보안에 더 강력하다고 말할 수 있다.
레드헷 리눅스의 경우 up2date 란 프로그램을 통해 윈도우 처럼 자동으로 패키지를
업데이트 할 수 있는데 기본적으로 배포판에 설치되는 up2date 로 업그레이드를 하면
SSL 인증 에러가 발생하게 될것이다. 이는 현재 배포 버전인 Redhat9 이 발표된 이후
레드헷사의 up2date 인증 방식에 변경이 있었기 때문에 정상적인 up2date를 이용하여
전체적인 패키지 업데이트를 하기 위해서는 먼저 up2date 를 업그레이드 해야 한다.
# wget ftp://updates.redhat.com/9/en/os/i386/up2date*
위의 구문으로 바로 up2date 에 관련된 패키지를 다운 받을 수 있을 것이다.
up2date / up2date-gnome 두개의 패키지를 다운 받게 될것인데 이중 up2date-gnome
은 Xwindows 의 gnome 이 설치 된 경우에만 설치 하도록 한다.
# rpm -Uvh up2date
# /etc/rc.d/init.d/rhnsd restart
# rhn_register
최초 rhn_register 를 실행하면 rhn_register 구성 편집 화면이 나오는데 그냥
q 를 치면 빠저 나온다.
# rpm –import /usr/share/rhn/RPM-GPG-KEY
# rhn_register
# gpg –import /usr/share/rhn/RPM-GPG-KEY
레드헷 사에 현 시스템의 정보 및 간단한 인증 정보를 기록합니다.
정식 레드헷 배포판을 구매하면 up2date 의 지원을 계속 받을 수 있지만 공개 배포판의
경우에는 3개월 기간 제한이 있기 때문에 설치 시에 한번 지원 받는다는 의미를 가진다.
# up2date -p -> 현 시스템이 RPM 패키지 정보를 정리한다.
# up2date -u -d -> 업데이트를 시킬 패키지를 다운 받는다.
up2date 에서 -d 옵션을 사용하면 업데이트 대상 패키지를 다운 받아 /var/spool/up2date
안데 저장된다.
-u 옵션만 사용하면 다운 받아서 업데이트 패키지를 바로 설치 하고 설치가 완료된
rpm 을 삭제 하게 됩니다. 만일 업데이트 대상 시스템이 여러대 일 경우 계속 같은 방법
으로 업데이트 시킬 필요 없이 한곳에서 다운 받아놓고 그 패키지를 이용하여 다른 시스
템들의 업그레이드를 시키는 방법이 편할 것이다. 단 위 경우는 시스템의 패키지 구성이
유사한 경우에 의미가 있다.
– H/W Driver Update
dmesg message 를 살펴 보면 커널이 로딩한 장치의 드라이브 버전을 확인 할 수 있다.
흔히 문제가 되는 것이 SCSI Controllor 와 Intel Gigabit Card 가 대표적이다.
먼저 현재 시스템에 설치 시 인식된 장치를 확인합니다.
# cat /etc/modules.conf
===============================================================================
alias eth0 e1000
alias eth1 e100
alias scsi_hostadapter aic7xxx
alias usb-controller usb-uhci
===============================================================================
# dmesg | grep Driver
# dmesg | grep DRIVER
# dmesg | grep driver
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
Intel(R) PRO/1000 Network Driver – version 4.4.19-k1
Intel(R) PRO/100 Network Driver – version 2.1.29-k2
대표적인 버전은 AIC79XX -> 2.0.2 이상
e1000 -> 5.0.43 이상
e100 -> 2.2.21 이상
의 버전을 설치 하도록 한다.
rpm 으로 만들어진 드라이브 버전은 현 시스템 커널 버전에 의존함으로 드라이버
설치 후 kernal upgrade를 할 경우에는 반드시 다시 장치 드라이브 버전을 확인하셔야
합니다.
1.4 운영체제 기본 보안 설정
리눅스 운영체제는 Open Source 기반 운영체제입니다. Open Source 기반의 운영체제라는
조건이 실제 시스템 운영 측점에서 장점이 될수도 있고, 단점이 될수도 있는데 대표적인
것이 바로 운영체제 보안이라 볼수 있습니다.
운영체제의 Source code 가 공개되어져 있기에 실제 운영체제의 보안 취약점이 크래커에게
공개되는 경우가 있을 수 있다는 것입니다.
하지만 반면에 전 세계적으로 분포된 리눅스 개발 프로젝트에 참여한 개발자, 엔지니어,
테스터들이 문제점을 사전에 발견하여 지속적인 패치를 해준다는 장점이 있습니다.
실제 상용 UNIX 의 경우 보안적인 문제가 발생하더라도 이가 해당 보안 담당자에게 알려
지는 기간이 길기 때문에 패치가 나오기 전에 해킹을 당하는 경우가 많습니다.
하지만 LINUX 의 경우는 대부분의 해킹 사례가 이미 리눅스 커뮤니티등에서 보안 이슈를
발표하고 1년이상 이후에 해당 취약점으로 패치가 안된 시스템을 공격하는 경우입니다.
이런 두가지 측면의 보안 이슈는 어느것이 좋고, 나쁨을 떠나 시스템 엔지니어의 보안에
대한 경각심과 시스템 보안 관리에 대한 노력의 문제라고 볼수 있습니다.
아래는 리눅스 시스템을 설치 후 기본적인 보안 설정에 대해 설명한 것입니다.
초기 배포 환경에서는 여러 측면의 서비스를 대상으로 하기 때문에 해당 시스템의 서비스
성격과 다른 패키지와 보안 정책등이 부여가 되어져 있을 것입니다. 이는 실제 불필요한
시스템의 자원 낭비일 뿐만아니라 관리 하지 않는 보안적 헛점이 존재한다는 측면에서
보안적으로 취약점이 될수 있기에 설치 이후 서비스를 시작하기 전에 적절한 조치를
취해 줘야 하는 내용들입니다.
1.4.1 시스템 서비스 데몬 관리
– 불필요한 서비스 데몬 제거
레드헷 기반의 리눅스 운영체제를 설치 하면 기본적으로 여러가지 서비스가 부팅 시
자동 시작이 되도록 설정이 되어져 있다. 하지만 대부분의 서비스들이 실제 서비스
대상과는 전혀 상관없는 서비스이다. 꼭 필요한 서비스이외의 나머지 서비스들은
아래와 같은 방법으로 부팅 시 자동 시작 리스트에서 제거 한다.
/sbin/chkconfig –del rpcgssd
/sbin/chkconfig –del mdmonitor
/sbin/chkconfig –del arptables_jf
/sbin/chkconfig –del autofs
/sbin/chkconfig –del cups
/sbin/chkconfig –del isdn
/sbin/chkconfig –del anacron
/sbin/chkconfig –del rawdevices
/sbin/chkconfig –del rpcsvcgssd
/sbin/chkconfig –del rhnsd
/sbin/chkconfig –del iptables
/sbin/chkconfig –del cups-config-daemon
/sbin/chkconfig –del lm_sensors
/sbin/chkconfig –del rpcidmapd
/sbin/chkconfig –del kudzu
/sbin/chkconfig –del acpid
/sbin/chkconfig –del netfs
/sbin/chkconfig –del portmap
/sbin/chkconfig –del apmd
/sbin/chkconfig –del messagebus
/sbin/chkconfig –del gpm
/sbin/chkconfig –del smartd
/sbin/chkconfig –del pcmcia
/sbin/chkconfig –del haldaemon
/sbin/chkconfig –del nfslock
/sbin/chkconfig –del atd
– 필요한 서비스 추가
/sbin/chkconfig –add crond
/sbin/chkconfig –add irqbalance
/sbin/chkconfig –add network
/sbin/chkconfig –add sshd
/sbin/chkconfig –add syslog
/sbin/chkconfig –add named
/sbin/chkconfig –add proftpd
/sbin/chkconfig –add sendmail
/sbin/chkconfig –add nfs
/sbin/chkconfig –add portmap
/sbin/chkconfig –add rlogin
/sbin/chkconfig –add rsh
/sbin/chkconfig –add rsync
/sbin/chkconfig –add xinetd
부팅 시 자동 시작 서비스 데몬 제어 방법으론 위 방식은 chkconfig 이외에
ntsysv 란 명령어를 이용하여 설정할수도 있다.
– 불필요한 Xinetd 서비스 제거
rm -f chargen
rm -f chargen-udp
rm -f daytime
rm -f daytime-udp
rm -f echo
rm -f echo-udp
rm -f finger
rm -f ntalk
rm -f rexec
rm -f rlogin
rm -f rsh
rm -f rsync
rm -f servers
rm -f services
rm -f sgi_fam
rm -f talk
rm -f telnet
rm -f time
rm -f time-udp
rm -f proftpd-inetd
1.4.2 시스템 계정 관리 및 운영체제 파일, 디렉토리 권한 조정
– 불필요 계정 삭제
userdel adm
userdel lp
userdel sync
userdel shutdown
userdel halt
userdel news
userdel uucp
userdel operator
userdel games
userdel gopher
– 불필요 그룹 삭제
groupdel adm
groupdel lp
groupdel news
groupdel uucp
groupdel games
groupdel dip
– 운영체제 기본 명령어 권한 조정 및 시스템 파일 보안 정책
# find / -type f \\( -perm -4000 -o -perm -2000 \\)
chmod 700 /usr/bin/chage
chmod 700 /usr/bin/gpasswd
chmod 700 /usr/bin/wall
chmod 700 /usr/bin/chfn
chmod 700 /usr/bin/chsh
chmod 700 /usr/bin/newgrp
chmod 700 /usr/bin/write
chmod 700 /usr/bin/passwd
chmod 700 /usr/bin/at
chmod 700 /usr/bin/lockfile
chmod 700 /usr/bin/rcp
chmod 700 /usr/bin/rlogin
chmod 700 /usr/bin/rsh
chmod 700 /usr/bin/slocate
chmod 700 /usr/bin/crontab
chmod 700 /usr/libexec/openssh/ssh-keysign
chmod 700 /usr/sbin/ping6
chmod 700 /usr/sbin/traceroute6
chmod 700 /usr/sbin/usernetctl
chmod 700 /usr/sbin/userhelper
chmod 700 /usr/sbin/lockdev
chmod 700 /usr/sbin/userisdnctl
chmod 700 /usr/sbin/sendmail.sendmail
chmod 700 /usr/sbin/traceroute
chmod 700 /usr/sbin/utempter
chmod 700 /bin/ping
chmod 700 /bin/mount
chmod 700 /bin/umount
chmod 700 /bin/su
chmod 700 /sbin/pam_timestamp_check
chmod 700 /sbin/pwdb_chkpwd
chmod 700 /sbin/unix_chkpwd
chmod 700 /sbin/netreport
chmod 700 /usr/bin/sudo
chmod 4750 /usr/bin/rcp
chmod 4750 /usr/bin/rsh
chmod 4750 /usr/bin/rlogin
chmod 4111 /usr/bin/sudo
chmod 2750 /usr/sbin/sendmail.sendmail
chmod 4750 /sbin/unix_chkpwd
chmod 4750 /bin/su
chattr +i /etc/fstab
chmod 750 /bin/ps
chmod 750 /bin/netstat
chmod 750 /bin/dmesg
chmod 750 /bin/df
chmod 750 /usr/bin/w
chmod 750 /usr/bin/who
chmod 750 /usr/bin/last
chmod 750 /usr/bin/top
chmod 750 /usr/sbin/lsof
chgrp wheel /bin/ps
chgrp wheel /bin/netstat
chgrp wheel /bin/dmesg
chgrp wheel /bin/df
chgrp wheel /usr/bin/w
chgrp wheel /usr/bin/who
chgrp wheel /usr/bin/last
chgrp wheel /usr/bin/top
chgrp wheel /usr/sbin/lsof
chgrp wheel /usr/bin/rcp
chgrp wheel /usr/bin/rsh
chgrp wheel /usr/bin/rlogin
chgrp wheel /sbin/unix_chkpwd
# vi /etc/group
==================================================================
.
.
wheel:x:10:root,clunix,alang
.
==================================================================
– 시스템 디렉토리 권한 조정
chmod 711 /
chmod 711 /home
chmod 711 /var
chmod 711 /var/log
chmod 711 /etc
chmod 700 /root
1.4.3 운영체제 기본 서비스 보안 설정
– 일반 Shell 사용자 보안 설정
시스템에 여러개의 접속 계정이 있을 경우 사용자 계정에 따른 적절한 보안 정책이 주어
져야 한다. 즉 사용자별 시스템 자원 사용 제한 정책이나, 사용자의 특정 작업을 감시하는
형태이 보안이 필요하게 된다.
사용자별 자원의 활당 정책은 주로 사용자 그룹을 이용하여 제한을 두는 것이 관리상 편리
하다. 자원의 제한 설정은 /etc/security/limits.conf 설정 파일에서 제어할 수 있다.
# vi /etc/security/limits.conf
——————————————————————-
@student hard nproc 20
@admin soft nproc 20
@admin hard nproc 50
ftp hard nproc 3
@student – maxlogins 4
alang – maxlogins 2
——————————————————————-
설정의 경우 student 란 그룹의 속해진 유저들은 이 시스템에서 최대 20개의 프로세스
사용할 수 있고. 최대 4개의 터미널 접속이 가능하도록 제한되어진다.
limits.conf 의 설정 방식은 아래와 같다.
<domain> <type> <item> <value>
<domain>은 시스템 계정이나 그룹에 해당되며 공백일 경우에는 와일드카드 문자인 *
이 적용되어진다. 그룹의 경우에는 그룹명 앞에 ‘@’ 를 붙여 사용할 수 있다.
<type>의 경우는 hard 와 soft 로 나누어지며 hard 의 경우는 hard limit 에 해당하고
soft 는 soft limit 에 해당하는 값이다. hard, soft limit 는 시스템 명령인 ulimit 란
명령으로 확인이 가능하다.
hard limit 확인 -> # ulimit -Ha
soft limit 확인 -> # ulimit -Sa
<item>의 경우는 실제 세부적인 시스템 자원에 해당된다. 여기에는 여러가지 해당 값으로
나눌 수 있다. 대표적인 항목으로는 다음과 같다.
core – limits the core file size (KB)
data – max data size (KB)
fsize – maximum filesize (KB)
memlock – max locked-in-memory address space (KB)
nofile – max number of open files
rss – max resident set size (KB)
stack – max stack size (KB)
cpu – max CPU time (MIN)
nproc – max number of processes
as – address space limit
maxlogins – max number of logins for this user
priority – the priority to run user process with
locks – max number of file locks the user can hold
<value>는 각 자원의 제한 값이다.
이밖에 사용자의 주요 작업 내역에 대해서는 아래의 방식으로 관리가 가능하다.
물런 이런 방식이 정상적으로 허용될지에 대해서는 각 사이트마다 다를 것이다.
하지만 여러명의 사용자가 존재하고 모두의 정상적인 시스템 사용을 위해서는 관리자의
막강한 관리 권한이 주어져야 하며, 권한을 가진 관리자에게는 시스템 관리에 따른
윤리성에 대한 자각이 갖추어져야 한다. 아래 방식은 실제 사용자의 주요 작업 히스토리
를 관리자가 쉽게 파악할 수 있도록 하는 방법이다. 관리자의 경우는 실제 시스템적
관리 권한에 이미 일반 사용자의 작업 히스토리를 볼수 있는 권한이 주어진다.
하지만 운영 정책에 의해 제한되어지는 환경도 많을 것이다. 아래 방법은 시스템상에서
적절한 권한을 위임 받은 상태에서 보다 효율적인 관리를 위해서 사용될 수 있는 방법일
것이다.
– 일반 shell 사용자 작업 내용 감시 하기
/etc/profile 파일의 제일 밑 부분에 아래 내용 추가
===================================================================
if [ $LOGNAME != “root” ]
then
HISTFILE=/var/log/user_history
TMOUT=200
echo -n ”
===================================================================
userhistory 로그인 ID: $LOGNAME 접속시간 : `/bin/date`
===================================================================
” >> /var/log/user_history
fi
===================================================================
/root/.bashrc 파일 밑 부분에 다음 라인 추가
===================================================================
HISTFILE=/root/.bash_history
TMOUT=-1
===================================================================
그런후 /var/log 밑에 user_history 란 파일을 생성합니다.
# touch /var/log/user_history
마지막으로 /var/log/user_history 파일의 퍼미션을 662 으로 해줍니다.
# chmod 662 /var/log/user_history
위와 같은 설정이 완료되면 일반 계정에서 로그인을 했을 경우 사용자 계정의 홈디렉토리
밑에 생성되어져야 할 작업 history 가 /var/log/user_history 밑에 아래와 같이 생성이
될것이다.
# cat /var/log/user_history
===================================================================
userhistory 로그인 ID: alang 접속시간 : Mon Apr 11 16:34:42 KST 2005
===================================================================
ls
ls
ps ax
cat .bash_history
참고 : 위 설정에서 TIMEOUT 설정은 사용자 계정이 접속 한 후 아무런 작업없이 200초를
유휴 상태로 있을 경우 자동 logoff 시키는 명령이다. limits.conf 등에서 사용자 계정의
터미널 최대 접속 수를 제한했을 경우 실제 시스템을 사용하지 않는 상태에서 접속만하고
있을 경우 다른 사용자들이 시스템 접속 제한에 걸려 접속을 하지 못하는 것을 방지하기
위한 설정이다. 만일 접속 사용자의 편위를 최대한 보장한다고 한다면, limits.conf 설정
의 maxlogin과 위 설정의 TIMEOUT 설정을 제거 하도록 한다.
이제 위의 사용자 히스토리 내역을 관리자에게 자동 메일을 보내주는 스크립트를 사용하
여 매일 편리하게 사용자 관련 보안을 점검하면 된다.
# vi cmdchk
——————————————————————————–
#!/bin/sh
date=`date +%Y%m%d`
mailadm=admin@domain.com
if [ -s /var/log/user_history ]
then
mail -s “$date `hostname` user_history check” admin@domain.com < /var/log/user_history
echo > /var/log/user_history
fi
——————————————————————————–
– Xinetd 서버스 보안 정책
시스템 기본 접속 단계에 해당하는 telnet, ssh, ftp 등의 서비스는xinetd 란 수퍼 데몬
상에서 관리되어진다. 이는 리눅스 기본 정책일뿐 반드시 위 서비스가 xinetd 데몬상에서
관리되어야 하는 것은 아니다. xinetd 데몬의 자세한 사용법에 대해서는 별도의 서적이나
인터넷 상의 정보를 참고 하길 바란다. 여기서는 xinetd 상에서 구동되어지는 서비스의
기본 보안 설정에 대해서만 다루도록 한다.
xinetd 데몬으로 구동되어지는 서비스들은 /etc/service 란 설정 파일에서 확인할 수 있다.
그리고 실제 서비스 적용 사항들은 /etc/xinetd.d 란 디렉토리에서 확인이 가능하다.
xinetd 설정 형식은 다음과 같다.
# cat /etc/xinetd.d/rsh
—————————————————————————–
service shell
{
disable = yes
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/sbin/in.rshd
}
——————————————————————————
실제 위 설정에서 ‘disable’ 설정에 ‘yes’ 가 되어져 있는 경우 서비스를 off 시켜두겠
다는 의미이다. 실제 사용을 하지 않는 서비스의 경우에서 설정 파일을 제거하는 것이
안정할 것이다. 임시적으로 사용을 중단하는 것이라면 위 설정과 같이 disable = yes
상태로 두는 것이 좋다.
이런 형태의 xinetd 데몬으로 관리하는 서비스의 경우 TCP Wrapper 란 프로그램으로 서비스
에 대한 접근 권한을 제어 할수 있다. 이는 iptables 와 같은 netfilter 기반의 보안방식
에 비해 가볍고 효율적인 보안 관리가 가능하다.
아래는 tcp wrapper 설정 방법이다.
# vi /etc/hosts.deny
===================================================================
sshd : ALL : twist ( /root/bin/hostchk Y Y %a %c %d %h %n %p %s %u ) &
in.proftpd : ALL : twist ( /root/bin/hostchk Y Y %a %c %d %h %n %p %s %u ) &
===================================================================
# vi /etc/hosts.allow
====================================================================
sshd : localhost 127.0.0.1 211.241.202. 192.168.1.
in.proftpd : localhost 127.0.0.1 211.241.202. 192.168.1.
=====================================================================
tcp wrapper 설정은 /etc/hosts.deny 와 /etc/hosts.allow 두가지 설정으로 나누어 진다.
hosts.deny 는 서비스 거부 설정이고 hosts.allow 는 서비스 허가 설정이다.
순서로 보면 /etc/hosts.deny 설정 파일에서 서비스 접근을 거부 시킬 서비스와 그 영역
을 설정한다.
위 설정에서는 sshd, proftpd 란 서비스에 대해 모든 곳에서의 접속을 거부한다는 의미다.
twist 설정은 실제 거부되는 서비스에 접근 시도가 있을 경우 뒤에 설정된 명령을 실행시키는
설정이다.
그런 후 접속을 허가할 사이트에 대해서 hosts.allow 파일에 허가 설정을 하도록 한다.
서비스 설정 방식은 아래와 같다.
<service>:<address>:<option>
<service>는 xinetd 데몬 상에서 구동되어지는 서비스 명이다.
<address>는 접속 사이트의 IP 주소 및 Subnet 영역 등이 포함된다.
‘ALL’ 이란 설정으로 모든 영역을 나타낼 수 있다.
<option>은 twist 와 같이 접근 제한, 혹은 접근 허가 이후 특정 작업을 실행할 수 있다.
위 설정은 hosts.allow 에서 허가하지 않는 사이트에서 접근할때 접근을 거부 시키고
/root/bin/hostchk 란 명령어를 실행하라는 의미이다.
hostchk 란 명령어는 접속 사이트 정보를 관리자에게 메일로 보내주는 관리용 스크립터
명령이다.
# vi /root/bin/hostchk
——————————————————————————–
#!/bin/sh
################################ 변수정의부문
# 메일 수신자
mailto=admin_user@domain.com
# 화면출력 여부, 메일전송 여부
dsp=$1; msg=$2
# 접속자 정보 등
a=$3; c=$4; d=$5; h=$6; n=$7; p=$8; s=$9; u=$10
# 현재 시간
time=`date`
# 접속시도자 소속 서버의 finger 정보
finger=`/usr/bin/finger -l @$h 2> /dev/null`
################################ 화면 출력부문
if [ $dsp = Y ]
then
/bin/echo -n ”
===================================
접속이 허용되지 않습니다.
===================================
Access Time : $time
Client host address : $a
Client information : $c
Client host name(or IP) : $h
Client host name : $n
Client user name : $u
”
fi
################################ 메일 송신부문
if [ $msg = Y ]
then
/bin/echo -n ”
===============================
접속 거부자 상세정보
===============================
Access Time : $time
Access client host address : $a
Access client information : $c
The daemon process name : $d
Access client host name(or IP) : $h
Access client host name : $n
The daemon process id : $p
Server information : $s
Access client user name : $u
————————————–
Access client finger information
————————————–
$finger
————————————————
” | \\
/bin/mail -s “tcp_wrapper report [$d]” $mailto
fi
————————————————————————————
허가 되지 않은 영역에서 접속을 하게 되면 위 관리 스크립터에 지정된 관리자 메일 주소
로 아래와 같은 메세지가 발송이 되어진다.
===============================
접속거부자 상세정보
===============================
Access Time : Mon Apr 11 17:18:25 KST 2005
Access client host address : 192.168.133.1
Access client information : arh01.clunix.org
The daemon process name : sshd
Access client host name(or IP) : arh01.clunix.org
Access client host name : arh01.clunix.org
The daemon process id : 4154
Server information : sshd@192.168.133.9
Access client user name : Y0
————————————–
Access client finger information
————————————–
————————————————
보안과 사용자 편리성은 상극적인 관계 상에 존재한다. 사용자의 편위만을 생각하면 실제
아무런 보안 설정이 되어져 있지 않는 것이 좋을 것이다. 오랜 시간 안정적인 시스템 환경
유지를 위해서라면 철저한 시스템 보안 정책 위주의 보안이 필요할 것이다. 하지만 이런
보안 환경에서는 사용자의 불편함이 클 수 밖에 없다. 이 두가지 관계속에 해당 사이트의
특성을 최대한 고려하여 관리자는 보안 정책을 적용해야 할것이다.
1.4.4 기본 보안 프로그램 설치 및 관리
– Tripwire 설치 및 관리
Tripwire 은 원래 리눅스가 아닌 유닉스 플랫폼에서 설계되어 왔으나 현재 리눅스에서
대표적으로 사용되는 파일 무결성 검사 도구이다.
트립와이어는 시스템 파일등의 변조및 추가등을 검사합으로써..해킹의도를 파악할수 있는
보안 도구 입니다.
Tripwrie 설치전 몇가지 알아 두어야 할점이 있다.
검사도구는 시스템 설치후에 바로 설치해야 의미가 있다.이미 해킹당한 상태에서 설치 해
보아야 검사도구엔 발견 되지 않는다.
초기에 아주 깨끗한 상태에서 시스템 파일 정보들을 DB file 로 만들어 놓고 앞으로 변화
되는 상황을 지켜 보아야 한다.
그리고 시스템 정보가 저장될 DB file 이 다른 사람에게 접근을 허용하면안된다.
이 두가지만 철저하게 지키면 아주 유용한 보안 도구로 사용이가능하다.
이제 설치에 들어가 보도록 하자. 설치는 RPM 과 Source 두가지 방법이 있다.
먼저 Source 설치 방법에 대해 알아보자.
tripwire 소스는 다음 사이트에서 다운 받을 수 있다.
http://www.tripwire.org
특정 디렉토리에 소스를 다운 받아 압축을 푼다.
# tar xzvf tripwire-2.3-47.bin.tar.gz
# cd tripwire-2.3
# ./install.sh
————————————————————————————
Installer program for:
Tripwire(R) 2.3 Open Source for LINUX
Copyright (C) 1998-2000 Tripwire (R) Security Systems, Inc. Tripwire (R)
is a registered trademark of the Purdue Research Foundation and is
licensed exclusively to Tripwire (R) Security Systems, Inc.
LICENSE AGREEMENT for Tripwire(R) 2.3 Open Source for LINUX
Please read the following license agreement. You must accept the
agreement to continue installing Tripwire.
Press ENTER to view the License Agreement. <— [ ENTER ]
.
.
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.
Please type “accept” to indicate your acceptance of this
license agreement. [do not accept] <— [ accept ]
.
.
TWBIN: /usr/sbin
TWMAN: /usr/man
TWPOLICY: /etc/tripwire
TWREPORT: /var/lib/tripwire/report
TWDB: /var/lib/tripwire
TWSITEKEYDIR: /etc/tripwire
TWLOCALKEYDIR: /etc/tripwire
CLOBBER is false.
Continue with installation? [y/n] <— [ y ]
Creating key files…
(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
Enter the site keyfile passphrase: <— [ password ]
Verify the site keyfile passphrase: <— [ password ]
(When selecting a passphrase, keep in mind that good passphrases typically
have upper and lower case letters, digits and punctuation marks, and are
at least 8 characters in length.)
Enter the local keyfile passphrase: <— [ password ]
Verify the site keyfile passphrase: <— [ password ]
.
.
———————————————-
Generating Tripwire configuration file…
———————————————-
Creating signed configuration file…
Please enter your site passphrase: <— [ password ]
.
———————————————-
Customizing default policy file…
———————————————-
Creating signed policy file…
Please enter your site passphrase: <— [ password ]
———————————————-
The installation succeeded.
Please refer to /usr/doc/tripwire/Release_Notes
for release information and to the printed user documentation
for further instructions on using Tripwire 2.3 Open Source for LINUX.
이로써 tripwire 의 설치가 완료되었다.
설치가 완료된 시점에서 일단 Tripwire 의 초기 DB 데이터를 생성하도록 한다.
Tripwire 의 초기 DB 데이터란 현 시스템의 운영체제의 파일들의 무결성 점검 결과를
저장한 DB 파일을 초기화 시킨다는 의미이다. 즉 깨끗한 시스템 파일 초기 상태의 기준
을 세운다는 의미로 보면 된다.
만일 이 초기화 작업을 이미 해킹을 당해 백도어가 설치된 상태에서 초기화를 시킨다고
하면 이런 백도어까지도 무결 파일의 기준으로 인식하게 된다.
그렇기 때문에 Tripwire 같은 무결성 프로그램은 반드시 OS 설치 후 정식 서비스를 시작하기
전에 설치를 해 두는 것이 좋을 것이다.
# tripwire –init
Please enter your local passphrase: <— [ password ]
이제 tripwire로 파일 시스템의 무결성을 체크 하면 된다.
# tripwire –check
Redhat 배포판의 경우 RPM 방식으로 배포를 하기 때문에 이 패키지 사용을 권장한다.
아래는 간단한 RPM 방식의 설치 및 기본 설정 방법에 대해 소개한다.
Redhat Linux 9 배포판 CD3 에 tripwire-2.3.1-17 버전의 패키지가 존재한다.
해당 RPM을 설치 한다.
# rpm -Uvh tripwire-2.3.1-17.i386.rpm
설치 정보는 다음과 같다.
ROOT =/usr/sbin
POLFILE =/etc/tripwire/tw.pol
DBFILE =/var/lib/tripwire/$(HOSTNAME).twd
REPORTFILE =/var/lib/tripwire/report/$(HOSTNAME)-$(DATE).twr
SITEKEYFILE =/etc/tripwire/site.key
LOCALKEYFILE =/etc/tripwire/$(HOSTNAME)-local.key
이제 위의 소스 방식의 설치 단계에 나오는 site.key 생성및 로컬 인증키 생성등의 과정에
해당하는 기본 보안 설정 스크립터인 twinstall.sh 를 실행한다.
twinstall.sh 실행 전에 /etc/tripwire/twpol.txt 에서 무결성 체크 대상 설정 변경 후에도
실행하도록 한다.
초기 twpol.txt 에 정의된 보안 정책은 기본 운영체제에 맞는 보안체제기 때문에 바로 적용
하기엔 너무 많은 체크 대상을 포함하게 된다. 그렇기 때문에 초기에는 우선 초기화 명령을
실행해서 출력되는 에러 내용을 파악하여 현 시스템에 맞는 체크 대상을 만들도록 한다.
# tripwire –init 2> error
# cat error
————————————————————————————.
.
### Filename: /bin/ksh
### 그런 파일이나 디렉토리가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.esd_auth
### 그런 파일이나 디렉토리가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome_private
### 그런 파일이나 디렉토리가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome-desktop
### 그런 파일이나 디렉토리가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome
### 그런 파일이나 디렉토리가 없음
————————————————————————————
위는 기본 정책에는 들어있는 체크 대상이지만 현 시스템에는 존재하지 않는 대상들이다.
이부분들을 /etc/tripwire/twpol.txt 에서 제거하고 다시 /etc/tripwire/twinstall.sh 를
실행한다.
# /etc/tripwire/twinstall.sh
체크 대상 보안 정책 DB 파일을 재생성 한다.
# twadmin –create-polfile twpol.txt
새로 생성된 체크 대상 보안 정책으로 초기 체크 대상 DB 파일을 초기화 한다.
# tripwire –init
이제 파일 시스템의 무결성을 체크 한다.
# tripwire –check
체크한 결과는 터미널 상에 출력되고, /var/lib/tripwire/report 에 twr확장 DB 파일로
생성이 된다.
twr 결과 리포트를 다시 확인 하고 싶을 때는 아래 방식을 이용하면 된다.
# twprint -m r –twrfile /var/lib/tripwire/report/arhdev-20050415-102800.twr
그럼 아래와 같은 결과가 출력된다.
————————————————————————————
Note: Report is not encrypted.
Tripwire(R) 2.3.0 Integrity Check Report
Report generated by: root
Report created on: 2005 04 15 () 10 28 00
Database last updated on: Never
===============================================================================
Report Summary:
===============================================================================
Host name: arhdev
Host IP address: 192.168.133.9
Host ID: None
Policy file used: /etc/tripwire/tw.pol
Configuration file used: /etc/tripwire/tw.cfg
Database file used: /var/lib/tripwire/arhdev.twd
Command line used: tripwire –check
===============================================================================
Rule Summary:
===============================================================================
——————————————————————————-
Section: Unix File System
——————————————————————————-
Rule Name Severity Level Added Removed Modified
——— ————– —– ——- ——–
Invariant Directories 66 0 0 0
Temporary directories 33 0 0 0
Tripwire Data Files 100 0 0 0
Critical devices 100 0 0 0
User binaries 66 0 0 0
Tripwire Binaries 100 0 0 0
Libraries 66 0 0 0
Operating System Utilities 100 0 0 0
Critical system boot files 100 0 0 0
File System and Disk Administraton Programs
100 0 0 0
Kernel Administration Programs 100 0 0 0
Networking Programs 100 0 0 0
System Administration Programs 100 0 0 0
Hardware and Device Control Programs
100 0 0 0
System Information Programs 100 0 0 0
Application Information Programs
100 0 0 0
Shell Related Programs 100 0 0 0
Critical Utility Sym-Links 100 0 0 0
Shell Binaries 100 0 0 0
Critical configuration files 100 0 0 0
System boot changes 100 0 0 0
OS executables and libraries 100 0 0 0
Security Control 100 0 0 0
Login Scripts 100 0 0 0
Root config files 100 0 0 0
.
.
————————————————————————————
이제 테스트를 해보도록 하자
/bin 디렉토리 밑에 test 란 임의의 파일을 하나 생성하고, /bin 밑의 명령어의 퍼미션을
변경해 보도록 하자.
# echo > /bin/test
# chmod 700 /bin/vi
그런 후 무결성 체크를 재 시도 해보자
# tripwire –check
# twprint -m r –twrfile /var/lib/tripwire/report/arhdev-20050415-104007.twr
————————————————————————————
===============================================================================
Rule Summary:
===============================================================================
——————————————————————————-
Section: Unix File System
——————————————————————————-
Rule Name Severity Level Added Removed Modified
——— ————– —– ——- ——–
Invariant Directories 66 0 0 0
Temporary directories 33 0 0 0
Tripwire Data Files 100 0 0 0
Critical devices 100 0 0 0
User binaries 66 0 0 0
Tripwire Binaries 100 0 0 0
Libraries 66 0 0 0
* Operating System Utilities 100 0 0 1
Critical system boot files 100 0 0 0
File System and Disk Administraton Programs
100 0 0 0
Kernel Administration Programs 100 0 0 0
Networking Programs 100 0 0 0
System Administration Programs 100 0 0 0
Hardware and Device Control Programs
100 0 0 0
System Information Programs 100 0 0 0
Application Information Programs
100 0 0 0
Shell Related Programs 100 0 0 0
Critical Utility Sym-Links 100 0 0 0
Shell Binaries 100 0 0 0
Critical configuration files 100 0 0 0
System boot changes 100 0 0 0
* OS executables and libraries 100 1 0 1
Security Control 100 0 0 0
Login Scripts 100 0 0 0
* Root config files 100 0 0 2
.
.
——————————————————————————-
Rule Name: OS executables and libraries (/bin)
Severity Level: 100
——————————————————————————-
Added:
“/bin/alang”
Modified:
“/bin”
.
.
——————————————————————————-
Rule Name: Operating System Utilities (/bin/vi)
Severity Level: 100
——————————————————————————-
Modified:
“/bin/vi”
.
.
———————————————————————————–
위와 같이 초기화 DB 에서 변경된 사항들을 확인 할 수 있다.
시스템을 관리 하면서 추가로 패키지를 설치하거나 관리 목적으로 설정 파일등을 변경했을때
매번 결과 리포트에 변경 사항이 적용되어 출력이 될것이다. 그렇기에 변경된 내용을 새로
업데이트 하여 초기 DB 를 갱신해야 할 때가 있다. 이때는 아래의 명령행을 이용한다.
# tripwire –update –twrfile /var/lib/tripwire/report/arhdev-20050415-104007.twr
그럼 결과 리포트 중 변동 내역에 대한 자세한 정보를 출력해 주고 이를 확인 후 관리작업
상의 변동 사항이라고 하면 site.key 의 인증 암호를 입력하여 업데이트를 시키도록 한다.
이로써 Tripwire 를 이용한 파일 시스템 무결성 체크에 대한 설명을 마치도록 한다.
– fcheck 설치 및 관리
fcheck 는 perl 기반의 파일 무결성관리 프로그램으로 Tripwire 에 비해 가볍고 간단하면서
Tripwire 와 유사한 역활을 충분히 해준다.
먼저 프로그램을 다운 받도록 하자.
http://www.geocities.com/fcheck2000/
가면 최신 프로그램이 있을것이다. 다운을 받고 /usr/local 및에 둔다.
압축을 풀고..fcheck,fcheck.cfg 파일의 설정값을 몇개 수정하자.
# tar xzvf FCheck_2.07.59.tar.gz
# cd fcheck
# vi fcheck
——————————————————————-
.
.
###############################################################
##############
# #
# User modifiable variable definitions: #
# #
###############################################################
##############
# This should be passed through the command line, but hard coding still works
$config=”/usr/local/fcheck/fcheck.cfg”;
—————————————– 이부분을 시스템 환경에 맞게 수정
——————————————————————-
# vi fcheck.cfg
——————————————————————-
Directory = /etc/
Directory = /bin/
Directory = /usr/bin/
Directory = /sbin/
Directory = /usr/sbin/
Directory = /usr/local/bin/
Directory = /usr/local/sbin/
Directory = /lib/
Directory = /usr/lib/
Directory = /usr/local/lib/
#
# Directory 설정은 fcheck 가 체크할 파일들이 들어 있는 디렉토리로 시스템에
# 중요한 명령어나 설정파일등이 있는 곳을 정해 주면 된다.
#
Exclusion = /etc/passwd
Exclusion = /etc/shadow
#
# Exclusion 설정은 Directory 설정에서 정한 디렉토리중 자주 변경이 되는 파일
# 이 있어서 체크때마다 걸리므로 체크 생략을 요하는 파일을 정해 주면 된다.
# 호스팅 업체나 기타 자주 사용자를 추가하는 서버라면 위와 같이 해주면 된다.
#
DataBase = /usr/local/fcheck/data/data.dbf
#
# DataBase 설정은 리눅스 파일 정보를 DB 파일로 저장해서 다음 체크시 비교
# 분석할때 사용되어진다.
#
TimeZone = GMT-9
#
# 한국 시간을 적용한다. GMT-9
#
#File = /usr/local/admtools/logs/sol.dbf
————————————————————————-
File 설정은 필요 없으니 주석 처리 해준다.
기타 여러 설정값이 있으나 크게 작동하는데 영향을 주지 않는다.기본값을 적용
한다.
이와 같이 적용후 /usr/local/fcheck/data 디렉토리를 만들어 준다.
# mkdir /usr/local/fcheck/data
# /usr/local/fcheck/fcheck -ac
이와 같이 fcheck -ac 로 파일 무결성 체크를 시작한다. 그럼 data 디렉토리 안
에 data.dbf 파일이 생성되어 진다.
이제 Directory 설정에 해당하는 디렉토리 안에다가 파일을 하나 생성하고 재대
로 점검을 하는지 테스트를 하여 보자..
# touch /etc/test
# /usr/local/fcheck/fcheck -a
그럼 아마 아래와 같은 결과를 출력할것이다.
PROGRESS: validating integrity of /etc/
STATUS:
ADDITION: [zzang911.net] /etc/test
Inode Permissons Size Created On
19508 -rw-r–r– 0 Sep 19 20:13 2001
자 이제 이 명령어를 이용하여 주기적으로 시스템 파일 무결성을 체크하고 관리
자에게 통보하는 프로그램을 만들어 보도록 하자.
# vi /root/bin/fcheck.sh
—————————————————————————
#!/bin/sh
ADM_MAIL=admin_user@domain.com
CHECK=`/usr/local/fcheck/fcheck -a | grep Inode`
HOSTNAME=`hostname`
if [ -n “$CHECK” ]
then
/usr/local/fcheck/fcheck -a > fcheck_result
mail -s “$HOSTNAME File 무결성 체크 결과” $ADM_MAIL < fcheck_result
rm -f fcheck_result
fi
—————————————————————————-
간단한 이정도 스크립터로 보다 효율적인 관리가 가능해 질것이다.
이제 cron 에 등록시켜 놓고..매일 파일 무결성 체크를 간단히 메일로 받아서 관리
할수 있게 된다. 만일 변화된 파일이 정당한 변화라면..
# /usr/local/fcheck/fcheck -ac
로 DBfile 를 업데이트 시켜 줘야 한다. 아님..계속 메일이 날아 오게 된다.
이로써 시스템 설치후 점검해야 할 보안 설정에 대해서 마치겠다. 시스템 보안은
초기의 보안 설정이 아주 큰 부분을 차지 하고 있다. 하지만..지속적은 감시와
관리역시 초기 보안 상태를 유지하는 가장 중요한 작업이라고도 할수 있다.
– Service Port Scan 확인
기본적인 OS 설정 및 보안 설정이 완료되면 최종적으로 현재 서비스가 이루어
지는 TCP/IP Port 에 대해 시스템 초기 상태에서 알아 두어야 한다.
이후 이때 파악 되지 않는 서비스 포트가 열려 있을 경우 보안에 의심을 해보
아야 할것이다.
Port Scan 도구로는 가장 많이 사용하는것이 nmap,nc,netstat,lsof 등 이다.
사용법은 다음과 같다.
nmap,nc,netstat 등을 이용해서 시스템의 열린 포트를 점검한다.
# nmap localhost -p 1-65535
# nc -w 3 -v -z localhost 1-65535
# netstat -ant | grep LISTEN
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
3306/tcp open mysql
불필요한 서비스 포트가 열려 있는 경우엔 반드시 해당 데몬이나 서비스를 off 시켜
크래킹에 이용되지 않도록 조치한다.
1.4.5 기타 추가 설정
이후 사이트 서비스 성격이나 시스템 관리자 취향에 맞게 추가 설정을 해 주도록 한다.
– Time 설정
# rdate -s time.bora.net
– command alias 설정
# vi .bash_profile
——————————————————————————
alias vf=’vi /etc/proftpd/proftpd.conf’
alias rf=’/etc/rc.d/init.d/proftpd restart’
alias rx=’/etc/rc.d/init.d/xinetd restart’
alias vh=’vi /usr/local/apache/conf/httpd.conf +’
alias re=’/usr/local/apache/bin/apachectl restart’
alias rn=’/etc/rc.d/init.d/named restart’
alias rs=’/etc/rc.d/init.d/sendmail restart’
——————————————————————————
– System Login Infomation 설정
# vi /etc/issue ( 콘솔 접속 로그인 화면 )
# vi /etc/issue.net ( Telnet 접속 로그인 화면 )
# vi /etc/motd ( ssh, rsh 등의 원격 접속 로그인 화면 )
– 시스템 시작 시 자동 실행 작업
시스템이 리부팅 될때 자동으로 실행 시켜야 하는 프로그램이나 명령어가 있을 경우
/etc/rc.d/rc.local 설정파일 마지막에 실행 명령을 적어 두면된다.
특정 계정 로그인 시 자동으로 실행해야 하는 작업이 있을 경우는 해당 계정의 홈폴더
밑에 있는 .bash_profile 혹은 .bashrc 파일 하단에 해당 작업을 적어 주면 된다.
1.5 엔터프라이즈 리눅스 커널 구성 하기
1.5.1 커널과 시스템 최적화
시스템 커널이란 실제 운영체제의 핵심 코어 부분으로 실제 OS 기능의 대부분의 역활
을 담당하는 부분이다. 운영체제란 컴퓨터 하드웨어를 사용자가 어플리케이션을 통해
바로 인식하여 작업에 사용할 수 없기때문에 이런 하드웨어 자원을 어플리케이션에서
인식하여 프로그램상에서 사용할 수 있는 중계 역활을 하는 프로그램으로 볼수 있다.
이런 운영체제의 구성으로는 크게 하드웨어의 기능을 인식하여 그 기능을 관리, 제어
하는 커널 부분과 기본적인 어플리케이션 부분으로 구성이 되어진다. 즉 커널 부분은
실제 운영체제의 가장 큰 역활인 하드웨어의 어떻게 인식하고, 어떤 방식으로 관리,
제어를 하는가를 결정하는 중요한 부분이다. 이런 커널 구성 방식에 따라 동일한 하드
웨어를 가진 시스템이라도 그 성능의 차이가 생기게 된다.
이 장에서는 커널의 최적화 요소와 해당 요소 별 성능에 미치는 영향에 대해 살펴보고
실제 엔터프라이즈 시스템 환경의 맞는 커널을 구성해 보도록 할 것이다.
커널의 최적화 기술은 시스템 엔지니어의 고급 능력 중에 하나이며, 이는 실제 엔지니어
의 기술력 차이를 통해, 동일 시스템의 성능의 차이를 가져 올 수 있는 요소 중의 하나
이다.
리눅스의 여러 배포판이 존재하는데 이중 엔터프라이즈급 리눅스 배포판이라는 명칭이
붙는 배포판의차이가 바로 이 커널 구성에서 있는 것이다. 즉 SMP 시스템을 인식하고
대용량 메모리를 인식하고, 메모리 I/O, 디스크 I/O, 시스템 I/O 성능을 개선하며,
보다 안정적인고 대용량 파일을 제어 할수 있는 파일 시스템을 지원토록 하며,
프로세스 처리 제한이나 파일 OPEN 제한 수치를 확장시키는등 대용량 서비스를 수행 할
수 있게 커널 환경을 구성함으로 엔터프라이즈 리눅스 환경이라 할 수 있다.
이 장에서는 실제 커널 컴파일에 대한 기본적인 기술에 대해서는 언급하지 않는다.
커널 컴파일에 대한 기술 부분은 인터넷 상의 기술문서나 다른 서적을 참고하길 바란다.
1.5.2 엔터프라이즈 커널 구성 요소
대용량 서비스를 할수 있는 시스템 구성을 위한 커널 튜닝에 대해 알아 보도록 하겠다.
http://www.kernel.org 에서 최신 커널 소스를 다운 받으면 기본적으로 범용 시스템에
맞는 커널 구성으로 되어져 있다. 이는 보편적으로 일반 시스템에 적합한 커널 구성이라
대용량 시스템에 바로 사용하면 실제 시스템의 하드웨어 성능을 최대한 활용할수 없게
된다. 그러므로 시스템 하드웨어에서 지원하는 성능을 최대한 효율적으로 활용 가능하도록
커널을 튜닝을 해주어야 한다. 여기서 다루는 커널 튜닝 방법은 대용량 SMP 시스템을
대상으로 하는 방법이기 때문에 보편적인 일반 시스템에서는 커널의 서비스 한계치가
하드웨어 실제 지원 한계치를 넘게되어 문제가 발생할 수 있으니 주의하길 바란다.
– Kernel 한계 수치 수정을 통한 최적화 작업
이는 커널 소스에 기본적으로 정의된 process, socket, file open 제한 수치를 해당
시스템에 맞게 확장 하여 시스템의 수용 성능을 향상 시키는 방법이다.
# vi /usr/src/linux/include/linux/fs.h
———————————————————————————–
.
-#define INR_OPEN 1024 /* Initial setting for nfile rlimits */
+#define INR_OPEN 4096 /* Initial setting for nfile rlimits */
.
.
-#define NR_FILE 8192 /* this can well be larger on a larger system */
+#define NR_FILE 65536 /* this can well be larger on a larger system */
————————————————————————————
# vi /usr/src/linux/include/linux/limits.h
————————————————————————————
.
-#define NR_OPEN 1024
+#define NR_OPEN 4096
.
.
-#define OPEN_MAX 256
+#define OPEN_MAX 4096
.
————————————————————————————-
# vi /usr/src/linux/include/linux/posix_types.h
————————————————————————————-
.
-#define __FD_SETSIZE 1024
+#define __FD_SETSIZE 4096
.
————————————————————————————-
– System I/O 최적화 작업
해당 작업은 리눅스 시스템 상의 I/O 성능 개선을 위한 바운스 버퍼 관련 패치 및 SCSI 병렬
큐잉 패치등의 작업이 있다
– File System 최적화 작업
SGI UNIX System 의 기본 파일 시스템으로 알려진 XFS 파일 시스템을 리눅스에서 사용할 수
있도록 하는 작업이다. 리눅스의 기본 파일 시스템은 Ext3 를 사용하는데 이는 일반적인 리눅스
시스템에서 적절한 성능과 안정성을 보장하기에 주로 사용을 하나 대용량 시스템이고 대형
파일을 작업에 주로 사용하는 경우 대용량 파일 제어에 탁월한 성능을 가진 XFS 파일시스템을
채택해 보는 것도 시스템 성능 개선에 효과를 볼수 있을 것이다.
– Sysctl을 이용한 커널 파라메터 최적화 작업
일반 시스템의 안정성을 위해 기본적으로 네트워크의 성능 임계치를 하향 조정해 놓는다.
하지만 실제 고성능 워크스테이션의 경우 시스템의 재 성능을 커널에서 제한하는 경우에
해당할 것이다. 이는 시스템 사양에 맞게 적절한 서비스 한계치를 조절함으로 최적 성능을
발휘할 수 있게 설정을 조절하여야 한다.
커널 파라메터를 통한 설정 변경은 커널의 소프트 레벨에서 수정이 가능하며 sysctl 프로그램
을 이용하여 설정 변경이 가능하다. 커널의 소프트 레벨의 수정이라 함은 실제 커널 소스상태
에서의 수치 수정을 통해 적용하는 것이 아니라 시스템이 부팅되어져 있는 상태에서 커널의
파라메터값을 변경하여 해당 수치를 적용하는 방법이다.
먼저 sysctl의 사용법에 대해 간단히 알아보도록 하자.
sysctl 은 리눅스의 가상 파일 시스템인 /proc 파일 시스템 내의 파일들을 직접 수정하여
커널 옵션의 변경을 효율적으로 관리하는 명령어이다.
사용법은 단순한다.
# sysctl -a : 커널 파라메터 값 확인하기
위의 명령으로 커널 파라메터를 확인을 하면 상당 수의 정보가 출력된다. 원하는 정보를
확인 하기 위해서는 grep 명령을 이용하여 확인 하면 된다.
# sysctl -a | grep fs.xfs
————————————————————————————-
fs.xfs.stats_clear = 0
fs.xfs.age_buffer_centisecs = 1500
fs.xfs.xfsbufd_centisecs = 100
fs.xfs.inherit_noatime = 1
fs.xfs.inherit_nodump = 1
fs.xfs.inherit_sync = 1
fs.xfs.xfssyncd_centisecs = 3000
fs.xfs.error_level = 3
fs.xfs.panic_mask = 0
fs.xfs.irix_symlink_mode = 0
fs.xfs.irix_sgid_inherit = 0
fs.xfs.restrict_chown = 1
fs.xfs.refcache_purge = 32
fs.xfs.refcache_size = 128
————————————————————————————–
# sysctl -w : 커널 파라메터 값을 변경
-w 옵션을 사용하여 커널 파라메터의 값을 변경할 수가 있다.
예를 들면 TCP SYN_Flooding 공격 차단을 위해 net.ipv4.tcp_syncookies 값을 기본 0에서
1로 변경을 해 보도록 하자
# sysctl -w net.ipv4.tcp_syncookies=1
위와 같이 시스템 서비스 현 상황에 맞게 커널 파라메터 값을 적절히 수정하여 시스템의
최적화를 만들 수 있다.
soft level 의 커널 파레메터 수정은 부팅 이 후 변경이 가능하고 만일 리부팅이 되어 지면
기본의 설정 내역이 다시 초기화 된다.
설정을 유지 하는 방법으로는 sysctl 명령행을 /etc/rc.d/rc.local 에 등록하는 방법과
/etc/sysctl.conf 설정 파일을 통한 설정도 가능하다.
/etc/sysctl.conf 를 통한 설정 방법은 다음과 같다.
# vi /etc/sysctl.conf
————————————————————————————–
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
kernel.core_uses_pid = 1
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
# Controls source route verification
net.ipv4.conf.default.rp_filter = 1
# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0
kernel.core_uses_pid = 1
————————————————————————————-
위의 형식으로 커널 파라메터 설정을 sysctl.conf 파일에 설정해 주면 리부팅 시에도
적용이 가능하다.
아래는 시스템 성능과 보안에 관련된 주요 커널 파라메터들이다.
– 주요 보안 관련 커널 설정
net.ipv4.icmp_echo_ignore_all = 1
: ping 요청에 반응 막기 . 외부에서 특정 시스템에 대해 ping 보내 시스템의 운영체제
정보를 알고 이를 시점으로 공격을 시도하는 경우가 많다. 이를 원천적으로 차단하는
방법이다.
net.ipv4.icmp_echo_ignore_broadcasts =1
: broadcast 로 오는 ping 차단하기. smurf 공격에 대응하는 방법이다. 스머프 공격은
echo request 패킷을 특정 네트워크 대역의 broadcast 에 보내는 것을 방지하는 설정이다.
이는 ping 을 수용하는 시스템에 문제가 발생하는 것이 아니라 ping 을 발송하는 시스템
에서 부하가 걸리서 다운시키는 문제를 방지하는 것이다.
net.ipv4.conf.all.accept_source_route =0
: IP Source routing 막기 . 해커가 이 기능을 이용하여 특정 네트워크 대역의 소스
라우팅을 보내고 응답하는 패킷을 중간에 가로채 상대방의 호스트와 신뢰관계를 맺은것처럼
속일 수있다. 이를 막지하는 것이다. 기본값이 1 인데 이를 0으로 변경한다.
net.ipv4.tcp_max_syn_backlog=1024
net.ipv4.tcp_syncookies = 1
위 두 설정은 SYN Attack DOS 공격을 막지 하기 위한 설정이다. 이는 호스트 간의 TCP 통신
의 원리를 이용한 공격으로 서비스 거부 공격이라 불린다. 즉 하나의 호스트에서 다른 호스
트로 TCP 패킷을 보내면 TCP 헤더에 SYN flag 를 on 한 상태로 연결 요청을 시도하게 된다.
이때 클라이언트에서는 SYN/ACK를 보내고 이를 다시 호스트에서 받아 ACK 신호를 보내게
되어 양 방향간의 통신이 이루어 진다. 이때 SYN/ACK 를 다시 받은 호스트에서 ACK를 보내지
않는 다고 하면 클라이언트 쪽에서 ACK가 돌아올때까지 큐에 발송된 SYN/ACK 패킷 정보를
보관해 두게 되는데 이 큐가 backlog 이다. 악으적으로 서비스 요청을 하고 응답된 SYN/ACK
신호에 대한 재응답을 해주지 않는 경우 상대 호스트는 backlog 에서 허용하는 제한 수까지
큐에 쌓아두지만 이 제한 수치가 넘어서게 되면 시스템에 문제가 발생하게 되는 것이다.
이를 SYN Flooding 이라고 한다. syncookies 는 이런 Syn flood 공격을 방어하기 위한 설정
이며, 이 기능을 사용하기 위해서는 커널에서 syncookie 기능이 on 되어져 있어야 한다.
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_redirects=0
: ICMP redirect 방지
net.ipv4.icmp_ignore_bogus_error_responses = 1
: bad icmp packet 차단
net.ipv4.conf.all.rp_filter = 1
: IP spoofing 방지 . 서비스 거부 공격 시 해커들은 공격 소스의 IP 정보를 속여서
공격하게 된다. 이 기능은 본 시스템이 spoofing 에 이용되는 것을 방지한다.
net.ipv4.conf.all.log_martians = 1
: IP spoofing 된 패킷 로그에 남기기
– 성능에 관련된 커널 설정
net.ipv4.tcp_fin_timeout = 30
: 연결 종료 시간 단축. 특정 호스트에서 TCP 연결이 이루어진 후 두 호스트 간의 서비스
요청이 완료되어도 일정 시간동안 서버 측에서는 소켓을 유지 하면서 재 요청을 기다린다.
이 시간 동안에 실제 서비스는 되지 않지만 계속 서버 시스템의 리소스를 활당하고 있기
때문에 다른 요청자의 요청이 이로 인해 문제가 발생할 수 있다. 이 수치를 현 서버의
서비스 상태에 맞게 적절히 단축 시켜 주는 것이 좋다.
net.ipv4.tcp_keepalive_time = 1800
: Keepalive 시간 줄이기. 이 설정은 웹서버의 keepalive와는 별도로 TCP 자체의 설정이고
이 설정값 역시 양 호스트 간의 서비스 관계가 종료되었지만 특정 시간 동안 연결 상태가
대기 상태로 유지 되면 시스템 리소스의 낭비를 불려 온다. 기본 값이 7200(2시간) 인데
이를 최적화하는 것이 좋다.
net.ipv4.ip_local_port_range = 32768 61000
: Open port 갯수 확장 하기 . 네트워크 서비스에 이용되는 서비스 포트의 갯수를 변경하는
것이다. 엔터프라이즈 서버에서는 일반 서버에 비해 많은 서비스 요청을 소화 해야 하기
때문에 서비스 Open port 수도 많이 필요하게 될것이다. 이를 시스템의 보유 리소스 크기에
맞게 조정을 해주는 것이 좋다. 위 설정은 32768번 포트 부터 61000번 포트 까지 열 수
있다는 것이다.
– 시스템 limit 설정을 통한 최적화 작업
커널 구성과 별도로 시스템 설정 제한에서 시스템의 리소스를 제한하는 경우가 있다.
앞에서 언급했듯이 /etc/securetty/limit.conf 파일에서 제한을 하게 되는데 고성능 서버의
경우 위 제한 치를 기본 설정에 비해 높게 잡아 주는 것이 재 성능 발휘에 좋을 것이다
1.5.3 커널 컴파일 실무 관련 주요 기술
– 시스템 성능 확장을 위한 주요 기능
리눅스 커널 컴파일시 시스템 성능에 중요한 역활을 하는 기능에 대해 살펴 보도록 하자
– 엔터프라이즈 커널 버전 관리 방안
시스템을 관리 하다보면 보안이나 성능 이슈에 의해 여러개의 커널 버전을 가지고 시스템
을 유지하게 된다. 여러개의 커널 버전을 관리하는 방법과 커널 컴파일 후 신규 커널 적용
시 유용한 기술에 대해 알아보도록 하자
– 리눅스 커널 패치 파일 만들기
리눅스 신규 커널이 나올때 마다 엔터프라이즈 패치를 한다면 매번 작업에 번거로움이
생길것이다. 해당 시스템에 적절한 커널 소스 튜닝 방안이 정해지면 해당 수정 내용을
패치 파일로 만들어 패치 적용 방식으로 관리하면 편리하다 여기서는 커널 패치 파일을
만드는 방법과 해당 패치 파일을 신규 파일에 적용하는 방법에 대해 살표 보도록 하자.
1.6 운영체제 설치 후 중요 데이터 백업 정책
시스템 엔지니어의 가장 비중 높은 역활 중의 하나로 시스템을 언제나 정상적인 서비스
가능 상태로 유지하는 임무가 있습니다. 하지만 사용자의 실수나 외부의 악의적인 행위
에 의해 중요한 데이터의 손실이 발생하게 되고 실제 서비스의 문제가 발생하는 경우가
생깁니다. 백업은 실제 문제 발생 시 정상적인 서비스 상태로 복구를 시키는데 있어 가장
중요한 역활 중에 하나입니다. 하지만 엔지니어의 입장에서는 “문제가 발생하니 복구했다”
라는 가시적인 엔지니어 역활에 대해 논하기 전에 여러가지 상황으로 나타날수 있는 문제에
대해 얼마나 빨리 정상적인 서비스로 복구 시킬 수 있는 방법에 대해 고려를 해야 할것입니다.
백업은 크게 나아가 시스템의 가용성에 중요한 척도로 작용하는 요소로 의미를 가집니다.
백업의 방식에 따라 문제 발생 상황 시 서비스 동작에는 영향을 미치지 않게 할수도 있고,
서비스에 문제가 발생하더라도 수 초 에서 수 분 사이에 복구가 가능하게 할수도 있습니다.
하지만 백업에 관련된 비용은 항상 실제 서비스 외 비용으로 작용하기 때문에 엔지니어
입장에서는 본 서비스의 중요성과 구축 비용을 고려하여 상황에 맞는 백업 방식을 설계해야
할것입니다.
이 장에서는 1차 백업에 해당하는 로컬 데이터 백업과 3차 백업에 해당하는 원격 데이터 백업
에 대해 살펴 보도록 할것입니다.
시스템의 고가용성 백업 방식은 이 후 엔터프라이즈 리눅스 서버 구축 및 운영의 고가용성
시스템 구축 부분에서 다루도록 할 것입니다.
1.6.1 로컬 데이터 백업 및 복구 방안
로컬 데이터 백업은 자체 시스템 내에서 중요한 데이터를 다른 디스크 장치에 백업을 하는
방식을 의미한다. 로컬 데이터 백업은 시스템 가용성 단계의 첫번째 단계로 사용자의 부주의
나 서비스 디스크의 문제 발생 시 최대한 신속히 시스템을 복구 시킬 수 있는 방법 중에
하나로 저렴한 비용으로 백업을 진행할 수 있다. 로컬 데이터 백업 방식은 RAID 장치를 이용
하여 디스크 미러링 방식으로 구성할 수도 있지만 별도의 하드디스크나 백업 미디어를 통해
주기적으로 데이터를 백업 하는 방식을 주로 사용한다.
데이터 백업에 주로 사용하는 명령은 tar, gzip, bzip 등이 있는데 tar 는 시스템 파일과
디렉토리 구조를 하나의 파일로 통합해 주는 명령이고 gzip, bzip은 시스템 데이터를 압축
하는 역활을 한다.
이 명령과 별도의 자동화 스크립터를 통해 백업 스케줄링을 만들어 놓으면 관리자의 설계에
따라 시간별, 날짜별, 요일별 백업이 가능하다.
백업의 시점과 주기는 시스템의 성능에 밀접한 관계가 있기 때문에 로컬 데이터 백업의 경우
시스템의 백업 시간을 서비스가 주로 진행되는 시간에서 멀리 하여야 한다. 백업에 사용되는
시스템 리소스로 인해 서비스에 사용되는 시스템 리소스가 줄어들기 때문에 현 시스템의 백업
시점은 서비스 요청이 가장 적은 시기에 행해져야 할것이다.
그럼 간단한 예제를 통해 백업 명령어의 사용법에 대해 알아보도록 하자.
예제 )
# cd /backup
# tar cvpfz /backup/home.tar.gz /home –exclude=/home/test
위의 명령에서 사용한 옵션에 대해 하나씩 알아보도록 하자.
먼저 백업파일은 /backup 이라는 디렉토리에서 생성하기를 원하므로 /backup 으로 이
동한후 tar 명령을 이용해 백업을 시작한다.
“c” 는 Create a new archive 의 뜻으로 백업시 새로운 파일을 생성하며
”v” 는 Verbosely list files processed 의 뜻으로 백업시 백업이 진행되고 있는 상황
및 디렉토리 리스트를 보여주며
“f” 는 archive file is local 의 뜻이며 명령어 이후의 이름이
생성될 파일의 이름이라는 뜻이며
“p” 는 Preserve-Permissions 의 뜻으로 이전 데이터의 Permission 정보를
그대로 보존한다는 뜻이며
“z” 는 filter the archive through gZip의 뜻으로 gzip 으로 압축한다는 뜻이다.
일반적으로 tar로 백업시 사용되는 확장자 규칙은 압축되지 않고 단순히 하나의 파일로
패킹(packing) 한 파일의 경우에는 “tar” 를, gzip 으로 압축된 파일의 경우에는
”tar.gz” 나 “tgz” 를 확장자로 한다.
따라서 확장자가 home.tar.gz 나 home.tgz 일 경우 tar 로packing
(즉 단순히 하나의 파일로 묶기만 함) 된후 gzip 으로 압축되었음을 뜻한다.
위 예제) 와 같이 실행했을 경우 /backup 디렉토리에 /home/test 이하를 제외한 /home의
나머지 모든 파일과 디렉토리를압축하여 home.tar.gz 란 파일로 백업하게 된다.
tar 의 경우 파일을 묶을 때 디렉토리 구조에 의해 하위 디렉토리를 모두 묶는 특성이
있기 때문에 백업 예외 디렉토리나 파일이 존재 할 경우 –exclude 란 옵션을 이용하여
백업 대상에서 제외 시킬 수 있다.
이것은 거대한 백업 대상이 존재 할 경우 선별적으로 꼭 필요한 데이터만을 백업하여
백업 시간의 단축 및 백업으로 인한 디스크 수명 연장등에 의미가 있다.
실제 여러명의 사용자가 존재하는 시스템에 사용자 데이터는 대부분 /home 이란 디렉토리
밑에 존재 하게 되는데 실제 백업의 필요가 있는 사용자와 백업이 필요없는 사용자가 있을
것이다. 혹은 백업이 필요한 파일 속성을 가진 데이터와 백업이 필요 없는 파일 속성을
가진 데이터가 하나의 디렉토리 안에 존재 할때 위의 방식을 이용하여 백업 스크립터를
제작하여 운영하면 보다 효율적인 1차 백업 설계를 할 수 있을 것이다.
이밖에 하나의 백업 파일의 크기가 수십기가바이트 이상으로 만들어 질 경우 백업을 하거나
복구 할때 시스템에 엄청난 무리를 주기 때문에 백업 시 하나의 백업 파일 크기에 제한을
두는 것도 중요할 것이다.
실제 /home 밑의 데이터가 50G 정도 된다고 할때 하나의 파일로 백업을 하게 되면 파일 속성
에 따라 압축율은 다르겠지만 그래도 2~30Gbyte 크기의 파일이 생성 될것이다.
이는 나중에 특정 파일 하나를 복구 할때 2~30Gbyte 에 해당하는 백업 파일의 압축을 풀어야
하는 부담을 가지게 됨으로 초기 설계 시 분할하여 백업 정책을 세워야 할것이다.
예를 들면..
# tar czvfp home_a_h.tar.gz /home/[a-h]*
# tar czvfp home_i_p.tar.gz /home/[i-p]*
# tar czvfp home_q_z.tar.gz /home/[q-z]*
와 같이 /home 및의 사용자 홈디렉토리를 3등분하여 3개의 백업 파일로 분할할 수 있을 것
이다. 시스템 환경에 따라 위와 같은 선별적인 백업 방식을 설계 시 잘 응용하면 보다 효율
적인 백업 시스템을 구축 할 수 있을것이다.
– 전체(Full) 백업 방식
실제 시스템에서 간단한 백업 스크립트 예제를 만들어 보도록 하자.
————————————————————————————
#!/bin/sh ……………… (1)
cd /backup ……………… (2)
rm -f *.tar.gz ………………. (3)
tar czvfp apache.tar.gz /usr/local/apache/* …….. (4)
tar czvfp home.tar.gz /home/* –exclude=/home/test …….. (5)
tar czvfp etc.tar.gz /etc/* ……….. (6)
tar czvfp mail.tar.gz /var/spool/mail/* ……….. (7) ,
chown backup.backup *.tar.gz ………….. (8)
chmod 700 *.tar.gz ………….. (9)
ls -alh | mail -s www_backup_report backup@clunix.com …….. (10)
df -sh | mail -s www_df_report backup@clunix.com ………. (11)
————————————————————————————
(1) 번은 시작되는 내용이 Shell Script 임을 정의한다.
(2) 백업작업이 이루어지는 파티션인 /backup 으로 이동한다.
(3) 새롭게 백업을 하여아 하므로 기존의 백업된 파일을 모두 삭제한다.
(4) – (7) 번까지는 백업을 해야 할 디렉토리 이하에 대해 데이터를 각각 백업한다.
(8) 백업된 파일의 소유권을 backup 으로 설정한다.
(9) 백업된 파일의 권한을 700 으로 설정한다.
(10) 백업이 제대로 되었는지 확인하기 위해 현재의 디렉토리내 백업 파일의 리스트등의
정보를 백업담당자인 backup@clunix.com 에게 메일로 발송한다.
(11) 혹 파티션이 가득 찰수도 있으니 현재의 파티션 사용 정보를 백업담당자에게
메일로 발송한다.
별도의 설명이 필요하지 않을 정도로 간단한 스크립트이다.
Shell 스크립트는 실행되어야 할 명령어를 순서대로 나열하기만 하면 된다.
위 예에서는 Full Backup을 보여주고 있는데, 필요에 따라 적절히 “증가분 백업” 도 이용
하기 바란다. 증가분(변경분) 백업은 풀백업을 받은 후 기존의 백업 데이터와 비교하여
이미 백업된 이후 변경되거나 추가된 부분만 백업하는 방식이다.
– 증가분 백업 방식
먼저 위 예제 예제 형식의 Full 백업 스크립터 제일 하단에 아래 구문을 추가한다.
-> echo `date +”%Y-%m-%d”` > FULL_BACKED_DAY
# /root/bin/fullbk.sh
———————————————————————————-
#!/bin/sh
cd /backup
rm -f *.tar.gz
tar czvfp home.tar.gz /home/*
chown backup.backup *.tar.gz
chmod 700 *.tar.gz
ls -alh | mail -s www_backup_report backup@clunix.com
df -sh | mail -s www_df_report backup@clunix.com
echo `date +”%Y-%m-%d”` > FULL_BACKED_DAY
———————————————————————————–
그런 후 아래 스크립터 구문을 실행하면 위 스크립터로 인해 백업된 이후 새로 생성되거나
변동된 데이터만 백업을 하게 된다.
# /root/bin/modbk.sh
———————————————————————————–
#!/bin/sh
cd /backup
TODAY=`date +”%Y-%m-%d”`
PREVIOUSDAY=`cat FULL_BACKED_DAY`
tar czvfpG ${TODAY}_modified_home.tgz -N “$PREVIOUSDAY” /home
———————————————————————————–
그런 후 Cron을 이용하여 백업 스케줄링을 정의 하면 될것이다.
# crontab -e
———————————————————————————–
0 3 * * 0 /root/bin/fullbk.sh
0 2 * * * /root/bin/modbk.sh
———————————————————————————–
# /etc/rc.d/init.d/crond restart
위와 같이 Cron 설정을 해 두면 매주 일요일 새벽 3시에 /home 디렉토리의 전체 백업이
진행 될것이다. 그리고 매일 새벽 2시에 전체 백업에서 변동된 데이터만을 선택적으로
백업을 할것이다.
이와 같은 방식으로 백업을 진행할 경우 매일 전체 백업을 해야 하는 경우보다 적은 리소스
로 빠른 백업 및 빠른 복구가 가능할 것이다.
1.6.2 원격 데이터 백업 및 복구 방안
로컬 데이터 백업의 짧은 주기의 정기적인 백업과 부분 문제 발생 시 신속한 복구를 위해
행하는 백업의 성격이 강하다. 하지만 로컬 시스템의 디스크 용량의 제한 문제로 인해
특정 시기에 백업한 데이터를 오랜 시간 보간할 수 없는 단점이 있다. 관리자의실수로 인해
백업 디스크나 데이터에 손상이 가거나 삭제가 되었을 경우, 혹은 로컬 시스템 자체가
물리적 ( 화재, 테러 )으로 손상이 갈 경우 그 문제의 심각성을 말로 표현하기 힘들것이다.
그렇기에 반드시 시스템 엔지니어는 초기 백업 설계 당시 다양한 백업 방안을 고려해야
한다. 원격 데이터 백업은 흔히 3차 데이터 백업이라 한다.
1차 데이터 백업은 실제 로컬 디스크 백업에 해당하고 2차 데이터 백업은 시스템 이중화 혹은
High Availability 시스템 구축에 주로 사용되는 미러링 기술로 백업과 동시에 서비스 고가용성
까지 고려한 백업 방식에 해당하고 3차 백업 방식은 흔히 물리적으로 다른 매체를 통한 백업
을 의미한다. 실제 지역적이나 물리적으로 다른 백업 시스템에 일정 주기로 원격 백업을
하게 되면 위의 제시한 여러가지 문제 사항에 대한 피해를 최소화할 수 있을 것이다.
원격 데이터 백업에 사용되는 방법은 여러가지가 존재 하지만 여기서는 실제 공개된 기본
기술을 이용하여 손 쉽게 사용할 수 있는 방법에 대해 소개하도록 하겠다.
흔히 원격 백업에 사용되는 기술로는 FTP를 이용한 원격 백업, Rsync를 이용한 원격 백업,
그리고 공개 인증키를 이용한 scp 백업등이 있다.
위 세가지 유형에 대한 백업 방법에 대해 간단한 예제를 제시하도록 하겠다.
– expect 를 이용한 FTP 백업 방법
# vi /root/bin/ftpbk
———————————————————————————
spawn ftp www.domain.com …………(2)
expect “Name :” …………..(3)
send “backup\\r” ………….(4)
expect “Password:” …………(5)
send “123456\\r” ………….(6)
expect “ftp>” ………..(7)
sleep 1 ………… (8)
send “bin\\r” …………(9)
expect “200 Type set to I.” …………(10)
sleep 1 ………..(11)
expect “ftp>” ………..(12)
send “get /backup/home.tar.gz /data/www/data_home.tar.gz\\r” ……….(13)
expect ” Kbytes/sec)” …………(14)
sleep 1 ………..(15)
expect “ftp>” ………….(16)
send “quit\\r” ………..(17)
expect “221 Goodbye.” …………(18)
interact ………….(19)
———————————————————————————
(1)먼저 expect 스크립트라는 것을 정의한후
(2)백업을 받으려는 서버인 www.domain.com 에 ftp로 접속한다.
(3)”Name :” 이라는 응답이 오기를 기대(expect)한다.
(4) 데이터 서버에 접속하기 위해 username 인 backup 을 입력후 엔터를 입력한다.
(5) username을 입력했으므로 Password: 라는 반응이 오기를 기다린다.
(6) username 에 해당하는 암호인 tomorrow를 입력한다.
(이 부분은 각자의 환경에 따라 다를 것이다)
(7) ftp> 라는 반응이 오기를 기다린다.
(8) 1초간 대기를 한후
(9) binary 로 전송을 받아야 하므로 bin 입력을 한다.
(10) 서버로부터 200 Type set to I 라는 반응이 오기를 기다린후
(11) 1초간 대기를 한후
(12) ftp> 라는 반응이 오기를 기대(expect) 한후
(13) 원격지 데이터 서버의 /backup/home.tar.gz 란 백업 데이터를 백업서버의
/data/www/ 란 디렉토리에 data_home.tar.gz 라는 파일로 저장한다.
(14) 사버로부터 Kbytes/sec) 라는 메시지가 출력되면
(15) 1초간 대기를 (sleep)한 후
(16) ftp> 메시지가 오기를 기다린 후
(17) quit를 입력하여 접속을 끊고
(18) 221 Goodbye 메시지가 나오기를 기대한 후
(19) 이후 명령어입력 정보를 기다린다.
만약 전송받는 파일의 사이즈가 클 경우에는 sleep 1 대신에
set timeout -1 를 지정하여야 정상적으로 ftp 전송이 가능하다.
Expect를 이용한 FTP 백업의 경우 실제 ftp 란 프로그램으로 ftp 접속을 하여 백업된
데이터를 다운 받는 과정을 자동화 시키는 방식으로 다소 복잡할 수도 있다.
이밖에 ncftpget 을 이용한 보다 간단한 방법도 있다.
# vi /root/bin/ncftpbk
————————————————————————————-
#!/bin/sh
ncftpget -u backup -p ‘123456’ www.domain.com \\
/data/www/data_home.tar.gz /backup/home.tar.gz
————————————————————————————
FTP를 이용한 백업 방법의 장점은 빠른 네트워크 백업이 가능하다는 점이다. 네트워크
전송 효율이 가장 놓은 FTP 프로토콜을 이용하여 백업을 하기 때문에 빠른 시간 내에
많은 데이터를 백업할 때 효율적이다. 하지만 파일 단위로 다운이 되기 때문에 증감 백업
과 같은 복잡한 백업 스케줄링을 설계할 경우에는 비효율적인 부분이 많을 것이다.
– Rsync 를 이용한 원격 백업 방법
rsync를 이용한 백업 방법은 이중화 시스템 구축 시 데이터 동기화 방식으로 많이 사용
되며 실제 3차 백업에서도 FTP 에 비해 다양한 백업을 지원하기 때문에 선호하는 방식
중에 하나이다.
이런 Rsync 의 고급 기능을 이용하여 데이터를 동기화하는 내용은 이후 고가용성 시스템
구축 부분에서 상세히 다루도록 하겠다.
여기서는 원격 백업에 대한 부분만 설명하도록 하겠다.
Rsync 패키지는 다음 사이트에서 다운 받을 수 있다.
http://rsync.samba.org/ftp/rsync
먼저 서비스 서버의 /etc/xinetd.d/rsync 파일을 설정한다.
# vi /etc/xinetd.d/rsync
———————————————————————-
service rsync
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = –daemon
log_on_failure += USERID
}
———————————————————————-
# /etc/rc.d/init.d/xinetd restart
그런 후 /etc/rsyncd.conf 설정 파일에 백업 대상 디렉토리의 정보를 설정한다.
# vi /etc/rsyncd.conf
———————————————————————–
[backup]
path = /backup
comment = www 웹서버
uid = root
gid = root
use chroot = yes
read only = yes
hosts allow = 210.47.67.1
max connections = 1
timeout 600
————————————————————————
backup] : 서비스명
path : 전송될 data가 들어 있는 경로
uid : data 를 전송하는 사용자의 uid 기본값은 nobody
gid : data 를 전송하는 사용자의 gid 기본값은 nobody
use chroot : path를 root 디렉토리로 사용. 보안상 필요함.
read only : 읽기전용
(클라이언트에서 서버로 올리는 경우에는 read only= no 로 설정을 해야됩니다. )
hosts allow : 호스트별 접속허용. 기본값은 all host이므로 보안을 유지하
려면 반드시 설정함
max connections : 동시접속자수.
timeout : 클라이언트에서 접근시 타임아웃시간.
anonymous 로 운영하는 경우 설정을 해야 클라이언트가 죽었을 때 서버에서 접속을
해체할 수 있습니다.
이로서 서비스 서버에 대한 설정이 완료되었다. 아래의 실제 백업 서버에 다음 스크립터
를 만들도록 한다.
# /root/bin/rsyncbk
————————————————————————–
#!/bin/sh
/usr/bin/rsync -avz data.domain.com::backup /data/www
————————————————————————–
3차 백업의 좀더 효율적인 백업을 위해서는 서비스 서버에 이더넷 카드를 2장을 설치하여
백업 전용 네트워크 채널을 분리 하는 방식을 사용하면, 원격 네트워크 백업에 사용되는
네트워크 리소스를 서비스 대역과 분리 시켜 실제 서비스 활당 리소스를 최대한 보장될수
있도록 한다.
1.7 긴급 발생 문제 해결 및 주요 관리 이슈
파일 시스템이 깨졌거나 해킹등의 문제로 정상 부팅이 안되는 경우 복구 방법 입니다.
실제 리눅스 커널로 부팅을 하는 것이 가장 중요하다. 부팅을 해서 시스템 상태를 점검
해야 이 다시 설치를 할지 아님 일부 중요 파일의 백업을 이용하여 복구를 할지 결정이
가능하다. 먼저 시스템 부팅이 안된다. 이제 부팅을 시켜 보자
– 긴급 부팅 시키기
1장에서 설정한 bootloader 설정 내용도 참조하세요.
** Linux 배포 CD를 통한 부팅
단 이때는 기본적으로 시스템의 하드의 파티션 중 / 파티션의 디바이스 명을 알고
있어야 한다. 1장에서 언급한바와 같이 그래서 초기 셋팅 후 시스템 정보를 보관하
는것은 상당히 중요하다.
Linux Install CD 를 넣고 부팅 한다. boot 프롬프트에 다음내용을 기재한다.
boot : linux initrd= root=/dev/hda2 -> /dev/hda2 가 실제 / 파티션의 device name
이는 Linux Install CD 에 있는 기본 커널로 시스템을 부팅하여 현 시스템의
root mount point ( / ) 에 접근하는 것이다.
이경우는 IDE 하드에 리눅스가 설치 된 경우 주로 사용한다. SCSI 의 경우 Install CD
커널에 SCSI 모듈 정보가 포함안되어져 있어서 root device 를 못찾는다면서 실패할
가능성이 많다.
주로 Lilo 가 깨졌을때 많이 사용한다.
** rescue mode booting
역시 Linux Install CD 를 이용하여 부팅할때 boot 프롬프트에서 rescue 라는 옵션과
같이 부팅
boot : linux rescue
그럼 text 설치 과정과 비슷하게 넘어가다가 bash prompt ( # ) 바로 떨어진다.
하드디스크에 크게 문제가 없을 경우에는 /mnt/sysimage 폴더에 system root 파티션이
mount 되어져 있을것이다.
# chroot /mnt/sysimage
하면 마치 정상적으로 부팅 한것 처럼 mount 가 되어진다.
이상태에서 정검하면 됩니다. 진짜 중요한 파일에 문제가 있어 이것이 안된다고 하면
수동으로 mount 하여 중요파일의 손상 정도를 파악한다.
rescue 방식은 주로 SCSI 하드 디스크 일 경우 많이 사용함.
주로 Lilo 깨졌을때, 파일 시스템 깨졌을때, 완전히 망가 졌을 때
** single mode 로 부팅하기
파일 시스템에 문제가 발생하여 파일 시스템을 체크하기 위해 부팅하는 모드로 LILO
Prompt 가 뜨면 ..
Lilo : linux single
위와 같이 부팅한다. 그런 후 안정스럽게 파일 시스템을 점검 및 복구 한다.
이밖에 파일 시스템 복구 목적으로 긴급 부팅 하는 방법으로는
lilo: linux init=/bin/sh
도 있다.
– 부팅 디스켓 만들기
먼저 부팅디스켓으로 사용할 커널 이미지를 선택한다.
그리고 선택한 커널 이미지가 root 장치(root mount point)가 재대로 잡혀 있는지
확인한다.
# rdev /boot/vmlinuz
Root device /dev/hda1
만일 루트 장치가 현재 잡혀 있는거랑 틀리다면 아래와 같이 수정한다.
# rdev /boot/vmlinuz /dev/hda3
#
이제 깨끗한 플로피 디스켓 하나 준비하고 포맷한다.
# fdformat /dev/fd0
# dd if=/boot/vmlinuz of=/dev/fd0 bs=8192
– 일반유저에게 장치 mount 허가하기
특정 장치를 일반유저에게 mount/umount 하게 해주기 위해서는 /etc/fstab 에서
허가할 장치의 옵션에 user 이란 옵션을 추가 해 주어야 한다.
혹은 mount/umount 명령어의 퍼미션을 setuid 로 해주어도 가능하다.
– 파일 시스템 만들기
mkfs 명령어 사용
# mkfs -t ext2 /dev/hdb1
# mkfs -t ext2 /dev/fd0
플로피 파일 시스템 만들기
# fdformat /dev/fd0
# mkfs -t ext2 -c /dev/fd0 -v
-c : 블럭체크
-v : 진행과정 display
– 파일시스템 점검 수리
# fsck -t [type] [device]
fsck 파일 점검은 가능한 umount 한 후에 실행한다. 하지만 / 을 mount 하지 않은
면 당근 부팅이 제대로 될수 없기에 / 를 체크할때는 플로피로 부팅을 하던지 아님
single mode 로 부팅한후 체크 한다.
체킹후 mount -t -w -o remount /
해주면 된다.
– 긴급 스왑 메모리 추가 하기
# touch /swap
# dd if=/dev/zero of /swap bs=1024 count=8192
# sync
# mkswap -c /swap 8192
# swapon /swap
하면 8M 의 스왑메모리를 추가 할수 있다.
이밖에 여유공간에 파티션을 나누고 /etc/fstab 에 추가 해 주어도 가능하다.
– RPM 패키지 상태 초기화 하기
누가 해킹 혹은 실수로 RPM 패키지의퍼미션이나 권한등을 변경하여 정상적인 작동을 안할 경우
이를 설치 시 상태로 복구 하는 방법이다.
# rpm –setperms -a
이로써 실무 환경을 고려한 엔터프라이즈 리눅스 운영체제 설치에 대한 교육 과정을 마치도록
하겠습니다.
