<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="http://valley.egloos.com/rss/style/style.xsl" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>이글루스 'syn' 태그 최근글</title>
		<link>http://valley.egloos.com/tag/syn</link>
		<description>syn</description>
		<language>ko</language>
		<pubDate>Thu, 23 Dec 2010 14:30:23 +0900</pubDate>
		<generator>Egloos</generator>
		<item>
	<title><![CDATA[syn 공격 기본 방어]]></title>
	<link>http://forbis.egloos.com/3530140</link>
	<guid>http://forbis.egloos.com/3530140</guid>
	<description>
	<![CDATA[ 
출처 :  1. 백로그 큐를 늘려준다. 직관적으로 보았을 때 서비스 거부에 돌입하게 되는 것은 백로그큐(Backlog Queue)가 가득 차서 다른 접속 요구를 받아들이지 못하기 때문이므로 백로그 큐의 크기를 늘려주면 될 것이다. 실제로 리눅스를 포함해서 많은 운영체제들의 백로그큐값을 조사해 보면 이 값이 필요 이상으로 작게 설정되어 있어 적절히 늘려주는 것이 좋다. 현재 시스템에 설정된 백로그큐의 크기는 [root@net /root]# sysctl -a|grep syn_backlog net.ipv4.tcp_max_syn_backlog = 128 또는 [root@net /root]# cat /proc/sys/net/ipv4/tcp_max_syn_backlog 128 로 확인가능하며 128kb 인 것을 확인할	]]>
	</description>
	<pubDate>Thu, 23 Dec 2010 14:30:23 +0900</pubDate>
	<dc:creator><![CDATA[나는 노력한다.]]></dc:creator>
</item>
<item>
	<title><![CDATA[[우분투, DDoS] 아파치 웹서버 신쿠키 설정]]></title>
	<link>http://mcchae.egloos.com/10524395</link>
	<guid>http://mcchae.egloos.com/10524395</guid>
	<description>
	<![CDATA[ 
같이 일하시는 곽책임님의 조언으로 알았습니다.요즘 웹서버는 일반 TCP SYN Flooding 공격을 대비할 수 있는 방편이리눅스 커널에 포함되어 있습니다.  일단, 아래와 같은 명령을 주어  $ sudo sysctl -a 2&amp;gt;/dev/null | grep syncookiesnet.ipv4.tcp_syncookies = 1  와 같이 1이 나오면 SYN Cookie가 설정되어 있는 것입니다.  만약 설정되어 있지 않다면,  $ sudo sysctl -w net.ipv4.tcp_syncookies=1  와 같이 설정할 수 있습니다.  초당 10만개의 TCP SYN 등의 공격도 잘 방어를 합니다.	]]>
	</description>
	<pubDate>Sat, 03 Jul 2010 19:38:54 +0900</pubDate>
	<dc:creator><![CDATA[지훈현서]]></dc:creator>
</item>
<item>
	<title><![CDATA[TCP SYN_Flooding 공격의 원인과 해결책]]></title>
	<link>http://visu4l.egloos.com/1677830</link>
	<guid>http://visu4l.egloos.com/1677830</guid>
	<description>
	<![CDATA[ 
TCP SYN_Flooding 공격의 원인과 해결책SYN Flooding 공격의 개념이 소개된지는 꽤되었지만 최근 들어 리눅스가 확산되고, 간단하게 실행할 수 있는 공격 소스가 광범위하게 배포되면서 이 공격이 자주 확인 되고있고, 이로 인해 그 피해가 급속히 확산되고 있다. 실제로 현재 가장 많이 사용되고 있는 배포본인 레드헷 6.x 계열에 이공격을 실행하기만 하면 단 몇 초만에 서비스가 정지해 버리게 된다. 따라서 이번 호에서는 피해가 확산되고 있는 이 공격의 원리와대처방법에 대해 알아보도록 하자.글/홍석범 오늘과 내일 넷센터(antihong@tt.co.kr)최근 자신이 운영하는 서버에 특별히 부하가 걸리거나 이상이 있는 것도 아니고 또 데몬도 정상적으로 떠 있는데, 정작 서비스가작동하지 않는 경우가 종종	]]>
	</description>
	<pubDate>Tue, 06 May 2008 16:47:45 +0900</pubDate>
	<dc:creator><![CDATA[Wonderful days...]]></dc:creator>
</item>
<item>
	<title><![CDATA[FreeBSD: Limiting open port RST response from xxx to 200 packets/sec]]></title>
	<link>http://purewell.egloos.com/3513098</link>
	<guid>http://purewell.egloos.com/3513098</guid>
	<description>
	<![CDATA[ 
FreeBSD에서 /var/log/message 안에 &quot;Limiting open port RST response from xxx to 200 packets/sec&quot;라는 메시지를 볼 수 있다. 외부로부터 잘못된 SYN요청이 과도하게 들어와서 RST로 응답하는 회수를 초당 200건으로 제한했다는 의미이다. 이게 SYN 공격을 통해서 발생할 수도 있지만, 의도치 않게 네트워크 상황에 따라 발생할 수도 있다.    예를 들어 해외에 NAT로 묶인 망이 있고, 그곳에 서비스 이용 클라이언트가 3,000개(순단 시 자동으로 재접속 시도가 있다는 것도 가정!)가 있다는 가정을 해보자. 해외망 특성상 네트워크 순단이 숨쉬기보다 조금 덜 발생하는데, 위에서 말한 망이 살짝 순단일 경우 동시에 3,000개 접속(session	]]>
	</description>
	<pubDate>Mon, 03 Dec 2007 10:48:19 +0900</pubDate>
	<dc:creator><![CDATA[Purewell.BIZ]]></dc:creator>
</item>
<item>
	<title><![CDATA[[network programming]TCP SYN flooding]]></title>
	<link>http://zubilan.egloos.com/3938460</link>
	<guid>http://zubilan.egloos.com/3938460</guid>
	<description>
	<![CDATA[ 
windows XP sp2에서는 raw socket으로 syn을 내보낼수 없다-_-!!!  이것 때문에 일주일을 밤샜고만...ㅠ   --------------------------------- 같은수업듣는 학생이 찾아 올려준 글 ---------------------------------저도 TCP Raw 패킷을 보낼 때 자꾸 에러가 나서 인터넷을 뒤져보니 다음과 같은 내용이 있더군요..2.Why can't I send TCP packets on Windows XP?New restrictions on raw socket functionality were imposed in Windows XP SP2. If you're running Windows XP SP2, you cannot send TCP packet	]]>
	</description>
	<pubDate>Fri, 16 Nov 2007 15:49:23 +0900</pubDate>
	<dc:creator><![CDATA[진인사대천명(盡人事待天命)]]></dc:creator>
</item>
<item>
	<title><![CDATA[connect 완료 시점은 accept가 아니다.]]></title>
	<link>http://purewell.egloos.com/3351468</link>
	<guid>http://purewell.egloos.com/3351468</guid>
	<description>
	<![CDATA[ 
흔히 생각하기에 TCP에서 3-way handshaking(SYN→SYN-ACK→ACK)를 완료하는 시점이 accept를 하는 시점이라고 착각하기 쉽다. 그러나 경기도 오산이라는거~* listen시점부터 이미 서버쪽은 3-way handshaking를 할 수 있고, 접속을 완료한 뒤에는 그것을 backlog queue에 고스란히 모셔둔다. accept함수는 큐에서 그것을 긁어올 뿐.	]]>
	</description>
	<pubDate>Thu, 23 Aug 2007 14:38:35 +0900</pubDate>
	<dc:creator><![CDATA[Purewell.BIZ]]></dc:creator>
</item>
	</channel>
</rss>

