linux系统怎么防止DDOS攻击

linux系统怎么防止DDOS攻击,第1张

用squid是利用端口映射的功能,可以将80端口转换一下,其实一般的DDOS攻击可以修改/proc/sys/net/ipv4/tcp_max_syn_backlog里的参数就行了,默认参数一般都很小,设为8000以上,一般的DDOS攻击就可以解决了。如果上升到timeout阶段,可以将/proc/sys/net/ipv4/tcp_fin_timeout设小点。
大家都在讨论DDOS,个人认为目前没有真正解决的方法,只是在缓冲和防御能力上的扩充,跟黑客玩一个心理战术,看谁坚持到最后,网上也有很多做法,例如syncookies等,就是复杂点。
sysctl -w netipv4icmp_echo_ignore_all=1
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
sysctl -w netipv4tcp_max_syn_backlog="2048"
sysctl -w netipv4tcp_synack_retries="3"
iptables -A INPUT -i eth0 -p tcp --syn -j syn-flood
# Limit 12 connections per second (burst to 24)
iptables -A syn-flood -m limit --limit 12/s --limit-burst 24 -j RETURN
这个地方可以试着该该:
iptbales -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
虚拟主机服务商在运营过程中可能会受到黑客攻击,常见的攻击方式有SYN,DDOS等。
通过更换IP,查找被攻击的站点可能避开攻击,但是中断服务的时间比较长。比较彻底
的解决方法是添置硬件防火墙。不过,硬件防火墙价格比较昂贵。可以考虑利用Linux
系统本身提供的防火墙功能来防御。
1 抵御SYN
SYN攻击是利用TCP/IP协议3次握手的原理,发送大量的建立连接的网络包,但不实际
建立连接,最终导致被攻击服务器的网络队列被占满,无法被正常用户访问。
Linux内核提供了若干SYN相关的配置,用命令:
sysctl -a | grep syn
看到:
netipv4tcp_max_syn_backlog = 1024
netipv4tcp_syncookies = 0
netipv4tcp_synack_retries = 5
netipv4tcp_syn_retries = 5
tcp_max_syn_backlog是SYN队列的长度,tcp_syncookies是一个开关,是否打开SYN Cookie
功能,该功能可以防止部分SYN攻击。tcp_synack_retries和tcp_syn_retries定义SYN
的重试次数。
加大SYN队列长度可以容纳更多等待连接的网络连接数,打开SYN Cookie功能可以阻止部分
SYN攻击,降低重试次数也有一定效果。
调整上述设置的方法是:
增加SYN队列长度到2048:
sysctl -w netipv4tcp_max_syn_backlog=2048
打开SYN COOKIE功能:
sysctl -w netipv4tcp_syncookies=1
降低重试次数:
sysctl -w netipv4tcp_synack_retries=3
sysctl -w netipv4tcp_syn_retries=3
为了系统重启动时保持上述配置,可将上述命令加入到/etc/rcd/rclocal文件中。
2 抵御DDOS
DDOS,分布式拒绝访问攻击,是指黑客组织来自不同来源的许多主机,向常见的端口,如80,
25等发送大量连接,但这些客户端只建立连接,不是正常访问。由于一般Apache配置的接受连接
数有限(通常为256),这些“假” 访问会把Apache占满,正常访问无法进行。
使用ipchains抵御DDOS,就是首先通过netstat命令发现攻击来源地址,然后用ipchains命令阻断
攻击。发现一个阻断一个。
首先查看ipchains服务是否设为自动启动:
chkconfig --list ipchains

1一般攻击者都是通过扫描端口来实施DOOS流量攻击的,因此游戏网站服务器一定要上加端口,且关闭不用的端口,避免通过端口扫描到你的网站服务器。
2尽可能对系统加载最新补丁,并采取有效的合规性配置,降低漏洞利用风险。
3保护网站服务器ip地址,在平时发布广告时一定要注意不要泄露你的ip地址。
4选择防御能力更强的高防服务器,可以选择美国高防服务器,因为美国服务器的防御能力最强。

Session共享有多种解决方法,常用的有四种:客户端Cookie保存、服务器间Session同步、使用集群管理Session、把Session持久化到数据库。


1客户端Cookie保存
以cookie加密的方式保存在客户端,每次session信息被写在客户端,然后经浏览器再次提交到服务器,即使两次请求在集群中的两台服务器上完成,也可以到达session共享。


优点是减轻服务器端的压力;


缺点是受到cookie的大小限制,可能占用一定带宽,因为每次请求会在头部附带一定大小的cookie信息,另外这种方式在用户禁止使用cookie的情况下无效。


传统网站一般通过将一部分数据存储在cookie中,来规避分布式环境下session的 *** 作。这样做的弊端很多,一方面cookie的安全性一直广为垢病,另一方面cookie存储数据的大小是有限制的。随着移动互联网的发展,很多情况下还得兼顾移动端的session需求,使得采用cookie来进行session同步的方式的弊端更为凸显,分布式session正是在这种情况下应运而生的。


2服务器间Session同步
定时同步各个服务器的session信息,此方法可能有一定延时,用户体验也不是很好。


使用主-从服务器的架构,当用户在主服务器上登录后,通过脚本或者守护进程的方式,将session信息传递到各个从服务器中,也可以手工把session文件存放的目录改为nfs网络文件系统,从而实现文件的跨机器共享(使用nfs或windows文件共享都可以,或者专用的共享存储设备)。


这样,用户访问其它的从服务器时,就可以读到session信息。


缺点:比如速度慢、不稳定等,另外,如果session信息传递是主->从单向的,会有一些风险,比如主服务器down了,其它服务器无法获得session信息。


3把Session持久化到数据库
这种共享session的方式即将session信息存入数据库中,其它应用可以从数据库中查出session信息。目前采用这种方案时所使用的数据库一般为mysql。


利用数据库共享session的方案有一定的实用性,但也有如下缺点:
首先session的并发读写在数据库中完成,对mysql的性能要求比较高;
其次,我们需要额外地实现session淘汰逻辑代码,即定时从数据库表中更新和删除session信息,增加了工作量。
对于系统可靠性要求较高的用户,可以将session持久化到DB中,这样可以保证宕机时会话不易丢失,但缺点也是显而易见的,系统的整体吞吐将受到很大的影响。


4使用集群管理Session
将session统一存储在缓存集群上,如memcache,这样可以保证较高的读、写性能,这一点对于并发量大的系统来说非常重要;并且从安全性考虑,session毕竟是有有效期的,使用缓存存储,也便于利用缓存的失效机制。


使用缓存的缺点是,一旦缓存重启,里面保存的会话也就丢失了,需要用户重新建立会话,可以使用缓存集群来保证缓存的稳定性。


如图(基于缓存的分布式session架构)所示,前端用户请求经过随机分发之后,可能会命中后端任意的Web Server,将session以sessionid作为key,保存到后端的缓存集群中,使得不管请求如何分配,即便是某个Web Server宕机,也不会影响其他Web Server获得 session,这样既实现了集群间的session同步,又提高了 Web Server的容错性。


Tomcat作为Web Server时,可以通过一个简单的工具memcached-session- manager9(一个Tomcat session共享解决方案), 实现基于memcache的分布式session。

前景不大,而且风险很大
首先,免费空间往往并不能引来真正的有实力的站长。
您的用户将主要包括二部分:
1菜鸟新手,风险:这些人由于是菜鸟,往往不会注意到做站的忌讳,可能会时不时发一些属于愤青的话(而这些往往会引起网监的注意)其次由于是新手,做的网站可能安全问题很多,容易被黑客入侵,造成服务器甚至整个机房的安全隐患
2职业骗子,如钓鱼网站很可能找您的站安家因为这些网站本来就是很容易被关闭的,因此当然是如果能找到免费的最好于是,网监又要找您了
这只是从网监的角度来说,当您的服务器满是新手站点,垃圾信息成群,诈骗信息成堆时,由于是新手或骗子,它们往往不会绑定自己的域名,往往使用你们赠送的免费三级甚至四级域名,于是,时间一长,可能QQ等第三方服务商就把您的域名封了,于是得不偿失!
虽然能短时期内引来大量用户,然而用户质量并不高,完全属于低端用户。而由于你们是免费空间,肯定是和收费空间无法比的,于是,各种贴吧,论坛等可能就会被用户充斥着对你们的不满,什么垃圾主机等这是对声誉的影响!
欢迎与我交流,直接HI我!


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13472445.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-08-13
下一篇 2023-08-13

发表评论

登录后才能评论

评论列表(0条)

保存