정보공학의 短想

select program
from v$session
where machine = '';

의심스러운 문제가 발견되었다면, 감사(audit) 기능을 활성화하여 실행 중인 프로그램을 확인하고 그 결과를 캡처합니다 (여기에 대해서는 다음 단계에서 상세하게 설명합니다)

Action
IF <서버로부터 연결된 프로그램이 없는 경우>, THEN
오라클 실행 파일의 권한을 변경
chmod 0700 $ORACLE_HOME/oracle
ELSIF some program connects from the server
연결을 UserID/Password에서 UserID/Password@Connect_String으로 변경
END IF
IF <”sqlplus / as sysdba”를 이용하여 쉘로부터 자주 연결하는 경우> THEN
DBAUser/Password@Connect_String을 사용하도록 변경
END IF

1.3 다른 실행 파일의 보안

배경 정보

$ORACLE_HOME/bin 디렉토리의 다른 실행 파일을 살펴 봅시다. Sqlplus, Isnrctl(리스너 시작을 위한 유틸리티) 등 몇 가지는 눈에 익기도 하지만, 몇 가지는 처음 보는 것일 수도 있습니다.

tnslsnr(Listener 프로세스가 실행하는 유틸리티), dbsnmp(Oracle Intelligent Agent에 의해 사용)과 같은 일부 파일은 엔드 유저가 직접 접근하지 않습니다. 이러한 실행 파일의 보안을 위해 적절한 조치를 취할 필요가 있습니다.

앞에서 설명한 것처럼 SUID 비트가 설정되어 있으면, 파일을 실제로 누가 실행하는가에 관계없이 파일이 소유자의 권한으로 실행됩니다. 또 SUID 설정은 보안상 매우 위험할 수 있으며 따라서 가능한 한 사용을 자제해야 합니다.

SUID가 설정된 몇 가지 실행 파일이 존재합니다. 한 번 찾아 보기로 합시다.

$ cd $ORACLE_HOME
$ find . -type f \( -perm -1700 -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

각각의 파일에 대해 알아 보겠습니다.

-rwsr-s--- 1 root dba 2986836 Jan 26 1705 dbsnmp

이 파일은 루트 권한이 있어야만 정상적으로 실행이 가능하며, 따라서 SUID 비트가 설정되어 있어야 합니다. 하지만 이 파일이 루트 계정에 의해 소유되어 있기 때문에, 해커들이 루트 권한을 획득하는 방법으로 활용되기도 합니다. 가장 좋은 방법은 파일을 제거하거나 오라클 소프트웨어의 소유자가 이 파일을 소유하도록 하고 권한을 700으로 설정하는 것입니다. 이로 인해 일부 기능이 제약될 수도 있지만, 그 정도의 위험을 감수할 만한 가치가 있습니다.

그 밖에 고려해야 할 실행파일로 tnslsnr(Oracle Net Listener)이 있습니다. 이에 관련하여 두 가지 실행 파일이 존재합니다

tnslsnr ? 리스너의 실행 파일
lsnrctl ? 리스너의 관리(시작, 중단 등)를 위한 유틸리티.

설정된 권한을 조회해 봅시다

$ 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 파일 역시 마찬가지입니다.

전략

각 실행 파일의 목적을 이해했다면, 이제 데이터베이스 인프라스트럭처의 보안을 구현하는 방법에 대해 알아봅시다. 대부분의 전략은 위 섹션에서 이미 충분히 설명되었습니다. 결론적으로, DBA가 취해야 할 전략이 아래와 같습니다

1. 불필요한 파일의 모든 권한을 제거합니다(예: lsnrctl0).
2. 실행 파일의 권한을 오라클 소프트웨어로만 제한합니다.
3. 오라클 소프트웨어 소유자가 프로세스를 시작하는 경우 SUID 비트를 제거합니다.

리스너에 관련된 파일의 권한은 아래와 같은 방법으로 변경합니다.

$ 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. oracleO, tnslsnr0, lsnrctl0의 실행 권한을 0000으로 변경합니다.
2. tnslsnr과 lsnrctl의 권한을 0700으로 변경합니다.
3. Enterprise Manager에서 외부 작업(external job)을 사용하고 있습니까?
4. IF <그렇지 않은 경우> THEN
ELSE
extjob의 권한을 0700으로 수정하고 소유자와 그룹을 각각 orasoft와 oinstall(또는 오라클 소프트웨어 소유자의 사용자 아이디와 그룹)으로 변경합니다.
END IF

IF Oracle9i Database를 사용하는 경우
Oracle Intelligent Agent를 사용 중입니까?
IF <그렇지 않은 경우> THEN
dbsnmp의 오너십을 orasoft로 변경합니다.
권한을 0700으로 변경합니다.
ELSE
변경 작업이 불필요합니다.
END IF

1.4 umask의 사용

배경 정보

여러분도 잘 알고 계시다시피, UNIX/Linux 환경에서는 chmod 커맨드를 이용하여 실행 권한을 변경해 줄 수 있습니다. 하지만 chmod는 이미 존재하는 파일에 대해서만 동작합니다. 그렇다면 차후에 생성될 파일에 대해 동일한 권한이 설정됨을 어떻게 보장할 수 있을까요?

예를 들어 디렉토리의 모든 파일이 r--r--r?(444) 권한을 갖도록 설정해야 하는 경우를 가정해 봅시다. 아래와 같은 방법을 사용하면 됩니다:

$ 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라는 이름의 매개변수에 의해 결정됩니다. umask는 모든 권한이 부여된 chmod 값(777)에서 새로운 파일의 chmod 값을 뺀 값을 저장하고 있습니다. 예를 들어 umask를 777로 설정하면, 새로운 파일의 권한은 777에서 777을 뺀 값, 즉 000이 됩니다. 그 실행 예가 아래와 같습니다.

$ 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)은 새로운 파일에만 영향을 미친다는 사실을 알 수 있습니다.

