logstash 사용법 및 활용 사례에 대하여 알아보겠습니다.
Logstash로 보안 로그 데이터 전처리를 하고있으며 elastic stack 연동하여 사용중입니다.
모든 서비스 보안 이벤트 로그(Firewall, IPS, WAF 등)를 logstash로 전처리하고
elastic stack으로 저장하고 있습니다.
일평균 처리량은 elastic indices 기준 일별 4억 2천건 ~ 4억 5천건 (Document Count 기준)
logstash filter 플러그인을 적용하여 꼭 필요한 부분만 저장중이며
실제 일평균 저장되는 스토리지 용량은 60GB~75GB 정도입니다.
logstash filter 부분 실제 운영 사례
drop filter plugin
보안 이벤트 로그의 deviceCustomString1 필드 키워드가 ATTACK 이나 BLACKIP 로 시작하는
로그는 모두 drop (폐기) 받지 않음
destinationAddress 필드값이 18.xx.xx.10, ... , ... 들은 drop
applicationProtocol 필드값이 icmp, ntp 등은 drop
service 필드값이 PING drop
if [deviceCustomString1] =~ /^ATTACK_+/ or [deviceCustomString1] =~ /^BLACKIP+/ {
drop {}
}
if [destinationAddress] =~ "18.xx.xx.10" or [destinationAddress] =~ "xx.xx.xx.11" or [destinationAddress] =~ "x8.x6.xx.1"
or [destinationPort] =~ "2048" or [applicationProtocol] =~ "icmp" or [service] =~ "PING" or [name] =~ "Notable Characteristics of the analyzed sample"
or [name] =~ "Deny List updated" or [name] =~ "Evidence" or [applicationProtocol] =~ "ntp" or [service] =~ "NTP" or [sourceAddress] =~ "10.10x.1x.7" or
[sourceAddress] =~ "10.x0.xx.30" or [sourceAddress] =~ "xx.xx5.x1.xx" or [name] =~ /^PHP DIESCAN+/ or [name] =~ /^NETGEAR+/ {
drop {}
}
mutate filter plugin rename option
보안 이벤트 로그의 deviceHostName 필드 키워드가 POD01-FW로 시작하는 로그
field 명이
.
name -> csname 로 필드명 변경
severity -> csseverity 로 필드명 변경
deviceCustomString6 -> threatAction 로 필드명 변경
.
.
쉽게 풀어쓰면 POD01-FW 방화벽 로그중 필요에 의해 특정 필드명(예:severity)을 변경하는것
elastic stack에 저장될때는 필드명이 severity -> csseverity 로 변경되서 저장 됩니다.
if [deviceHostName] =~ /^POD01-FW+/ {
mutate {
rename => { "deviceCustomString1" => "policyName" }
rename => { "name" => "csname" }
rename => { "severity" => "csseverity" }
rename => { "applicationProtocol" => "csapplicationProtocol" }
}
}
if [deviceHostName] =~ "IPSAA001" {
mutate {
rename => { "deviceCustomString1" => "title" }
rename => { "deviceCustomString3" => "domainName" }
rename => { "deviceCustomString6" => "threatAction" }
rename => { "deviceEventCategory" => "threatType" }
rename => { "severity" => "hostSeverity" }
}
}
mutate filter plugin replace option
로그 내용중 해당 필드의 값을 특정 문자열로 대체 변경
예: hostServerity 값 2 or hostServerity 값 3 -> hostSeverity -> Low-Minor 로 변경
if [hostSeverity] == "2" or [hostSeverity] == "3" {
mutate {
replace => { "[hostSeverity]" => "Low-Minor" }
}
}
if [hostSeverity] == "4" or [hostSeverity] == "5" or [hostSeverity] == "6" or [hostSeverity] == "7" {
mutate {
replace => { "[hostSeverity]" => "Medium-Major" }
}
}
if [hostSeverity] == "8" or [hostSeverity] == "9" or [hostSeverity] == "10" {
mutate {
replace => { "[hostSeverity]" => "High-Critical" }
}
}
mutate filter plugin remove_field common option (공통 옵션)
특정 필드 삭제
예: "PanOSDGl2", "PanOSDGl4", "PanOSDstUUID", "PanOSPacketsReceived" ... 필드 삭제
mutate {
remove_field => [ "msg", "message", "tags", "requestContext", "SN", "deviceReceiptTime", "deviceVersion", "deviceProcessName", "cefVersion", "type", "sourceUserName", "deviceEventCategory", "host", "port", "deviceDirection", "generatorID", "bytesIn", "bytesOut", "PanOSDGl2", "PanOSDGl4", "PanOSDstUUID", "PanOSPacketsReceived", "PanOSParentSessionID", "PanOSParentStartTime", "deviceExternalId", "eventId", "externalId", "reason", "deviceSeverity", "endTime", "sourceMacAddress", "destinationMacAddress", "baseEventCount", "dvcmac" ]
}
prune filter plugin
prune 필터는 필드 이름 또는 해당 값의 화이트 리스트 또는 블랙리스트를 기반으로
이벤트로그에서 필드를 제거하기 위한 것입니다
(이름과 값은 정규표현식 사용 가능)
간혹 보안장비 로그를 수집하다보면 이상한 필드들이 수집될때가 있습니다.
"ad.MSDSë±_,ì´ë©ì¼_,: <a_,href"
"AK1+5tjxgmI4Mzay6RcmD2QfBk75Y3OqvyJ0E3gposr9NM"
"AK12/yfqLS0tcTt7H5X1/4pRTv0MAUAW66z40ozyXXP3KE"
엘라스틱 Index Patterns
수많은 보안 장비 로그중 가끔 위와같이 듣도보도 못한 필드명의 로그가 들어올때가 있었습니다.
이 문제 때문에 한동안 삽질아닌 삽질을 ㅜㅜ
위와 같은 경우 AK1 AK12... ad.xx ad.bb ad.Xz ... 형태로 필드명이 무작위로 생성될때
저런 패턴의 필드를 강제 제거하고자 할때 정규 표현을 잘 조합하여
prune filter 를 사용하면 됩니다.
prune {
blacklist_names => [ "^*[\\]+", "^*[/]+", "^*[..]+", "^ad.+", "^A.+", "^B.+", "^AK1+", "^SH2+", "^AK+", "^agent+", "^deviceEvent+", "^file+", "^cfg+", "^category+", "^flex+", "^xau+", "^*ZoneURI$", "^*boundInterface$", "^*.TimeZone$" ]
}
참고 사항
사실 로그 데이터 전처리 부분에 logstash 를 사용하지 않아도 됩니다.
elastic 버전이 향상되면서 logstash 대신 elastic ingest node 를 구성하여 사용해도 됩니다.
logstash 구성 VS elastic ingest node 구성의 성능 차이등은
구글에서 "logstash vs ingest node" 이렇게 검색하면 비교 자료를 볼수 있습니다.
이상 방대한 보안 로그이벤트 처리에 대한 logstash 사용 및 활용 사례에 대해서
적어 보았습니다.
부족한 내용이지만 부디 누군가에게는 도움이 되었으면 합니다. ^^
