189 8069 5689

服务器集群安全设置 服务器集群的作用

Linux服务器集群只允许堡垒机SSH登录

在局域网中的Linux服务器集群,为了保障运维安全,只能从堡垒机登录到各个Linux服务器。那么需要对Linux服务器集群进行安全加固,限制访问权限。在堡垒机上可以部署脚本来记录用户操作的审计日志(详情参考笔者的文章),那么整个局域网的Linux服务器集群的安全性就可以大大提高。

创新互联建站专业为企业提供巴南网站建设、巴南做网站、巴南网站设计、巴南网站制作等企业网站建设、网页设计与制作、巴南企业网站模板建站服务,十多年巴南做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。

堡垒机作用明显,其提供运维统一入口和安全审计功能,切断直接访问和事后审计定责,解决“运维混乱”变得“运维有序” 。

下面是三种方法总结。分别从服务端,系统端、防火墙端来完成只允许堡垒机SSH登录的功能。

1、/etc/ssh/sshd_config

修改添加AllowUsers到ssh配置文件/etc/ssh/sshd_config  :

AllowUsers myuser@20.132.4.*

然后重启 sshd服务:systemctl restart sshd

2、hosts.allow与hosts.deny

修改/etc/hosts.deny中添加设置 sshd : ALL ,拒绝所有的访问;

修改/etc/hosts.allow,添加设置sshd : 20.132.4.* ,单独开启某个IP地址 。

这两个文件优先级为先检查hosts.deny,再检查hosts.allow。

更加详细信息参考笔者的文章-Linux中hosts.allow与hosts.deny  。

3、iptables防火墙

tcp协议中,禁止所有的ip访问本机的22端口。

iptables -I INPUT -p tcp--dport 22 -j DROP

只允许20.132.4.* 访问本机的22端口

iptables  -I  INPUT  -s  20.132.4.*   -ptcp  --dport  22  -j   ACCEPT

另外/etc/pam.d/sshd也可以提供访问控制功能,调用的pam_access.so模块是根据主机名、IP地址和用户实现全面的访问控制,pam_access.so模块的具体工作行为根据配置文件/etc/security/access.conf来决定。但是囿于资料过少,待以后遇到再解决把。

如何构建安全的Kafka集群

扩展、可靠性、异步通信和高吞吐率等特性而被广泛使用。目前越来越多的开源分布式处理系统都支持与Kafka集成,其中Spark

Streaming作为后端流引擎配合Kafka作为前端消息系统正成为当前流处理系统的主流架构之一。

然而,当下越来越多的安全漏

洞、数据泄露等问题的爆发,安全正成为系统选型不得不考虑的问题,Kafka由于其安全机制的匮乏,也导致其在数据敏感行业的部署存在严重的安全隐患。本

文将围绕Kafka,先介绍其整体架构和关键概念,再深入分析其架构之中存在的安全问题,最后分享下Transwarp在Kafka安全性上所做的工作及

其使用方法。

Kafka架构与安全

首先,我们来了解下有关Kafka的几个基本概念:

Topic:Kafka把接收的消息按种类划分,每个种类都称之为Topic,由唯一的Topic Name标识。

Producer:向Topic发布消息的进程称为Producer。

Consumer:从Topic订阅消息的进程称为Consumer。

Broker:Kafka集群包含一个或多个服务器,这种服务器被称为Broker。

 

 Kafka的整体架构如下图所示,典型的Kafka集群包含一组发布消息的Producer,一组管理Topic的Broker,和一组订阅消息的

Consumer。Topic可以有多个分区,每个分区只存储于一个Broker。Producer可以按照一定的策略将消息划分给指定的分区,如简单的

轮询各个分区或者按照特定字段的Hash值指定分区。Broker需要通过ZooKeeper记录集群的所有Broker、选举分区的Leader,记录

Consumer的消费消息的偏移量,以及在Consumer Group发生变化时进行relalance.

Broker接收和发送消息是被动的:由Producer主动发送消息,Consumer主动拉取消息。

然而,分析Kafka框架,我们会发现以下严重的安全问题:

网络中的任何一台主机,都可以通过启动Broker进程而加入Kafka集群,能够接收Producer的消息,能够篡改消息并发送给Consumer。

网络中的任何一台主机,都可以启动恶意的Producer/Consumer连接到Broker,发送非法消息或拉取隐私消息数据。

Broker不支持连接到启用Kerberos认证的ZooKeeper集群,没有对存放在ZooKeeper上的数据设置权限。任意用户都能够直接访问ZooKeeper集群,对这些数据进行修改或删除。

Kafka中的Topic不支持设置访问控制列表,任意连接到Kafka集群的Consumer(或Producer)都能对任意Topic读取(或发送)消息。

 

 随着Kafka应用场景越来越广泛,特别是一些数据隐私程度较高的领域(如道路交通的视频监控),上述安全问题的存在犹如一颗定时炸弹,一旦内网被黑客

入侵或者内部出现恶意用户,所有的隐私数据(如车辆出行记录)都能够轻易地被窃取,而无需攻破Broker所在的服务器。

Kafka安全设计

基于上述分析,Transwarp从以下两个方面增强Kafka的安全性:

身份认证(Authentication):设计并实现了基于Kerberos和基于IP的两种身份认证机制。前者为强身份认证,相比于后者具有更好的安全性,后者适用于IP地址可信的网络环境,相比于前者部署更为简便。

权限控制(Authorization):设计并实现了Topic级别的权限模型。Topic的权限分为READ(从Topic拉取数据)、WRITE(向Topic中生产数据)、CREATE(创建Topic)和DELETE(删除Topic)。

Broker启动时,需要使用配置文件中的身份和密钥文件向KDC(Kerberos服务器)认证,认证通过则加入Kafka集群,否则报错退出。

Producer(或Consumer)启动后需要经过如下步骤与Broker建立安全的Socket连接:

Producer向KDC认证身份,通过则得到TGT(票证请求票证),否则报错退出

Producer使用TGT向KDC请求Kafka服务,KDC验证TGT并向Producer返回SessionKey(会话密钥)和ServiceTicket(服务票证)

Producer

使用SessionKey和ServiceTicket与Broker建立连接,Broker使用自身的密钥解密ServiceTicket,获得与

Producer通信的SessionKey,然后使用SessionKey验证Producer的身份,通过则建立连接,否则拒绝连接。

ZooKeeper需要启用Kerberos认证模式,保证Broker或Consumer与其的连接是安全的。

 

 Topic的访问控制列表(ACL)存储于ZooKeeper中,存储节点的路径为/acl/topic/user,

节点数据为R(ead)、W(rite)、C(reate)、D(elete)权限的集合,如/acl/transaction/jack节点的数据为

RW,则表示用户jack能够对transaction这个topic进行读和写。

另外,kafka为特权用户,只有kafka用户能够赋予/取消权限。因此,ACL相关的ZooKeeper节点权限为kafka具有所有权限,其他用户不具有任何权限。

构建安全的Kafka服务

首先,我们为Broker启用Kerberos认证模式,配置文件为/etc/kafka/conf/server.properties,安全相关的参数如下所示:

其中,authentication参数表示认证模式,可选配置项为simple, kerberos和ipaddress,默认为simple。当认证模式为kerberos时,需要额外配置账户属性principal和对应的密钥文件路径keytab.

认证模式为ipaddress时,Producer和Consumer创建时不需要做任何改变。而认证模式为kerberos时,需要预先创建好相应的principal和keytab,并使用API进行登录,样例代码如下所示:

