BLUE STUDY

Kevin Fenzi, kevin@tummy.com
Dave Wreski, dave@nic.com
v1.1.0 2000년 3월 8일
장 범수, bschang@kldp.org
2000년 5월 9일

-----------------------------------------------------------------------------------
이 문서는 Linux System 관리자가 상대하게 되는 보안 이슈에 대한 일반적 개론을 밝힌다. 일반적인 보안 철학 등과 Linux System을 침입자로부터 보호할 방법 등의 특정 보기를 몇 가지 적어 놓았다. 보안에 관계된 자료들과 Program을 구할 수 있는 곳도 적어 놓았다. 개선 사항, 건설적인 비평, 첨가 사안, 그리고 수정안 등을 감사한 마음으로 수용하겠다. 여러분의 의견은 두 저자 모두에게 "Security HOWTO"를 Mail의 제목에 써서 보내 주기 바란다
-----------------------------------------------------------------------------------

9. Online 전의 보안 준비 (접속에 앞서서)

좋다. System에 대한 전반적인 검사가 끝났고 가능한 한 System을 안전하게 만들었다는 판단이 되었으면, 이제는 접속을 할 순서다. 하지만, 침입이 생길 경우 빠르게 침입자를 무능력화 시키고, 원상 복구를 하려면 준비를 해야 할 것이 아직도 몇 가지 있다.

9.1 완벽한 Backup을 만들 것

Backup 방법과 저장은 이 문서의 주제에서 벗어나는 일이지만 Backup과 보안에 관하여서 몇 마디는 적어 놓겠다. 만약에 하나의 Partition에 650 MB 이하의 Data를 가지고 있다면 CD-R을 쓰는 것 이 좋다. (내용을 변경하기가 쉽지 않고, Data의 장기간 저장이 가능하기 때문이다) 내용을 변경 당하는 경우가 없도록, Tape와 다른 재사용이 가능한 것들은 Backup이 끝나는 대로 쓰기 방지를 하도록 하고, 이에 대한 확인을 하는 것이 좋다. Backup은 안전한 제 2의 장소에 저장하도록 하라. 제대로 된 Backup은 System을 다시 복구하는 시발점이 될 것이므로.

9.2 좋은 Backup Schedule을 고르기

예로서, 6개의 Tape를 1 주기용 한 묶음으로 쓰는 것이 관리하기에 편하다. 4개의 Tape를 매일 하나씩 주중에 사용하고, 한 개를 격주로 짝수 금요일에, 남은 한 개를 격주로 홀수 금요일에 사용하는 것을 방법이다. 매일 부분 Backup (incremental backup)을 만들고, 전체 Backup을 적절한 (격주로 사용되는) 금요일 용 Tape에 만든다. 만약 특별히 중요한 변경을 했거나, 어떤 중요한 Data를 추가했을 경우에는 특별히 Backup을 만드는 것이 좋을 것이다. [33. Backup Schedule]

9.3 RPM과 Debian File Database의 Backup

침입의 경우에는 RPM Database를 Tripwire처럼 사용할 수 있겠지만, 이 경우에는 Database까지도 변경되지 않도록 확인을 하고 써야 할 것이다. RPM Database를 Floppy에 Copy하고, 이것을 항상 제 2의 장소에 보관한다. Debian 배포본도 비슷한 것을 가지고 있다.

/var/lib/rpm/fileindex.rpm과 /var/lib/rpm/packages.rpm은 Diskette 한 장에 들어가지 않을 수 있다. 하지만 압축하면 각각 한 장씩에 들어갈 것이다.

만약 System이 침입을 당하면 다음의 명령어를 사용할 수 있다.

root# rpm -Va

이것을 사용해서 System의 각 File을 확인한다. 이 명령어는 다소 말이 많은 셈이니 (짧은 결과가 되도록 하는) Option들을 보기 위해서, rpm man Page를 보도록 하자. RPM 이진 File들 또한 침입 당하지 않도록 확인을 해 두도록 하자.

이 방법을 쓰면 새로운 RPM을 더할 때마다 RPM Database를 다시 복사해 두어야 한다. 장단점은 여러분이 결정해서 써야 할 것이다.

9.4 System 사용 정보 (account data)의 조사

