프로젝트 Lockdown
데이터베이스 인프라스트럭처의 보안을 위한 단계적 접근법
저자 - Arup Nanda 
게시일: 2006년 5월 - 목차 참조
1 단계기간: 1 일보안/컴플라이언스 프로젝트의 1 단계에서는, 24시간 이내에 인프라스트럭처 보안 체계를 구현하기 위한 방법을 알아 봅니다. 목차:· 1.1 디폴트 패스워드의 제거 · 1.2 오라클 바이너리 권한 설정 · 1.3 다른 실행 파일의 보안 · 1.4 umask의 사용 · 1.5 SYSDBA 로그인의 제한 · 1.6 Listener 패스워드의 생성 · 1.7 Listener의 보호 · 1.8 과도한 권한의 제한 · 1.9 DBSNMP 패스워드의 변경 1.1 디폴트 패스워드의 제거 배경 SQL> select username, password 2 from dba_users 3 where username = 'SCOTT'; USERNAME PASSWORD ------------------------------ ------------------ SCOTT F894844C34402B67 패스워드가 해쉬 처리 되어 있기 때문에 해독이 불가능하지만, SCOTT의 암호가 “tiger”라는 사실은 알고 있습니다. 따라서 사용자 아이디가 “scott”인 경우 “tiger”의 해쉬값은 F894844C34402B67입니다. SCOTT의 패스워드가 변경되면 해쉬값도 역시 변경됩니다. DBA_USERS 뷰를 통해 SCOTT의 암호가 이 해쉬값과 일치하는지 확인하면 암호가 “tiger”인지 알 수 있습니다. 하지만 패스워드의 문자열 만으로 해쉬값이 결정되는 것은 아니라는 사실을 참고하실 필요가 있습니다. 다른 사용자가 “tiger”라는 암호를 갖는 경우, 그 해쉬값은 달라지게 됩니다.. SQL> create user scott2 identified by tiger; User created. SQL> select username, password 2 from dba_users 3 where username = 'SCOTT2'; USERNAME PASSWORD ------------------------------ -------------------- SCOTT2 C44C11D4C34DB67D 위의 예와 같이, 패스워드가 동일함에도 다른 해쉬값( C44C11D4C34DB67D)이 표시되고 있습니다. CREATE TABLE osp_accounts ( product VARCHAR2(30), security_level NUMBER(1), username VARCHAR2(30), password VARCHAR2(30), hash_value VARCHAR2(30), commentary VARCHAR2(200) ) 다음으로 피트가 수집한 데이터를 테이블에 로드합니다. (스크립트는 이곳에서 다운로드할 수 있습니다.) 테이블이 로드되었다면, 디폴트 패스워드를 검색할 준비를 모두 마친 셈입니다. 간단한 SQL 구문을 사용하여 사용자를 검색해 봅시다.) col password format a20 col account_status format a20 col username format a15 select o.username, o.password, d.account_status from dba_users d, osp_accounts o where o.hash_value = d.password / 위에서, 가장 우려했던 문제가 발견되었습니다. 마지막 라인에서 SYS의 패스워드가 “ORACLE”로 설정되어 있습니다! “change_on_install”보다는 낫겠지만, 그래도 쉽게 알아맞힐 수 있는 패스워드임에는 분명합니다. alter user dmsys account lock expire password; 위 구문을 실행하면 계정이 EXPIRED & LOCKED 상태로 설정되었습니다. 사용자가 로그인을 시도하면 아래와 같은 에러가 발생합니다. ERROR: ORA-28000: the account is locked Warning: You are no longer connected to ORACLE. 잠금 설정을 할 수 없는 계정에 대해서는 패스워드를 변경해 줍니다. 그 한 가지 예로 DBNSMP를 들 수 있습니다 (여기에 대해서는 뒷부분에서 다시 설명합니다.) 주의 사항사용되지 않는 계정을 잠그는 것으로 인해 문제가 발생할 이유는 없습니다. 실행 계획
1.2 오라클 바이너리 권한의 설정 배경 정보 # cd $ORACLE_HOME/bin # ls -l oracle -rwsr-s--x 1 oracle oinstall 69344968 Jun 10 14:05 oracle 실행 권한은 디폴트 값으로 설정되어 있습니다. (권한은 오라클 버전에 관계없이 동일하게 설정됩니다.) 각각의 설정이 의미하는 바를 확인해 보시다 (UNIX 실행 권한의 개념에 익숙하다면, 이 섹션을 생략하고 "2-태스크 아키텍처"로 바로 진행하셔도 됩니다.)
각 권한은 특정 값 또는 “-“의 값을 갖습니다. “-“은 해당 권한이 부여되지 않았음을 의미합니다. 실행 예의 6 번째 위치에서 Group에 대한 쓰기 권한이 “-“로 표시되어 있습니다. 따라서 (파일이 소속된) “dba” 그룹은 이 파일에 쓰기 작업을 수행할 수 없습니다. 권한이 부여된 경우에는, 해당되는 값이 문자로 표시됩니다. 실행 예에서 그룹의 읽기 권한(5번째 문자)이 “r”로 표시되어 있으므로 “dba” 그룹은 이 파일을 읽을 수 있습니다. “Two-Task” 아키텍처. 오라클 데이터베이스가 사용자 프로세스와 서버 프로세스를 구분하여 실행한다는 사실을 기억하고 계실 줄 압니다. 기억이 잘 나지 않는다면, Oracle Database 10g Concepts Manual 의 앞 부분 몇 챕터를 읽어 보시기 바랍니다. 이 자료는 오라클 데이터베이스의 실행 방식에 대해 매우 간략한 형태로 설명하고 있으며, 권한에 대한 기본적인 개념을 이해하는데 도움이 됩니다. (하지만 제품 매뉴얼의 내용만큼 자세하지는 않습니다.) $ sqlplus arup/arup 다음으로 프로세스를 조회해 봅시다: $ ps -aef|grep sqlplus 그러면 아래와 같은 결과가 표시됩니다: oracle 6339 6185 0 13:06 pts/0 00:00:00 sqlplus 여기서는 다른 SQL*Plus 세션이 서버에서 실행 중이지 않음을 가정하고 있습니다. $ ps -aef|grep 6339 두 개의 프로세스가 결과로 출력됩니다: oracle 6339 6185 0 13:06 pts/0 00:00:00 sqlplus oracle 6340 6339 0 13:06 ? 00:00:00 oracleDBA102 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 첫 번째 프로세스(SQL*Plus 세션을 위한 프로세스)는 이미 우리가 잘 알고 있는 것입니다. 두 번째 프로세스(프로세스 ID 6340)은 오라클이 사용자를 위해 생성한 서버 프로세스입니다. 여기서 프로세스의 Parent Process ID(6339)가 SQL*Plus 세션의 프로세스 ID임을 알 수 있습니다. select spid from v$session s, v$process p where s.sid = (select sid from v$mystat where rownum <2) and p.addr = s.paddr; 위 쿼리를 실행하면 서버 프로세스의 프로세스 ID가 반환됩니다. 클라이언트 프로세스가 다른 서버에서 실행 중이라면(예: 사용자의 노트북에서SQL*Plus으로 데이터베이스에 접속한 경우), 이 쿼리가 프로세스 ID를 확인하기 위한 유일한 방법입니다. DBA102 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradba)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = DBA102)
)
)
이제 사용자가 아래와 같은 방법으로 oradba 서버에 연결합니다: sqlplus arup/arup@dba102 다이내믹 뷰에서 프로세스 ID를 확인해 봅시다: SQL> select spid 2 from v$session s, v$process p 3 where s.sid = (select sid from v$mystat where rownum <2) 4 and p.addr = s.paddr 5 / SPID ------------ 6428 프로세스 ID는 6428입니다. 프로세스 ID를 기준으로 서버의 프로세스를 조회해 보겠습니다: $ ps -aef|grep sqlplus | grep -v grep oracle 6426 6185 0 13:20 pts/0 00:00:00 sqlplus 이제 데이터베이스 서버의 서버 프로세스를 검색하면 아래와 같은 결과를 얻습니다: $ ps -aef|grep 6426 | grep -v grep oracle 6426 6185 0 13:20 pts/0 00:00:00 sqlplus ....서버 프로세스가 확인되지 않았습니다. 사용자 프로세스 6426의 자식 프로세스가 존재하지 않습니다. 하지만 다이내믹 성능 뷰를 통해 서버 프로세스의 ID가 6428이라는 사실은 이미 확인했습니다. 그렇다면 프로세스 ID 6428의 부모 프로세스는 누구일까요? $ ps -aef|grep 6428 | grep -v grep oracle 6428 1 0 13:20 ? 00:00:00 oracleDBA102 (LOCAL=NO) 부모 프로세스는 “1”입니다. 왜 6426이 아니고 1일까요? $ chmod 4700 $ORACLE_HOME/bin/oracle 명령을 실행한 후의 권한 설정이 아래와 같습니다. -rws------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle 여기서는 SUID 비트를 이용하여 설정을 변경하는 방법을 사용하기로 합니다. 이 경우 (소유자의 rws 권한에 명시된 대로) SUID 비트는 ON으로 설정되어 있습니다. 전략오라클 소프트웨어 소유자(“orasoft”) 이외의 어떤 사용자도 오라클 실행 파일을 실행할 필요가 없으므로, SUID 비트를 제거하고 바이너리의 소유자에 의해서만 접근이 가능하도록 설정해야 합니다. $ chmod 0700 $ORACLE_HOME/bin/oracle 변경된 설정이 아래와 같습니다: -rwx------ 1 orasoft oinstall 248754168 Oct 8 07:11 oracle 주의 사항 $ sqlplus arup/arup 사용자는 아래와 같은 에러를 확인하게 됩니다. ERROR: ORA-12546: TNS:permission denied Enter user-name: 그 이유는 아주 간단합니다. “oracle” 파일의 SUID 권한을 제거했기 때문입니다. 사용자가 로컬 연결을 시도한다는 것은, 결국 사용자가 “oracle” 실행 파일을 실행함을 의미합니다. 하지만 SUID가 설정되어 있지 않으므로 “orasoft”가 아닌 “ananda”의 이름으로 실행됩니다. ananda가 이 파일을 실행할 권한이 없으므로 ORA-12546 에러가 발생하는 것입니다. $ sqlplus arup/arup@dba102 위 명령은 다른 서버에서 사용자가 접근하는 것과 같은 효과를 갖습니다. 따라서 오라클 소프트웨어를 소유한 사용자(orasoft)만이 “bequeath” 연결을 통해 데이터베이스에 연결함을 보장할 수 있습니다. $ sqlplus /nolog SQL> connect sys/Password_of_SYS@dba102 as sysdba 이 경우 SYS 암호를 사용하게 되며, 이는 “/ as sysdba”보다 더 효과적인 방법입니다. 하지만 좀 더 나은 방법은 각각의 DBA를 위해 별도의 Oracle UserID를 생성하는 것입니다. connect ANANDA/Password_of_ANANDA@dba102 as sysdba 해커들은 임의의 계정을 이용하여 데이터베이스에 강제 침입하는 방법을 즐겨 사용하곤 합니다(이때 자주 사용되는 계정이 “nobody”입니다). 해커가 데이터베이스에 진입하지 못한 경우라도 오라클 실행 파일에 버퍼 오버플로우를 발생시켜 DoS 공격을 시도하는 것이 가능합니다. 파일의 실행 권한을 제거하는 방법으로, 공격의 피해를 극적으로 감소시킬 수 있습니다. 이렇게 하더라도, 합법적인 사용자는 아무런 제약을 받지 않습니다. 대부분의 사용자는 리스너를 사용하여 데이터베이스에 연결하므로 설정 변화에 아무런 영향을 받지 않습니다. 실행 계획준비 작업 “bequeath” 연결을 사용하여 시스템에 접근하는 사용자가 있는지 확인합니다. 두 가지 방법이 가능합니다:
select program from v$session where machine = '<machine_name>'; 의심스러운 문제가 발견되었다면, 감사(audit) 기능을 활성화하여 실행 중인 프로그램을 확인하고 그 결과를 캡처합니다 (여기에 대해서는 다음 단계에서 상세하게 설명합니다) Action
1.3 다른 실행 파일의 보안 배경 정보 $ cd $ORACLE_HOME
$ find . -type f \( -perm -2000 -o -perm -4000 \) -exec ls -l {} \;
Oracle Database10g Release 1 이후 버전에서는 아래와 같은 실행 파일이 반환됩니다: -rwsr-s--x 1 orasoft dba 93300507 Jul 22 11:20 ./bin/oracleO -r-sr-s--- 1 root dba 0 Jul 1 23:15 ./bin/oradism -rwsr-s--x 1 orasoft dba 94492 Jul 22 11:22 ./bin/emtgtctl2 -rwsr-s--- 1 root dba 18944 Jul 22 11:22 ./bin/nmb -rwsr-s--- 1 root dba 20110 Jul 22 11:22 ./bin/nmo -r-sr-sr-x 1 nobody nobody 58302 Jul 22 11:23 ./bin/extjob 각각의 파일에 대해 알아 보겠습니다:
Oracle9i Database Release 2에서는 ./bin/dbsnmp 파일(Oracle Intelligent Agent 실행 파일)이 존재합니다. 이 파일의 권한은 아래와 같이 설정되어 있습니다: -rwsr-s--- 1 root dba 2986836 Jan 26 2005 dbsnmp 이 파일은 루트 권한이 있어야만 정상적으로 실행이 가능하며, 따라서 SUID 비트가 설정되어 있어야 합니다. 하지만 이 파일이 루트 계정에 의해 소유되어 있기 때문에, 해커들이 루트 권한을 획득하는 방법으로 활용되기도 합니다. 가장 좋은 방법은 파일을 제거하거나 오라클 소프트웨어의 소유자가 이 파일을 소유하도록 하고 권한을 700으로 설정하는 것입니다. 이로 인해 일부 기능이 제약될 수도 있지만, 그 정도의 위험을 감수할 만한 가치가 있습니다. tnslsnr – 리스너의 실행 파일 설정된 권한을 조회해 봅시다: $ ls -l *lsnr* -rwxr-x--x 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl -rwxr-xr-x 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0 -rwxr-x--x 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr -rwxr-xr-x 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0 두 파일에 대해 모든 사용자에게 실행 권한이 부여되어 있습니다. oracleO 실행파일과 마찬가지로, 오라클 소프트웨어의 재링크(relink)를 통해 새로운 tnslsnr 파일이 생성되면 기존의 tnslsnr 파일은 tnslsnr0로 이름이 변경됩니다. tnslsnr0 파일은 프로세스를 롤백 해야 하는 경우에 기존의 실행 파일을 새로운 파일에 덮어쓰기 할 때 사용됩니다. tnslsnr0 파일은 기존의 tnslsnr 파일과 동일한 기능을 수행할 수 있습니다. lsnrctl0 파일 역시 마찬가지입니다. 전략
리스너에 관련된 파일의 권한은 아래와 같은 방법으로 변경합니다. $ chmod 700 lsnrctl tnslsnr $ chmod 000 lsnrctl0 그 결과를 확인해 봅시다. $ ls -l *lsnr* -rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl ---------- 1 orasoft oinstall 214720 Oct 1 18:50 lsnrctl0 -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr ---------- 1 orasoft oinstall 1118816 Oct 1 18:50 tnslsnr0 주의 사항
1.4 umask의 사용 배경 정보 $ chmod 444 * 이제 해당 디렉토리에 내용이 없는 파일 하나를 생성하고 그 권한을 확인합니다. $ touch a_file.txt $ ls -l a_file.txt -rw-r--r-- 1 orasoft dba 0 Oct 21 13:44 a_file.txt 소유자에 대해 읽기/쓰기, 그룹에 대해 읽기, 그리고 다른 사용자에 대해 읽기 (644) 권한이 설정되어 있습니다. 여러분이 기대했던 444와는 다른 결과입니다. 그 이유가 무엇일까요? $ umask 777 $ touch b_file.txt $ ls -l ?_file.txt -rw-r--r-- 1 oracrmp dba 0 Oct 21 13:44 a_file.txt ---------- 1 oracrmp dba 0 Oct 21 13:53 b_file.txt b_file.txt 파일의 권한이 000으로 설정되어 있음을 확인하시기 바랍니다. 하지만 앞에서 생성된 a_file.txt의 권한은 변경되지 않았습니다. umask의 값(777)은 새로운 파일에만 영향을 미친다는 사실을 알 수 있습니다. 전략
주의 사항
1.5 SYSDBA 로그인의 제한 배경 정보 “dba” 그룹에 포함된 UNIX/Linux 사용자는 아래와 같은 명령을 이용하여 SYSDBA 권한으로 로그인할 수 있습니다: sqlplus / as sysdba DBA가 SYS 패스워드를 기억하거나 입력할 필요가 없다는 편의성 때문에 이러한 방법이 자주 사용되곤 합니다. 하지만 이로 인한 취약점 또한 존재합니다. dba 그룹 멤버로 로그인할 수 있는 모든 사용자는 SYS 권한으로 데이터베이스에 로그인할 수 있습니다. SYS에 아무리 강력한 암호 체계를 적용해도 이는 무용지물과 다름없습니다. SYS 계정의 강력한 권한을 보호하려면 dba 그룹이 SYS 계정으로 로그인하면서 SYS 암호를 반드시 입력하도록 하는 것이 좋습니다. 이런 방법으로 외부 침입을 완전히 차단할 수는 없겠지만, 그 위험을 상당 수준 줄일 수 있습니다. 전략 SQLNET.AUTHENTICATION_SERVICES=(NONE) 이제 dba 그룹에 포함된 사용자가 아래와 같은 방법으로 로그인을 시도하면: $ sqlplus / as sysdba 다음과 같은 에러를 확인하게 됩니다: ERROR: ORA-01031: insufficient privileges 성공적으로 연결하기 위햇는 SYS 패스워드를 함께 입력해야 합니다: $ sqlplus /nolog SQL> connect sys/oracle as sysdba 이와 같은 방법으로 SYS 패스워드를 알지 못하는 해커가 dba 계정을 이용하여 접근을 시도하는 것을 차단할 수 있습니다. 주의 사항
1.6 Listener 패스워드의 생성 배경 정보 LSNRCTL> set displaymode verbose
LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)
(HOST=prolin1.proligence.com)(PORT=1521)(IP=FIRST)))
Services Summary...
Service "PROPRD" has 1 instance(s).
Instance "PROPRD1", status READY, has 1 handler(s) for this
service...
Handler(s):
"DEDICATED" established:0 refused:0 state:ready
LOCAL SERVER
(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=/u01/oracle/products/10.1/db1/bin/ora
cle)(ARGV0=oraclePROPRD11)(ARGS='(LOCAL=NO)')(ENVS='_=/u01/oracle/pro
ducts/10.1/db1/bin/racgmain,_USR_ORA_CONNECT_STR=/ as
sysdba,_CAA_CHECK_INTERVAL=600,SHLIB_PATH=/u01/oracle/products/10.1/d
b1/lib32:/u01/oracrs/10gr1crs/lib32:/opt/nmapi/nmapi2/lib/hpux32:,_CA
A_ACTIVE_PLACEMENT=0,PATH=,_USR_ORA_ALERT_NAME=,_USR_ORA_IF=,_CAA_OPT
IONAL_RESOURCES=,_USR_ORA_START_TIMEOUT=0,ORACLE_BASE=/u01/oracle/pro
ducts/10.1/db2,_USR_ORA_DISCONNECT=false,_CAA_SCRIPT_TIMEOUT=600,_CAA
_UPTIME_THRESHOLD=7d,_USR_ORA_STOP_TIMEOUT=0,_CAA_FAILOVER_DELAY=0,_U
SR_ORA_PRECONNECT=none,_USR_ORA_FLAGS=,_CAA_TYPE=application,_USR_ORA
_INST_NOT_SHUTDOWN=,_CAA_REASON=boot,INIT_STATE=3,_USR_ORA_OPEN_MODE=
,_CAA_STATE=:OFFLINE,,_CAA_RESTART_ATTEMPTS=5,_CAA_ACTION_SCRIPT=/u01
/oracle/products/10.1/db1/bin/racgwrap,_CAA_DESCRIPTION=CRS
application for
Instance,_CAA_HOSTING_MEMBERS=prolin1,ORA_RACG_EXEC_ENV=LD_LIBRARY_PA
TH=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nm
api/nmapi2/lib/hpux64:/usr/lib:,_CAA_CLIENT_LOCALE=,_CAA_NAME=ora.PRO
PRD1.PROPRD11.inst,ORA_CRS_HOME=/u01/oracrs/10gr1crs,_CAA_AUTO_START=
1,_CAA_TARGET=:ONLINE,,_USR_ORA_PFILE=,_USR_ORA_OPI=false,_USR_ORA_CH
ECK_TIMEOUT=0,_CAA_PLACEMENT=restricted,_USR_ORA_LANG=,LD_LIBRARY_PAT
H=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nma
pi/nmapi2/lib/hpux64:/usr/lib:,_CAA_REQUIRED_RESOURCES=ora.prolin1.vi
p,_CAA_FAILURE_THRESHOLD=0,ORACLE_HOME=/u01/oracle/products/10.1/db1,
_USR_ORA_SRV=,PWD=/u01/oracrs/10gr1crs/bin,_USR_ORA_VIP=,_USR_ORA_STO
P_MODE=immediate,_CAA_FAILURE_INTERVAL=0,_USR_ORA_NETMASK=,_USR_ORA_D
EBUG=0,ORACLE_SID=PROPRD1,ORA_NET2_DESC=9,12,ORACLE_SPAWNED_PROCESS=1
')(ENV_POLICY=NONE))
또 다른 해킹 유형으로 리스너를 셧다운하는 방법이 있습니다. 새로운 연결은 거부되며, 따라서 실질적인 서비스 거부 공격이 가능합니다. 또는 다른 서버에 먼저 침입한 후 리스너의 원격 관리 기능을 이용하여 리스너를 원격에서 종료하는 방법이 가능합니다. 이러한 위협으로부터 데이터베이스를 보호하려면 어떻게 해야 할까요? 전략 -rwx------ 1 orasoft oinstall 214720 Oct 25 01:23 lsnrctl -rwx------ 1 orasoft oinstall 1118816 Oct 25 01:23 tnslsnr 경우에 따라 리스너의 시작/종료 권한을 다른 사용자에게 허용해야 할 수도 있습니다. 이러한 경우라면 아래와 같이 권한을 변경해 주어야 합니다. $ chmod 0711 lsnrctl 하지만 이와 같은 경우라 하더라도 패스워드 정책을 통해 불법적인 침입을 차단할 수 있어야 합니다. 패스워드를 설정하면 (HELP와 같은 무해한 명령을 제외한) 모든 커맨드가 비활성화됩니다.
패스워드의 설정 방법이 아래와 같습니다: $ lsnrctl LSNRCTL> change_password Old password: <OldPassword> Not displayed New password: <NewPassword> Not displayed Reenter new password: <NewPassword> Not displayed Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521)(IP=FIRST))) Password changed for LISTENER The command completed successfully 패스워드를 처음으로 설정하는 경우, “Old Password”를 묻는 프롬프트에서 그냥 ENTER 키를 눌러도 됩니다. 변경 사항을 적용한 뒤 그 결과를 매개변수 파일에 저장합니다: LSNRCTL> save_config 위 커맨드는 패스워드를 암호화하여 리스너 매개변수 파일에 저장합니다. 그 내용은 나중에 확인이 가능합니다: #----ADDED BY TNSLSNR 24-OCT-2005 17:02:28--- PASSWORDS_LISTENER_ODSSDB01 = 75CD180DE6C75466 #-------------------------------------------- 이제 커맨드를 사용하려면 패스워드를 입력해야 합니다 (Oracle Database 10g 및 이후 버전에서는 소프트웨어를 소유한 OS 사용자는 패스워드를 입력할 필요가 없습니다.) LSNRCTL> services Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) TNS-01169: The listener has not recognized the password 패스워드를 입력하는 방법이 아래와 같습니다: LSNRCTL> set password mypassword The command completed successfully LSNRCTL> status Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ------------------------ Alias LISTENER ... 잘못된 패스워드가 입력되면 아래와 같은 에러가 뜹니다. TNS-01169: The listener has not recognized the password. 패스워드를 입력하지 않고 명령을 실행하면 아래와 같은 에러가 뜹니다. TNS-01190: The user is not authorized to execute the requested listener command 패스워드가 적용되었는지 확인하기 위해서는 아래와 같이 실행하여 리스너의 STATUS 설정을 조회합니다: $ lsnrctl status 출력 결과는 버전에 따라 다릅니다. Oracle9i Database 환경의 실행 결과 중 일부가 아래와 같습니다: STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Solaris: Version 9.2.0.6.0 - Production Start Date 25-OCT-2005 10:26:47 Uptime 0 days 13 hr. 8 min. 36 sec Trace Level off Security ON 마지막 라인(Security ON)에서 패스워드가 설정되었음을 확인할 수 있습니다. Oracle Database 10g에서는 설정 방법이 조금 다릅니다. 10g의 경우 오라클 소프트웨어의 소유자만이 패스워드 없이 리스너를 실행할 수 있도록 설정되어 있습니다. 따라서 패스워드가 설정된 경우, 다른 사용자들은 패스워드를 입력한 경우에만 리스너의 실행이 가능합니다. STATUS 설정값의 확인 결과가 아래와 같습니다: STATUS of the LISTENER ------------------------ Alias LISTENER_ODSPDB02 Version TNSLSNR for HPUX: Version 10.1.0.4.0 - Production Start Date 16-OCT-2005 05:58:35 Uptime 9 days 17 hr. 44 min. 41 sec Trace Level off Security ON: Local OS Authentication 마지막 라인(ON: Local OS Authentication)에서 패스워드가 설정되지 않았음을 알 수 있습니다. 패스워드가 설정된 경우에는 아래와 같이 표시됩니다: Security ON: Password or Local OS Authentication “Password”라는 단어를 통해 패스워드가 설정되어 있음을 알 수 있습니다. 주의 사항
1.7 리스너의 보호 배경 정보 LSNRCTL> set trc_level support Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_level" set to support The command completed successfully LSNRCTL> set trc_directory /tmp Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=prolin1)(PORT=1521))) LISTENER parameter "trc_directory" set to /tmp The command completed successfully 트레이스 레벨이 SUPPORT로 설정되어 있으므로 리스너는 해커에게 유용한 여러 가지 정보를 출력합니다. 또 트레이스 파일이 /tmp 디렉토리에 저장되므로 조회하기가 쉽습니다. 해커는 이러한 정보를 서버에 직접 로그인하지 않고도 파악할 수 있습니다. 전략 ADMIN_RESTRICTIONS_LISTENER = ON 그런 다음 리스너를 재시작합니다. 이제는 lsnrctl 프롬프트에서 SET 커맨드를 사용할 수 없습니다. 실행 예가 아래와 같습니다: LSNRCTL> set trc_directory /hacker_dir Connecting to (ADDRESS=(PROTOCOL=IPC)(KEY=PROPRD1)) TNS-12508: TNS:listener could not resolve the COMMAND given 위에서 볼 수 있듯 TNS-12508 에러가 발생하였습니다. 이제부터는 설정 값을 변경하려면 listener.ora 파일을 수정하고 커맨드를 다시 로드해야 합니다. LSNRCTL> reload 이 방법은 모든 오라클 버전에 동일하게 적용됩니다. 주의 사항
1.8 과도한 권한의 제한 배경 정보 전략 set pages 50000
break on privilege skip 1
select privilege, grantee, admin_option
from dba_sys_privs
where privilege not in
(
/* list any other privilege here you don't find
"sweeping"
*/
'ALTER SESSION',
'QUERY REWRITE',
'CREATE DIMENSION',
'CREATE INDEXTYPE',
'CREATE LIBRARY',
'CREATE OPERATOR',
'CREATE PROCEDURE',
'CREATE SEQUENCE',
'CREATE SESSION',
'CREATE SNAPSHOT',
'CREATE SYNONYM',
'CREATE TABLE',
'CREATE TRIGGER',
'CREATE TYPE',
'CREATE USER',
'CREATE VIEW',
'UNLIMITED TABLESPACE'
)
and grantee not in
('SYS','SYSTEM','WKSYS','XDB',
'MDSYS','ORDPLUGINS','ODM','DBA')
/* Place all the user names you want to exclude */
order by privilege, grantee
/
쿼리 실행 결과의 일부가 아래와 같습니다: PRIVILEGE GRANTEE ADM
--------------------------- ------------------------------ ---
ADMINISTER DATABASE TRIGGER EXFSYS NO
IMP_FULL_DATABASE NO
ADMINISTER RESOURCE MANAGER EXP_FULL_DATABASE NO
IMP_FULL_DATABASE NO
ALTER ANY MATERIALIZED VIEW DWETL NO
REPORTMAN NO
ALTER ANY OUTLINE REPORTMAN NO
ALTER ANY PROCEDURE IMP_FULL_DATABASE NO
QCO NO
ALTER ANY RULE CDC_PUB YES
ALTER ANY RULE SET CDC_PUB YES
ALTER ANY TABLE IMP_FULL_DATABASE NO
CNSMP NO
QCO NO
ALTER ANY TRIGGER IMP_FULL_DATABASE NO
QCO NO
VCHANG NO
ALTER ANY TYPE IMP_FULL_DATABASE NO
ALTER SYSTEM ORADBA NO
QCO NO
ALTER TABLESPACE QCO NO
ALTER USER QCO NO
SYSMAN NO
ANALYZE ANY AFFMAN NO
ARAO NO
CONCASTER NO
CREATE ANY SYNONYM ATHOTANG YES
ARUP YES
IMP_FULL_DATABASE NO
DB_MONITOR YES
QCO YES
RCHUNG YES
SPOT YES
CREATE ANY TABLE IMP_FULL_DATABASE NO
CNSMP NO
QCO NO
SYSMAN NO
DROP ANY TABLE ATHOTANG YES
IMP_FULL_DATABASE NO
CNSMP NO
QCO YES
_ 후략 _
위 실행 결과에서 DROP ANY TABLE과 같은 권한은 일반 사용자들에게 전혀 필요하지 않은 것으로 볼 수 있습니다.
이 작업은 결코 한 번에 실행해서는 안됩니다. 사용자에게서 권한을 제거하기 전에 그 영향을 주의 깊게 분석해야 합니다. 의심스러운 부분이 있다면, 해당 ID를 사용하는 실제 사용자와 인터뷰를 하는 것이 가장 좋은 방법입니다. 예를 들어, ATHOTANG 사용자는 실제로 테이블의 DROP 작업을 수행할 필요가 없음에도 자신이 그러한 권한을 필요로 한다고 생각하고 있을 수도 있습니다. (결코 놀랄 일이 아닙니다. 이런 경우는 매우 흔합니다.) 실행 계획
1.9 DBSNMP 패스워드의 변경 배경 정보 DBSNMP의 패스워드를 “dbsnmp”가 아닌 다른 것으로 바꾸어 주어야 합니다. 하지만 패스워드가 에이전트 설정 파일에도 저장되어 있기 때문에, 단순히 데이터베이스 레벨에서 패스워드를 변경해 주는 것만으로는 충분치 않습니다. 설정 파일에서도 새로운 패스워드를 사용하도록 업데이트해 주어야 합니다. Oracle Database 10g 환경에서의 패스워드 변경 방법이 아래와 같습니다.
주의 사항 Action Plan
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'IT-Consultant' 카테고리의 다른 글
| Oracle Redo Log 파일에 대한 Wait가 너무 많다면 메모리에 올리셈 (0) | 2010.09.16 |
|---|---|
| oracle 11r2 에서 root 권한이 필요한 파일들 (0) | 2010.09.14 |
| Oracle Enterprise Linux 설치시 yum install 안된다면? (0) | 2010.09.13 |
| DB_WRITER_PROCESSES 수치를 한번 변경해 볼까 한다. (2) | 2010.09.08 |
| IP4를 리눅서에서 설치 시 방화벽 통과용으로 사용할때 라우팅 테이블 설정 방법 (0) | 2010.09.06 |