솔라리스 OS 보안 (2)

15. 네트워크 서비스 보안 
 
네트워크 서비스는 다른 곳, 또는 유저와 통신을 위해 제공되는 서비스 입니다. 이러한 서비스의 종류에는 웹 서비스(apache), 파일 전송(ftp), 메일 전송(sendmail), 네트워크를 이용한 네트워크 프린팅 서비스, 그리고 원격 접속 서비스 등등... 많은 서비스가 존재합니다. 
그리고 일반적인 솔라리스 OS 설치시 이러한 서비스가 제공되도록 설정되어 있습니다. 그리고 Third-party로 제공되는 여러 어플리케이션으로 서비스가 제공되도록 할 수 있습니다. 
 
일반적인 솔라리스 설치시 이러한 서비스가 제공되도록 \"기본적\"으로 설정되어 있다는 것에 우리는 관심을 두어야 합니다. 이러한 정보들은 제공하려는 서비스 이외에 여러가지 정보를 제공해주는 방법이 되며, 이러한 정보들은 해킹을 시도하는 해커들에거 아주 유용한 정보들이 됩니다. 
 
이러한 이유에서 솔라리스 OS의 최소 설치는 아주 중요한 것이 됩니다. 그렇다고 방법이 없는 것은 아닙니다. 시스템 관리자가 알아서 제공되는 서비스를 제외한 서비스를 중지해주면 됩니다. 
 
 
15-1 네트워크 보안에 사용가능한 여러 툴 
 
이와 같이 네트워크 보안에 사용할 수 있는 여러가지 툴이 존재합니다. 이러한 툴을 먼저 소개하려 합니다. 
 
우선 SunScreen이라는 제품이 있습니다. 이 제품은 네트워크 레벨에서 제공되어 질 수 있는 보안을 제공합니다. 네트워크 로깅, Access에 대한 control이 제공되어 질 수 있습니다. 
이 제품은 shareware로, 2개의 NIC까지 서비스가 가 가능하다는 단점이 있습니다. 이 이상의 제품은 구입을 통해서 가능합니다. 
 
########## 김석님의 추가부분 ############################################ 
sun screen 은 솔라리스 8까지는 2번째 시디에 들어 있고 이버전은 라이트 버전으로 기능제한이 있는 버전입니다. 
그러나 솔라리스 9 부터는 정책이 바뀌어 sun screen 은 오픈으로 전환되어 무료로 사용할 수 있습니다. 
라이트 버전이 아니고 full 버전입니다. 
그럼..^^ 
 
p.s 예전에는 14000 달러 였나 ....그랬다죠...아마...^^ 
######################################################################### 
쿨럭. 저도 만능은 아닙니다. -ㅁ-; 
 
