GNU/Linux安全基线与加固

55 views
Skip to first unread message

Shawn

unread,
Mar 19, 2015, 11:32:10 AM3/19/15
to CDLUG_c...@googlegroups.com, sh...@googlegroups.com
原文:

https://raw.githubusercontent.com/citypw/DNFWAH/master/4/d4_0x02_DNFWAH_gnu-linux_security_baseline_hardening.txt

--
GNU powered it...
GPL protect it...
God blessing it...

regards
Shawn

Shell Xu

unread,
Mar 19, 2015, 11:28:53 PM3/19/15
to shlug, CDLUG_c...@googlegroups.com
谢谢,正好需要。

--
-- You received this message because you are subscribed to the Google Groups Shanghai Linux User Group group. To post to this group, send email to sh...@googlegroups.com. To unsubscribe from this group, send email to shlug+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/shlug?hl=zh-CN
---
您收到此邮件是因为您订阅了 Google 网上论坛的“Shanghai Linux User Group”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到shlug+un...@googlegroups.com
要查看更多选项,请访问 https://groups.google.com/d/optout



--
彼節者有間,而刀刃者無厚;以無厚入有間,恢恢乎其於游刃必有餘地矣。
blog: http://shell909090.org/blog/

AR

unread,
Mar 19, 2015, 11:56:40 PM3/19/15
to sh...@googlegroups.com, CDLUG_c...@googlegroups.com
On Thu, Mar 19, 2015 at 11:32 PM, Shawn <cit...@gmail.com> wrote:
> 原文:
>
> https://raw.githubusercontent.com/citypw/DNFWAH/master/4/d4_0x02_DNFWAH_gnu-linux_security_baseline_hardening.txt
>

赞,正好需要+1,多谢。

--
Silence is golden.

Chaos Eternal

unread,
Mar 22, 2015, 9:38:06 AM3/22/15
to sh...@googlegroups.com
大概看了一下,以下几点觉得可以探讨一下:
A. 1.2 2 密码策略

对于不同的设备用不同的密码,这一点并不永远正确。按照文中的密码长度要求,如果一个人管十台设备,他要记十个密码,如果这些设备的登录频率不一样,那么他只能要么选择弱密码,要么将密码记在某个地方,而这些反而增加了管理的复杂度并增加了不确定性。你不知道他是把密码写在贴纸上还是放在一个B+级安全设备里面。如果用同一个密码,那由于这个密码常常使用,反而不会忘记。
所以从组织的角度,应该尽量减少管理员要记的密码,使用单点登录技术最好(比如kerberos)。
B. 1.3 ssh 对称密码选择:
3DES 的密钥长度是112位,足够安全,如果你要说它的s-box可能有后门,那aes就更不安全了。
根据下文, arcfour的安全性也比rc4强。
http://security.stackexchange.com/questions/26765/what-are-the-differences-between-the-arcfour-arcfour128-and-arcfour256-ciphers

MAC算法: hash算法能碰撞不代表hmac也会碰撞。如下文所说。
http://security.stackexchange.com/questions/26765/what-are-the-differences-between-the-arcfour-arcfour128-and-arcfour256-ciphers
再比如: https://tools.ietf.org/html/rfc4226 这里面也提到:

Historically, the HMAC design has already proven itself in this
regard. MD5 is considered broken in that collisions in this hash
function can be found relatively easily. But there is still no
attack on HMAC-MD5 better than the trivial 2^{64} time birthday one.
(MD5 outputs 128 bits, not 160.) We are seeing this strength of HMAC
coming into play again in the SHA-1 context.
所以没有明显的理由专门排除 HMAC-MD5。
C. 1.4.2 禁止修改history相关变量,是没有效果的,完全不可以依赖这个。保险的做法是用sudo
记录权限用户的操作,或者前面放贵老板公司产的堡垒机,以及用selinux/apparmor做记录。

D.
net.ipv4.icmp_echo_ignore_all = 1 带来的麻烦比解决的问题多。这个是15年前的说法了,没想到现在还拿出来说。


另外:
建议说明一下文档的授权,个人建议是 CC-BY

