禁止监听在公网
描述
ES服务监听在0.0.0.0,可能导致服务对外或内网横向移动渗透风险,极易被黑客利用入侵。
加固
修改ES服务配置文件elasticsearch.yml的network.host配置: network.host: 127.0.0.1或者内网IP,然后重启服务。
ES服务监听在0.0.0.0,可能导致服务对外或内网横向移动渗透风险,极易被黑客利用入侵。
修改ES服务配置文件elasticsearch.yml的network.host配置: network.host: 127.0.0.1或者内网IP,然后重启服务。
在服务器agent.conf文件中添加以下内容
<agent_config> <localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile> </agent_config>
docker安装的wazuh,agent配置文件在 `wazuh.manager` 容器中。
将logall_json修改为yes,如下:
<logall_json>yes</logall_json>
docker安装的wazuh,agent配置文件在 `wazuh.manager` 容器中。
修改上述两项后重启wazuh-manager服务
修改filebeat配置文件,修改内容如下:
... filebeat.modules: - module: wazuh alerts: enabled: true archives: enabled: true ...
重启filebeat
service filebeat restart
测试filebeat输出
filebeat test output
在WUI中,Management -> Stack Management -> Index Patterns
添加wazuh-archives-*的Patterns
添加完后,可以在Discover中看到客户端的sysmon日志。
开始接收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
ES生产环境中, 磁盘的读写能力是非常重要的, 尤其对于大量写操作的集群, 比如电商公司将每天的实时日志数据以高并发的方式写入ES集群.
使用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(先进先出)队列机制.
RAID 0也被称之为条带式(striping)存储机制, 在RAID各种级别中性能是最高的, 它的基本原理是:
把连续的数据分散存储到多个磁盘上进行读写, 也就是对数据进行条带式存储 —— 磁盘的读写请求被分散到多个磁盘上并行执行.
没有必要使用镜像或者RAID的其他模式, 因为我们并不需要通过RAID来实现数据的高可用存储 —— 这方面的工作ES的Replica副本机制已经实现了.
虽然很多供应商都说他们的NAS解决方案性能非常高, 而且比本地存储的可靠性更高, 但在实际使用上还是会有很多风险: 网络传输可能存在比较高的时延, 还可能存在单点故障.
社工库使用ELK架构,记录一下社工库搭建过程中的一些未解决的问题及可能的解决方案。还有最重要的,去哪收集数据。
遇到的问题主要有以下几个:
1.导入数据过慢
2.库内有大量重复数据
1.砸钱上NAS(导入数据慢)
2.每个文件建立新索引,建立索引的主机与查询主机分开(导入数据慢)
3.建立索引时与现有索引数据进行对比,重复数据超过阈值后不建立索引(有重复数据)
https://nuclearleaks.com/random/ (提供下载)
https://ghostproject.fr/ (仅查询)
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搜索)
在导入大量数据时,不使用数据备份并仅使用一个节点,速度会较之前提升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 的持久化队列技术尽量保证数据可靠传输至 output;
适用场景:传输可靠性要求稍低的场景下(和 Kafka 类比),替换架构中的 Kafka 或者加固 Logstash 本身的可靠性,因为即使 queue.checkpoint.writes:1,也有可能因为磁盘故障(检查点文件 和 queue 文件同时损坏)丢至多 1 条数据,核心的问题是在于没有多副本和选举相关的实现;
Deliver 策略:at-least-once;
由于系统宕机,导致大量索引出现了Unassigned 状态。在上一篇文章中,我们通过reroute API进行了操作,对主分片缺失的索引,经过上述操作之后,分配了主分片。但是在接下来的操作中,对于副本分片,reroute出错!
如下是索引 alarm-2017.08.12,第0个分片的副本没有分配: