# prometheus.yml
global:
scrape_interval: 15s
evaluation_interval: 15s

alerting:
alertmanagers:
– static_configs:
– targets: [‘localhost:9093’]

rule_files:
– “rules/security_alerts.yml”

scrape_configs:
– job_name: ‘tidb’
static_configs:
– targets: [‘192.168.1.100:9090’]
– job_name: ‘tikv’
static_configs:
– targets: [‘192.168.1.101:9091’, ‘192.168.1.102:9091’, ‘192.168.1.103:9091’]
– job_name: ‘pd’
static_configs:
– targets: [‘192.168.1.100:9092’]
– job_name: ‘node’
static_configs:
– targets: [‘192.168.1.100:9100’, ‘192.168.1.101:9100’, ‘192.168.1.102:9100’, ‘192.168.1.103:9100’]

# 安装ELK Stack用于日志分析
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.0-linux-x86_64.tar.gz
tar -xzf elasticsearch-7.17.0-linux-x86_64.tar.gz

wget https://artifacts.elastic.co/downloads/logstash/logstash-7.17.0-linux-x86_64.tar.gz
tar -xzf logstash-7.17.0-linux-x86_64.tar.gz

wget https://artifacts.elastic.co/downloads/kibana/kibana-7.17.0-linux-x86_64.tar.gz
tar -xzf kibana-7.17.0-linux-x86_64.tar.gz

# 配置Logstash收集TiDB审计日志
cat > logstash/pipeline/security.conf << 'EOF' input { file { path => “/tidb/logs/audit.log”
start_position => “beginning”
}
}

filter {
grok {
match => {
“message” => “\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{LOGLEVEL:level}\] \[%{DATA:component}\] \[%{DATA:user}\] \[%{DATA:host}\] \[%{DATA:db}\] \[%{DATA:command}\] \[%{DATA:sql}\]”
}
}
}

output {
elasticsearch {
hosts => [“localhost:9200”]
index => “tidb-security-%{+YYYY.MM.dd}”
}
}
EOF

#!/bin/bash
# security_incident_response.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: http://www.fgedu.net.cn

# 安全事件响应脚本

log_file=”/tidb/logs/security_incident.log”

log() {风哥提示：
echo “[$(date +’%Y-%m-%d %H:%M:%S’)] $1” >> $log_file
echo “[$(date +’%Y-%m-%d %H:%M:%S’)] $1”
}

# 检测安全事件
detect_incident() {
log “开始检测安全事件”
# 检查失败的登录尝试
failed_logins=$(grep “ERROR.*login” /tidb/logs/audit.log | wc -l)
if [ $failed_logins -gt 10 ]; then
log “检测到可疑的登录尝试，失败次数：$failed_logins”
return 1
fi

# 检查敏感表访问
sensitive_access=$(grep “fgedu_users” /tidb/logs/audit.log | wc -l)
if [ $sensitive_access -gt 50 ]; then
log “检测到对敏感表的大量访问，访问次数：$sensitive_access”
return 1
fi

return 0
}

# 隔离受影响的系统
isolate_system() {
log “开始隔离受影响的系统”
# 临时限制网络访问
iptables -A INPUT -p tcp –dport 4000 -s ! 192.168.1.0/24 -j DROP
log “已限制非内部网络访问TiDB端口”
}

# 收集证据
collect_evidence() {
log “开始收集证据”
# 复制审计日志
cp /tidb/logs/audit.log /tidb/backup/audit_$(date +’%Y%m%d%H%M%S’).log
# 复制数据库日志
cp /tidb/logs/tidb.log /tidb/backup/tidb_$(date +’%Y%m%d%H%M%S’).log
log “已收集关键日志文件”
}

# 分析事件
analyze_incident() {
log “开始分析事件”
# 分析审计日志
echo “分析失败的登录尝试：” >> $log_file
grep “ERROR.*login” /tidb/logs/audit.log | tail -20 >> $log_file
echo “分析敏感表访问：” >> $log_file
grep “fgedu_users” /tidb/logs/audit.log | tail -20 >> $log_file
log “事件分析完成”
}

# 恢复系统
recover_system() {
log “开始恢复系统”
# 恢复网络访问
iptables -D INPUT -p tcp –dport 4000 -s ! 192.168.1.0/24 -j DROP
log “已恢复网络访问”
# 重置可疑用户密码
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “ALTER USER ‘fgedu’@’%’ IDENTIFIED BY ‘new_password’;”
log “已重置用户密码”
}