On Thu, Mar 19, 2015 at 11:32 PM, Shawn <cit...@gmail.com> wrote:

Shell Xu

unread,
Mar 22, 2015, 10:38:59 PM3/22/15
to shlug
sudo也不算靠谱,selinux之类也有类似的问题。只要能拿到一个无限制的shell,被渗入的可能性就大大增加了。而这些机制在渗入后都是靠不住的。
堡垒机是个办法,不过这广告打的明显了点。。。

Shell Xu

unread,
Mar 22, 2015, 10:40:48 PM3/22/15
to shlug
另外,授权的事确实也要注意一下。原则上说,无授权即是版权所有。但是操作上,你懂。所以我对大部分互联网公开文档的建议都是上一个cc协议,大家都没麻烦。

在 2015年3月22日 下午9:38,Chaos Eternal <chaose...@shlug.org>写道:

Chaos Eternal

unread,
Mar 23, 2015, 12:25:45 AM3/23/15
to sh...@googlegroups.com
A. 1.2 2 密码策略
这个我说的清楚一点:
对于不同的设备用不同的密码,这一点并不永远正确。按照文中的密码长度要求,如果一个人管十台设备,他要记十个复杂密码,如果这些设备的登录频率不一样,对于登录频率低的服务器的密码就很容易忘记,对于这些服务器,他只能要么选择弱密码,要么将密码记在某个地方,而这些反而增加了管理的复杂度并增加了不确定性。你不知道他是把密码写在贴纸上还是放在一个B+级安全设备里面。如果这些服务器用同一个密码就可以登录,那由于这个密码常常使用,反而不会忘记。
我不是说,这些服务器的密码都应该设成一样, 而是说从组织的角度来看,应该尽量减少管理员要记的密码,使用单点登录技术最好(比如kerberos)。

另外,对于一个服务器有多个管理员的情况,我不赞成把root密码在这些管理员之间共享,而是建议用sudo 给这些人sudo成root的权限。

别跟我说ppll13%dkstFeb1st 这是扯淡。

Shell Xu

unread,
Mar 23, 2015, 12:46:53 AM3/23/15
to shlug
如果你是说给权限的问题,是的,sudo比su更好。

Shawn

unread,
Mar 25, 2015, 4:08:40 AM3/25/15
to sh...@googlegroups.com
2015-03-22 21:38 GMT+08:00 Chaos Eternal <chaose...@shlug.org>:
> 大概看了一下,以下几点觉得可以探讨一下:
> A. 1.2 2 密码策略
>
> 对于不同的设备用不同的密码,这一点并不永远正确。按照文中的密码长度要求,如果一个人管十台设备,他要记十个密码,如果这些设备的登录频率不一样,那么他只能要么选择弱密码,要么将密码记在某个地方,而这些反而增加了管理的复杂度并增加了不确定性。你不知道他是把密码写在贴纸上还是放在一个B+级安全设备里面。如果用同一个密码,那由于这个密码常常使用,反而不会忘记。
> 所以从组织的角度,应该尽量减少管理员要记的密码,使用单点登录技术最好(比如kerberos)。
> B. 1.3 ssh 对称密码选择:
> 3DES 的密钥长度是112位,足够安全,如果你要说它的s-box可能有后门,那aes就更不安全了。
>
3DES和AES是否安全取决于你的威胁建模,你要防谁,你觉得谁会用twofish;-)

> 根据下文, arcfour的安全性也比rc4强。
> http://security.stackexchange.com/questions/26765/what-are-the-differences-between-the-arcfour-arcfour128-and-arcfour256-ciphers
>
> MAC算法: hash算法能碰撞不代表hmac也会碰撞。如下文所说。
> http://security.stackexchange.com/questions/26765/what-are-the-differences-between-the-arcfour-arcfour128-and-arcfour256-ciphers
> 再比如: https://tools.ietf.org/html/rfc4226 这里面也提到:
>
> Historically, the HMAC design has already proven itself in this
> regard. MD5 is considered broken in that collisions in this hash
> function can be found relatively easily. But there is still no
> attack on HMAC-MD5 better than the trivial 2^{64} time birthday one.
> (MD5 outputs 128 bits, not 160.) We are seeing this strength of HMAC
> coming into play again in the SHA-1 context.
> 所以没有明显的理由专门排除 HMAC-MD5。
>
你是对的。