umask는 오라클이 생성하는 파일의 권한을 제어하기 위한 매우 효과적이고 강력한 도구입니다.

전략

오라클 소프트웨어 소유자의 umask는 022로 설정되어야 합니다. 즉, 소유자에게는 Read+Write 권한이, 다른 사용자에게는 Read 권한이 할당되어야 합니다. 이 설정을 사용자의 로그인 프로파일에 저장하여 언제든 실행될 수 있도록 할 수 있습니다.

오라클이 사용하는 파일에는 데이터 파일, 리두 로그 파일, 트레이스 파일 등 여러 가지 종류가 있습니다. 데이터파일은 미리 생성되며 그 권한을 쉽게 변경할 수 있지만, 트레이스 파일은 런타임에 생성됩니다. 따라서 umask를 이용하여 파일이 외부 사용자에게 노출되지 않도록 할 필요가 있습니다. 트레이스 파일은 해커에 의해 악용될 수 있는 민감한 정보를 포함하고 있습니다. 예를 들어, 데이터 파일을 복제하고 별도의 서버에 마운트하는 방법으로 정보를 유출하는 것이 이론적으로 가능합니다.

각 디렉토리의 umask를 아래와 같이 설정합니다.

주의 사항

위와 같은 방법으로 umask를 적용한 경우, user_dump_dest 디렉토리에 생성된 세션 트레이스 파일에 개발자들이 접근할 수 없는 상황이 발생할 수 있습니다. 따라서 이 디렉토리에 대해서만큼은 예외적인 룰을 정의할 필요가 있습니다.

실행 계획

1.5 SYSDBA 로그인의 제한

배경 정보 “dba” 그룹에 포함된 UNIX/Linux 사용자는 아래와 같은 명령을 이용하여 SYSDBA 권한으로 로그인할 수 있습니다

sqlplus / as sysdba

