X-Security X的安全控制

X-Security

X-Window系统的’访问控制(access control)’功能由X-Security来定义,X-Server端可配置基于IP级别的验证和基于共享key的验证.
确认当前X-Server的’访问控制’功能已开启
xhost配置的是当前终端环境变量DISPLAY所指向的X-Server.所以配置前先确认当前环境变量中的DISPLAY值
rock@rock-ubuntu17:~$ echo KaTeX parse error: Expected 'EOF', got '#' at position 12: DISPLAY :1 #̲显示当前访问控制的状态,和xh… xhost
access control enabled, only authorized clients can connect
SI:localuser:rock
该输出表示访问控制功能已开启,只允许通过IP验证 或 通过共享密钥验证的才能访问X-Server服务
#关闭访问控制. 不验证xhost和xauth
rock@rock-ubuntu17:~$ xhost +
access control disabled, clients can connect from any host
#开启访问控制. 验证xhost和xauth
rock@rock-ubuntu17:~$ xhost -
access control enabled, only authorized clients can connect

基于IP验证
一个Displayer(X-Server)对应一个xhost列表
只需在X-Server端配置
X-Client请求接入时, X-Server验证X-Client的IP是否在放行列表中,不在则拒绝接入
使用xhost维护
#指定配置Displayer1
rock@rock-ubuntu17:~$ export DISPLAY=:1
#允许10.211.55.2上的X-Client接入Displayer1
rock@rock-ubuntu17:~$ xhost + 10.211.55.2
10.211.55.2 being added to access control list
#显示Displayer1上的IP放行列表
rock@rock-ubuntu17:~$ xhost
access control enabled, only authorized clients can connect
INET:10.211.55.2
SI:localuser:rock

以上设置重启失效,永久设置需要写入到对应的配置文件:/etc/X[n].hosts. n为X-Server显示器ID.即:
/etc/X0.hosts: 配置Displayer0的放行列表
/etc/X1.hosts: 配置Displayer1的放行列表

基于预共享密钥验证
一个X-Server关联一个Xauthority文件, 一个Xauthority文件可包含多个Displayer的预共享密钥. X-Server只使用他所关联的Xauthority文件里自身Displayer的密钥记录
需要在X-Server端和X-Client端配置一致的密钥
X-Client接入时带上目标Displayer的密钥,X-Server验证该密钥是否与本地Xauthority文件里配置的一致,不一致则拒绝
使用xauth维护
xauth默认配置的是环境变量XAUTHORITY所指向的Xauthority文件或用户家目录的.Xauthority(当环境变量’XAUTHORITY’不存在时); 可以用-f参数显式指定

在X-Server端为Displayer2生成密钥

rock@rock-ubuntu17:~$ xauth
Using authority file /run/user/1000/gdm/Xauthority
#生成DISPLAY=:2显示器的共享key, '.'表示使用机制’MIT-MAGIC-COOKIE-1’明文共享密钥
xauth> generate :2 .
authorization id is 572
#查看当前显示器共享key列表
xauth> list
rock-ubuntu17/unix:1 MIT-MAGIC-COOKIE-1 5d8f557af058440ef69d6aaa665c91fb
rock-ubuntu17/unix:2 MIT-MAGIC-COOKIE-1 578f3bb50f08cd4831277cc4397a2611
xauth> exit
Writing authority file /run/user/1000/gdm/Xauthority
在X-Client端配置对端Displayer2的密钥
#添加目标Displayer的访问密钥
root@dld:~# xauth add 10.211.55.5:2 . 578f3bb50f08cd4831277cc4397a2611
#配置当前终端使用上步骤的远端Displayer2
root@dld:~# export DISPLAY=10.211.55.5:2
root@dld:~# xclock
如果要编辑指定的Xauthority文件,则:
rock@rock-ubuntu17:~$ xauth -f /root/.Xauthority
X-Server执行时可使用’-auth [auth-file]’选项指定使用的Xauthority文件
rock@rock-ubuntu17:~$ sudo X :1 vt5 -auth /run/user/121/gdm/Xauthority

协议
NAT-sensitive(NAT敏感)

