철학이 있는 리눅스 운영체제 설치 관리하기
철학이 있는 리눅스 운영체제 설치 관리 하기
======================================================
작성일 : 2005년 1월 1일
작성자 : 시스존/서진우 (alang@syszone.co.kr)
======================================================
1. 실무 환경을 고려한 엔터프라이즈 Linux 운영체제 설치
시스템 엔지니어링 분야의 시작과 끝이 있다면 그것은 운영체제 관련 분야입니다.
운영체제의 설치 자체 기술은 엔지니어 분야의 시작 시 다루는 기술이지만 실제
운영체제의 설치 의미는 설치 자체에 있기 보다는 운영체제를 설치 하는 시스템의
서비스 성격과 운영 정책을 사전에 고려 하여 운영체제 설치 계획을 세워야 합니다.
운영체제의 설치는 그 설치 방식에 따라 성능, 보안, 안정성, 시스템 가용성 등의
시스템 전체 성능이 좌우 됩니다. 기초 설치 문서나 서적에 의해 설치를 한다면
실제 서비스 자체 환경 구현은 가능 하겠지만, 최적의 성능이나 시스템 보안 레벨
시스템 회복 능력, 시스템 관리상의 효율성 등에서 실무 서비스 환경을 고려한
운영체제와는 큰 차이를 보일 것입니다.
여기서는 실무 환경에 맞는 운영체제 설치를 하는데 고려 해야 할 사항과 실제
운영체제 설치 이후 설치 방식에 따라 이후 관리에 어떤 차이가 있는지, 그리고
안정적인 시스템 환경 유지를 위해 설치 이후 어떤 작업등이 필요한지에 대해
설명하도록 할 것입니다.
1.1 설치 전 고려 사항
– 파티션 정책
자동파티션 설치를 선택하면 기본적으로 /boot, /, swap 3개의 파티션으로 자동
할당 되어 진다. 하지만 정식 서비스를 위해서는 가지고 있는 하드디스크를 계산하여
성능 및 보안등을 고려하여 현 서비스에 가장 적절한 정책을 세워야 한다.
Linux의 대표 파티션들은 모두 보안적인 측면이나 성능적인 측면에서 의미를 부여
하고 있다. Linux의 대표적인 파티션을 살펴 보면 다음과 같다.
/boot
/
/etc
/home
/usr
/usr/local
/tmp
/var
swap
각 대표적인 모든 파티션을 다 나누어 설치를 하게 되면 가장 안정적 일수 있지만
제한된 하드디스크로 모든 파티션을 나누게 되면 각 파티션에서 사용할 수 있는
용량이 고정되어 버리기 때문에 실제 서비스 도중 특정 파티션에 용량이 초과할
경우 추가 하드 디스크를 사용해야 하는 경우가 발생하기 쉽다.
뿐만 아니라 많은 파티션을 나누어 놓게 되면 성능 면에서는 Disk i/o를 분산 시
킬 수 있어 바람 직 할 수 있지만 관리 측면을 고려 해 본다면 필요에 의한 적절한
파티션 분배가 이루어 져야 할 것이다.
각 파티션 별로 그 의미에 대해 알아보자.
/boot:
/boot 파티션은 Linux 부팅에 관련된 파일이나 이미지들이 모여 있는 파티션이다. 만일 /boot 파티션을 나누어 놓은 경우는 크게 세 가지 의미가 있다.
첫째는 안정성이다. 실제 /boot 파티션을 나누지 않고 그냥 / 에 포함 시킬 경우 시스템이 과도한 사용이나 해킹 등의 이유로 / 파티션이 망가질 경우 실제 / 포함된 /boot Directory의 booting image 들 역시 깨어질 위험성이 크다. /boot 가 나누어져 있을 경우 / 가 망가지더라도 새로운 / 파티션을 만들고 /boot 에 있는 부팅 이미지를 가지고 어느 정도 까지는 복구가 가능하다.
둘째는 기능성(?)이라 볼 수 있다. 실제 /boot 에 들어 있는 kernel image 가 즉 Linux OS 라 볼 수도 있다. 만일 당신이 개발자나 Linux 전문 엔지니어라서 여러 개의 배포 판을 설치 할 경우 각 배포 판 마다 /, swap 등의 파티션을 별도로 나누어서 설치해야 하는 어리석음을 갖지 말길 바란다. 실제 배포 버전 별로 /boot 파티션을 나누어 준다고 하면 각각의 다른 Linux 배포 판을 설치 하고도 실제 /etc /usr/local 등에 있는 설정이나 패키지를 통합해서 관리 할 수가 있다.
셋째는 Linux OS의 boot loader의 기능적인 제한 때문에 /boot를 나누는 경우가 많다. Linux의 대표적인 boot loader로 Lilo 가 있는데 이는 실제 1024 실린더 밖에 설치 될 경우 치명적인 에러가 발생한다. 그래서 대부분이 하드디스크의 MBR 영역에 설치를 하게 되는데 만일 MBR 에 다른 boot loader를 설치하고 Lilo는 Linux 파티션의 첫 번째 파티션에 설치를 한다고 할 때 /boot 파티션을 첫 번째 파티션으로 만들어 이곳에 Lilo를 설치 할 수 있다.
/ :
루트 파티션은 실제 Linux 파티션의 최 상위 파티션으로 실제 / 파티션과 Swap파티션만으로도 Linux를 설치 하여 서비스를 할 수도 있다. 하지만 이렇게 설치를 하게 되면 앞에서 언급하였고 뒤에서 설명하는 바와 같이 부적절한 상황을 초래하기 쉽다. 일단 Kernel 이미지에서 실제 / 파티션을 찾아서 / 파티션을 최상위로 해서 하위의 파티션들을 찾기 때문에 / 파티션이 없으면 Linux를 부팅 시킬 수 없게 된다. 아래에서 설명하는 바와 같이 여러 개의 파티션을 나눌 경우 실제 별도의 파티션을 나누지 않는 상위 Directory들이 모두 이 / 파티션 안에 포함 되게 될 것이다.
이 경우 대표적으로 보안적인 측면과 성능 측면에서 문제가 발생 할 수 있다. 즉 외부 적으로 흔히 공격에 사용되는 /tmp, /dev 가 /root 안에 포함 되어 있을 경우 해당 Directory에 불필요한 파일을 무작위로 생성해서 Disk Full 상태로 만들어 서비스에 영향을 주는 경우가 많이 존재 한다.
또한 실제 어플리케이션이 구동되는 /usr, /usr/local 등이 / 파티션에 포함되어 있으면, 운영체제 자체 구동에서 사용되는 디스크 I/O 와 사용자 어플리케이션에서 사용되는 DISK I/O 가 물리적으로 같은 볼륨에서 발생 하기 때문에 전체적인 시스템 성능이 저하 되게 된다.
/etc :
/etc 는 Linux 시스템의 모든 설정 파일이 모여 있는 Directory이다. 만일 /etc를 / 파티션에 포함한 경우 변수에 의해 / 파티션이 깨어진 경우 별도의 백업이 없으면 관리자로써 상당히 난처한 상황에 빠지게 된다.
즉 아무리 데이터를 백업을 하고 있다 하더라도 설정 파일이 없으면 서비스를 구동 할 수 없게 된다. 그렇기 때문에 /etc를 별도의 파티션으로 나누는 것도 고려해야 할 것이다. 하지만 /etc 의 용량은 매우 작기 때문에 백업만 적절히 한다고 하면 굳이 나눌 필요는 없다. 파티션이 너무 많이 나누어 지면 관리측면에서 부적절 할 수도 있다.
/usr :
/usr 는 실제 Redhat Linux의 RPM 패키지가 설치되는 파티션이다. 이 파티션을 나누는 이유는 크게 성능과 패키지 관리 측면에서 볼 수 있다. 일단 Redhat Linux의 모든 프로그램이 이곳에 설치가 된다고 볼 수 있다.
즉 서비스 구동 시에 프로그램 성능에 가장 큰 영향을 주는 파티션인 만큼 다른 Disk i/o 과 많은 다른 파티션과 동일 파티션으로 구성하면 성능에 많은 지장을 주게 된다.
관리 측면으로 보면 최근 배포 판 버전으로 업그레이드를 하고자 할 때 /usr 파티션이 나누어져 있을 경우 설치 시 /usr 파티션만 새로 포맷하고 새 패키지를 설치하면 실제 redhat 7.3 에서 redhat 9 로 업그레이드를 한다고 해서 서버의 모든 자료를 백업하고 새로 OS 설치 후 복구하는 수고를 들 수 있다.
/usr/local :
/usr/local 는 응용프로그램을 Source 로 설치 할 경우 파일이 위치 하는 Directory 이다. 기본적으로 배포 판의 패키지는 기본적이 서버 구성에 해당하는 패키지만 설치 하고 나머지는 모두 Source 설치 하는걸 권장 한다. Linux 배포 판의 패키지를 무 분별하게 설치 할 경우에는 보안/ 관리 측면에서 상당히 부적절 할 수 있다.
그러므로 최소 설치 후 필요한 프로그램을 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 는 로그 및 메일 queue 등이 쌓이는 곳이기 때문에 해커들이 고의적으로 시스템에 나쁜 코드를 심어 놓거나 mail 서버의 spam를 무수히 보냄으로 해서 /var의 디스크 용량이 커지는 경우가 발생한다. 이때 /var의 파티션이 나누어 있지 않는 경우 실제 / 파티션의 disk 용량이 가득 차게 되고, 이로 인해 / 파티션의 중요한 파일들이 손상을 입게 된다. 이런 일들을 방지 하기 위해서도 /var 파티션을 나누는 것을 권장한다.
이밖에 해커들이 / 파티션을 공격하여 시스템을 깨어버린다 하더라도 실제 /var 파티션이 나누어져 있으면 이런 해커의 작업등이 시스템 로그에 남게 됨으로 시스템은 망가졌지만 이후 /var 의 로그를 이용하여 시스템에 무슨 문제가 있었는지를 확인할 수도 있다.
/tmp :
/tmp 는 실제 시스템 서비스가 가동될 때 임시 파일이나 세션 파일들이 생기는 곳 이다. 보통 nobody 권한의 파일들이 생김으로 해서 보안이 약한 곳이라 볼 수 있는데 해커들이 주고 이 /tmp 를 통해 원격지에서 시스템을 공격하는 경우가 많다. 그러므로 해서 해커의 공격을 받더라도 /tmp Directory만 영향을 받게 하기 위해 파티션을 분리 하는 것을 권장한다.
swap :
swap 은 물리적인 메모리가 부족한 경우 하드디스크를 메모리처럼 사용할 수 있게 하는데 이용되는 파티션이다. 보통 시스템의 물리적인 메모리의 1.5배에서 2배로 잡는 것이 정석이다.
시스템의 주요 사용 용도 중에 매우 큰 용량의 파일을 다루는 작업일 경우 보통 swap 을 크게 잡아야 한다. 대표적으로 Oracle 의 경우 보통 DB file 하나가 작게는 500M 에서 크게는 2Gbyte 정도 하고, SGA 메모리 영역을 실제 물리적 메모리의 50% 이상을 할당하여 사용하는 경우가 대부분이다. DB 엔진에서 대용량 메모리에 이 대량의 작업을 올려 놓고 작업을 하게 되는데 실제 물리적 메모리가 1.5 G 일 경우 swap 이 없는 경우에는 작업을 할 수 없게 되거나 paging 이 일어나 성능이 급속 하게 저하 된다. 이를 방지하기 위해서 서비스에 이용되는 메모리 수치를 예상하여 swap 을 잡으면 된다.
swap 은 상황에 따라서 여러 가지 방법으로 추가 할 수 있기 때문에 초기에는 권장 방법대로 1.5배에서 2배 정도로 잡으면 된다.
– 최신 하드웨어 드라이브 패치
하드웨어의 발전 속도가 운영체제의 발전 속도를 앞선지는 벌써 몇 해가 되어가고 있다. 그러므로 운영체제 배포 CD에는 이후 출시된 하드웨어 인식 드라이브가 누락되어 최신 하드웨어를 가진 시스템에 운영체제 설치 시 문제가 발생하는 경우가 종종 발생한다.
이런 대표적인 문제를 발생하는 하드웨어로 SCSI Controller 와 Network Ethernet Card
들을 들 수 있다. 배포 CD로 운영체제를 설치 시 Network Ethernet Card 의 경우에는 크게
문제가 되진 않지만 SCSI Controller 의 경우에는 실제 운영체제를 설치할 하드디스크를
인식하지 못하여 운영체제 설치가 안 되는 경우가 발생한다.
이런 경우 Linux 운영체제에서는 설치 시 추가 하드웨어 드라이브를 인식하여 설치하도록
하는 방법이 제시되어 있다.
아래는 실무에서 흔히 발생하는 Adaptec SCSI Controller 문제를 해결하는 방법에 대해
설명한다.
최신 Ultra320 SCSI Controller 의 경우 기본 Redhat 지원 드라이버를 사용하면 i/o error를 발생 하는 경우가 있다. 대표적인 제품으로 Adaptec 의 AIC-29320 제품의 경우 그러함. 설치 시에 그냥 설치 하면 SCSI 장치 인식 중에 멈추어 버리는 증세가 발생한다.
boot : linux apic
와 같은 방식으로 부팅하면 장치는 인식하지만 Redhat 기본 Kernel에 있는 드라이버
로 서비스 가동 시에 조금 과도한 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 의 Kernel 이미지로 부팅을 진행하면서 하드디스크 혹은 기타 장치를
인식하기 전에 추가 드라이브 디스켓을 삽입하라는 Message 가 뜬다. 이때 위에서
만든 드라이브 디스켓을 삽입한다.
그러면 설치 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 를 통해 수동으로 파티션을 나눈 후 Redhat 기본 파일 시스템인 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의 swap 파티션 보다는 1G의 swap 파티션 2개가 I/O 분산으로 인해 성능이 좋기 때문이다.
OS 의 설치는 초보 엔지니어나 경력 엔지니어나 다 기본으로 하기 마련이다.
하지만 시스템 엔지니어의 시작이 OS 설치 라고 하면 마지막 역시 OS 설치라고 말할 수 있는 만큼 자신만의 설치 방법을 세워 두길 바란다.
– 패키지 정책
실제 OS 구동에 필요한 기본 프로그램 (부팅관련 프로그램, 라이브러리)은 배포 판에 있는 패키지를 선택하지만 서비스에 필요한 프로그램은 되도록이면 Source로 직접 설치 하는 것을 권장한다.
이는 패키지 관리 및 보안성격상에도 큰 의미를 가지고 있지만 시스템 성능에 미치는 영향도 크다
실제 배포 판은 대표적인 아키텍처에 해당하는 시스템에서 해당 프로그램을 build 하여 패키지를 만들어 놓은 것이다. 유사한 아키텍처를 가진 시스템에서 사용 하는 데 지장이 없지만 그래도 자기 시스템에 최적화된 프로그램을 사용하기 위해서는 실제 Source로 해당 시스템에서 직접 설치 하는 것이 좋다.
(이와 같은 패키지 관리를 한다고 하면 앞에서 설명한 바와 같이 /usr/local 파티션을
별도로 나누어 관리하는 것이 시스템 문제 발생하여 재 설치 시 오랜 시간이 소요되는
Source rebuilding 작업을 생략할 수 있게 된다. )
Redhat Linux에서의 패키지 선택은 기본적으로 패키지 선택 단계에서
/ 편집기 / DNS 서버 / 네트워크 서버 / 개발 도구 / Kernel 개발 /시스템 도구
정도를 기본 설치 하고 기타 서비스 관련 프로그램 및 기타 관리 도구는 필요한 프로
그램만을 수동으로 설치 하면 된다.
기본적으로 설치가 완료 된 후 부팅이 정상적으로 되는지와 부팅 시 에러 내용이 있는
지, 파티션이 정책대로 적용이 되었는지 등을 확인 합니다.
# dmesg -> 부팅 Message 확인
# df -h -> 파티션 별 용량 확인
1.3 Redhat Linux 운영체제 설치 후 추가 작업
정해진 버전의 배포 CD로 운영체제를 설치 하고 나면 몇 가지 추가 작업이 필요하다.
흔히 설치 시에는 별다른 문제가 없었는데 설치 이후 정상적인 부팅이 되지 않거나
부팅이 되더라도 시스템이 불안한 경우가 종종 발생한다. 이런 문제가 발생하는 경우
대부분이 실제 하드웨어 환경과 운영체제 설치 환경이 최적화 되지 않아서 발생하는
문제들이다. 여기서는 Linux 설치 이후 주요 발생하는 문제를 해결하는 방법과 안정적인
운영체제 환경을 유지 하기 위한 추가 작업들에 대해 설명하도록 한다.
1.3.1 설치 이후 주요 발생 문제 해결 방법
설치 직후 주요 발생하는 문제로는 당연 Boot Loader 에서 발생하는 문제를 들수 있다.
Boot Loader 란 운영체제의 버전을 관리하는 대표적인 프로그램으로 Linux에서는 주로
LILO 와 GRUB을 사용한다. Boot Loader 에서는 시스템에 설치 되어져 있는 여러 운영체제
나 Kernel 버전을 관리하여 해당 운영체제나 Kernel버전에 맞는 부팅 이미지로 부팅을 시켜
주는 역할을 한다.
이런 Boot Loader 에서 발생하는 문제의 주요 원인으로는 하드웨어의 BIOS상의 정보와
설치된 운영체제의 환경이 맞지 않아 발생하는 경우가 그에 해당한다.
– LILO Bootloader로 부팅 시 문제 발생 했을 때 해결 방법
LILO 상에 발생하는 주요 문제로는 흔해 “LI” 문제를 들 수 있다. 이는 Linux Boot Loader
의 고전적인 문제로 Boot Loader 가 실제 하드디스크의 1024 실린더 안에 설치가 되지 않으
면 발생하는 문제이다.
예를 들어 Linux 운영체제를 설치할 때 / 파티션을 하드디스크의 초기 8GByte 범위 밖에
설치 하면 위와 같은 문제가 발생할 수 있다.
하지만 이런 경우는 Linux의 LILO 버전이 발전함에 따라 개선되어 지금의 배포 판 환경에서
는 거의 나타나진 않는다. 하지만 실무에서는 항상 최신 OS 환경을 유지한다는 보장이 없기
때문에 이런 문제에 대해 사전에 알아두는 것이 좋다. 이와 같이 LILO 상에 문제가 발생하면
실제 해당 시스템의 하드디스크에 설치된 부팅이미지로 부팅을 할 수 없기 때문에 다른 부팅
이미지를 통해 긴급 부팅을 하여 문제를 해결해야 한다. 아래는 긴급 부팅을 통해 부팅하여
문제를 해결하는 방법에 대해 설명한 것이다.
– LILO Boot Loader 사용 환경에서는 긴급 부팅 방법
Linux설치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라는 bootloader는 실제 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로서 최신 버전의 Linux에서는 대부분 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 파일 시스템이다. Linux 파일 시스템의 종류에 따라 시스템 성능과 안정성의 차이가 있기 때문에 서비스 성격에 따라 최적의 파일 시스템으로 구성을 하면 시스템의 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 의 Directory 구조를 백업해 둠
# cp local.tgz /
# mount -a
# cd /
# tar xzvf local.tgz
실제 파티션과 파일 시스템 구성이 정상적으로 되었는지를 확인 한다.
# df -Th
=================================================================================
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
Linux 시스템은 Open 된 OS 인 만큼 보안에 대한 취약점이 있다고 생각할 수 있지만
이와 달리 Open 된 시스템인 만큼 보안의 취약점을 미리 사전에 파악하여 패치 함으로
관리자의 관심만 유지되면 보안에 더 강력하다고 말할 수 있다.
Redhat Linux의 경우 up2date 란 프로그램을 통해 윈도우 처럼 자동으로 패키지를
업데이트 할 수 있는데 기본적으로 배포 판에 설치되는 up2date 로 업그레이드를 하면
SSL 인증 에러가 발생하게 될것이다. 이는 현재 배포 버전인 Redhat9 이 발표된 이후
Redhat사의 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
Redhat 사에 현 시스템의 정보 및 간단한 인증 정보를 기록합니다.
정식 Redhat 배포 판을 구매하면 up2date 의 지원을 계속 받을 수 있지만 공개 배포 판의
경우에는 3개월 기간 제한이 있기 때문에 설치 시에 한번 지원 받는다는 의미를 가진다.
# up2date -p -> 현 시스템이 RPM 패키지 정보를 정리한다.
# up2date -u -d -> 업데이트를 시킬 패키지를 다운 받는다.
up2date 에서 -d 옵션을 사용하면 업데이트 대상 패키지를 다운 받아 /var/spool/up2date
안데 저장된다.
-u 옵션만 사용하면 다운 받아서 업데이트 패키지를 바로 설치 하고 설치가 완료된
rpm 을 삭제 하게 됩니다. 만일 업데이트 대상 시스템이 여러대 일 경우 계속 같은 방법
으로 업데이트 시킬 필요 없이 한곳에서 다운 받아놓고 그 패키지를 이용하여 다른 시스
템들의 업그레이드를 시키는 방법이 편할 것이다. 단 위 경우는 시스템의 패키지 구성이
유사한 경우에 의미가 있다.
– H/W Driver Update
dmesg message 를 살펴 보면 Kernel이 로딩한 장치의 드라이브 버전을 확인 할 수 있다.
흔히 문제가 되는 것이 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 으로 만들어진 드라이브 버전은 현 시스템 Kernel 버전에 의존함으로 드라이버
설치 후 kernel upgrade를 할 경우에는 반드시 다시 장치 드라이브 버전을 확인하셔야
합니다.
1.4 운영체제 기본 보안 설정
Linux 운영체제는 Open Source 기반 운영체제입니다. Open Source 기반의 운영체제라는
조건이 실제 시스템 운영 측점에서 장점이 될수도 있고, 단점이 될수도 있는데 대표적인
것이 바로 운영체제 보안이라 볼수 있습니다.
운영체제의 Source code 가 공개되어져 있기에 실제 운영체제의 보안 취약점이 크래커에게
공개되는 경우가 있을 수 있다는 것입니다.
하지만 반면에 전 세계적으로 분포된 Linux 개발 프로젝트에 참여한 개발자, 엔지니어,
테스터들이 문제점을 사전에 발견하여 지속적인 패치를 해준다는 장점이 있습니다.
실제 상용 UNIX 의 경우 보안적인 문제가 발생하더라도 이가 해당 보안 담당자에게 알려
지는 기간이 길기 때문에 패치가 나오기 전에 해킹을 당하는 경우가 많습니다.
하지만 LINUX 의 경우는 대부분의 해킹 사례가 이미 Linux 커뮤니티등에서 보안 이슈를
발표하고 1년이상 이후에 해당 취약점으로 패치가 안된 시스템을 공격하는 경우입니다.
이런 두가지 측면의 보안 이슈는 어느것이 좋고, 나쁨을 떠나 시스템 엔지니어의 보안에
대한 경각심과 시스템 보안 관리에 대한 노력의 문제라고 볼수 있습니다.
아래는 Linux 시스템을 설치 후 기본적인 보안 설정에 대해 설명한 것입니다.
초기 배포 환경에서는 여러 측면의 서비스를 대상으로 하기 때문에 해당 시스템의 서비스
성격과 다른 패키지와 보안 정책등이 부여가 되어져 있을 것입니다. 이는 실제 불필요한
시스템의 자원 낭비일 뿐만아니라 관리 하지 않는 보안적 헛점이 존재한다는 측면에서
보안적으로 취약점이 될수 있기에 설치 이후 서비스를 시작하기 전에 적절한 조치를
취해 줘야 하는 내용들입니다.
1.4.1 시스템 서비스 Daemon 관리
– 불필요한 서비스 Daemon 제거
Redhat 기반의 Linux 운영체제를 설치 하면 기본적으로 여러가지 서비스가 부팅 시
자동 시작이 되도록 설정이 되어져 있다. 하지만 대부분의 서비스들이 실제 서비스
대상과는 전혀 상관없는 서비스이다. 꼭 필요한 서비스이외의 나머지 서비스들은
아래와 같은 방법으로 부팅 시 자동 시작 리스트에서 제거 한다.
/sbin/chkconfig –del anacron
/sbin/chkconfig –del atd
/sbin/chkconfig –del autofs
/sbin/chkconfig –del echo
/sbin/chkconfig –del finger
/sbin/chkconfig –del gpm
/sbin/chkconfig –del nfs
/sbin/chkconfig –del nfslock
/sbin/chkconfig –del portmap
/sbin/chkconfig –del rlogin
/sbin/chkconfig –del rsh
/sbin/chkconfig –del rsync
/sbin/chkconfig –del lpd
/sbin/chkconfig –del xfs
– 필요한 서비스 추가
/sbin/chkconfig –add crond
/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
부팅 시 자동 시작 서비스 Daemon 제어 방법으론 위 방식은 chkconfig 이외에
ntsysv 란 명령어를 이용하여 설정할수도 있다.
– 불필요한 Xinetd 서비스 제거
Xinetd 서비스 설정은 /etc/xinetd.d/ 안에 존재 한다. 이 설정 파일을 잘못 관리 하게 되면 원하지 않는 서비스를 허용하게 된다. 원천적으로 사용 하지 않는 서비스 설정에 대해서는 삭제 해 버리는 것이 좋다.
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 시스템 계정 관리 및 운영체제 파일, Directory 권한 조정
Linux를 설치 하게 되면 기본적으로 많은 시스템 계정과 어플리케이션 계정이 존재 하게 된다.
이는 이전의 Linux 버전에서 실제 서비스 Daemon의 대부분을 root 계정에서 관리를 하였는데 이런 취약한 서비스 Daemon을 이용하여 시스템의 root 권한을 외부에 허용하는 보안 상의 헛점이 많이 존재 하였다. 그 후 서비스 Daemon을 제어하는 시스템 계정을 별도로 생성하게 되었는데 이런 이유로 Linux를 기본적으로 설치 하면 많은 시스템 계정이 생성되게 된다. 하지만 사용하지 않는 서비스나 어플리케이션에 구동 되어지는 계정의 경우 불필요한 계정 관리 부담 및 보안 상에 위험 요소를 가지고 있게 된다. 이런 이유로 불필요한 계정과 그룹 정보를 초기 운영체제 설치 후에 반드시 지원 주도록 하다. 이런 기본 시스템 계정 삭제에 앞서 해당 설정 파일을 백업을 받고 삭제를 하길 바란다. 주요 백업 대상 파일은 /etc/passwd, /etc/group, /etc/shadow 가 그에 해당한다.
– 불필요 계정 삭제
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
– 운영체제 기본 명령어 권한 조정 및 시스템 파일 보안 정책
기본 운영체제 설치 이 후 root setuid, setgid 권한의 명령어를 검색하여 불필요한 명령어의 퍼미션을 조정한다. 참고로 setuid, setgid 는 일반 유저가 해당 명령어를 실행할 때 root 권한으로 명령어가 실행되도록 하는 권한이다. 이는 해당 명령어를 통해 일반 유저가 root 관리자 권한을 얻게 되는 것으로 불필요한 경우에는 반드시 퍼미션을 조정해야 한다.
# 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
chomd 700 /usr/bin/gcc
chmod 700 /sbin/netreport
chmod 700 /usr/bin/sudo
아래는 setuid, setgid 권한의 명령어와 일반 관리자용 명령어 중 특정 일반 유저가 사용할 필요가 있는 경우 특정 그룹을 만들어 해당 그룹에 속한 유저만 사용 가능토록 지정하는 방법이다.
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 /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
chmod 750 /usr/bin/gcc
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 whell /usr/bin/gcc
chgrp wheel /usr/bin/rcp
chgrp wheel /usr/bin/rsh
chgrp wheel /usr/bin/rlogin
# vi /etc/group
==================================================================
.
wheel:x:10:root,clunix,alang
.
==================================================================
– 시스템 Directory 권한 조정
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>는 각 자원의 제한 값이다.
이밖에 사용자의 주요 작업 내역에 대해서는 아래의 방식으로 관리가 가능하다.
물론 이런 방식이 정상적으로 허용될지에 대해서는 각 사이트마다 다를 것이다.
하지만 여러 명의 사용자가 존재하고 모두의 정상적인 시스템 사용을 위해서는 관리자의
막강한 관리 권한이 주어져야 하며, 권한을 가진 관리자에게는 시스템 관리에 따른
윤리성에 대한 자각이 갖추어져야 한다. 아래 방식은 실제 사용자의 주요 작업 history
를 관리자가 쉽게 파악할 수 있도록 하는 방법이다. 관리자의 경우는 실제 시스템적
관리 권한에 이미 일반 사용자의 작업 history를 볼 수 있는 권한이 주어진다.
하지만 운영 정책에 의해 제한 되어지는 환경도 많을 것이다. 아래 방법은 시스템상에서
적절한 권한을 위임 받은 상태에서 보다 효율적인 관리를 위해서 사용될 수 있는 방법일
것이다.
– 일반 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 파일의 permission을 662 으로 해줍니다.
# chmod 662 /var/log/user_history
위와 같은 설정이 완료되면 일반 계정에서 로그인을 했을 경우 사용자 계정의 홈Directory
밑에 생성되어져야 할 작업 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 설정을 제거 하도록 한다.
이제 위의 사용자 history 내역을 관리자에게 자동 메일을 보내주는 스크립트를 사용하
여 매일 편리하게 사용자 관련 보안을 점검하면 된다.
# 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 란 수퍼 Daemon
상에서 관리 되어 진다. 이는 Linux 기본 정책일뿐 반드시 위 서비스가 xinetd Daemon 상에서
관리되어야 하는 것은 아니다. xinetd Daemon의 자세한 사용법에 대해서는 별도의 서적이나
인터넷 상의 정보를 참고 하길 바란다. 여기서는 xinetd 상에서 구동되는 서비스의 기본 보안 설정에 대해서만 다루도록 한다.
xinetd Daemon으로 구동 되어 지는 서비스들은 /etc/service 란 설정 파일에서 확인할 수 있다.
그리고 실제 서비스 적용 사항들은 /etc/xinetd.d 란 Directory에서 확인이 가능하다.
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 Daemon으로 관리하는 서비스의 경우 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 Daemon 상에서 구동되어지는 서비스 명이다.
<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
————————————————————————————
허가 되지 않은 영역에서 접속을 하게 되면 위 관리 스크립터에 지정된 관리자 메일 주소
로 아래와 같은 Message 가 발송이 되어진다.
===============================
접속거부자 상세정보
===============================
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 은 원래 Linux가 아닌 유닉스 플랫폼에서 설계되어 왔으나 현재 Linux에서
대표적으로 사용되는 파일 무결성 검사 도구이다.
Tripwire는 시스템 파일 등의 변조 및 추가 등을 검사함으로써..해킹의도를 파악할 수 있는
보안 도구 입니다.
Tripwrie 설치 전 몇 가지 알아 두어야 할 점이 있다.
검사도구는 시스템 설치 후에 바로 설치해야 의미가 있다.이미 해킹 당한 상태에서 설치 해
보아야 검사도구엔 발견 되지 않는다.
초기에 아주 깨끗한 상태에서 시스템 파일 정보들을 DB file로 만들어 놓고 앞으로 변화
되는 상황을 지켜 보아야 한다.
그리고 시스템 정보가 저장될 DB file 이 다른 사람에게 접근을 허용하면 안 된다.
이 두 가지만 철저하게 지키면 아주 유용한 보안 도구로 사용이 가능하다.
이제 설치에 들어가 보도록 하자. 설치는 RPM 과 Source 두 가지 방법이 있다.
먼저 Source 설치 방법에 대해 알아보자.
tripwire 소스는 다음 사이트에서 다운 받을 수 있다.
http://www.tripwire.org
특정 Directory에 소스를 다운 받아 압축을 푼다.
# 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 파일을 초기화 시킨다는 의미이다. 즉 깨끗한 시스템 파일 초기 상태의 기준
을 세운다는 의미로 보면 된다.
만일 이 초기화 작업을 이미 해킹을 당해 백도어가 설치된 상태에서 초기화를 시킨다고
하면 이런 Back door 까지도 무결 파일의 기준으로 인식하게 된다.
그렇기 때문에 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
### 그런 파일이나 Directory가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.esd_auth
### 그런 파일이나 Directory가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome_private
### 그런 파일이나 Directory가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome-desktop
### 그런 파일이나 Directory가 없음
### Continuing…
### Warning: File system error.
### Filename: /root/.gnome
### 그런 파일이나 Directory가 없음
————————————————————————————
위는 기본 정책에는 들어있는 체크 대상이지만 현 시스템에는 존재하지 않는 대상들이다.
이 부분들을 /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 Directory 밑에 test 란 임의의 파일을 하나 생성하고, /bin 밑의 명령어의 permission을
변경해 보도록 하자.
# 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 가 체크할 파일들이 들어 있는 Directory로 시스템에
# 중요한 명령어나 설정파일등이 있는 곳을 정해 주면 된다.
#
Exclusion = /etc/passwd
Exclusion = /etc/shadow
#
# Exclusion 설정은 Directory 설정에서 정한 Directory중 자주 변경이 되는 파일
# 이 있어서 체크때마다 걸리므로 체크 생략을 요하는 파일을 정해 주면 된다.
# 호스팅 업체나 기타 자주 사용자를 추가하는 서버라면 위와 같이 해주면 된다.
#
DataBase = /usr/local/fcheck/data/data.dbf
#
# DataBase 설정은 Linux 파일 정보를 DB 파일로 저장해서 다음 체크시 비교
# 분석할때 사용되어진다.
#
TimeZone = GMT-9
#
# 한국 시간을 적용한다. GMT-9
#
#File = /usr/local/admtools/logs/sol.dbf
————————————————————————-
File 설정은 필요 없으니 주석 처리 해준다.
기타 여러 설정값이 있으나 크게 작동하는데 영향을 주지 않는다.기본값을 적용
한다.
이와 같이 적용후 /usr/local/fcheck/data Directory를 만들어 준다.
# mkdir /usr/local/fcheck/data
# /usr/local/fcheck/fcheck -ac
이와 같이 fcheck -ac 로 파일 무결성 체크를 시작한다. 그럼 data Directory 안
에 data.dbf 파일이 생성되어 진다.
이제 Directory 설정에 해당하는 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
불필요한 서비스 포트가 열려 있는 경우엔 반드시 해당 Daemon이나 서비스를 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 등의 원격 접속 로그인 화면 )
– 시스템 시작 시 자동 실행 작업
시스템이 Rebooting 될 때 자동으로 실행 시켜야 하는 프로그램이나 명령어가 있을 경우
/etc/rc.d/rc.local 설정파일 마지막에 실행 명령을 적으면 된다.
특정 계정 로그인 시 자동으로 실행해야 하는 작업이 있을 경우는 해당 계정의 홈 폴더
밑에 있는 .bash_profile 혹은 .bashrc 파일 하단에 해당 작업을 적어 주면 된다.
1.5 엔터프라이즈 Linux Kernel 구성 하기
1.5.1 Kernel과 시스템 최적화
시스템 Kernel이란 실제 운영체제의 핵심 코어 부분으로 실제 OS 기능의 대부분의 역할
을 담당하는 부분이다. 운영체제란 컴퓨터 하드웨어를 사용자가 어플리케이션을 통해
바로 인식하여 작업에 사용할 수 없기 때문에 이런 하드웨어 자원을 어플리케이션에서
인식하여 프로그램상에서 사용할 수 있는 중계 역할을 하는 프로그램으로 볼 수 있다.
이런 운영체제의 구성으로는 크게 하드웨어의 기능을 인식하여 그 기능을 관리, 제어
하는 Kernel 부분과 기본적인 어플리케이션 부분으로 구성이 되어 진다. 즉 Kernel 부분은
실제 운영체제의 가장 큰 역할인 하드웨어의 어떻게 인식하고, 어떤 방식으로 관리,
제어를 하는가를 결정하는 중요한 부분이다. 이런 Kernel 구성 방식에 따라 동일한 하드
웨어를 가진 시스템이라도 그 성능의 차이가 생기게 된다.
이 장에서는 Kernel의 최적화 요소와 해당 요소 별 성능에 미치는 영향에 대해 살펴보고
실제 엔터프라이즈 시스템 환경의 맞는 Kernel을 구성해 보도록 할 것이다.
Kernel의 최적화 기술은 시스템 엔지니어의 고급 능력 중에 하나이며, 이는 실제 엔지니어
의 기술력 차이를 통해, 동일 시스템의 성능의 차이를 가져 올 수 있는 요소 중의 하나
이다.
Linux의 여러 배포 판이 존재하는데 이중 엔터프라이즈 급 Linux 배포 판이라는 명칭이
붙는 배포 판의 차이가 바로 이 Kernel 구성에서 있는 것이다. 즉 SMP 시스템을 인식하고
대용량 메모리를 인식하고, 메모리 I/O, 디스크 I/O, 시스템 I/O 성능을 개선하며,
보다 안정적인고 대용량 파일을 제어 할 수 있는 파일 시스템을 지원토록 하며,
프로세스 처리 제한이나 파일 OPEN 제한 수치를 확장 시키는 등 대용량 서비스를 수행 할
수 있게 Kernel 환경을 구성함으로 엔터프라이즈 Linux 환경이라 할 수 있다.
이 장에서는 실제 Kernel 컴파일에 대한 기본적인 기술에 대해서는 언급하지 않는다.
Kernel 컴파일에 대한 기술 부분은 인터넷 상의 기술문서나 다른 서적을 참고하길 바란다.
1.5.2 엔터프라이즈 Kernel 구성 요소
대용량 서비스를 할 수 있는 시스템 구성을 위한 Kernel 튜닝에 대해 알아 보도록 하겠다.
http://www.kernel.org 에서 최신 Kernel 소스를 다운 받으면 기본적으로 범용 시스템에
맞는 Kernel 구성으로 되어져 있다. 이는 보편적으로 일반 시스템에 적합한 Kernel 구성이라
대용량 시스템에 바로 사용하면 실제 시스템의 하드웨어 성능을 최대한 활용할 수 없게
된다. 그러므로 시스템 하드웨어에서 지원하는 성능을 최대한 효율적으로 활용 가능하도록
Kernel을 튜닝을 해주어야 한다. 여기서 다루는 Kernel 튜닝 방법은 대용량 SMP 시스템을
대상으로 하는 방법이기 때문에 보편적인 일반 시스템에서는 Kernel의 서비스 한계치가
하드웨어 실제 지원 한계치를 넘게 되어 문제가 발생할 수 있으니 주의하길 바란다.
– Kernel 한계 수치 수정을 통한 최적화 작업
이는 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 최적화 작업
해당 작업은 Linux 시스템 상의 I/O 성능 개선을 위한 바운스 버퍼 관련 패치 및 SCSI 병렬
큐잉 패치등의 작업이 있다
– File System 최적화 작업
SGI UNIX System 의 기본 파일 시스템으로 알려진 XFS 파일 시스템을 리눅스에서 사용할 수
있도록 하는 작업이다. 리눅스의 기본 파일 시스템은 Ext3를 사용하는데 이는 일반적인 리눅스 시스템에서 적절한 성능과 안정성을 보장하기에 주로 사용을 하나 대용량 시스템이고 대형
파일을 작업에 주로 사용하는 경우 대용량 파일 제어에 탁월한 성능을 가진 XFS 파일시스템을
채택해 보는 것도 시스템 성능 개선에 효과를 볼 수 있을 것이다.
XFS 파일 시스템을 사용해 보도록 하자.
XFS 파일 시스템은 CVS를 통해서 다운 받을 수 있다. 아래의 절차를 통해 XFS source를 다운
받도록 한다.
# cd /usr/src
# export CVSROOT=’:pserver:cvs@oss.sgi.com:/cvs’
# cvs login
Logging in to :pserver:cvs@oss.sgi.com:2401/cvs
CVS password: < ‘cvs’>
# cvs -z3 co linux-2.4-xfs
실제 XFS Kernel의 경우 리눅스 기본 Kernel에도 포함이 되어져 있으므로 굳이 XFS 전용Kernel을
이용할 필요는 없다. 하지만 실제 XFS 파일 시스템을 관리하는 프로그램이 XFS 전용 Kernel
안에 포함되어져 있기 때문에 위의 절차를 통해 XFS 전용 Kernel을 다운 받도록 한다.
Kernel 소스 경로로 디렉토리를 변경하고 Kernel 컴파일을 하도록 한다. 먼저 Kernel 설정을
해야 한다.
XFS 관련 Kernel 설정 내용은 모두 File System 항목 안에 있다.
XFS 관련 항목을 체크한 후 Kernel 컴파일을 하면 된다.
(이 장에서는 Kernel 컴파일에 대한 부분은 생략합니다. Kernel 컴파일 관련 서적이나 문서를
참고하시길 바랍니다.)
XFS 관련 프로그램은 아래와 같이 다운 받을 수 있다.
# cvs -z3 co xfs-cmds
# cd xfs-cmds
# make && make install
XFS 가 적용된 Kernel로 Rebooting을 한 후 mkfs.xfs 명령으로 XFS 파일 시스템을 생성할 수 있다.
– Sysctl을 이용한 Kernel 파라메터 최적화 작업
일반 시스템의 안정성을 위해 기본적으로 네트워크의 성능 임계치를 하향 조정해 놓는다.
하지만 실제 고성능 워크스테이션의 경우 시스템의 재 성능을 Kernel에서 제한하는 경우에
해당할 것이다. 이는 시스템 사양에 맞게 적절한 서비스 한계치를 조절함으로 최적 성능을
발휘할 수 있게 설정을 조절하여야 한다.
Kernel 파라메터를 통한 설정 변경은 Kernel의 소프트 레벨에서 수정이 가능하며 sysctl 프로그램
을 이용하여 설정 변경이 가능하다. Kernel의 소프트 레벨의 수정이라 함은 실제 Kernel 소스상태
에서의 수치 수정을 통해 적용하는 것이 아니라 시스템이 부팅되어져 있는 상태에서 Kernel의
파라메터값을 변경하여 해당 수치를 적용하는 방법이다.
먼저 sysctl의 사용법에 대해 간단히 알아보도록 하자.
sysctl 은 Linux의 가상 파일 시스템인 /proc 파일 시스템 내의 파일들을 직접 수정하여
Kernel 옵션의 변경을 효율적으로 관리하는 명령어이다.
사용법은 단순한다.
# sysctl -a : Kernel 파라메터 값 확인하기
위의 명령으로 Kernel 파라메터를 확인을 하면 상당 수의 정보가 출력된다. 원하는 정보를
확인 하기 위해서는 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 : Kernel 파라메터 값을 변경
-w 옵션을 사용하여 Kernel 파라메터의 값을 변경할 수가 있다.
예를 들면 TCP SYN_Flooding 공격 차단을 위해 net.ipv4.tcp_syncookies 값을 기본 0에서
1로 변경을 해 보도록 하자
# sysctl -w net.ipv4.tcp_syncookies=1
위와 같이 시스템 서비스 현 상황에 맞게 Kernel 파라메터 값을 적절히 수정하여 시스템의
최적화를 만들 수 있다.
soft level 의 Kernel 파레메터 수정은 부팅 이 후 변경이 가능하고 만일 Rebooting이 되어 지면
기본의 설정 내역이 다시 초기화 된다.
설정을 유지 하는 방법으로는 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
————————————————————————————-
위의 형식으로 Kernel 파라메터 설정을 sysctl.conf 파일에 설정해 주면 Rebooting 시에도
적용이 가능하다.
아래는 시스템 성능과 보안에 관련된 주요 Kernel 파라메터들이다.
– 주요 보안 관련 Kernel 설정
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 공격을 방어하기 위한 설정
이며, 이 기능을 사용하기 위해서는 Kernel에서 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 된 패킷 로그에 남기기
– 네트워크 성능에 관련된 Kernel Parameter 설정
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번 Port 에서 61000번 Port 까지 열 수
있다는 것이다.
net.ipv4.tcp_max_syn_backlog = 8192
: Socket의 listen backlog 값 조정으로 동시 접속이 많을 때 최적화 방법이다.
기본은 1024.
net.core.rmem_default = 1048576
net.core.rmem_max = 1048576
: Socket 수신 큐의 최대값과 기본값 조정. 대용량 서비스 시 최적화 필요
기본값은 65536.
net.core.wmem_default = 1048576
net.core.wmem_max = 1048576
: Socket 출력 큐의 최대값과 기본값 설정. 대용량 서비스 시 최적화 필요
기본값은 65536.
net.ipv4.tcp_rmem = 4096 87380 8388608
: TCP layer의 수신 버퍼 값. 대량의 테이터를 클라이언트로 전송할때 위 설정값 사용 권장
기본값은 4096 16384 131072.
net.ipv4.tcp_wmem = 4096 65536 8388608
: TCP layer 의 송신 버퍼를 조정값.
net.ipv4.tcp_mem = 4096 4096 4096
: TCP stack의 메모리 페이지 단위 설정, 설정 값의 의미는 순서대로 min, pressure, max
를 의미한다. tcp_wmem 과 tcp_rmem 설정에 따라 적절한 크기를 활당한다.
net.ipv4.tcp_sack = 1
: selective acknowledgements 설정으로 외부 서비스용 시스템에서는 on
내부 전용 서비스에서는 off 권장
net.ipv4.tcp_timestamps = 1
: timestamps 생성 유무 외부 서비스 시에는 on, 내부 전용 서비스에서는 off 권장
net.ipv4.tcp_orphan_retries = 7
: 유저 파일 핸들에 할당되지 않은 커넥션에 대해 몇 번을 제거 시도를 할 것인지를
정하는 파라메터, 시스템 평균 로드 값이 높은 웹 서버의 경우에 이 값이 7이하로 떨어
지면 “TCP: toomany of orphaned sockets” 와 “Out of socket memory” 와 같은
Kernel 메세지가 나타난다.
ifconfig lo mtu 1500
: loopback interface 에 대한 MTU 값 변경
localhost에 접속 시 송수신 최적화. 기본값은 16436.
Gigabit 기반에서는 MTU 를 9000 으로 해줌
– 파일,메모리 성능 관련 Kernel Parameter 설정
kernel.msgmni = 1024
: 메시지 큐 크기 조정. 기본값 16
kernel.sem = 1000 32000 32 512
: 세마포어 최대값 조정
kernel.shmmax = 1024483648
: 공유메모리 최대값 조정
오라클과 같은 대형 서비스에서는 실제 시스템 메모리의 50% 이상을잡도록 한다.
단위는 byte 단위. 위 설정은 메모리가 2G 일 경우 공유메모리를 1G로 잡는 설정
fs.file-max = 65535
: Kernel이 활당할 수 있는 파일 핸들 최대값
vm.bdflush = 100 1200 128 512 15 5000 500 1884 2
: 가상 메모리 및 버퍼 메모리 관리에 대한 성능 향상
– Securing and Optimizing Linux 권장
– 시스템 limit 설정을 통한 최적화 작업
Kernel 구성과 별도로 시스템 설정 제한에서 시스템의 리소스를 제한하는 경우가 있다.
앞에서 언급했듯이 /etc/securetty/limits.conf 파일에서 제한을 하게 되는데 고성능 서버의
경우 위 제한 치를 기본 설정에 비해 높게 잡아 주는 것이 재 성능 발휘에 좋을 것이다
# vi /etc/securetty/limits.conf
————————————————————————————-
* hard core 0
* hard rss 5000
* hard nproc 20
* hard cpu 5
* hard data 10000
* soft nofile 4096
* hard nofile 4096
* soft stack 8192
* hard stack 8192
ftp maxlogin 4
————————————————————————————
limits.conf 의 값은 실제 성능을 상향 조정하는 의미 보다는 개별 유저, 프로세서에 대한
최대 사용의 제한 값을 주는 의미가 더 강하다.
위의 ftp 계정의 최대 접속 허용 수는 4개이다. 즉 4개의 connection 에 연결된 상태라고
하면 다음 5번째 connection 은 거절되는 것이다.
1.5.3 Kernel 컴파일 실무 관련 주요 기술
– 시스템 성능 확장을 위한 주요 기능
Linux Kernel 컴파일 시 시스템 성능에 중요한 역할을 하는 기능에 대해 살펴 보도록 하자
– 엔터프라이즈 Kernel 버전 관리 방안
시스템을 관리 하다 보면 보안이나 성능 이슈에 의해 여러 개의 Kernel 버전을 가지고 시스템
을 유지하게 된다. 여러 개의 Kernel 버전을 관리하는 방법과 Kernel 컴파일 후 신규 Kernel 적용 시 유용한 기술에 대해 알아보도록 하자
– Linux Kernel 패치 파일 만들기
Linux 신규 Kernel이 나올 때 마다 엔터프라이즈 패치를 한다면 매번 작업에 번거로움이
생길 것이다. 해당 시스템에 적절한 Kernel 소스 튜닝 방안이 정해지면 해당 수정 내용을
패치 파일로 만들어 패치 적용 방식으로 관리하면 편리하다 여기서는 Kernel 패치 파일을
만드는 방법과 해당 패치 파일을 신규 파일에 적용하는 방법에 대해 살펴 보도록 하자.
1.6 운영체제 설치 후 중요 데이터 백업 정책
시스템 엔지니어의 가장 비중 높은 역할 중의 하나로 시스템을 언제나 정상적인 서비스
가능 상태로 유지하는 임무가 있습니다. 하지만 사용자의 실수나 외부의 악의적인 행위
에 의해 중요한 데이터의 손실이 발생하게 되고 실제 서비스의 문제가 발생하는 경우가
생깁니다. 백업은 실제 문제 발생 시 정상적인 서비스 상태로 복구를 시키는데 있어 가장
중요한 역할 중에 하나입니다. 하지만 엔지니어의 입장에서는 “문제가 발생하니 복구했다”
라는 가시적인 엔지니어 역할에 대해 논하기 전에 여러 가지 상황으로 나타날 수 있는 문제에
대해 얼마나 빨리 정상적인 서비스로 복구 시킬 수 있는 방법에 대해 고려를 해야 할 것입니다.
백업은 크게 나아가 시스템의 가용성에 중요한 척도로 작용하는 요소로 의미를 가집니다.
백업의 방식에 따라 문제 발생 상황 시 서비스 동작에는 영향을 미치지 않게 할 수도 있고,
서비스에 문제가 발생하더라도 수 초 에서 수 분 사이에 복구가 가능하게 할 수도 있습니다.
하지만 백업에 관련된 비용은 항상 실제 서비스 외 비용으로 작용하기 때문에 엔지니어
입장에서는 본 서비스의 중요성과 구축 비용을 고려하여 상황에 맞는 백업 방식을 설계해야
할 것입니다.
이 장에서는 1차 백업에 해당하는 로컬 데이터 백업과 3차 백업에 해당하는 원격 데이터 백업
에 대해 살펴 보도록 할 것입니다.
시스템의 고 가용성 백업 방식은 이 후 엔터프라이즈 Linux 서버 구축 및 운영의 고 가용성
시스템 구축 부분에서 다루도록 할 것입니다.
1.6.1 로컬 데이터 백업 및 복구 방안
로컬 데이터 백업은 자체 시스템 내에서 중요한 데이터를 다른 디스크 장치에 백업을 하는
방식을 의미한다. 로컬 데이터 백업은 시스템 가용성 단계의 첫 번째 단계로 사용자의 부주의
나 서비스 디스크의 문제 발생 시 최대한 신속히 시스템을 복구 시킬 수 있는 방법 중에
하나로 저렴한 비용으로 백업을 진행할 수 있다. 로컬 데이터 백업 방식은 RAID 장치를 이용
하여 디스크 Mirroring 방식으로 구성할 수도 있지만 별도의 하드디스크나 백업 미디어를 통해
주기적으로 데이터를 백업 하는 방식을 주로 사용한다.
데이터 백업에 주로 사용하는 명령은 tar, gzip, bzip 등이 있는데 tar 는 시스템 파일과
Directory 구조를 하나의 파일로 통합해 주는 명령이고 gzip, bzip은 시스템 데이터를 압축
하는 역할을 한다.
이 명령과 별도의 자동화 스크립터를 통해 백업 스케줄링을 만들어 놓으면 관리자의 설계에
따라 시간 별, 날짜 별, 요일 별 백업이 가능하다.
백업의 시점과 주기는 시스템의 성능에 밀접한 관계가 있기 때문에 로컬 데이터 백업의 경우
시스템의 백업 시간을 서비스가 주로 진행되는 시간에서 멀리 하여야 한다. 백업에 사용되는
시스템 리소스로 인해 서비스에 사용되는 시스템 리소스가 줄어들기 때문에 현 시스템의 백업
시점은 서비스 요청이 가장 적은 시기에 행해져야 할 것이다.
그럼 간단한 예제를 통해 백업 명령어의 사용법에 대해 알아보도록 하자.
예제)
# cd /backup
# tar cvpfz /backup/home.tar.gz /home –exclude=/home/test
위의 명령에서 사용한 옵션에 대해 하나씩 알아보도록 하자.
먼저 백업파일은 /backup 이라는 Directory에서 생성하기를 원하므로 /backup 으로 이
동한후 tar 명령을 이용해 백업을 시작한다.
“c” 는 Create a new archive 의 뜻으로 백업 시 새로운 파일을 생성하며
”v” 는 Verbosely list files processed 의 뜻으로 백업 시 백업이 진행되고 있는 상황
및 Directory 리스트를 보여주며
“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 Directory에 /home/test 이하를 제외한 /home의
나머지 모든 파일과 Directory를 압축하여 home.tar.gz 란 파일로 백업하게 된다.
tar 의 경우 파일을 묶을 때 Directory 구조에 의해 하위 Directory를 모두 묶는 특성이
있기 때문에 백업 예외 Directory나 파일이 존재 할 경우 –exclude 란 옵션을 이용하여
백업 대상에서 제외 시킬 수 있다.
이것은 거대한 백업 대상이 존재 할 경우 선별적으로 꼭 필요한 데이터만을 백업하여
백업 시간의 단축 및 백업으로 인한 디스크 수명 연장 등에 의미가 있다.
실제 여러 명의 사용자가 존재하는 시스템에 사용자 데이터는 대부분 /home 이란 Directory
밑에 존재 하게 되는데 실제 백업의 필요가 있는 사용자와 백업이 필요 없는 사용자가 있을
것이다. 혹은 백업이 필요한 파일 속성을 가진 데이터와 백업이 필요 없는 파일 속성을
가진 데이터가 하나의 Directory 안에 존재 할 때 위의 방식을 이용하여 백업 스크립터를
제작하여 운영하면 보다 효율적인 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 밑의 사용자 홈Directory를 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) 번까지는 백업을 해야 할 Directory 이하에 대해 데이터를 각각 백업한다.
(8) 백업된 파일의 소유권을 backup 으로 설정한다.
(9) 백업된 파일의 권한을 700 으로 설정한다.
(10) 백업이 제대로 되었는지 확인하기 위해 현재의 Directory내 백업 파일의 리스트등의
정보를 백업담당자인 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 Directory의 전체 백업이
진행 될 것이다. 그리고 매일 새벽 2시에 전체 백업에서 변동된 데이터만을 선택적으로
백업을 할 것이다.
이와 같은 방식으로 백업을 진행할 경우 매일 전체 백업을 해야 하는 경우보다 적은 리소스로 빠른 백업 및 빠른 복구가 가능할 것이다.
1.6.2 원격 데이터 백업 및 복구 방안
로컬 데이터 백업의 짧은 주기의 정기적인 백업과 부분 문제 발생 시 신속한 복구를 위해
행하는 백업의 성격이 강하다. 하지만 로컬 시스템의 디스크 용량의 제한 문제로 인해
특정 시기에 백업한 데이터를 오랜 시간 보관할 수 없는 단점이 있다. 관리자의실수로 인해
백업 디스크나 데이터에 손상이 가거나 삭제가 되었을 경우, 혹은 로컬 시스템 자체가
물리적 (화재, 테러 )으로 손상이 갈 경우 그 문제의 심각성을 말로 표현하기 힘들 것이다.
그렇기에 반드시 시스템 엔지니어는 초기 백업 설계 당시 다양한 백업 방안을 고려해야
한다. 원격 데이터 백업은 흔히 3차 데이터 백업이라 한다.
1차 데이터 백업은 실제 로컬 디스크 백업에 해당하고 2차 데이터 백업은 시스템 이중화 혹은
High Availability 시스템 구축에 주로 사용되는 Mirroring 기술로 백업과 동시에 서비스 고 가용성까지 고려한 백업 방식에 해당하고 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/ 란 Directory에 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 설정 파일에 백업 대상 Directory의 정보를 설정한다.
# 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 Directory로 사용. 보안상 필요함.
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 긴급 발생 문제 해결 및 주요 관리 이슈
파일 시스템이 깨졌거나 해킹 등의 문제로 정상 부팅이 안 되는 경우 복구 방법 입니다.
실제 Linux Kernel로 부팅을 하는 것이 가장 중요하다. 부팅을 해서 시스템 상태를 점검
해야 이 다시 설치를 할지 아님 일부 중요 파일의 백업을 이용하여 복구를 할지 결정이
가능하다. 먼저 시스템 부팅이 안 된다. 이제 부팅을 시켜 보자
– 긴급 부팅 시키기
1장에서 설정한 bootloader 설정 내용도 참조하세요.
** Linux 배포 CD를 통한 부팅
단 이때는 기본적으로 시스템의 하드의 파티션 중 / 파티션의 디바이스 명을 알고
있어야 한다. 1장에서 언급한 바와 같이 그래서 초기 셋팅 후 시스템 정보를 보관 하는 것은 상당히 중요하다.
Linux Install CD 를 넣고 부팅 한다. boot 프롬프트에 다음내용을 기재한다.
boot : linux initrd= root=/dev/hda2 -> /dev/hda2 가 실제 / 파티션의 device name
이는 Linux Install CD 에 있는 기본 Kernel로 시스템을 부팅하여 현 시스템의
root mount point ( / ) 에 접근하는 것이다.
이 경우는 IDE 하드에 Linux가 설치 된 경우 주로 사용한다. SCSI 의 경우 Install CD
Kernel에 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
도 있다.
– 부팅 디스켓 만들기
먼저 부팅디스켓으로 사용할 Kernel 이미지를 선택한다.
그리고 선택한 Kernel 이미지가 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 명령어의 permission을 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 패키지의 permission 이나 권한 등을 변경하여 정상적인 작동을 안 할 경우 이를 설치 시 상태로 복구 하는 방법이다.
# rpm –setperms -a
이로써 실무 환경을 고려한 엔터프라이즈 Linux 운영체제 설치에 대한 교육 과정을 마치도록
하겠습니다.