DBA가 SYS 패스워드를 기억하거나 입력할 필요가 없다는 편의성 때문에 이러한 방법이 자주 사용되곤 합니다. 하지만 이로 인한 취약점 또한 존재합니다. dba 그룹 멤버로 로그인할 수 있는 모든 사용자는 SYS 권한으로 데이터베이스에 로그인할 수 있습니다. SYS에 아무리 강력한 암호 체계를 적용해도 이는 무용지물과 다름없습니다. SYS 계정의 강력한 권한을 보호하려면 dba 그룹이 SYS 계정으로 로그인하면서 SYS 암호를 반드시 입력하도록 하는 것이 좋습니다. 이런 방법으로 외부 침입을 완전히 차단할 수는 없겠지만, 그 위험을 상당 수준 줄일 수 있습니다.

전략

이 프로세스는 SQLNET.ORA 파일의 SQLNET.AUTHENTICATION_SERVICES 매개변수에 의해 통제됩니다. 이 매개변수가 NONE으로 설정되었다면, SYSDBA 역할의 자동 로그인 기능은 비활성화됩니다. 자동 로그인의 비활성화를 위해 $ORACLE_HOME/network/admin 디렉토리에 위치한 SQLNET.ORA 파일에 아래 라인을 삽입해 줍니다.

SQLNET.AUTHENTICATION_SERVICES=(NONE)

이제 dba 그룹에 포함된 사용자가 아래와 같은 방법으로 로그인을 시도하면

$ sqlplus / as sysdba

다음과 같은 에러를 확인하게 됩니다.

ERROR:
ORA-01031: insufficient privileges

성공적으로 연결하기 위햇는 SYS 패스워드를 함께 입력해야 합니다.

$ sqlplus /nolog
SQL> connect sys/oracle as sysdba

이와 같은 방법으로 SYS 패스워드를 알지 못하는 해커가 dba 계정을 이용하여 접근을 시도하는 것을 차단할 수 있습니다.

주의 사항

위에서 분명히 확인할 수 있는 것처럼, SYS 패스워드를 명시적으로 입력해야 한다는 사실이 중요합니다. 따라서 SYS 계정으로 연결하는 스크립트에 변경 사항을 적용해 주어야 합니다.

SYS 패스워드를 분실하더라도 걱정할 필요는 없습니다. SQLNET.ORA 파일의 라인을 주석 처리하고 이전과 같은 방법(/ as sysdba)으로 로그인할 수 있습니다.

실행 계획

IF <스크립트에서 SYS 계정을 이용하여 연결하는 경우> THEN
““/ as sysdba”를 “ sys/ as sysdba”로 변경합니다.
SQLNET.ORA 파일에 “SQLNET.AUTHENTICATION_SERVICES=(NONE)” 설정을 추가합니다.
ELSE
변경 작업이 불필요합니다.
END IF

1.6 Listener 패스워드의 생성

배경 정보

해커들이 가장 즐겨 사용하는 트릭 중 하나가 대량의 텍스트를 리스너로 전달하여 실행을 강제 종료하도록 유도하는 것입니다. 이 경우 데이터베이스는 여전히 실행 중이지만 리스너가 다운되기 때문에 새로운 연결을 생성할 수 없게 되므로, “서비스 거부(denial of service)” 공격이 가능합니다.

해커는 이를 위해 리스너의 속성 변경을 시도할 수 있습니다. 이를 위해 services 커맨드를 이용하여 리스너에 의해 처리되는 서비스의 목록을 조회하는 방법이 자주 사용됩니다. 아래 실행 예에서 볼 수 있는 것처럼 해커에게 필요한 충분한 수준의 정보가 제공되고

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))

또 다른 해킹 유형으로 리스너를 셧다운하는 방법이 있습니다. 새로운 연결은 거부되며, 따라서 실질적인 서비스 거부 공격이 가능합니다.

또는 다른 서버에 먼저 침입한 후 리스너의 원격 관리 기능을 이용하여 리스너를 원격에서 종료하는 방법이 가능합니다.

