참고 : http://www.sun.com/blueprints
선 시스템의 보안에 관련된 정확한 한글 문서가 존재하지 않아서 이곳 저곳을 기웃거려 작성한 내용입니다.
Solaris Operating Environment (OE) 보안
Solaris Operating Enviroment (OE)는 아주 일반적인 목적을 가진 operating system 입니다. 그러니 비인가 접속과 시스템 수정을 막기 위해서는 시스템적인 보안 조치를 취해줘야 합니다.
1. 각 파일 시스템의 독립
파일 시스템 구성에 있어 /var 디렉토리는 따른 파일 시스템으로 구성해 주는 것을 권장합니다. (/) 과 /var이 같은 파일 시스템에 존재할 경우 심각한 부작용이 존재 할
수 있습니다.
semdmail 과 같은 소프트웨어는 받은 메일과 보내는 메일을 /var 디렉토리에 존재함으로 해서 잘못될 경우 (/) 파일 시스템이 full이 되어 시스템 운영에 큰 장애가 될 수 있습니다.
그리고 log 파일들이 /var에 존재합니다. 로그 데몬 설정을 잘못할 경우 또는 로그만 전문적으로 관리하는 시스템일 경우, 로그 파일의 존재 만으로 시스템 full이라는 에러 메시지를 발생 시킬 수 있습니다.
덧붙여 /usr, /opt 디렉토리도 독립 시켜주는 것을 추천합니다.
2. 최소 설치 추천
가능하면 지원하려는 서비스를 제외한 최소 설치를 권합니다. 이렇게 권장하는 이유는 패치 적용시, 필요로 하는 패치의 수를 줄일 수 있으며, 보다 해킹에 대한 노출이 적어지게 합니다.
또한 패치는 주기적으로 필히 해주시기 바랍니다. 자주 보안 사이트에 들러 관심 목록을 둘러보는 습관을 들여, 패치가 필요한 경우, 필히 패치를 권장합니다.
그리고 unbundle software의 경우도 주기적으로 살펴보 패치도 해주기를 권장합니다.
(unbundle software : 컴파일 설치된 소프트웨어들)
3. 다음은 스팍 머신에 대한 경우입니다.
스팍 머신의 경우 Console Security가 필요합니다. 아무나 시스템에 접근해 OpenBootProm에 접근해서 시스템에 접근할 수 있습니다. 이럴 경우를 원천적으로 대비해야 합니다.
참고로 "man eeprom"을 실행해 manpage를 확인해봐도 이를 추천합니다.
shell> eeprom security-mode=full
Changing PROM password:
New password : aaaaaaa
Retype new password : aaaaaa
패스워드 변경
shell> eeprom security-password=
Changing PROM password:
New password : aaaaaaa
Retype new password : aaaaaa
ok 모드에서
ok setenv security-mode command
securiry-mode = command
ok setenv security-password aaaaaa
security-password =
EEPROM password 모니터링
shell> eeprom security-#badlogins
security-#badlogins=4
이런 결과가 나올 경우 eeprom으로 잘못된 접속이 4번이 있었다는 것을 보여줍니다.
EEPROM password 모니터링 초기화
shell> eeprom security-#badlogins=0
security-#badlogins=0
x86의 경우 이를 지원하지 않습니다. bios의 password 기능을 추천하고 잇습니다.
4. Keyboard Abort 불가능 하게 하기
스팍 머신의 경우 ctrl-A 키를 사용해버리면 시스템에 재시동해버립니다. 이런 경우를 대비하기 위해서 ctrl-A 키 사용을 불가능하게 해야합니다.
/etc/default/kbd 파일에서
#KEYBOARD_ABORT=enable
를
KEYBOARD_ABORT=disable
로 변경한다.. (주석 지우고 enable를 disable로)
X86인 경우 이런 것이 있다고 넘어가자.. 설정해도 않됩니다. -ㅁ-;;
5. Set-user-ID 와 Set=group-ID 파일들을 체크
내 시스템이 해킹 당했을 것 같다고 생각이 들면 우선 이 파일들 부터 확인해야 안심하니 말입니다.
Set-user-ID, Set-group-ID 파일들은 무엇인가?
가끔 소프트웨어를 실행하다 보면 root가 실행해야하는 경우가 아주 가끔 있다. 이런 소프트웨어의 경우 Set-user-ID, Set-group-ID의 퍼미션을 가지고 root의 작업을 합니다. 해킹 파일의 경우 root 쉘을 따기 위해서 이런 파일을 심어 놓기도 한다.
root의 Set-user-ID, Set-group-ID의 퍼미션을 가지는 파일들을 찾는 방법입니다.
shell> find / -type f -perm -u+s -o -perm -g+s -ls
이렇게 명령어를 실행하면 Set-user-ID, Set-group-ID 파일들이 찾아진다. 이 파일들의 목록을 해커가 찾을 수 없는 다른 곳에 숨겨두거나.. 다른 시스템에 저장해서 파일의 목록을 보존해둡니다.
만약 파일들이 변조되었다고 생각이 든다면 checksum 해봅니다.
선에서는 이런 파일들에 대해서 Fingerprint Database를 운영하고 있다.
http://sunsolve.sun.com에 접속해서 파일에 대한 chechsum을 Fingerprint Database와 비교해봅니다. 변조 되었다면 checksum 값이 다를 것입니다.
참고 md5sum이 없어요.!
당연히 없습니다. 솔라리스 OS에서는 기본적으로 md5sum을 지원하지 않습니다. companian CD나 http://www.gnu.org에서 textutils을 설치하기를 권장하고 있습니다.
md5는 sun.com에서 다운 받으실 수 있으며 스팍용과 x86용 모두 제공되어 집니다.
sun의 핑거프린트와 비교하여 파일의 변조 유무를 검사할 수 있습니다.
sunsolve.sun.com 에서 findegrprint 관련 페이지를 선택하시면 다운 가능합니다.
6. 필요 없는 계정들을 삭제
sendmail을 운영하지 않는 서버라면 smmsp 계정은 필요 없을 것입니다. 당연히 이러한 계정들은 제거합니다. 이런 계정들이 몇가지 존재합니다.
(lp, uucp, nuucp, smmsp 등..)
계정을 살펴보다. 패스워드가 없는 계정들이 있습니다. ("cat /etc/shadow") 이러한 계정들은 NP라는 스트링이 붙어 있습니다. 이런 스트링의 뜻은 "no password"이다. 그러나 가끔 윗선의 관리자들이 특별한 작업을 원하는 경우도 있습니다. 이럴 경우 -l 이라는 옵션을 사용합니다. passwd 명령어에서 -l 옵션은 계정의 잠금을 의미합니다.
shell> passwd -l uucp
이럴 경우 혹시라도 쉘로의 접근 가능성이 불가능해집니다.
또다른 방법으로는 쉘을 변경하는 방법입니다. 시스템에 없는 쉘로 변경해 주면 됩니다.
shell> passwd -e uucp
old shell: /sbin/sh
new shell: /usr/bin/true (또는 /bin/false)
참고로 /usr/bin/true, /usr/bin/false에 대해서 아시고 싶으시다면 man을 추천합니다.
이 방법까지 사용한다면 uucp의 계정을 통한 쉘의 접근이 거의 불가능해집니다. (가능 할수는 있습니다. -ㅁ-;)
7. at, cron의 batch 보안
at나 cron의 경우 실행하기 우선에 at.allow, at.deny, cron.allow, cron.deny의 파일을 먼저 검사해서 cron은 실행되기 앞서 cron.allow 파일을 살펴서 해당 계정이 cron에 접근이 가능한지 검사합니다. 이를 잘 활용하도록 해봅시다.. 해당 계정 이외의 접근은 막도록 합니다. 또한 필요 없는 계정일 경우 지웁니다.
8. System Default Umask를 변경
솔라리스 8의 경우 기본 시스템 파일 모드(default system file mode creation mask)가 000으로 지정되어 있습니다. 이것은 데몬이 파일을 생성할 때 666의 퍼미션을 가지는 파일을 만드므로 아주 위험힙니다. 이것을 변경하도록 합시다.
shell> echo "umask 022" > /etc/init.d/umask.sh
shell> chmod 744 /etc/init.d/umask.sh
shell> chgrp sys /etc/init.d/umask.sh
shell> for d in /etc/rc?.d; do
ln /etc/init.d/umask.sh $d/S00umask.sh
done
shell>
부팅시 시스템의 umask를 022로 지정합니다.
9. NFS 보안
기본적으로 솔라리스 네트워크 파일 시스템(NFS) 서비스 시스템에서는 클라이언트 NFS 서버로 부터의 임의의 포트로 부터의 통신을 허락합니다. 그러나 이러한 요구들은 보안에 영향을 줄 수 있습니다. 그러니 이런 요청들은 privileged system port를 통해 이루어 져야합니다. 만약 시스템에 NFS 서비스가 운용 중이라면 /etc/system 파일에 다음을 추가해줘야 privileged system port로 통신합니다.
set nfssrv:nfs_portmon = 1
10. 실행할 수 있는 stack (STACK Exploitation)
몇가지 해킹 프로그램들은 솔라리스 OE kernel에 특별한 이득을 가지고 있습니다. 왜나하면 기본적으로 "솔라리스의 기본적인 설정은 Stack이 Excuteable한 상태로 설치된다." 이기 때문입니다.
이러한 문제도 다음의 설정을 통해 stack non-executable의 상태로 만들 수 있습니다.
/etc/system 파일에 다음을 추가하도록 합시다.
set noexec_user_stack = 1
set noexec_user_stack_log = 1
다음과 같이 noexec_user_stack_log 가 enable 상태로 운영 중인 솔라리스의 경우, 시스템의 로그 프로그램들은 stack 상의 execute code의 시도를 체크해서 알려줍니다.
이는 exploit 프로그램의 해킹 시도와 유저의 exploit 버그를 이용한 해킹 시도를 알려줘서 보안에 상당한 도움을 줍니다. 이러한 시스템의 보안은 최신의 솔라리스 exploit 프로그램의 해킹 시도를 로그에 남겨주기도 합니다.
로그 메시지
Aug 10 21:57:19 ns unix: sdtcm_convert308 attempt to
execute code on stack by uid 102
이것은 sdtcm_convert 버퍼오버플로의 패치가 되어 있을 경우 나오는 메시지입니다. 그러나 패치를 하지 않은 경우 이러한 stack의 공격에 허술 할 수는 있습니다. 이 설정이 buffer overflow exploition의 모든 공격에서 자유로울 수 있다는 착각에서 벗어나시기 바랍니다. 그러나 Non-executable stack는 버퍼 공격에 조금 더 유동적으로 대처할 수 있게 합니다.
이 옵션이 모든 buffer overflow exploition 프로그램의 공격을 다 막지는 못합니다. 그러나 이 옵션 하에서 움직이는 시스템의 경우 다른 시스템에 비해 조금더 보안 효율성이 높다는 것만 알아줍시다.
항상 염두에 둬야할 부분은 우리는 항상 최신의 security patch를 적용해야 한다는 점입니다. 이 부분은 아무리 강조해도 모자람이 없는 부분입니다.
특히 모든 64 bit 솔라리스 시스템은 non-executable stacks를 항상 default로 지정해야 합니다.
11. Core Files 보안
core 파일은 실행중인 프로세스가 종료 직전 나타내는 시그날 등 유용한 메모리 이미지 정보를 가지고 있습니다. 이러한 이유로 core 파일은 프로그램 에러의 원인을 파악하는데 종종 사용됩니다. 그러나 이러한 core파일도 2가지 문제점을 가지고 있는데 하나는 디스크 용량을 차지 한다는 것, 그리고 아주 민감한 정보를 가질 수 있다는 문제점이 있습니다.
우선 처음의 경우, 거대한 용량의 core파일 발생시 (/) 파일 시스템이 full이라는 에러를 발생시킬 수도 있습니다.
그러나 이것보다 더 중요한 것은 아주 민감한 정보를 가질 수 있다는 점입니다.
만약 개인 유저가 가질 수 없는 민감한 정보를 core파일이 가지고 있으며, 이를 유저가 검사한다면 심각한 문제를 발생 시킬 수 있습니다.
예로 어떤 프로그램이 실행중에 /etc/shadow에 대한 정보를 가지고 있거나, 시스템의 중요한 설정 정보를 저장한체로 core파일을 발생시키고 중단된다면, core 파일은 이러한 정보를 가진체 발생할 것입니다. 이러한 것을 막기 위해 다음과 같은 설정을 해 줍시다.
set sys:coredumpsize = 0
이러한 보안 원인을 위해 솔라리스는 자신의 실 ID와 다른 ID를 가지고 실행 중인 프로세스의 core 파일 발생시키지 않을 것입니다.
12. 로그 (SYSLOG)
/etc/syslog.conf 파일에서
#auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)
위와 같은 내용이 주석 처리되어 있다. 최소한 누군가 계정의 해킹 시도를 알려면 저정도는 주석을 지워줘야 하지 않을까 생각합니다.
적은 량의 계정을 사용할 경우 auth.notice보다는 auth.debug를 사용해서 강력하게 해당 시스템에 접근하는 모든 유저를 감시할 수도 있습니다. 그러나 많은 유저가 오가는 서버일 경우 엄청난 로그 파일을 생성 시키며, 시스템에 무리한 부하를 줄 수 있습니다.
13. 로그(Application Log Files)
application 의 로그 파일들은 다음과 같습니다.
/var/adm/sulog - /var/bin/su
/var/adm/vold.log - /usr/sbin/vold
/var/adm/wtmpx - /usr/bin/login
/var/cron/log - /usr/sbin/cron
위의 로그 파일들을 점검합시다.
또한 솔라리스는 기본적으로 /var/adm/loginlog 파일을 생성하지 않습니다. 이 프로그램은 /usr/bin/login의 로그 파일이며, 로그인 실패를 저장하는 파일이다. 그러니 꼭 파일을 생성해 둬야합니다.
14. Login Command
/etc/default/login 파일에서
CONSOLE=/dev/console
라는 부분이 있습니다. 이것은 root의 경우 console 접속만을 가능하게 설정하는 경우입니다.
만약 root가 serial device만을 통해서 접근이 가능하게 하려면
CONSOLE=/dev/ttya
라고 설정해 주면 됩니다.
이는 모두 root 계정의 직접적인 원격 접속을 막는 방법이 됩니다.
직접적인 접속이 불가능이라는 말이지 간접적인 방법은 모든 계정이 가능합니다. (su라는 유틸이 있는 것을 생각하자)
만약 root 계정의 모든 직접적인 접속을 막으려면 다음과 같이 설정해주면 됩니다.
CONSOLE=-
이러한 이유는 root 계정의 직접적인 노출을 막기 위함입니다.

출처 : http://www.solarisschool.com/tip/view.html?board=tip1&no=17457&start=0&sselect=ssubncon&mode=search&qry_string=보안