分类目录归档：Elasticsearch

wazuh采集sysmon日志

发表评论

agent.conf

在服务器agent.conf文件中添加以下内容

<agent_config>
  <localfile>
    <location>Microsoft-Windows-Sysmon/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
</agent_config>

docker安装的wazuh，agent配置文件在 `wazuh.manager` 容器中。

ossec.conf

将logall_json修改为yes，如下：

<logall_json>yes</logall_json>

docker安装的wazuh，agent配置文件在 `wazuh.manager` 容器中。

修改上述两项后重启wazuh-manager服务

filebeat.yml

修改filebeat配置文件，修改内容如下：

...
filebeat.modules:
 - module: wazuh
  alerts:
   enabled: true
  archives:
   enabled: true
...

重启filebeat

service filebeat restart

测试filebeat输出

filebeat test output

添加Index Patterns

在WUI中，Management -> Stack Management -> Index Patterns

添加wazuh-archives-*的Patterns

添加完后，可以在Discover中看到客户端的sysmon日志。

添加IP黑名单

开始接收sysmon日志后，日志存储量会无限增大，需要对发送过来的源地址进行限制。

如果使用docker安装，需要在docker-compose.yml中，添加privileged，不添加的话无法在容器中启动iptables，如下：

services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.8.0
    hostname: wazuh.manager
    restart: always
    privileged: true       #添加
    ports:
      - "1514:1514"
      - "1515:1515"
      - "514:514/udp"
      - "55000:55000"

构建好docker容器后，在`wazuh.manager`容器中安装iptables，并添加目的端口为1514的黑名单即可，如下：

# apt update
# apt install iptables
# iptables -I INPUT -s x.x.x.x -p tcp --dport 1514 -j DROP
# iptables-save

 

 

 

Elasticsearch 性能调优-硬盘

发表评论

ES生产环境中, 磁盘的读写能力是非常重要的, 尤其对于大量写操作的集群, 比如电商公司将每天的实时日志数据以高并发的方式写入ES集群.

使用SSD(固态硬盘), 而不是(HDD)机械硬盘

使用SSD, 就需要配置SSD的I/O Scheduler —— 数据写入磁盘时, IO Scheduler会决定将数据从OS Cache刷入到磁盘的时机.
大部分SSD的默认IO Scheduler是CFQ (completely fair queuing), 它会为每个进程都分配一些时间片(time slice), 然后通过磁盘的物理布局来决定如何将数据写入磁盘 (对各个进程的数据写入进行优化), 进而提升写入磁盘的性能.
但是默认的CFQ并不高效. 对SSD来说, 推荐使用Deadline/Noop Scheduler, 它基于写操作被Pending的时间长短来进行写磁盘优化, 而Noop Scheduler就是一个简单的FIFO(先进先出)队列机制.

使用RAID0

RAID 0也被称之为条带式(striping)存储机制, 在RAID各种级别中性能是最高的, 它的基本原理是:
把连续的数据分散存储到多个磁盘上进行读写, 也就是对数据进行条带式存储 —— 磁盘的读写请求被分散到多个磁盘上并行执行.
没有必要使用镜像或者RAID的其他模式, 因为我们并不需要通过RAID来实现数据的高可用存储 —— 这方面的工作ES的Replica副本机制已经实现了.

避免使用NAS

虽然很多供应商都说他们的NAS解决方案性能非常高, 而且比本地存储的可靠性更高, 但在实际使用上还是会有很多风险: 网络传输可能存在比较高的时延, 还可能存在单点故障.

社工库问题汇总及一些常见的泄露数据共享网站

发表评论

社工库使用ELK架构，记录一下社工库搭建过程中的一些未解决的问题及可能的解决方案。还有最重要的，去哪收集数据。

问题

遇到的问题主要有以下几个：

1.导入数据过慢

2.库内有大量重复数据

可能的解决方案

1.砸钱上NAS（导入数据慢）

2.每个文件建立新索引，建立索引的主机与查询主机分开（导入数据慢）

3.建立索引时与现有索引数据进行对比，重复数据超过阈值后不建立索引（有重复数据）

泄露数据共享网站

https://nuclearleaks.com/random/ （提供下载）

https://ghostproject.fr/ （仅查询）

https://www.inoitsu.com/（仅查询）

https://leaksify.com/dashboard/（查询、下载，需要注册）

https://cdn.databases.today/ （下载，目前貌似仅提供收费的查询服务）

https://hacked-emails.com/ （仅发布泄露的数据来源，不提供查询、下载服务）

https://weleakinfo.com/ （仅查询）

https://ashley.cynic.al/ （仅查询）

https://data.occrp.org/ （仅查询）

https://dehashed.com/ （仅查询）

https://haveibeenpwned.com/ （仅查询）

https://scatteredsecrets.com/ （仅查询）

有可能会发布泄露数据的地方

http://www.pastebin.com/ （ pastebin ）

https://psbdmp.ws/ （pastebin搜索）

es迁移分片

发表评论

在导入大量数据时，不使用数据备份并仅使用一个节点，速度会较之前提升2倍左右，导入速度提升明显。

第一步

设置cluster.routing.allocation.disable_allocation的值，通过reroute api对索引分片进行手动分配。

curl -H "Content-Type:application/json" -XPUT 192.168.56.225:9200/_cluster/settings -d'{
    "transient": {
        "cluster.routing.allocation.enable": "none"
    }
}'

第二部

手动将116上的主分片迁移至225节点（这里迁移的是索引test的第0个分片。可通过修改shard后面的至指定分片序号）

curl -H "Content-Type:application/json" -XPOST '192.168.56.225:9200/_cluster/reroute' -d  '{
    "commands" : [
        {
            "move" : {
                "index" : "test", "shard" : 0,
                "from_node" : "192.168.56.116", "to_node" : "192.168.56.225"
            }
        }
    ]
}'

第三部

可通过 GET /_cat/shards 来查看索引的分片部署情况，当所有主分片都成功迁移至225节点时，停止116节点的es服务，把cluster.routing.allocation.disable_allocation的值改为默认值。

curl -H "Content-Type:application/json" -XPUT 192.168.56.225:9200/_cluster/settings -d'{
    "transient": {
        "cluster.routing.allocation.enable": "all"
    }
}'

 

 

 

logstash持久队列

发表评论

我们可以使用 Logstash 的持久化队列技术尽量保证数据可靠传输至 output；

适用场景：传输可靠性要求稍低的场景下(和 Kafka 类比)，替换架构中的 Kafka 或者加固 Logstash 本身的可靠性，因为即使 queue.checkpoint.writes：1，也有可能因为磁盘故障(检查点文件 和 queue 文件同时损坏)丢至多 1 条数据，核心的问题是在于没有多副本和选举相关的实现；

Deliver 策略：at-least-once；

解决elasticsearch集群Unassigned Shards 无法reroute的问题

发表评论

1.背景&问题描述

由于系统宕机，导致大量索引出现了Unassigned 状态。在上一篇文章中，我们通过reroute API进行了操作，对主分片缺失的索引，经过上述操作之后，分配了主分片。但是在接下来的操作中，对于副本分片，reroute出错！
如下是索引 alarm-2017.08.12，第0个分片的副本没有分配：

继续阅读 →