이러한 위협으로부터 데이터베이스를 보호하려면 어떻게 해야 할까요?

전략

최선의 대안은 tnslsnr, lsnrctl 실행 파일의 소유자를 제외한 모든 권한을 제거하는 것입니다. (이 방법은 앞 섹션에서 설명한 바 있습니다.) 이러한 방법으로 오라클 소프트웨어의 소유자를 제외한 어느 누구도 리스너를 시작 또는 종료할 수 없도록 통제할 수 있습니다. 실행 파일의 권한은 아래와 같이 설정됩니다.

-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: Not displayed
New password: Not displayed
Reenter new password: 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”라는 단어를 통해 패스워드가 설정되어 있음을 알 수 있습니다.

주의 사항

Oracle Database 10g 및 이후 버전에서는 특별히 주의할 사항이 없습니다. 사용자 인증을 위해 OS 인증이 사용되며 리스너의 시작/중단을 위해 패스워드를 입력할 필요가 없습니다. Oracle9i 및 이전 버전에서는 패스워드를 입력해 주어야 하며 따라서 스크립트에도 패스워드를 포함시켜야 합니다.

Action Plan

IF THEN
소유자를 제외한 모든 사용자의 권한을 제거합니다.
ELSE
소유자를 제외한 모든 사용자의 권한을 제거합니다.
리스너의 패스워드를 설정합니다.
END IF

1.7 리스너의 보호

배경 정보

시스템에 침입하기 위한 방법으로 리스너에 매우 긴 문자열을 전송하여 버퍼 오버플로우를 유도하는 테크닉이 자주 사용됩니다. 또 다른 침입 경로로 lsnrctl 유틸리티의 SET DISPLAYMODE VERBOSE 명령을 사용하여 컴포넌트의 목록을 확인하는 방법이 있습니다. 이 경우 해커는 취약한 머신에서 lsnrctl을 실행하여 설정을 조작한 후, 이를 이용하여 타겟 서버의 리스너에 접근합니다. 그 예가 아래와 같습니다.

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

전략

리스너를 보호하기 위한 최상의 대안은 패스워드를 설정하는 것입니다. 또는 lsnrctl 유틸리티를 사용하여 리스너 매개변수의 설정 기능을 제한할 수 있습니다. 이 경우, 매개변수를 변경하기 위해서는 리스너 설정 파일을 변경한 후 다시 로드해야 합니다. 매개변수 설정을 제한 하려면 listener.ora 파일에 아래 라인을 추가하면 됩니다.

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

이 방법은 모든 오라클 버전에 동일하게 적용됩니다.

패스워드를 사용하여 리스너를 보호하는 경우에도, 이 테크닉을 추가로 적용하여 해커의 리스너 접근 능력을 제한할 수 있습니다. 특히 오라클 소프트웨어 소유자에게는 리스너 패스워드를 요구하지 않는 Oracle Database 10g 환경에서 이 방법이 유용하게 사용됩니다.

주의 사항

특별히 주의할 사항은 없습니다. 사용자가 온라인 상태에서 매개변수를 편집하는 경우는 거의 없으며, 대부분 listener.ora를 편집하고 리스너를 다시 로드하는 방법을 사용하기 때문입니다.
하지만 다른 서버의 리스너를 관리하기 위해 원격 리스너 컨트롤 기능을 사용할 수 없다는 점을 참고해야 합니다. 그 대신, 원격 서버에 로그온한 후 listner.ora 파일을 수정하고 리스너를 다시 로드하는 방법을 사용해야 합니다 (실제로도 이러한 방법이 권장됩니다).

실행 계획

1. listener.ora 파일에 ADMIN_RESTRICTIONS_LISTENER = ON 매개변수를 설정합니다.
2. lsnrctl reload 명령을 실행하여 리스너를 다시 로드합니다.

1.8 과도한 권한의 제한

배경 정보