NAT敏感 通常是因为协议的应用报文中带有对端的IP信息, 对端在处理应用逻辑里需要依赖这IP信息. 然而对端在NAT环境后面(即做了DNAT, 外网IP映射为内网IP), 本端是不知道你是做了DNAT的, 所以带的对端的IP是对端的外网IP, 这时对端解释到的IP信息是外网IP, 但他应用逻辑是用内网IP的, 因此导致应用逻辑上的混乱

X-Server与X-Client之间的远程通信使用TCP方式, 在实际测试中发现X-Server和X-Client在同一个局域网内才能连接成功, X-Client连接NAT后的X-Server的话是不能成功的. 看来这协议是’NAT敏感’的. 解决方法通常是使用SSH隧道

还有一个内容本文章没提及, 那就是XDM(X-Display-Manager), 他使用的是XDMCP协议, 走UDP177端口. 以后有机会再补充这块内容
结合SSH隧道运行远端GUI应用
为解决刚说的’NAT敏感’问题. 我们常常使用SSH隧道上的端口转发功能来绕过问题, 其原理图如下:
ssh_tunnel

远端上的X-Client应用程序访问其本地SSH-Server开启的转发监听端口PORT1, SSH-Server将其在Port1在监听接入的数据通过已经建立好连接的SSH隧道转发到我们本地的SSH-Client, SSH-Client再将数据转发到本地X-Server所监听的TCP端口PORT2
以PORT1为6010, PORT2为6002为例, 其SSH隧道建立及开启转发功能的连接命令为:
ssh -R 127.0.0.1:6010:127.0.0.1:6002 user@remotehost

ssh有个简洁的-X参数能自动根据环境配置以上转发参数及远端SSH终端的DISPLAY环境变量. 可以自行翻阅文档查看详情, 这功能需要在SSH-Server开启’X11 Forwarding’选项
这样一来就避开了’NAT敏感’的问题, 从X-Client看来他只是访问本地的X-Server, 从X-Server看来他只是接入本地的X-Client, 所有X层面上看到的IP都是127.0.0.1

同时这个做法避开了X-Security的f远程主机验证,因为都认为是本地主机的访问,只需允许本地访问即可
应用案例
本地MAC端运行远端GUI应用
下面演示使用XQuartz结合SSH的’Forwarding’运行远端GUI
先在本地运行XQuartz:
配置允许网络客户端接入(开启使用TCP方式):
xquartz_conf
关闭XQuartz, 重新打开XQuartz. 此时已发现tcp6000端口已经在监听:
xquartz_listen
允许本地主机访问XQuartz. XQuartz默认没允许本机IP访问
xhost + 127.0.0.1
xquartz_xhost
用ssh的’-R’选项在SSH会话上开启隧道端口转发功能:
意思为将本地XQuartz的X-Server端口tcp6000映射到远端本地上的tcp6010
root@test:~# ssh -R 127.0.0.1:6010:127.0.0.1:6000 user@remotehost
xquartz_ssh
配置远程终端的DISPLAY环境变量
root@test:~# export DISPLAY=:10
如步骤2截图
执行GUI
root@test:~# xterm&
root@test:~# xeyes

使用X11-Forwarding(即’ssh -X user@host’)操作会比较简单, 其实他自动做的事的步骤就是以上说的

