Transcript IDS
IDWG 표준화 동향
2001. 5. 10
채기준
이화여자대학교
[email protected]
1
목 차
IDWG 개요
Intrusion Detection Exchange Requirements
IAP: Intrusion Alert Protocol
The Intrusion Detection Exchange Protocol (IDXP)
The Tunnel Protocol
IDMEF XML Document Type Definition
IDMEF Comparison of SMI and XML
Implementations
결론
2
IDWG 개요(1/3)
Chairs:
Michael Erlinger ([email protected])
Stuart Staniford-Chen
([email protected])
제 43차 회의 시 첫 모임 (98. 12)
General Discussion:[email protected]
To Subscribe: idwg-public-request@
zurich.ibm.com
Archive: http://www.semper.org/idwg-public/
3
IDWG 개요 (2/3)
목적
IDS와 대응 시스템, 그리고 이들과 상호 작동하는
관리시스템 사이의 정보를 공유하기 위한 데이터 포
맷 및 교환 절차에 대하여 정의
WG의 Outputs
Requirements documents
Common intrusion language specification
(Data formats)
Framework documents
4
IDWG 개요 (3/3)
Internet-Drafts
Intrusion Detection Exchange Requirements
IAP: Intrusion Alert Protocol
The Intrusion Detection Exchange Protocol (IDXP)
The TUNNEL Profile
Intrusion Detection Message Exchange Format
Extensible Markup Language (XML) Document
Type Definition
Intrusion Detection Message Exchange Format
Comparison of SMI and XML Implementations
No RFC
5
Intrusion Detection Message
Exchange Requirements
<draft-ietf-idwg-requirements-05.txt>
개요
IDS, 대응 시스템, 관리 시스템 사이의 통
신을 위한 high-level 요구사항을 기술함
(이론적 해석 및 시나리오 포함)
IDMEF
IDS가 의심스럽다고 간주하는 이벤트를 보고
하기 위하여 사용하는 표준 포맷
7
IDS 용어 및 관계
Data
Source
Operator
Activity
Sensor
Notification
Event
Response
Analyzer
Alert
Manager
Security
Policy
Administrator
8
구조상의 가정들
Analyzer는 sensor에 의해 수집된 의심
스러운 이벤트에 대하여 어떻게 할 것인가
를 결정하고, manager에게 alert을 보냄
Alert의 포맷과 통신하는 방법을 IDMEF
에서 표준화
Analyzer와 manager는 별개의 구성요
소로 가정하고, 서로간에 TCP/IP 네트워
크를 통하여 통신한다고 가정
9
요구사항
일반 요구사항
메시지 포맷 요구사항
IDMEF 통신프로토콜 (IDP) 요구사항
메시지 내용 및 의미 요구사항
이벤트 정의 및 정의절차 요구사항
10
일반 요구사항
IDMEF는 기존에 출간된 RFC들을 참조
하고 사용해야 함
IDMEF는 IPv4와 IPv6의 구현을 포함
하는 환경에서 운용 가능하여야 함
11
메시지 포맷 요구사항
IDMEF 메시지 포맷들은 완전한 국제화와
지역화를 지원해야 함
IDMEF 메시지는 manager에 의한 데이
터의 filtering/aggregation을 지원해야
함
12
IDMEF 통신프로토콜 (IDP) 요구사항(1/2)
IDP는 메시지의 신뢰성있는 전송을 지원해야 함
IDP는 보안을 위협하지 않으면서 방화벽 경계를
가로질러 있는 IDS 구성요소들간의 메시지 전송
을 지원해야 함
IDP는 analyzer와 manager 상호간에 인증을
제공해야 함
IDP는 메시지 교환 동안 메시지 내용의 기밀성
을 제공해야 함
13
IDMEF 통신프로토콜 (IDP) 요구사항(2/2)
IDP는 메시지 내용의 무결성을 보장해야
함
IDP는 IDMEF 메시지의 근원지에 대한
부인봉쇄를 보장해야 함
IDP는 서비스 거부 공격을 막을 수 있어
야함
IDP는 메시지의 유해한 복사를 막을 수
있어야 함
14
메시지 내용(1/5)
IDMEF는 다양한 IDS들이 “어떻게 (How)”가 아닌
“무엇을(What)”을 탐지하느냐에 초점을 맞추어 설계
되어야 함
Signature-based detection system
Anomaly-based detection system
Correlation-based detection system
Network-based detection system
Host-based detection system
Application-based detection system
15
메시지 내용(2/5)
IDMEF 메시지의 내용은 알려진 이벤트의 경우,
그 이벤트의 알려진 이름을 포함하여야 함
IDMEF 메시지는 alert에 의해 보고되는 이벤트
의 배경 정보를 수신자가 찾을 수 있도록 송신자
에 의해 제공되는 정보를 포함하여야 함
IDMEF 메시지는 특정의 이벤트와 관계된 추가
적인 상세 데이터를 참조할 수 있어야 함
(Optional)
IDMEF 메시지는 이벤트의 소스와 타겟의 식별
자가 알려진 경우 그들을 포함하여야 함
16
메시지 내용(3/5)
IDMEF 메시지는 다른 종류의 device
address를 표현할 수 있어야 함
IDMEF 메시지는 타겟상에서 이벤트의 가능
한 영향력에 대한 기술을 포함하여야 함
IDMEF 메시지는 이벤트에 대한 대응으로
analyzer에 의해 취해지는 자동적인 행위에
대한 정보를 제공하여야 함
IDMEF 메시지는 이벤트를 보고했던 각각의
analyzer를 식별하고 찾을 수 있도록 하는 정
보를 포함하여야 함
17
메시지 내용(4/5)
IDMEF 메시지는 구현자의 식별자와 이벤트
를 탐지하는 analyzer에 대한 정보를 포함해
야함
IDMEF 메시지는 보고의 기밀성의 정도를 기
술할 수 있어야 함 (Optional)
IDMEF 메시지는 다른 IDMEF 메시지와 구분
될 수 있도록 독특하게 식별 가능하여야 함
IDMEF는 각 이벤트에 대하여 alert 생성 날
자와 시간을 보고해야 함 (추가적으로 이벤트
탐지 날짜와 시간도 보고할 수 있음)
18
메시지 내용(5/5)
시간은 다른 time zone에 있는 여러 analyzer로부
터의 이벤트를 manager가 받았을 때 각 analyzer
의 local time을 추론할 수 있도록 보고되어야 함
날짜를 보고하는 형식은 2000년에 대한 현재의 표
준을 따라야 하고, 2038년을 지난후의 날짜 보고
능력도 가져야 함
이벤트 메시지 내의 시간의 세분성 및 정확성은
IDMEF에 의해 정의될 필요는 없음
IDMEF 메시지는 구현자들이 특정 구현 데이터를
정의하기 위해 사용할 확장 메커니즘을 지원해야 함
(Optional)
IDMEF 메시지의 의미는 잘 정의되어야 함
19
Alert 식별자와 Alert 식별자 정의 절차
IDMEF alert의 표준 리스트는 확장 가
능하여야 함
IDMEF 그 자체도 확장 가능하여야 함
Alert 식별자의 표준 list는 구현자와 관
리자에 의해 확장 가능하여야 함
새로운 alert 식별자가 정의되고 표준화
되는 절차는 구현과 독립적이어야 함
20
Intrusion Alert Protocol (IAP/0.5)
<draft-ietf-idwg-iap-05>
개요
정의
IAP는 IP 네트워크 상에서 침입탐지 구성 요소들 사
이 (sensor/analyzers 와 managers)에 침입 경보
데이터 (Intrusion alert data)를 교환하기 위한 응용
계층의 프로토콜
목적
신중을 요하는 alert data를 IP 네트워크를 통해 전달
하기 위해 필수적인 전송 및 보안 특성을 제공할 수 있
도록 설계
응용계층에서 침입탐지 sensor/analyzers를 구성하
고, 응답을 보낼 수 있도록 설계
IAP는 수송계층 프로토콜로 TCP를 사용
22
Operation (1/2)
Sensor/analyzer가 alert data를 manager
에게 전송
Sensor/analyzer : 잠재적인 침입을 감지하고
alert data를 만듬
Manager : Alert data를 받아서 운용자에게 보여
주거나, 데이터베이스에 기록하거나,
적절한 조치를 취함
23
Operation (2/2)
The simplest case :
SA
M
More than one intermediaries :
SA
P
IAP
G
IAP
M
The native protocol
supported by M
SA : Sensor/Analyzer, M : Manager
P : Proxy, G : Gateway
24
IAP Communication Model
IAP 통신은 TCP 상에서 발생함
TCP 연결은 HTTP와 유사한 request/response
를 전달함 (차이: Initiator가 SA/M 가능)
Phases
Setup phase
Data phase
Proxies
IAP 식별자를 가지고 있지 않음
내용을 이해하지 않고 단지 중계함
Alert의 보안 요소에 영향을 주지 않으며 Rewrite 가능
25
IAP Setup Phase (1/2)
TCP setup
iap-connect-request/iap-response
(success : 200, failure : 403)
Proxy : iap-proxy-via를 덧붙이고, receiving entity로 넘겨줌
Security setup
iap-upgrade-request/iap-response가 연결의 보안을 upgrade 하기
위해 사용됨
Handshake for TLS 1.0 protocol : 프로토콜의 버전, 암호 알고리즘,
상호 인증을 협상하고 공개키 생성
TLS handshake는 TLS connection originator에 의해 시작
Channel setup
TLS record layer를 사용하여 데이터 전달, 공격 차단
iap-channel-setup-request/iap-response를 이용하여 IAP 버전을 확
인하고, 데이터를 전달할 payload의 종류를 결정
26
IAP Setup Phase (2/2)
Secured data transport
인코드된 IDMEF alerts가 TLS record
layer 상에서 sensor/analyzer에 의해
manager로 전달됨
Termination
Sender: TLS close-notify alert을 보냄
Recipient: 응답으로 close-notify alert을
보냄
27
Analyzer
Proxy
Manager
[ Setup Phase]
iap-connect-request
iap-connect-request
iap-response
iap-response
[Proxy is now a transparent forwarding agent]
iap-upgrade-request
iap-response
(TLS handshake negotiation initiated by analyzer)
[TLS handshake completed : data sent using the TLS record layer]
iap-channel-setup-request
iap-response
[Data Phase]
iap-content
iap-response
28
IAP Wire Protocol (1/6)
IAP syntax는 HTTP/1.1과 유사
(request/response 프로토콜)
Request/response는 CRLF로 끝남
IAP 메시지
iap-message=(iap-request | iap-response)
Version
iap-version = “ IAP/0.5 ”
TCP connection initiator의 역할
sender-receiver = “ Sender ” | “ Receiver ”
29
IAP Wire Protocol (2/6)
IAP request
iap-request-start-line
*(message-header)
CRLF
[message-body]
iap-reuest-start-line =
( iap-connect-request |
iap-upgrade-request
iap-channel-setup-request |
iap-content-request)
30
IAP Wire Protocol (3/6)
iap-connect-request
“CONNECT” SP
HOST
“:” port SP
iap-version
CRLF
iap-upgrade-request
“PUT” SP iap-config-url SP
iap-version
CRLF
“/iap/config”
Message-header에 포함되어야 하는 내용
“Upgrade: TLS/1.0”
CRLF
31
IAP Wire Protocol (4/6)
iap-channel-setup-request
“PUT” SP iap-config-url SP
iap-version
CRLF
Message-header에 포함되어야 하는 내용
“IAP-Version: 0.5”
“IAP-Role: ” SP
CRLF
(“Sender”|”Receiver”) CRLF
32
IAP Wire Protocol (5/6)
iap-content-request
“PUT” SP iap-config-url SP
iap-version
CRLF
“/iap/alert”
Message-header에 포함되어야 하는 내용
• Content Length
“Content-Length: ”
SP
+DIGIT
CRLF
SP
“Appl./xml”
CRLF
• Content Type
“Content-Type: ”
33
IAP Wire Protocol (6/6)
IAP Responses
iap-response-start-line
iap-version
*(message-header)
CRLF
[message-body]
SP 3*DIGIT CRLF
34
Scenario
Simple analyzer
단지 연결만을 초기화하고, 한번에 하나의 manager
와 연결이 가능함
Manager의 IP주소와 인증서의 명세서를 포함
Simple analyzer with proxy
Proxy의 IP 주소를 포함
Proxy는 manager의 주소를 포함
Proxy는 TLS handshake에 참여하지 않음
Manager design considerations
복수의 sensor/analyzer로부터의 연결을 받아들일
수 있어야 함
35
Implementation Consideration(1/2)
TCP connection initiation
SA는 보안경계 밖에 있고, M은 안에 있을 때 => M
이 초기화
Service provider가 관리하는 remote SA -> SA는
우선 경계에 있는 proxy에 접속한 후 M에 연결
Urgent Data
IAP를 사용하는 entity는 TCP 계층에서의 urgent
data를 사용해서는 안됨
종단은 urgent data를 받으면 그것을 무시해야하고,
연결을 종료할 수도 있음
TLS/1.0 프로토콜을 사용해야 함
이전 버전 프로토콜과의 협상을 거부해야 함
36
Implementation Consideration(2/2)
Sensor/analyzer의 인증이 필수적임
TLS handshake동안 인증 내용을 검증함
공개키 인증서에 기반하여 IAP 클라이언트와
서버는 서로의 identity를 검증할 수 있어야 함
악의적으로 IAP 세션을 종료시키려는 외부의
공격 가능성 때문에, TLS close-notify alert
을 받지 못했다면 TLS session을 재개할 수 있
어야 함
37
Security Considerations
Fast unreliable delivery
=> SNMP trap을 이용하여 alert을 표현 가능
TCP가 연결설정을 위해 3-message handshake 사용시
서비스 거부 공격 가능
노드에 접속이 허락된 IP 주소를 제한
각각의 알려진 peer에 허가된 연결의 수를 제한
알려진 peer들의 집합에 허가된 연결의 수를 제한
pkix WG에서 정의하고 있는 공개키 메커니즘을 사용 가능
메시지의 길이를 이용하여 alert의 종류 식별 가능
=> 데이터를 pad하여 메시지 길이가 특정 분포가 되게 함
Proxy는 보안 정책을 파괴할 수 없도록 설계되어야 함
38
The Intrusion Detection
Exchange Protocol (IDXP)
<draft-ietf-idwg-beep-idxp-01>
개요
침입탐지 엔티티 사이에 데이터를 교환하기
위한 응용계층 프로토콜
BEEP (Blocks Extensible Exchange
Protocol) profile에 기반을 둠
연결지향 프로토콜 위에서 상호인증, 무결성,
기밀성을 제공
IDMEF 메시지, unstructured text, binary
data의 교환을 지원
여러 개의 Beep Session 생성 가능
하나의 Beep session에 여러 개의 Beep
channel 사용 가능
40
Connection Provisioning (1/3)
Proxy가 없는 경우
[1] ‘initial’ initiates a transport connection to ‘final’,
Triggering the exchange of BEEP greeting messages.
[2] both entities negotiate the use of a BEEP security profile.
[3] both entities negotiate the use of the IDXP profile.
41
Connection Provisioning (2/3)
Proxy가 있는 경우
42
Connection Provisioning (3/3)
[1] Instead of immediately acknowledging the
request from ‘initial’ to start TUNNEL, ‘proxy1’
attempts to establish use of TUNNEL with
‘proxy2’.
‘proxy2’ also delays its acknowledgment to
‘proxy1’.
[2] ‘final’ acknowledges the request from ‘proxy2’
to start TUNNEL, and this acknowledgment
propagates back to ‘initial’ so that a TUNNEL
application-layer tunnel is established from
‘initial’ to ‘final’
43
Data Transfer (1/2)
Single BEEP Channel
Note that the arrowhead for the BEEP channel using
the IDXP profile points from client to server.
44
Data Transfer (2/2)
Multiple BEEP Channels
45
The Tunnel Profile
Beep peer들이 응용계층 터널을 형성하도록 돕기 위한
메커니즘을 제공하는 Beep profile
Peer들은 source route를 기술하는 터널 요소를 교환함
권한을 부여받은 사용자가 firewall을 통해 서비스에 접근
할 수 있도록 함
SASL을 통해 협상된 사용자 ID에 기초하여 서버 밖으로
의 연결을 제한함
양 종단간에 연결이 설정되면, 터널링 프록시는 더 이상
의 데이터 번역을 하지 않음
프록시가 교환되는 정보에 접근할 수 없다는 보장하에 양
종단간에 인증 정보를 교환하는 TLS 협상을 함
46
IDMEF XML Document Type Definition
XML DTD
XML의 element, attribute, value를 정의
XML DTD와 Data Model의 통합
XML은 IDMEF의 필수 요구사항을 만족
메시지 포맷이 국제화/지역화를 지원
메시지 포맷이 filtering/aggregation을 지
원
IDMEF의 alert 메시지를 XML로 구현함
47
IDMEF Comparison of SMI
and XML Implementations
SMI : MIB에서 사용하는 datatype을
식별하고, MIB 자원의 표현 및 명명하
는 방법 규정
2000년 2월 회의에서 XML 채택
XML의 확장성
XML은 텍스트 기반
=> 용이한 압축과 적은 용량
XML은 표준 및 제조업자들이 지원하는
Tell-only 방식에 적합
48
결 론
IDS의 사용 확산 추세
다양한 IDS간의 상호운용성 확보를 위한
표준화 시급 => IDWG의 역할
표준에 기반한 IDS 개발
IETF 등의 국제 표준화 기구에 의견 반영
을 통한 국내 기술의 국제화
49