일반적으로 사용자들은 자신이 주로 수행하는 작업에 관련된 권한만을 필요로 합니다. 각 사용자에게 꼭 필요한 권한만을 부여하는 방법이 현실적인 대안이 되기는 어렵겠지만, 차선책으로 사용자들에게 부여된 강력한 권한 중 일부를 제거하는 작업이 필요할 수 있습니다.

사용자들에게 불필요한 강력한 권한의 예로 “CREATE ANY TABLE”이 있습니다. 사용자는 이 명령을 사용하여 자신의 스키마 뿐 아니라 다른 어떤 스키마에서도 테이블을 생성할 수 있습니다. 사용자들이 이 권한을 실제로 사용하는 경우는 매우 드물기 때문에, 권한을 취소하더라도 문제는 없습니다. 반면, 사용자 세션에서 함수 기반 인덱스 또는 MV(materialized view)를 이용한 쿼리 재작성을 허용하는 “QUERY REWRITE”와 같은 권한은 상대적으로 무해하다고 볼 수 있습니다.

전략

먼저, 위험하지 않다고 판단되는 권한의 목록을 작성합니다 (CREATE TYPE, CREATE SESSION 등). 필자는 이 목록에 “UNLIMITED TABLESPACE”를 포함시켰습니다만 동의하지 않는 분도 계실 것입니다.

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              NOADMINISTER RESOURCE MANAGER EXP_FULL_DATABASE              NO                            IMP_FULL_DATABASE              NOALTER ANY MATERIALIZED VIEW DWETL                          NO                            REPORTMAN                      NOALTER ANY OUTLINE           REPORTMAN                      NOALTER ANY PROCEDURE         IMP_FULL_DATABASE              NO                            QCO                            NOALTER ANY RULE              CDC_PUB                        YESALTER ANY RULE SET          CDC_PUB                        YESALTER ANY TABLE             IMP_FULL_DATABASE              NO                            CNSMP                          NO                            QCO                            NOALTER ANY TRIGGER           IMP_FULL_DATABASE              NO                            QCO                            NO                            VCHANG                         NOALTER ANY TYPE              IMP_FULL_DATABASE              NOALTER SYSTEM                ORADBA                         NO                            QCO                            NOALTER TABLESPACE            QCO                            NOALTER USER                  QCO                            NO                            SYSMAN                         NOANALYZE ANY                 AFFMAN                         NO                            ARAO                           NO                            CONCASTER                      NOCREATE ANY SYNONYM          ATHOTANG                       YES                            ARUP                           YES                            IMP_FULL_DATABASE              NO                            DB_MONITOR                     YES                            QCO                            YES                            RCHUNG                         YES                            SPOT                           YESCREATE ANY TABLE            IMP_FULL_DATABASE              NO                            CNSMP                          NO                            QCO                            NO                            SYSMAN                         NODROP ANY TABLE              ATHOTANG                       YES                            IMP_FULL_DATABASE              NO                            CNSMP                          NO                            QCO                            YES_ 후략 _

Implications

이 작업은 결코 한 번에 실행해서는 안됩니다. 사용자에게서 권한을 제거하기 전에 그 영향을 주의 깊게 분석해야 합니다.
의심스러운 부분이 있다면, 해당 ID를 사용하는 실제 사용자와 인터뷰를 하는 것이 가장 좋은 방법입니다. 예를 들어, ATHOTANG 사용자는 실제로 테이블의 DROP 작업을 수행할 필요가 없음에도 자신이 그러한 권한을 필요로 한다고 생각하고 있을 수도 있습니다. (결코 놀랄 일이 아닙니다. 이런 경우는 매우 흔합니다.)

실행 계획

이 작업을 수행하기 위해서는 어느 정도 사전 계획이 필요합니다. 따라서 실제 조치는 다음 단계로 연기하고 여기에서는 필요한 정보만 수집해 두도록 합니다.

1.9 DBSNMP 패스워드의 변경

배경 정보

여러분들도 잘 알고 있다시피, Oracle Intelligent Agent는 Oracle Enterprise Manager와의 커뮤니케이션을 통해 데이터베이스, 리스너, 서버 등의 컴포넌트에 대한 정보를 전달합니다. 데이터베이스에 대한 정보를 얻기 위해 에이전트는 특정 사용자 아이디를 사용하여 데이터베이스에 접근해야 합니다. 디폴트 설정에서 사용되는 사용자 아이디는 DBSNMP입니다.

데이터베이스가 생성되는 과정에서 dbsnmp의 패스워드는 “dbsnmp”로 설정됩니다. 이 사용자는 UNLIMITED TABLESPACE, SELECT ANY DICTIONARY(다이내믹 성능 뷰와 데이터 딕셔너리 뷰에 대한 쿼리), ANALYZE ANY DICTIONARY(시스템 오브젝트의 분석)와 같은 일부 강력한 권한을 소유하고 있습니다. 침입자들은 이 아이디와 패스워드를 이용하여 데이터베이스의 백도어 진입을 시도하기도 합니다. 따라서 매우 중요한 보안 취약점으로 고려되어야 합니다. .

전략

DBSNMP의 패스워드를 “dbsnmp”가 아닌 다른 것으로 바꾸어 주어야 합니다. 하지만 패스워드가 에이전트 설정 파일에도 저장되어 있기 때문에, 단순히 데이터베이스 레벨에서 패스워드를 변경해 주는 것만으로는 충분치 않습니다. 설정 파일에서도 새로운 패스워드를 사용하도록 업데이트해 주어야 합니다. Oracle Database 10g 환경에서의 패스워드 변경 방법이 아래와 같습니다.

1. 먼저 DBSNMP 사용자의 패스워드를 다른 것(예: TopSecret:)으로 바꾸어 줍니다.
SQL> alter user dbsnmp identified by topsecret;
2. Oracle Agent Home이 설치된 디렉토리로 이동합니다 (예: /u01/app/oracle/10.1/gridc).
3. /sysman/emd 디렉토리(은 호스트 또는 서버 이름)로 이동합니다. (예를 들어 서버 이름이 prolin1이라면, 디렉토리는 prolin1/sysman/emd입니다.)
4. 디렉토리에서 targets.xml 이라는 이름의 파일을 찾아 다른 이름으로 복사합니다 (예: targets.xml.old).
5. targets.xml 파일을 열고 "dbsnmp" 단어를 검색합니다. 아래와 같은 내용을 확인할 수 있을 것입니다.















6. 아래 라인을 주목하십시오.

이 곳에서 패스워드를 설정해 주어야 합니다. 위 라인을 아래 라인으로 대체합니다.

7.
여기서 ENCRYPTED를 FALSE로 설정하였음에 주의합니다.
RAC 데이터베이스의 경우, 파일에 위 라인이 두 번 나오므로, 두 개의 항목을 모두 변경해 주어야 합니다. "password" 단어를 기준으로 검색하면 두 항목을 쉽게 찾을 수 있습니다.

8. 이제 아래 명령을 실행하여 에이전트를 중단시킵니다.
/u01/app/oracle/10.1/gridc/bin/emctl stop agent

9. 에이전트를 재시작합니다.
/u01/app/oracle/10.1/gridc/bin/emctl stop agent

10. 에이전트를 재시작할 때, 설정 파일에 저장된 패스워드가 자동으로 암호화됩니다. targets.xml 파일을 다시 열어 보면 위 라인이 아래와 같이 수정되어 있음을 확인할 수 있습니다.

일반 텍스트로 작성된 값이 암호화된 값으로 변경되어 있습니다.

11. 이제 에이전트에 새로운 패스워드를 설정하는 작업을 완료하였습니다. 12. Grid Control 대신 스탠드얼론 Database Console을 사용하는 경우에도 유사한 방법을 사용합니다. 단 2 단계에서 Agent Home이 아닌 ORACLE_HOME으로 이동해야 한다는 것이 다른 점입니다.

주의 사항

특별히 주의할 사항은 없습니다.

Action Plan