# 主函数
main() {
log “安全事件响应程序启动”

if detect_incident; then
log “未检测到安全事件”
exit 0
fi

isolate_system
collect_evidence
analyze_incident
recover_system

log “安全事件响应完成”
}

main

# 1. 检测到数据泄露事件
# 从审计日志中发现大量对敏感表的访问

# 2. 隔离受影响的系统
# 限制网络访问
iptables -A INPUT -p tcp –dport 4000 -s ! 192.168.1.0/24 -j DROP

# 3. 收集证据
cp /tidb/logs/audit.log /tidb/backup/audit_$(date +’%Y%m%d%H%M%S’).log

# 4. 分析事件学习交流加群风哥QQ113257174
# 查看访问敏感表的SQL语句
grep “fgedu_users” /tidb/logs/audit.log | grep “SELECT” | tail -50

# 5. 采取措施
# 重置用户密码
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “ALTER USER ‘fgedu’@’%’ IDENTIFIED BY ‘new_secure_password’;”

# 6. 恢复系统
iptables -D INPUT -p tcp –dport 4000 -s ! 192.168.1.0/24 -j DROP

# 7. 事后总结
# 分析访问模式，加强访问控制

# 1. 检测到SQL注入攻击
# 从审计日志中发现可疑的SQL语句

# 2. 隔离受影响的系统
# 暂时关闭对外访问
iptables -A INPUT -p tcp –dport 4000 -j DROP

# 3. 收集证据
cp /tidb/logs/audit.log /tidb/backup/audit_$(date +’%Y%m%d%H%M%S’).log

# 4. 分析事件
# 查看可疑的SQL语句
grep “UNION” /tidb/logs/audit.log | tail -20

# 5. 采取措施
# 检查数据库是否被修改
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “SELECT * FROM fgedudb.fgedu_users LIMIT 10;”

# 6. 恢复系统
# 从备份恢复数据
br restore full –pd “192.168.1.100:2379” –storage “local:///tidb/backup” –ratelimit 128 –log-file /tidb/logs/restore.log

# 7. 加强防护
# 配置Web应用防火墙，过滤SQL注入攻击

# 1. 检测到权限滥用
# 从审计日志中发现用户执行了超出权限的操作

# 2. 隔离受影响的用户
# 暂时禁用可疑用户
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “REVOKE ALL PRIVILEGES ON *.* FROM ‘fgedu’@’%’;”

# 3. 收集证据
cp /tidb/logs/audit.log /tidb/backup/audit_$(date +’%Y%m%d%H%M%S’).log

# 4. 分析事件
# 查看用户执行的操作
grep “fgedu” /tidb/logs/audit.log | grep “DDL” | tail -20

# 5. 采取措施
# 恢复被修改的对象
# 例如，重新创建被删除的表
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “CREATE TABLE fgedudb.fgedu_backup LIKE fgedudb.fgedu_users;”

# 6. 恢复系统
# 重新授权用户，限制权限
mysql -h 192.168.1.100 -P 4000 -u root -p”password” -e “GRANT SELECT, INSERT, UPDATE ON fgedudb.* TO ‘fgedu’@’%’;”

# 7. 事后总结
# 审查所有用户的权限，实施最小权限原则

更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 安全事件应急最佳实践

• 建立完善的安全事件监控体系，及时发现安全事件
• 制定详细的应急响应计划，明确各环节的职责和流程
• 定期进行安全事件应急演练，提高团队的应急响应能力
• 建立安全事件知识库，总结过往事件的处理经验
• 加强与外部安全机构的合作，获取最新的安全威胁信息

5.2 常见问题与解决方案

• 事件检测不及时：加强监控系统建设，设置合理的告警阈值
• 应急响应流程不明确：制定详细的应急响应计划，定期演练
• 证据收集不完整：建立标准化的证据收集流程，确保关键证据不丢失
• 恢复过程耗时过长：建立快速恢复机制，备份重要数据
• 事后总结不到位：建立事件复盘机制，及时总结经验教训

5.3 安全事件预防建议

• 定期进行安全评估和漏洞扫描，及时发现和修复安全隐患
• 加强员工安全意识培训，提高安全防护能力
• 实施多层安全防护策略，建立纵深防御体系
• 保持系统和软件的及时更新，修补安全漏洞
• 建立安全事件预警机制，提前发现潜在的安全威胁

from tidb视频:www.itpux.com