그와 반대로 IP Filter(http://coombs.anu.edu.au/ipfilter)라는 Freeware 방화벽 툴이 있습니다. 이 제품은 솔라리스 2.3 부터 10까지 지원합니다. 그리고 여러가지 형태로 방화벽 구성이 용의하여, 네트워크 보안에 아주 좋은 툴입니다. 여러 형태의 로깅, Access에 대한 control을 지원합니다. 
 
그리고 TCP Warpper라는 open source tool이 있습니다. 이 제품은 TCP 레벨에서 Access, 로깅을 지원합니다.  
 
마지막으로 OpenSSH와 SSH를 들 수 있습니다. SSH의 경우 상용 제품입니다. 이 두개의 툴은 안전하지 않은 telnet, ftp, rlogin. rsh,그리고 rcp등을 대체할 수 있는 제품으로 강력한 인증 보안을 지원합니다. 
 
15-2 서비스들의 간단한 소개 
 
telnet 
 
telnet는 유용한 유틸이지만 보안에 대해 상당한 문제점이 있습니다. 간단한 예로, 텔넷을 통한 접속의 경우, telnet의 TCP를 살펴볼 경우 모든 것이 들어납니다. 이러한 것은 보안에 아주 심각한 영향을 줄 수도 있습니다. 
예를들어 같은 네트워크 망에서 sniff툴을 이용해 TCP를 모니터링 할 경우, telnet 을 이용한 접속의 경우 ID, passwd, telnet를 통해서 하는 작업이 그대로 들어납니다. 이것은 보안에 있어 아주 치명적인 결과를 초래할 수 있습니다. 
대체가 가능한 서비스(Openssh, ssh)가 있다면 이서비스는 중지하는 것이 좋습니다. 
 
Remote Access Services (rsh, rlogin, and rcp) 
 
이러한 유틸리티들은 해당 서비스에 passwd 없이 접속할 수 있는 도구로 사용됩니다. 그러나 이런 것들은 보안에 아주 심각한 원인을 유발 할 수 있는 것들입니다. 
예로 서버에서 모든 호스트들의 접속을 허용하고, rsh 또는 rlogin을 허용할 경우, 외부에서 passwd 없이 바로 root나 해당 계정으로 접속이 가능합니다. 
이러한 서비스에 대한 보안으로 Kerberos를 이용한 방법이 대두되고 있습니다만, 이러한 서비스는 해당 시스템에 심각한 보안적 헛점을 유발한다고 항상 염두에 두어야합니다. 
가능하면 이 서비스도 중지하는 것이 좋습니다. 
 
Remote Execution Service (rexec) 
 
recec 데몬 서버의 이름은 in.rexecd 이며, /etc/initd.conf를 통해서 실행됩니다. 이 데몬은 계정과 password 정보를 기본으로 실행이 됩니다. 그러나 이 데몬은 in.telnetd 데몬을 통해서 계정과 password를 주고 받습니다. 이중 가장 문제가 되는 부분이 in.telnetd 데몬을 통해서 정보를 주고 받는다는 것인데, 위에서 설명이 나왔다 싶이 telnet 서비스는 보안이 가장 허술한 면모를 보이는 서비스입니다. 
이서비스는 반드시 중지해야할 서비스 입니다. 
 
FTP 
 
ftp 또한 telent과 마찬가지로 TCP를 통해 계정과 비밀번호를 전달 받지만, TCP를 살펴보면 계정과 비밀번호가 그대로 들어나는 단점이 있습니다. 
만약 ftp를 운영해야 한다면 2가지 방법이 있습니다. 하나는 특정 계정에 대한 접속을 제한하도록 해야합니다. 솔라리스에서 제공되는 ftp를 사용할 경우 /etc/ftpusers 파일에 ftp를 통해서 서비스에 접근할 수 없는 계정을 등록해서 ftp를 통해서 등록하지 말아야하는 계정을 꼭 등록해 놓기 바랍니다. 다른 방법으로는 모든 connecting와 해당 서비스에서 하는 commands를 로깅하는 방법입니다. 이러한 로깅은 syslog 서비스를 통해서 가능합니다. 
 
Trivial FTP 
 
Trivial FTP 서비스는 disk-less 시스템에서 네트워크를 통한 파일에 대한 접근이 가능하도록 하는 서비스입니다. 이 in.tftpd 데몬은 인증이 필요 없고, 단지 일반적으로 읽기가 가능하도록 설정해 엄격한 디렉토리에 대한 접근이 가능하도록 설정되어져 있습니다. 
기본으로 이서비스도 중지하는 것이 좋습니다. 
 
15-3. inetd Manaaged Services 
 
inetd 데몬은 시스템에서 사용가능한 minor network service에 대한 대부분의 콘트롤을 하는 서비스 입니다. 이 데몬에 대한 설정 파일은 /etc/inetd.conf입니다. 
/etc/inetd.conf 파일이 없다면 inetd 데몬이 실행되지 않으며, /etc/inetd.conf는 자주 읽어 지는 파일이 아니라 실행시 한번 읽어 들여 inetd 데몬이 실행합니다. 즉 /etc/inetd.conf 파일이 변경되어 진다면 inetd 데몬이 재 실행해야 합니다. 
만약 /etc/inetd.conf 에 존재하는 서비스를 중지시키려면 첫줄에 comment(#)를 붙이면 됩니다. 
 
이미 TELNET, Remote Access Services, Remote Execution Sservice, FTP, TFTP에 대한 서비스에 대해서 위에서 설명했습니다. 그 외의 서비스에 대해서 살펴보도록 하겠습니다. 
 
* in.tnamed - DARPA 네임 서비스 프로토콜을 지원하는 서비스입니다. 이 서비스는 중지되어야 합니다. 
 
* in.uucpd - 네트워크를 통한 UUCP 접속을 지원하는 서비스입니다. UUCP 서비스가 제공되어 지지 않는다면 중지되어야 합니다. 
 
* in.fingerd - 해당 시스템의 계정의 정보를 제공하는 서비스 입니다. 이 서비스가 필요 없다면 중지하십시요. 
 
* systat - 시스템에 접속한 어떤 계정이나 사람이라도 ps -ef에 대한 OUTPUT에 대해 정보를 제공합니다. 이 서비스는 너무 많은 시스템 정보를 제공하므로 반드시 중지해야 합니다. 
 
* netstat - 이 서비스 netstat command에 대해 외부 네트워크 접속에 대한 정보를 제공합니다. 이 서비스는 반드시 중지되어야 합니다. 이 서비스가 제공하는 정보는 시스템에 대한 공격의 정보가 될 수 있습니다. 
 
* time - 현재 시간을 표시해 주는 서비스입니다. 솔라리스 2.6 부터 xntp 함수는 시간에 대해 Synchronization 해주는 함수가 있습니다. 그러므로 xntp 데몬이 rdate와 time보다는 더 나은 보안을 제공합니다. 그러니 xntp를 사용하는 것이 좋습니다. 
 
* echo - 들어오는 data stream에 대해서 제 출력 해주는 데몬입니다. 이 서비스도 중지해야 합니다. 
 
* discard - 들어오는 data stream에 대해 버리는 데몬입니다. 이 서비스도 중지해주십시요. 
 
* chargen - stream chracters를 발생시키는 데몬입니다. 이 서비스도 중지해주십시요. 
 
이 서비스들에 대해서 /etc/inetd.conf에서 대부분의 시스템에서 제거해주는 것이 좋습니다. 그리고 /etc/inetd.conf에서 제공되는 서비스들은 접속이 들어올 시 로깅이 되도록 설정해주는 것이 좋습니다. 덧붙이 inetd 데몬이 실행하는 start script는 /etc/init.d/inetsvc입니다. 
 
15-3. RPC Service 
 
RPC는 원격 시스템에 대한 요청에 procedure를 만드는 것입니다. (process가 아니다.) 
RPC 서비스는 많은 유닉스 서비스에서 사용되고 있습니다. 예를들어서 NFS, NIS, NIS++, 그리고 Kerberos 입니다. 또한 Solstice, DiskSuite 소프트웨어, 선 클러스터 소프트웨어등에서 사용됩니다. RPC 서비스가 시작된다면, 이 서비스들은 rpcbind 데몬에 어떤 주소로 어떻게 네트워크 요청을 들어야 할지 요청합니다. 그리고 클라이언트에서 RPC 프로그램 번호에 대한 요청이 들어왔을 때, rpcbind는 어느 주소로 어떤 번호로 요청을 보내야 할지를 전해 줍니다. 
 
RPC(rpcbind)는 자체적으로 해커에게 시스템의 정보를 줄 수 있습니다. 사실 이것은 보안문제에 있어 문제가 아닙니다. 그러나 강력한 인증 메카니즘이 없는 서비스를 제공할 경우. 이러한 RPC는 보안 문제로 대두될 수 있습니다. 
 
솔라리스 시스템은 다음과 같은 데몬 또는 서비스가 제공되어 집니다. 
 
### /etc/inetd.conf 에서 
 
* testsvc 
* kcms.server 
* sadmind 
* ufsd 
* rquotad 
* cachefsd 
* kerbd 
* xaudio 
* rpc.rusersd 
* rpc.sprayd 
* rpc.rwalld 
* rpc.rstatd 
* rpc.cmsd 
* rpc.ttdbserver 
* rpc.rexd 
 
### /etc/init.d/rpc 에서 
 
* rpcbind 
* nis_cachemgr 
* keyserv 
* rpc.nispasswdd 
* rpc.nisd 
 
### /etc/init.d/nfs.server 에서 
 
* rpc.bootparamd 
 
대부분의 서버에서는 /etc/inetd.conf 상의 RPC 서비스들은 제거하는 것이 좋다. 
그리고 NIS의 경우 보안 모델이 취약한 관계로 제공하지 않는 것이 좋다. 
이러한 서비스를 제공하고 싶다면 몇가지 문서를 참고로 해서 보안 모델을 적용해서 실행하는 것이 좋다.

출처 : http://www.solarisschool.com/

너 무슨생각하니? | 형수형
http://blog.naver.com/gudtn7995/90000378743

솔라리스 OS 보안(1)

참고 : 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_convert[308] 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://blog.naver.com/gudtn7995/90000378411