syslog (System일지: syslog)의 정보가 침해를 받지 않도록 하는 것은 중요한 것이다. /var/log File을 오직 제한된 사용자들만이 읽고 쓸 수 있도록 하는 것은 좋은 시작이다.

auth항에 특히 주의를 두면서, 일지에 어떤 것들이 쓰여지고 있는 지를 감시하는 것이 좋다. 예를 들어서, 여러 번의 (연속된) 접속 실패는 침입 시도를 의미하는 것일 수 있다.

Log 문서 (log file: 일지 문서)가 어디에 위치하는 지는 여러분 배포본의 종류에 따라서 다르다. Redhat과 같이 "Linux File System 규격 (Linux File System Standard)을 따르는 배포본이라면, /var/log을 보면서 메시지를 확인하고, mail.log과 다른 것들을 보는 것이 좋다.

/etc/syslog.conf를 보면 여러분이 쓰는 배포본이 어느 장소에 무엇에 관한 일지 (log)를 적어 놓는지 볼 수 있다. 이 File은 syslogd (System일지 Daemon)에게 어떤 내용의 일지를 어떤 장소에 적어 놓아야 한다는 것을 알려주는 것이다. 시간이 날 때 검사할 있도록 -- 여러분의 일지 보관 Script나 Daemon을 조정해서 -- 일지들을 오래 보관하도록 하는 것도 좋다. 최근의 Redhat 배포본의 logrotate Package를 한 번 보라. 다른 배포본도 비슷할 것이 있을 가능성이 있다.

만약 여러분의 일지 문서가 이미 변경된 것처럼 보이면, 언제 변경이 시작되었는지, 어떤 내용이 변경되었는지 결정을 내리도록 노력해 보라. 일지가 오랜 시간 동안 비어 있는가? (만약 있다면) Backup Tape에 있을 변경되지 않은 일지를 뒤져보는 것도 좋은 생각이다.

보통은 침입자가 침입 흔적을 없애기 위해서 바꿔 버리지만, 그래도 이상한 일들을 검사하기 위해서 일지를 확인하는 것이 좋다. 어쩌면 침입자가 침입을 시도하는 것이나, root 계정을 얻으려고 Program의 침탈을 (exploit a program) 시도하는 것을 알아챌 수 있다. 침입자가 채 바꾸기 전에, 일지를 볼 수도 있는 것이다.

su를 써서 사용자를 바꾸려는 시도나, 접속 시도나, 다른 사용자 계정 정보 등의 다른 일지 Data 등에서 auth항은 별개로 하는 것이 좋다.

가능하다면, 가장 중요한 Data는 보안이 철저한 System으로 복사본을 보내도록 syslog을 조정하라. 이 방법은 /login/sy/ftp/etc 시도를 지움으로써 흔적을 지우려는 침입자를 막을 것이다. syslog.conf의 man Page를 보고, @ Option을 참조하도록.

syslogd보다 진보되어 있는 Program들도 있다. Secure Syslog Program을 한 번 보기 바란다. Secure syslog는 여러분의 syslog 값을 암호화함으로서 이것을 누군가가 임의로 조작하는 일이 없도록 해준다.

많은 기능을 가진 또 다른 syslogd에는 syslog-ng가 있다. 이 것은 여러분이 일지를 쓸 때에 보다 높은 융통성을 발휘해 주며, 원격 syslog Stream을 사용하여 침입을 막는다.

마지막으로, 아무도 읽지 않는 다면, 일지(日誌: Logs)라는 것은 무용지물이다. 시간을 만들어서 일지를 읽도록 하고, 평일 평상시의 작업이 일지에는 어떻게 적히는가를 이해하는 것이 좋다. 이것을 알아두는 것이 이상한 일을 알아채는 데 도움이 된다.

9.5 새로운 System Update의 설치

대부분의 Linux 사용자는 CD-ROM에서 설치를 한다. 보안 구멍 막이 작업은 그 주기가 빠르므로, 새로이 (고쳐진) Program은 항상 나오고 있다. Network에 기계를 연결하기에 앞서서, 배포본의 (ftp://ftp.redhat.com등의) ftp에 가서 Update된 Package를 받아서 새로 설치를 먼저 하는 것이 좋다. 이런 Package는 중요한 보안 개선책을 자주 담고 있으므로, 설치를 반드시 하는 것이 좋을 것이다.

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.