개요
- 2012년 5월 1일, Oracle사는 Oracle 데이터베이스의 TNS listener 취약점에 대한 임시 조치 권고 발표[1]
4월에 발표된 April 2012 Critical Patch Update를 통해 패치 되지 아니한 취약점에 대해 개념증명코드(PoC)가 공개되어 패치 전에 취할 수 있는 조치에 대한 보안권고
설명
- TNS listener와 관련된 취약점으로 원격에서 사용자 인증 없이 데이터베이스로의 연결을 엿보거나 임의의 명령어 실행이 가능한 취약점
※ TNS(Transparent Network Substrate) : Oracle에서 개발한 기술로 서로 다른 Network 구성을 가지고 있는 Client/Server 또는 Server/Server 간에도 Data의 전송을 가능하게 해주는 Network 기술
해당 소프트웨어
- Oracle Database 11g Release 2, versions 11.2.0.2, 11.2.0.3
- Oracle Database 11g Release 1, version 11.1.0.7
- Oracle Database 10g Release 2, versions 10.2.0.3, 10.2.0.4, 10.2.0.5
임시 조치 방안
- Real Application Clusters(RAC) 사용자는 My Oracle Support Note 1340831.1 참고 [2]
※ RAC(Real Application Clusters) : Oracle 데이터베이스 환경에서 클러스터링과 고가용성 기능을 가능케 하는 추가 기능 - Real Application Clusters(RAC) 비사용자는 My Oracle Support Note 1453883.1 참고 [3]
- 상기 문서를 검토하고 벤더사 및 유지보수업체와 협의/검토 후 조치 요망
기타 문의사항
- 한국인터넷진흥원 인터넷침해대응센터: 국번없이 118
[참고사이트]
[1] http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
[2] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1340831.1
[3] https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1453883.1
|
업체명
(가나다순.) |
솔루션
|
주요
특징 및 장점 |
|
모니터랩 |
DB인사이트
SG
|
-데이터베이스
성능에 영향을 미치지 않고 기본 인프라
환경의
변경 없음
-IP,
DB 접근 사용자, 접근 시간대별로 제어가 가능
-IP그룹
지정 및 DB 접근 사용자 그룹 지정을 통한 접
근제어
가능
-저장
및 분석 DB에 접근하는 모든 SQL 쿼리 저장·차
단·탐지로그
저장, 감사로그 분석 수행 |
|
소만사 |
DB-i
|
-개인정보보호법에
규정한 개인정보의 안전성 확보조
치
기준에 맞춘 개인정보 접근, 저장, 전송 최소화
-접근통제,
접근차단 및 이상징후 탐지, 전송 시 암호
화,
접속기록 위·변조방지보관 기능
-DB
내 개인정보가 엔드포인트에 무단 저장되는 것을
막는
기능 |
|
신시웨이 |
페트라
|
-스니핑(Sniffing),
게이트웨이, 에이전트 방식 지원
-고객의
업무환경에 따라 단일형 또는 혼합형으로 제공
-‘SOHA’라는
자체 개발한 메인 메모리 DBMS를 리포
지토리(Repository)
DBMS로 사용해 신속한 규칙 적
용과
로그저장이 가능 |
|
STG
시큐리티 |
ToFAZ Ｘ
|
-DB에
대한 접근을 실시간으로 감시·통제하며 모든 작
업활동을
기록·보관해 사후 감사자료를 제공
-사용자
IP Address 및 접속 어플리케이션, 날짜·시간
등의
조건으로 DB접근 통제
-사용자
DB 작업내역을 실시간 모니터링 하는 감사 기
능
등을 제공
-자체
개발한 아메바트리(ameba tree)엔진과 메모리
DB를
적용하여 중·대형 시스템에도 성능과 안정성 보장 |
|
웨어밸리 |
샤크라
맥스 |
-대용량
DB에 대한 접근제어 및 감사기능 동시에 지원
-DB에
직접 접근하는 사용자에 대한 접근제어, 서비스적
인
접근에 대해서도 성능 부하 없이 로깅 및 위험도에 대
한
감사기록 지원
-뛰어난
SQL 처리 성능을 바탕으로 접근 통제, 감사 기록
을
통한 개인정보보호 수행 |
|
이니텍 |
SeNeapp
|
-시스템
접근제어와 계정관리, 감사 기능을 결합한 ‘통합 계정 및 접근 제어 솔루션’
-
일체형 장비(Appliance)로 빠른 구축과 유지보수 편리
-Agent
설치 필요 없고 운영체제(OS)와 데이터베이스(DB)동시 지원
-TP(Transparent)모드
지원으로, 네트워크 및 타 장비에 완전히 투명하게 작동
-
기존 인프라 환경 변경하지 않고 사용 가능
|
|
피앤피
시큐어 |
DB세이퍼 |
-가상계정,
사용자 IP, 애플리케이션 등 주제별로 다양한
정보
동시에 접근제어
-구문에
대한 통제가 가능하며 명령어로 인한 DB의 부하
를 증가시키는 행위에 대해서도 제어
-지정된
시간이 지나도록 DB서버에서 사용자에게 요청
값을
통보하지 못할 경우 해당 사용자 세션 강제로 중단
-사용자별,
접속세션별 접속 이력을 실시간으로 모니터링
및
감시대상 DB로 요청되는 초당 SQL요청수, 초당 평균
응답시간,
데이터 조회 건수 등을 실시간 제공 |
출처 : 보안뉴스
I published at my blog a new tool called xSQLScanner. This program
allow the user audit MS-SQL and My-SQL servers.
Some features:
1 - 6 Vulnerability Audit options;
1.2 - Test for weak password fast;
1.3 - Test for wear/user passwords;
1.4 - Wordlist option;
1.5 5 - Userlist option;
2 - Portscanner
7 - Range IP Address audit and more.
Now the good news, i made 2 versions. Windows & Linux. The linux
version use the Mono Project, so i compiled mono version
to run under Linux (BackTrack 5 - GNOME).
Here the instructions to install under linux:
1 - get http://www.4shared.com/file/ykeEX3TV/xsqlscan-mono.html
2 - tar -xzvf xsqlscan.tar.gz
3 - cd xsqlscan
4 - ./xsqlscanw
5 - The program will verify if you have Mono Core files. If already
have, the application will launcher.
5.1 - Answer 'yes' to download the libs and mono core files
6 - Restart the application typing: ./xsqlscanw
7 - Enjoy.
The link for Windows version:
http://www.4shared.com/file/9evD9RTY/xsqlscanner-12.html
Remember: any bugs, suggestions please contact me.
Regards
------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board
Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT
and CEPT certs require a full practical examination in order to become certified.
http://www.iacertification.org
------------------------------------------------------------------------
From: Rodrigo Matuck <rodrigomatuck () globo com>
DDL 트리거는 UPDATE, DELETE, INSERT 등과 같은 명령문에 작동하는 DML 트리거와 달리 테이블이나 뷰에 대한 CREATE, ALTER 및 DROP 또는 사용자 계정이나 로그인 설정, 프로 시저 생성 및 변경, 파티션 생성 및 변경 등과 같은 DDL문에 대하여 동작하는 트리거입니다.
- 데이터베이스 스키마에 대한 특정 변경 작업을 방지하려는 경우
- 데이터 스키마가 변경될 때 데이터베이스에서 특정 작업이 수행되도록 하려는 경우
- 데이터베이스 스키마의 변경 내용이나 이벤트를 기록하려는 경우
DDL 트리거는 SQL 문이 완료된 후에 실행이 되며, INSTEAD OF 트리거로 사용될 수는 없습니다. 또한 DML 트리거와 같이 inserted, deleted 테이블을 생성하지는 않습니다. DDL 트리거는 서버에 대해서 설정할 수도 있고 특정 데이터베이스에서만 수행되도록 설정할 수도 있습니다. 데이터베이스, 사용자, 끝점, 로그인 관련 이벤트는 서버 범위의 이벤트 그룹이며, 테이블, 뷰, 인덱스 등과 같은 데이터베이스 개체 관련 이벤트는 데이터베이스 범위의 이벤트 그룹입니다.
- DDL 트리거를 디자인하기 전에 다음 사항이 필요합니다.
- DDL 트리거 영역에 대하여 이해해야 합니다.
- 어떤 Transact-SQL문(들)에 대하여 트리거를 발생시킬 것인지를 결정해야 합니다.
DDL 트리거 생성
[구문] CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] | EXTERNAL NAME < method specifier > [ ; ] }
[따라하기] 테이블의 DROP 및 ALTER 작업에 대하여 DDL 트리거 생성하기
USE AdventureWorks;
GO
IF EXISTS (SELECT * FROM sys.triggers WHERE parent_class = 0 AND name =
'safety')
DROP TRIGGER safety ON DATABASE;
GO
CREATE TRIGGER safety
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
PRINT '테이블을 변경/삭제하려면“safety”트리거를 비활성화 하세요.'
ROLLBACK;
GO
-- safety라는 DDL 트리거를 비활성화합니다.
DISABLE TRIGGER safety ON DATABASE;
GO
-- safety라는 DDL 트리거를 활성화합니다.
ENABLE TRIGGER safety ON DATABASE;
GO
[따라하기] AdventureWorks 데이터베이스 내의 모든 DDL 문에 대하여, 사용 기록 남기기
USE AdventureWorks;
GO
CREATE TABLE ddl_log (PostTime datetime, DB_User nvarchar(100), Event
nvarchar(100), TSQL nvarchar(2000));
GO
CREATE TRIGGER log
ON DATABASE
FOR DDL_DATABASE_LEVEL_EVENTS
AS
DECLARE @data XML
SET @data = EVENTDATA( )
INSERT ddl_log (PostTime, DB_User, Event, TSQL) VALUES
(GETDATE( ),
CONVERT(nvarchar(100), CURRENT_USER),
@data.value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)'),
@data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'nvarchar(2000)') ) ;
GO
--생성한 트리거 테스트
CREATE TABLE TestTable (a int); --임시 테이블을 생성
DROP TABLE TestTable ; --생성한 임시 테이블 삭제
GO
--DDL 로그 확인
SELECT * FROM ddl_log ;
GO
--트리거 삭제
DROP TRIGGER log ON DATABASE;
GO
--ddl_log 테이블 삭제
DROP TABLE ddl_log;
GO
DDL 트리거 정보 확인
[따라하기] 데이터베이스 수준의 DDL 트리거 목록 확인하기
SELECT * FROM sys.triggers WHERE parent_class = 0;
GO
[따라하기] 서버 수준의 DDL 트리거 목록 확인하기
SELECT * FROM sys.triggers WHERE parent_class = 0;
GO
[따라하기] 트리거 정의 확인하기
SELECT tr.name, sm.definition
FROM sys.triggers tr JOIN sys.sql_modules sm ON tr.object_id = sm.object_id
WHERE tr.parent_class = 0;
GO
출처 : DBGuide.net
작동 방식
- Query cache는 system-wide한 글로벌 메모리 공간
- Query cache는 Full scan등과 같이 큰 공간이 필요한 결과는 캐시하지 않도록
캐시 최대 사이즈를 제한(query_cache_limit)
- Query의 결과를 캐시하기 위해서 메모리의 공간을 할당 받을 때,
query_cache_min_res_unit 단위로 할당 받으며 (필요시 더 추가적으로),
캐시 작업이 완료된 이후 남은 미사용 공간은 반납하게 된다.
- Query cache는 테이블 단위로 Invalidate 되기 때문에,
테이블이 상당히 자주 변경된다면 cache의 효율이 떨어질 수 있다.
- 일반적으로는 Query cache의 매치 기준은 Query 문장이 동일한지(대소문자 및 공백까지) 비교하는 방식이며 InnoDB의 경우에는 레코드 기반의 락을 사용하며 MVCC의 제어가 필요하기 때문에
재사용 가능한지 판단은 Query 문장뿐만 아니라 Transaction Id로 레코드 접근성까지 비교해야 함
- Query cache의 관리 비용은 얻는 효과에 비하면 아주 미미하지만,
가끔은 캐시 내용을 invalidate 하는데 상당히 많은 비용이 필요할 수도 있음
- 일반적으로 Query cache는 아래의 경우 상당히 도움이 된다.
- 테이블이 자주 변경되지 않는 경우
- 쿼리의 실행 과정은 복잡하고 많은 처리가 필요하지만 결과 셋의 사이즈가 작은 경우
- 동일 쿼리가 자주 실행되는 경우
- Query cache의 Hit-Ratio는 계산하는 MySQL의 Status 값 Key_reads를 Status값 Key_read_requests로 나누는 방법으로 계산하지만, 이 값이 90%면 좋고 20%면 나쁘다는 단순한 판단은 힘듬
-> Query cache의 효율성 판단은 실제 운영 시스템에서 활성화/비활성화를 비교해보는 것이 제일 좋을 듯 하지만, 운영 시스템이므로 주의가 필요
-> query_cache_size 설정 변수는 전역이면서 동적 변수이기 때문에 실시간으로 변경이 가능하므로 서비스 영향 없이 설정 변경 후 비교 가능
(주의해야 할 것은 기존과 동일하든지 다른 값이든지 일단 한번 설정이 되면 지금까지의 캐시된 내용은 모두 제거됨)
메모리 할당 방식
- 1) 그림의 아래 부분 처럼 각 색깔별로 A,B,C,D,E 쿼리들이 실행되어서, 1) 번과 같은 상태의 Query cache가 있다고 가정해보자
- 그림에서 하나의 영역은 Query cache block 으로 일반적으로 "query_cache_min_res_unit"로 정의된 사이즈이며,
- <1>번이라고 적힌 영역은 캐시될 ResultSet 을 저장하기 위해서 "query_cache_min_res_unit" 크기의 메모리 블럭을 할당 받아서 사용하다가 남는 공간은 다시 반납하게 되는데, 이 때문에 발생한 빈 공간임 (Fragmentation이라고도 하며, 이런 공간들은 쉽게 재활용되지 못함)
- 뒷 부분의 흰색 블럭들은 아직 미사용된 블럭들을 표시함
- 2) 이 상태에서 아래와 같이 tab2와 tab4를 변경하는 쿼리가 실행되면, 해당 테이블을 참조하는 모든 Query cache는 모두 제거됨
- UPDATE tab2 SET ... WHERE ...
- UPDATE tab4 SET ... WHERE ...
이런 공간들은 주위의 미사용 영역들과 병합되어서, 나중에 재활용될 수 있음
(이런 공간들도 모두 일반적으로 Fragmentation 이라고 표현함)
- 3) 아래 명령을 이용하여 이렇게 발생한 Query cache의 Fragmentation을 제거하고,
미 사용 영역을 모두 연속된 공간으로 만들어줄 수 있음
- FLUSH QUERY CACHE;
이 명령은 Query cache 전체에 대해서 변경되지 않도록 락을 걸기 때문에 조심해서 실행해야 함
- 이러한 Query cache 의 block 할당에 관련된 정보는 MySQL의 상태값으로 확인 가능함
- Qcache_total_blocks : 무조건 할당된 공간까지의 모든 block들(사용중이든 아니든)의 수를 보여줌
- Qcache_free_blocks : 미사용 block들 (Fragmentation이라고 표현한 영역들)의 수를 보여줌
- 1)번 그림 : Qcache_total_blocks -> 16, Qcache_free_blocks -> 2
- 2)번 그림 : Qcache_total_blocks -> 16, Qcache_free_blocks -> 3
- 3)번 그림 : Qcache_total_blocks -> 11, Qcache_free_blocks -> 1
제약 사항
- 아래와 같은 형태로 실행되는 쿼리는 Query cache를 사용하지 못함
- PreparedStatement로 실행되는 쿼리 (MySQL 5.1.17 이후 부터는 Query cache를 사용 가능)
- Stored Procedure, Function, Trigger 내부에서 실행되는 쿼리
- Sub Query 형태로 실행되는 쿼리
관련 설정 변수
- query_cache_limit
이 값으로 설정된 사이즈 이상의 결과 셋을 가지는 경우에는 Query cache에 캐시하지 않도록 설정
- query_cache_min_res_unit
Query cache에서 결과 셋을 캐시하기 위한 메모리 공간을 할당 받을 때 사용하는 메모리 할당 최소 단위 사이즈
- query_cache_size
Query cache의 전체 사이즈를 설정하며 1024Byte의 배수로 설정,
Query cache를 완전히 비활성화하기 위해서는 이 변수의 값을 0으로 설정해야 한다.
- query_cache_type
Query 의 결과 셋을 어떻게 저장할지를 결정함,
- OFF는 캐시하지 않음,
- ON은 SQL_NO_CACHE 힌트가 없는 SELECT 문장의 결과 셋은 캐시 대상으로 가정,
- DEMAND 는 SQL_CACHE 힌트가 SELECT 문장에 있는 결과 셋만 캐시 대상으로 가정
- query_cache_wlock_invalidate
어떤 Client가 MyISAM 테이블에 Write lock을 가지고 있는 경우,
다른 Client가 Query cache에서 결과를 가져갈 수 있는 SELECT문장을 실행하는 것은 Block되지 않는데, 이 값을 TRUE로 설정하면 결과를 Query cache에서 가져갈 수 있다 하더라도, 다른 Client는 대기해야 하도록 만든다.
출처 : http://intomysql.blogspot.com/