本地Ubuntu端运行远端GUI应用
下面演示使用Xorg结合SSH的’Forwarding’运行远端GUI
先在本地的tty5运行Xorg
当前在tty2:
rock@ubuntu17:~$ sudo X :2 vt5 -listen tcp -retro&
tty5:
x_blank
ctrl+alt+F2回到tty2, 确认已经在本地开启Displayer2对应是tcp6002监听:
用ssh的’-R’选项在SSH会话上开启隧道端口转发功能:
ssh -R 127.0.0.1:6010:127.0.0.1:6002 user@remotehost
确认SSH-Server已为我们启动端口转发功能:已开启tcp6010监听
​ 配置远程终端的DISPLAY环境变量, 执行GUI
配置DISPLAY=:10指向SSH启动的转发端口6010:
ctrl+alt+F5 :
最终已转发到我们本地的6002端口:
xorg_xclock
使用X11-Forwarding(即’ssh -X user@host’)操作会比较简单, 其实他自动做的事的步骤就是以上说的
本地Windows端运行远端GUI应用
下面演示使用Xmanager套件结合SSH的’X11 Forwarding’运行远端GUI
先在本地运行X-Server:
现在X-Server已启动, 为Displayer0, 监听tcp6000
接下来运行Xshell, 配置远端会话属性, 开启SSH隧道中的’转发X11’选项:
注意: SSH服务端也需要开启’X11 Forwarding’选项. 不开的话Xshell配置隧道中用’TCP/IP转移’也行, 原理就是前面所说的
登录SSH,并执行GUI, 相应的UI已经在windows本地显示出来:
可看到’X11 Forwarding’已经帮我们终端配置好DISPLAY环境变量了
远端的SSH Server在本地也开启的相应的tcp6015监听, 用于隧道上的端口转发

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供Web应用程序访问主机的PC / SC子系统。 通过Thales e-Security的payShield Manager,安全团队可以执行远离数据中心的所有任务,从而降低成本并提高运营效率。这是专门为Thales payShield 9000 HSM设计的硬件安全模块(HSM)管理工具,通过标准浏览器界面进行操作。通过智能卡访问控制支持到HSM的安全连接,可以远程执行密钥管理,安全配置和软件/许可证更新。通过一个专门的,受限制的操作员角色也可以灵活地检查任何HSM的运行状态。其结果是显着降低了运营成本。 Thales payShield Manager设计时考虑到了最严格的安全要求,解决了当今组织面临的两个主要挑战:如何安全地管理跨多个数据中心的支付HSM,以及如何适应不断增加的必须执行的操作数量。如今日益增加的工作量往往导致更多的旅行和更高的成本。但是,对于Thales payShield Manager,一旦HSM最初安装在数据中心机架中(不依赖于安全团队或主关键组件持有者),可以使用标准Web浏览器界面从远程位置安全地执行配置和管理任务。除了消除旅行的时间和成本之外,浏览器还可以通过加快执行复杂命令来简化操作。由于能够提供更大的职责分离,安全人员可以将更多日常任务委派给安全敏感性较低的操作,同时保持当今支付生态系统所需的高度安全性。 payShield Manager的好处 - 通过消除HSM管理的物理存在,降低运营成本。 - 即使本地物理访问HSMs不可用,也提供24 x 7管理。 - 支持跨多个地点部署的大量HSM。 - 无缝运行VPN和防火墙。 - 通过支持设备访问的管理端口白名单,迅速适应不断变化的组织需求。 支持语言:English
这些都是常见的安全标头(security headers),用于增强网站的安全性。每个标头有不同的作用和配置方式。 1. Strict-Transport-Security(严格传输安全性):该标头指示浏览器只能通过HTTPS与网站建立连接,防止中间人攻击和窃听。可以设置一个时间段,告诉浏览器在该时间内始终使用HTTPS连接。 2. Content-Security-Policy(内容安全策略):该标头定义了哪些内容可以加载到网页中,以防止跨站点脚本攻击(XSS)、点击劫持等安全问题。可以配置允许加载的资源源,限制脚本执行等。 3. X-Content-Type-Options(内容类型选项):该标头指示浏览器不要根据响应中的内容类型进行 MIME 类型猜测。这可以防止一些类型混淆攻击,例如将 JavaScript 文件伪装成图片文件。 4. X-Frame-Options(框架选项):该标头控制网页是否可以在框架中显示,以防止点击劫持攻击。可以配置为禁止在框架中显示、仅允许同源站点显示等。 5. Referrer-Policy(引用来源策略):该标头控制浏览器在发送引用来源信息时的行为。可以配置为完全禁止发送引用来源、仅在同源请求中发送等。 6. Permissions-Policy(权限策略):该标头用于控制网站的权限,例如访问摄像头、麦克风、地理位置等设备或功能。可以配置为允许或禁止特定权限。 这些安全标头可以通过在服务器的响应中添加相应的HTTP头字段来设置。配置正确的安全标头有助于提高网站的安全性和防御能力。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值