ELK+kafka踩坑记.md

2020-10-21

本次的背景是在与组内同学对接口时发现的两个坑点，感觉排查问题的过程蛮有意思的，记录一下。本次的背景是将蜜罐数据从kafka读到ES中，主要进行了两项内容，第一是logstash从kafka里读取数据，第二是用kibana把geo地址数据作成maps系列的图。

一、 Logstash对接kafka配置

在熟悉kafka配置的同学的指导下，上来我就从文档里摘了一部分与kafka的配置，开始冲：

input{
      kafka{
        bootstrap_servers => "domain:9093"
        client_id => "test"
        group_id => "test"
        auto_offset_reset => "latest"
        consumer_threads => 2
        topics => ["honeypot","sniffer"]
        ssl_truststore_location => "/opt/logstash/config/kafka/truststore.jks"
        ssl_truststore_password => "123456"
        jaas_path => "/opt/logstash/config/kafka/kafka_client_jaas.conf"
        }
}

疑难现象：客户端logstash正常启动，有一条报错信息不断重复，在网卡上可以监听到与kafka服务器的通信。

在客户端抓个包可以看到，一个大约七八次的交互在不断重复进行，一个阶段失败以后就会换一个端口重复与kafka服务器交互，首先排除了因为防火墙等原因导致的网络层不通的问题。

网络层的原因排除以后，那么就是软件层面的问题了。在与kafka对接的配置中配置了证书等，因此在交互前是要进行协商通信的一些配置，如所使用的密码组件等，如果在通信早期不断出问题，那么必然是SSL握手时除了问题，排除了证书copy错误的可能，决定抓个包用wireshark看看。

分析->选择34772端口并识别为TLS，可以看到识别之后可以分析了

1	Alert(Level:Fatal,Description:Internnal Error)

该错误是wireshark给出的错误，一般表示按照给出的解析方式，wireshark认不出来。因此我们着重分析第一个

1	Ignored Unknown Record

可以看到本来应该出现SSL握手信息的位置，出现的却是报错，甚至在字段中提取到了test-0、apache-kafka等信息，问题已经很明白了，客户端是以明文发过去的配置信息，而kafka服务器却要执行SSL过程，牛头不对马嘴，肯定走不下去，于是我们再看了看文档，找到了指定SSL的配置如下。

具体的配置细节请参照大神的三探kafka:

1 2	sasl_mechanism => "PLAIN" security_protocol => "SASL_SSL"

指定SSL配好了以后，终于可以正常从kafka里面读取数据了hh。

二、kibana做图

既然读到数据了，下一步自然要用kibana画出来，咋们的源数据是蜜罐数据，那么自然而然地要，这里踩的小坑是对geoip插件数据精度不准的误解。最初的现象是我们分布在全国各地的蜜罐节点地址是不一样的，但是却全部被解析到北京的geoip地址。

先贴filter配置

filter {
json {
        source => "message"
        target => "output_json"
}
mutate {
   add_field => {
         "sip"  =>  "%{[output_json][sip]}"
}
   add_field => {
         "dip"  =>  "%{[output_json][dip]}"
}
}
geoip   {
id => "2"
source   => "dip"
database => "/opt/GeoLite2-City_20201013/GeoLite2-City.mmdb"
target   => "map_dip"
}
geoip   {
id => "1"
source   => "sip"
database => "/opt/GeoLite2-City_20201013/GeoLite2-City.mmdb"
target   => "map_sip"
}
mutate {
    add_field => {
      "[map][location1][lat]" => "%{[map_sip][latitude]}"
      "[map][location1][lon]" => "%{[map_sip][longitude]}"
      "[map][location2][lat]" => "%{[map_dip][latitude]}"
      "[map][location2][lon]" => "%{[map_dip][longitude]}"
    }
  }
}

sip是访问蜜罐的攻击者IP，dip是蜜罐节点的IP地址。现象是，所有的dip都被解析成{34，113}这是北京的地址。

最后做出来的图就成了汇聚北京节点。

针对这个问题，我的debug流程如下：

1. 交换sip和dip的生成顺序->现象不变

2. 交换sip和dip的赋值顺序->sip会被解析到北京

从以上两个信息我推出来一个错误的结论->dip的解析有问题.在一段时间内,我始终认为是dip的解析写法不对,导致坐标解析错误.

于是浪费了大量的时间在调整dip的赋值等等.直到我做了如下尝试:

1 2	sip = "某节点IP" dip = "某节点IP"

配置对应的现象是都解析到了北京的地址,我恍然大悟,实际上是我使用的mmdb精度也就这样,就是输入这个IP,他就是会把这个位置解析错误.实际上复盘来看,大西洋上还有一个sip的节点显然是解析的问题,当时就应该想到这一层.

但我过于钻配置的牛角尖,所以误导了自己导致得出了错误的结论,原因是公开库的解析准确度没有我们想像的那么高.

三、复盘总结

复盘总结一下最近debug的逻辑思维:

1. 首先定位是软件的问题还是网络的问题,网络的问题通常表现为防火墙/路由/网桥转发,等导致数据包到不了对方端口.

2. 排除网络的问题之后再来看软件的问题,这里有一个可以辅助我们判断的点是,软件配置的问题有时候会表现在网络层,也通常可以通过网络层控制点来排查,比如说本文中碰到的SSL配置不全导致本应是握手阶段的内容,却看到了明文,这就能够辅助我们得到相应的判断.

3. 如果定位了纯粹是软件配置层面的问题,那么一般只能通过软件自身的error_log来观测,定位问题.