Я создавал несколько шаблонов Grok для анализа файла журнала / var / log / secure, и все работало нормально. Я создаю гроковые узоры на http://grokconstructor.appspot.com/ и даже тогда протестируйте их на http://grokdebug.herokuapp.com/ и оба сайта идеально соответствуют шаблонам. Я использую logstash 2.1.1, elasticsearch 2.1.1 и kibana 4.3.1, все они работают на CentOS 7.1 с использованием JAVA openjdk 1.8.0.65-2.b17.
Затем я взял эти шаблоны и реализовал их с помощью фильтра на своих серверах logstash. Большинство фильтров работают нормально, но SECURENETREG и SECURENETBADGE по какой-то причине не совпадают. logstash --configtest не показывает никаких проблем, а logstash в остальном работает нормально, но когда я смотрю на записи, которые должны соответствовать этим шаблонам в Kibana, кажется, что ни один из синтаксического анализа не работает.
Вот мой файл шаблонов /etc/logstash/patterns.d/secure-log.grok:
SECURETIMESTAMP %{MONTH}%{SPACE}%{MONTHDAY} %{TIME}
SECUREPROG %{PROG:program}(?:\[%{POSINT:pid}\])?
SECUREHOST %{IPORHOST:host}
SECUREBASE %{SECURETIMESTAMP:secure_timestamp}%{SPACE}%{SECUREHOST}%{SPACE}%{SECUREPROG}:
SECURESU %{SECUREBASE} (runuser: |)%{PROG:pam_program}(?:\[%{POSINT:pid}\])? session %{WORD} for user %{USER:user}( by \(uid=%{NUMBER:su_caller_uid}\)|)
SECURESUDORUN %{SECUREBASE}%{SPACE}(%{USER:user} : TTY=%{DATA} ; PWD=%{DATA} ; USER=%{USER:sudo_runas_user} ; COMMAND=%{GREEDYDATA:sudo_command}|\S+:%{SPACE}(TGT verified|error reading keytab %{GREEDYDATA}|authentication %{WORD} for '%{USER:user}'%{GREEDYDATA}|%{GREEDYDATA}user=%{USER:user}))
SECURESSHDPUBKEY %{SECUREBASE} (Found matching RSA key: %{GREEDYDATA:rsa_key}|%{WORD} publickey for %{USER:user} from %{IPORHOST:src_ip}( port %{NUMBER:port} %{WORD}( \[preauth\]|: RSA %{GREEDYDATA:rsa_key}|)|)|)
SECURESSHDREST %{SECUREBASE} (Did not receive identification string from %{IPORHOST:src_ip}|pam_unix\(sshd:session\): session %{WORD} for user %{USER:user}|Starting session: command for %{USER:user} from %{IPORHOST:src_ip}|Connection from %{IPORHOST:src_ip}|Accepted (password|publickey) for %{USER:user} from %{IPORHOST:src_ip}|Received disconnect from %{IPORHOST:src_ip}|Connection closed by %{IPORHOST:src_ip}|User child is on pid %{NUMBER}|Set %{UNIXPATH} to %{NUMBER})
SECURENETREG %{SECUREBASE} connect from %{IPORHOST:src_ip}%{GREEDYDATA}
SECURENETBADGE %{SECUREBASE} (%{WORD:whois_action}|Authentication %{WORD:auth_result}): (reply from %{URI:whois_uri}: Result: %{GREEDYDATA:whois_result}|User: %{USER:user}, %{GREEDYDATA:auth_result_detail}, From: %{IPORHOST:src_ip}, %{GREEDYDATA}, URL: %{URI:netbadge_source_uri})
Вот мой файл конфигурации, в котором применяется фильтр, /etc/logstash/conf.d/46-filter-secure-log.conf:
filter {
if [type] == "secure" {
grok {
patterns_dir => ["/etc/logstash/patterns.d/"]
match => { "message" => [
"%{SECURESU}",
"%{SECURESUDORUN}",
"%{SECURESSHDPUBKEY}",
"%{SECURESSHDREST}",
"%{SECURENETREG}",
"%{SECURENETBADGE}"
]
}
add_field => {
"received_at" => "%{@timestamp}"
"received_from" => "%{host}"
}
}
date {
match => [ "secure_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
}
}
}
И, наконец, вот несколько (очищенных от идентифицирующей информации) сообщений журнала, которые идеально соответствуют тестерам шаблонов, но, похоже, не получают должного анализа в logstash (хотя я знаю, что фильтр попадает в них, потому что я временно протестировал, добавив новое поле только для убедитесь, что сообщения пропускались через фильтр):
Jan 8 09:22:22 netbadge-serv netbadge[3534]: verify_whois: reply from https://whois.domain.edu/whois: Result: 0:-1000:0:0:Error with submitted data Illegal characters in data stream#012
Jan 8 09:22:19 netreg-serv autoreg.pl[13867]: connect from 10.250.100.22 (10.250.100.22)
Jan 8 09:22:19 netbadge-serv netbadge[3522]: Authentication success: User: mst3k, Password: Test Test, From: 10.250.28.30, Appid: webmail_login, URL: https://www.mail.domain.edu/switchboard/
Jan 8 09:39:51 netbadge-serv netbadge[11358]: Authentication failure: User: mst3k, Invalid User/Password, From: 10.250.28.31, Appid: Shibboleth Identity Provider, URL: https://shib.domain.edu/idp/Authn/RemoteUser
Я уверен, что это что-то простое, что мне не хватает из-за того, что я так долго смотрю на все это, поэтому я очень надеюсь, что кто-то может сказать мне, что здесь происходит.
Спасибо,
Боб
Догадаться. В конце SECURESSHDPUBKEY был | перед концом), который соответствовал всему остальному, поэтому он никогда не доходил до шаблонов ниже. Я знал, что это просто, просто слишком долго смотрел на этот грок.