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