> C. 1.4.2 禁止修改history相关变量,是没有效果的,完全不可以依赖这个。保险的做法是用sudo
> 记录权限用户的操作,或者前面放贵老板公司产的堡垒机,以及用selinux/apparmor做记录。
>
没人说“完全依赖”,history本身也能bypass,selinux就一定靠谱?防御需要考虑所有的点..........

> D.
> net.ipv4.icmp_echo_ignore_all = 1 带来的麻烦比解决的问题多。这个是15年前的说法了,没想到现在还拿出来说。
>
好吧,我承认我还活在90's:-)

>
> 另外:
> 建议说明一下文档的授权,个人建议是 CC-BY
>
我虽然喜欢CC/FDL,但。。。你见过有“文档授权申明”的ezine吗?

Chaos Eternal

unread,
Mar 25, 2015, 9:48:21 AM3/25/15
to sh...@googlegroups.com
1. 所以你的观点是? 到底安全基线是为了啥?
2. 既然是安全基线,当然要比较reasonable啊,搞history没啥意义,反而误导管理员
3. 关icmp_echo真的不必要,让防火墙干这个活更好。

最后这个吧。。anyway了

李伟斌

unread,
Mar 25, 2015, 10:50:59 AM3/25/15
to sh...@googlegroups.com
看大家讨论的好深奥哦....那我管理的服务器不是很不安全?我所有的设备都用了一样的密码,长度21位,另外服务器登录管理都是由一台Linux跳板服务器跳转,远程只能有两台主机通过VPN连到堡垒机..没有设置密码策略,基本都是默认...开了防火墙和selinux。你们说的基线是不是我们定义网络安全最低容忍的综合考量?我听你们这么一说感觉好恐怖,服务器时刻暴露再极度不安全环境下一样.大家给支点儿招吧.....

发自我的 iPhone

Aron Xu

unread,
Mar 25, 2015, 4:14:09 PM3/25/15
to sh...@googlegroups.com
貌似市面上的堡垒机问题也都不少,用了这货其实也是个问题。

Aron
Regards,
Aron Xu

Shell Xu

unread,
Mar 25, 2015, 11:18:43 PM3/25/15
to shlug
别吐槽堡垒机了,真搞过就知道,那是为了解决在实际工作环境中一坨屎的情况。
搞运维的多了,总有几个水平好的几个水平差的,几个认真的几个胡搞的。要是真的全让他们直连服务器,先不说入侵的问题。没三天,服务器自己炸了。

Shell Xu

unread,
Mar 25, 2015, 11:25:05 PM3/25/15
to shlug
当然,我自己补一刀。
对好点的运维来说,有无数办法绕过堡垒机干点坏事,但是却没有办法绕过堡垒机(或者通过堡垒机)天天干好事。。。

在 2015年3月26日 上午4:13,Aron Xu <aronm...@gmail.com>写道:



--

AR

unread,
Mar 26, 2015, 4:05:02 AM3/26/15
to sh...@googlegroups.com
2015-03-26 11:24 GMT+08:00 Shell Xu <shell...@gmail.com>:
> 当然,我自己补一刀。
> 对好点的运维来说,有无数办法绕过堡垒机干点坏事,但是却没有办法绕过堡垒机(或者通过堡垒机)天天干好事。。。

这样干了好事也没人知道啦噗。

不过堡垒机虽蛋疼,但面对鱼龙混杂的环境确实还得上啊.....防君子不防小人...嗯,起码还能防一下没水平的小人

--
Silence is golden.

macint0sh

unread,
Mar 27, 2015, 10:23:14 PM3/27/15
to sh...@googlegroups.com
原来是大神你写的文章啊 膜拜

On 2015年03月19日 23:32, Shawn wrote:
> 原文:
>
> https://raw.githubusercontent.com/citypw/DNFWAH/master/4/d4_0x02_DNFWAH_gnu-linux_security_baseline_hardening.txt
>

Reply all
Reply to author
Forward
0 new messages