public class SecureProducer extends Thread {

private final kafka.javaapi.producer.ProducerInteger, String producer;

private final String topic;

private final Properties props = new Properties();

public SecureProducer(String topic) {

AuthenticationManager.setAuthMethod("kerberos");

AuthenticationManager.login("producer1", "/etc/producer1.keytab");

props.put("serializer.class", "kafka.serializer.StringEncoder");

props.put("metadata.broker.list",

"172.16.1.190:9092,172.16.1.192:9092,172.16.1.193:9092");

// Use random partitioner. Don't need the key type. Just set it to Integer.

// The message is of type String.

producer = new kafka.javaapi.producer.ProducerInteger, String(

new ProducerConfig(props));

this.topic = topic;

}

. . .

Topic权限管理

Topic的权限管理主要是通过AuthorizationManager这个类来完成的,其类结构如下图所示:

其中,resetPermission(user, Permissions, topic) 为重置user对topic的权限。

grant(user, Permissions, topic) 为赋予user对topic权限。

revoke(user, Permissions, topic) 为取消user对topic权限。

isPermitted(user, Permissions, topic) 为检查user对topic是否具有指定权限。

调用grant或revoke进行权限设置完成后,需要commit命令提交修改到ZooKeeper

Kerberos模式下,AuthorizationManager需要先使用AuthenticationManager.login方法登录,与ZooKeeper建立安全的连接,再进行权限设置。示例代码如下所示:

public class AuthzTest {

public static void main(String[] args) {

Properties props = new Properties();

props.setProperty("authentication", "kerberos");

props.setProperty("zookeeper.connect", "172.16.2.116:2181,172.16.2.117:2181,172.16.2.118:2181");

props.setProperty("principal", "kafka/host1@TDH");

props.setProperty("keytab", "/usr/lib/kafka/config/kafka.keytab");

ZKConfig config = new ZKConfig(props);

AuthenticationManager.setAuthMethod(config.authentication());

AuthenticationManager.login(config.principal(), config.keytab());

AuthorizationManager authzManager = new AuthorizationManager(config);

// reset permission READ and WRITE to ip 172.16.1.87 on topic test

authzManager.resetPermission("172.16.1.87",

new Permissions(Permissions.READ, Permissions.WRITE), "test");

// grant permission WRITE to ip 172.16.1.87 on topic test

authzManager.grant("172.16.1.87", new Permissions(Permissions.CREATE), "test");

// revoke permission READ from ip 172.16.1.87 on topic test

authzManager.revoke("172.16.1.87", new Permissions(Permissions.READ), "test");

// commit the permission settings

authzManager点抗 mit();

authzManager.close();

}

}

ipaddress认证模式下,取消和赋予权限的操作如下所示:

public class AuthzTest {

public static void main(String[] args) {

Properties props = new Properties();

props.setProperty("authentication", "ipaddress");

props.setProperty("zookeeper.connect",

"172.16.1.87:2181,172.16.1.88:2181,172.16.1.89:2181");

ZKConfig config = new ZKConfig(props);

// new authorization manager

AuthorizationManager authzManager = new AuthorizationManager(config);

// reset permission READ and WRITE to ip 172.16.1.87 on topic test

authzManager.resetPermission("172.16.1.87",

new Permissions(Permissions.READ, Permissions.WRITE), "test");

// grant permission WRITE to ip 172.16.1.87 on topic test

authzManager.grant("172.16.1.87", new Permissions(Permissions.CREATE), "test");

// revoke permission READ from ip 172.16.1.87 on topic test

authzManager.revoke("172.16.1.87", new Permissions(Permissions.READ), "test");

// commit the permission settings

authzManager点抗 mit();

authzManager.close();

}

}

超稳攻略!Rancher 2.3手动轮换证书,保护集群安全!

Rancher 2.3正式发布已经一年,第一批使用Rancher 2.3的用户可能会遇到Rancher Server证书过期,但是没有自动轮换的情况。这会导致Rancher Server无法启动,并且日志出现报错:

请注意:

Rancher Server无法启动不会影响下游集群,下游集群依然可以通过kubeconfig去操作。

为了让大家更好的理解这个问题,下面将以手动修改系统时间的形式来重现这个问题。

当前时间: 2020年10月30日 星期五 10时37分59秒 CST

1、启动Rancher v2.3.1,并且添加下游集群,操作步骤可以参考官网:

2、启动Rancher 之后,从浏览器上查看到的过期时间: 2021年10月30日 星期六 中国标准时间 10:29:35

3、查看Rancher Server容器内的K3s证书过期时间为 Oct 30 02:28:49 2021 GMT

4、将服务器时间调整为证书过期后5天的日期,比如: 20211105

此时,Rancher UI 已经无法访问:

并且Rancher 容器由于内置的K3s证书过期而不断重启。

以上现象是因为Rancher Server内置的K3s证书过期,导致K3s无法启动,从而导致Rancher Server容器无法启动。

为了可以继续操作Rancher Server容器,需要将系统时间调整到K3s证书过期之前。

接下来我们就可以进入到容器内手动删除K3s证书,然后重启Rancher,重启成功后将重新生成K3s证书。

Rancher Server如果出现以下日志,那么需要再重启一次Rancher Server:

1、将服务器时间再次调整为证书过期后5天的日期,比如: 20211105

证书更新之后,我们需要确认K3s证书是否更新成功,还需要检查下游集群是否会有影响。

2、确认K3s证书已经更新

K3s证书过期时间已经从 Oct 30 02:28:49 2021 GMT 更新到了 Oct 24 16:00:54 2022 GMT

3、确认浏览器证书已经更新

浏览器上的证书过期已经从 2021年10月30日 星期六 中国标准时间 10:29:35 更新到了 2022年10月25日 星期二 中国标准时间 00:01:34

4、确认下游集群不受影响

从Rancher 2.3开始,Rancher Server容器中内置了K3s作为local集群来支撑Rancher Server运行。

而K3s内部自动签发的证书有效期是1年,正常情况下如果证书已过期或剩余的时间少于90天,则在重新启动K3s时将轮换证书。参考官方文档:

实际上由于K3s的bug导致在证书已过期或剩余的时间少于90天时重启Rancher,没有将K3s证书轮换,所以才会出现上述问题。

不过无需担心,在后续的K3s v1.19版本中已经解决了这一问题,请参考:

redis 3.0 cluster 集群 安全性要怎么配置

一直认为redis3.x 集群有自己的安全措施.比如密码,然而在此版本并不会用.

那么就采用了linux防火墙指定了开放端口的访问权限 编辑iptables文件 添加可以访问的IP. 那么只有添加了的IP才能连接上redis服务器端口,也就没有了安全性问题!解决OK

详细可对iptables -s 参数进行了解.


网站标题:服务器集群安全设置 服务器集群的作用
当前URL:http://cdxtjz.cn/article/ddgdcoh.html

其他资讯