一、配置加固
1)限制连续密码错误的登录次数,是对抗密码暴力破解的重要手段;
2)拆分系统管理员的权限,取消超级管理员,从而限制入侵者获取管理员账户时的权限;
3)删除不需要的各种账户,避免被攻击者利用;
4)关闭不需要的服务端口,一是减少攻击者的入侵点,二是避免被入侵者当作后门利用;
5)限制远程登录者的权限,尤其是系统管理权限;
二、合规性加固
比如权限划分
三、反控制加固
比如:掌握控制权、发现隐藏者、监控 *** 作者
景安网络专业的数据中心服务商,值得你托管租用服务器!
应邀回答行业问题Linux系统广泛被应用在服务器上,服务器存储着公司的业务数据,对于互联网公司数据的安全至关重要,各方面都要都要以安全为最高优先级,不管是服务器在云端还在公司局域网内,都要慎之又慎。
如果黑客入侵到公司的Linux服务器上,执行下面的命令,好吧,这是要彻底摧毁的节奏,5分钟后你只能呵呵的看着服务器了,为什么要seek呢?给你留个MBR分区。
dd if=/dev/zero of=/dev/sda bs=4M seek=1
Linux系统的安全加固可分为系统加固和网络加固,每个企业的业务需求都不一样,要根据实际情况来配置。比如SSH安全、账户弱口令安全、环境安全、关闭无用服务、开启防火墙等,已经Centos7为例,简单说下linux系统SSH网络安全加固。
SSH安全
将ssh服务的默认端口22修改为其他端口,并限制root用户登陆,配置firewall允许ssh端口通过。
[root@api ~]#sed -i 's#Port 22#Port 6022#' /etc/ssh/sshd_config
[root@api ~]#echo 'PermitRootLogin no' /etc/ssh/sshd_config
[root@api ~]# firewall-cmd --zone=public --add-port=6022/tcp --permanent
[root@api ~]# firewall-cmd --reload
限制访问ssh的用户和IP
[root@api ~]#echo 'AllowUsers NAME' >>/etc/ssh/sshd_config
[root@api ~]# echo 'sshd:xxxxx:allow' >>/etc/
hostsallow
[root@api ~]# systemctl restart sshd
禁止ping测试服务器,禁止IP伪装。
[root@api ~]# echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
[root@api ~]# echo nospoof on >> /etc/hostconf
在Centos7以后iptables将被firewall替代,当然我们还能够使用iptables,首先需要删除firewall后,才能够使用iptables,技术总是在进步的,老的会慢慢被替代。
Linux系统安全加固还有很多,想要继续可以查阅资料。所谓SQL注入式攻击,就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串,欺骗服务器执行恶意的SQL命令。在某些表单中,用户输入的内容直接用来构造(或者影响)动态SQL命令,或作为存储过程的输入参数,这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如:
⑴ 某个ASPNET Web应用有一个登录页面,这个登录页面控制着用户是否有权访问应用,它要求用户输入一个名称和密码。
⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令,或者直接用作存储过程的参数。下面是ASPNET应用构造查询的一个例子:
SystemTextStringBuilder query = new SystemTextStringBuilder(
"SELECT from Users WHERE login = '")
Append(txtLoginText)Append("' AND password='")
Append(txtPasswordText)Append("'");
⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。
⑷ 用户输入的内容提交给服务器之后,服务器运行上面的ASPNET代码构造出查询用户的SQL命令,但由于攻击者输入的内容非常特殊,所以最后得到的SQL命令变成:SELECT from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。
⑸ 服务器执行查询或存储过程,将用户输入的身份信息和服务器中保存的身份信息进行对比。
⑹ 由于SQL命令实际上已被注入式攻击修改,已经不能真正验证用户身份,所以系统会错误地授权给攻击者。
如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询,他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能,欺骗系统授予访问权限。
系统环境不同,攻击者可能造成的损害也不同,这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限,攻击者就可能对数据库的表执行各种他想要做的 *** 作,包括添加、删除或更新数据,甚至可能直接删除表。
⑴ 对于动态构造SQL查询的场合,可以使用下面的技术:
第一:替换单引号,即把所有单独出现的单引号改成两个单引号,防止攻击者修改SQL命令的含义。再来看前面的例子,“SELECT from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。
第二:删除用户输入内容中的所有连字符,防止攻击者构造出类如“SELECT from Users WHERE login = 'mas' -- AND password =''”之类的查询,因为这类查询的后半部分已经被注释掉,不再有效,攻击者只要知道一个合法的用户登录名称,根本不需要知道用户的密码就可以顺利获得访问权限。
第三:对于用来执行查询的数据库帐户,限制其权限。用不同的用户帐户执行查询、插入、更新、删除 *** 作。由于隔离了不同帐户可执行的 *** 作,因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。 ⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外,它还使得数据库权限可以限制到只允许特定的存储过程执行,所有的用户输入必须遵从被调用的存储过程的安全上下文,这样就很难再发生注入式攻击了。
⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符,那么不要认可表单中输入的10个以上的字符,这将大大增加攻击者在SQL命令中插入有害代码的难度。
⑷ 检查用户输入的合法性,确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证,是为了弥补客户端验证机制脆弱的安全性。在客户端,攻击者完全有可能获得网页的源代码,修改验证合法性的脚本(或者直接删除脚本),然后将非法内容通过修改后的表单提交给服务器。因此,要保证验证 *** 作确实已经执行,唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象,例如RegularExpressionValidator,它们能够自动生成验证用的客户端脚本,当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象,你可以通过CustomValidator自己创建一个。
⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据,然后再将它与数据库中保存的数据比较,这相当于对用户输入的数据进行了“消毒”处理,用户输入的数据不再对数据库有任何特殊的意义,从而也就防止了攻击者注入SQL命令。SystemWebSecurityFormsAuthentication类有一个HashPasswordForStoringInConfigFile,非常适合于对输入数据进行消毒处理。
⑹ 检查提取数据的查询所返回的记录数量。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)