HTTP/1.0 protocol 접근 제한
글쓴이: 김정균 / 작성시간: 목, 2006/06/22 - 5:34오후
2006.06.22 17:20 분 부터 *.kldp.org 로 접근시에, HTTP/1.0 protocol 로 접근하는 case 를 차단하고 있습니다.
현재, 중국발 worm attack 으로 서버의 부하가 엄청나게 높아져서 제대로 서비스를 할 수 없어, case by case 로 attack 유발을 막기 위한 일단의 첫번째 조치로, HTTP/1.0 protocol 을 막게 되었습니다.
이로 인하여 다음의 증상이 유발이 될 수 있습니다.
1. 잘 작동하던 RSS Feed 가 되지 않을 수 있습니다.
(RSS Feed 가 HTTP/1.0 protocol 을 사용하고 있다면 문제가 됩니다.)
2. 일부 검색 엔진의 scraw 들이 페이지 수집을 못할 수 있다.
3. KLDP page 를 긁어가는 스크립트를 운영하시는 분들께서 1.0 protocol 을 사용할 경우 더이상 가져가지 못할수 있다.
대충 이정도 입니다. 혹시 1.0 Protocol 이 변경 됨으로 해서 문제가 되는 경우가 있다면 댓글을 달아 주시기 바랍니다.
P.S
수정해서 사용할 수 있다면, HTTP/1.1 을 이용해 주십시오.
관리자 주제:
댓글
해당 IP를 차단하면 안될까요?
해당 IP를 차단하면 안될까요?
그리고 해당 ip를 게시판에 공지하죠^^
-------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)을 쓰지 말아 주십시요.
의견이 있으시면 원 글에 댓글(comment)로 써 주세요.
IP 로 막기에는
IP 로 막기에는 범위가 너무 넓습니다. 그때그때 추가하는 것도 한계가 있습니다.
Liferea
피드 리더 Liferea 1.0.12, GtkHTML 백엔드인데 HTTP/1.0을 써서 막히네요. 막연히 가볍다는 이유로 써 왔는데 Mozilla 백엔드로 바꿔야겠습니다.
백엔드
백엔드와는 상관 없네요. Mozilla 백엔드도 마찬가지입니다.
소스
Liferea 소스에서 src/net/netio.c 안에 HTTP/1.0으로 하드코딩 되어 있습니다.
RSS Feed 의 UserAgent name
RSS Feed 의 UserAgent name 을 적어 주시면 (1.0 으로 작동하는 것들..) 풀어보도록 하겠습니다.
User-Agent
User-Agent: Liferea/1.0.12 (Linux; ko_KR.EUC-KR; http://liferea.sf.net/)
입니다.
풀어 놓았습니다.
풀어 놓았습니다. 테스트 후에 확인 부탁 드립니다. 이 외에 w3m/lynx/HanRSS/MagpieRSS 를 같이 풀어 놓았습니다. 1.0 으로 들어오는 것은 몇개 안되는 듯 싶군요.
확인
방금 확인하였습니다. 잘 됩니다.
RSS리더 연모도 되지 않습니다. -.0 허용해 주세요
RSS리더 연모도 안됩니다.
( http://yeonmo.theple.com )
연모의 경우 1.0을 사용하는듯 합니다.
브라우져 에이전트는 특별히 모르겠는데
갑자기 좀 답답하네요.
속도가 느린 부분을 고치지 않고
접속을 차단하게 하는 방식으로는
그리 길게 효용이 있을것 같지는 않다고 생각하니
관리자분께서는 다른 조치가 필요할것 같습니다.
국내 IP대역에서 들어오는 1.0은 허용해 주시는것이 어떨까요?
지나가는 연모
지나가는 연모 사용자입니다.
연모는 Ver.5의 경우 (이전 버전은 모르겠습니다) HTTP 1.1을 사용합니다. 구독 데이터를 받아올 때 오가는 패킷을 살짝 훔쳐보니, 분명 데이터를 잘 받아오는데 연모에서 표시해 주지를 않는군요. 다른 RSS 리더로 해봤을 때는 표시까지 잘 해주는 걸로 보아, 연모가 사이트를 좀 가리는 듯 합니다.
----
$PWD `date`
$PWD `date`
확인은 해
확인은 해 보겠습니다만.. 몇가지 오해가 있는 듯 해서 남깁니다.
속도가 느린 부분이 아니라 정상적인 사용에서는 문제가 없는 부분에서, 특정 쿼리가 이를 유발하는 case 입니다. 즉, 조치를 취하기 전의 KLDP load average 는 거의 100 이상이었지만, 조치 후에는 1 이 되지 않는 값을 유지하므로, 특정 attack 에 모든 system resource 를 다 잡아 먹었다는 얘기입니다.
HTTP/1.0 을 막은 조치는
일 뿐입니다. 판단을 위한 근거를 가지기 위한 조치일 뿐입니다. 다만, 효과가 너무 확실해서 계속 유지하는 것이 어떨까 하는 생각을 지금 하고 있습니다. 즉, 모두 열어주고 문제가 되는 것을 막는 것 보다, 모두 막고 문제가 되지 않는 것을 열어주는 식이 훨씬 경제적이라 판단이 들고 있습니다.
이건 누가 판단을 하죠 ^^; 국내 IP 대역에서 들어오는 1.0 기준은 어떻게 판단을 해야 파는 것이며, 공격은 특정 ip 에서의 공격이 아니라, random 한 곳에서 들어오는 것이라 특별하게 국내 IP 에 대해서 무결성을 주어줄 수는 없습니다.
웬지 답장을 보니 씨니컬 하신듯 한데..그래도
국내 IP 대역인지 아닌지 파악하는것이 꽤 유용할데가 있습니다.
http://linuxchannel.net/docs/korean_ip_addr.txt
에 가보시면 완전히 정확하지는 못하더라도
쓸만한 코드와 자료를 얻을수 있을것이라 생각합니다.
필요하시면 한번 보세요.
(아~ 물론 제가 만들것이나 도움한번 드린적 없는 코드 입니다
하지만 꽤 유용하여 이자리를 빌어서 다시한번 감사드립니다 ^^)
국내 IP 판단 여부는
국내 IP 판단 여부는 GeoIP library 를 이용하면 쉽게 구할 수는 있습니다. 다만 문제는 이를 어떻게 적용을 하느냐 입니다. 즉, log 를 파싱하면 되지 않겠느냐 하시겠지만, 이 방법은 소 읽고 나서 외양간 고치는 격의 뒷북 작업일 뿐입니다. 즉, 엄청 들어와서 서비스에 영향을 미치고 나서야, 로그 분석해서 차단할테니 말이죠.
시니컬한 반응으로 보였다면 죄송할 뿐입니다. 제가 글재주가 좀 부족한 관계로..
또한, 윗 글에서 남겼듯이, 국내 IP 에 대한 무결성을 어떻게 보장하느냐의 문제도 있습니다. 국내 IP 는 숙주가 되지 말라는 법이 없으며, 또한, 중국발 보다는 국내발 attack 시도가 더 많은 것이 현실입니다.
그리고 마지막으로, 저나 순선님이나, 기타 운영을 도와 주시는 분들 역시 KLDP 에만 매달려 있을 수 있는 상황은 아닙니다. 다들 밥 벌어먹고 살기에 치여 사시는 (^^) 분들 입니다. 이런 상황에서 최소한의 작업으로 최대한의 효과를 보고 싶은 마음이 제일 굴뚝 같은 것이죠.
다른 분 께서 "초강수"를 두었다고 하셨는데, 정말 고민고민 끝에 결정한 일입니다. 계속 부하가 올라가면서, 운영진 메일링 리스트에서 "어떻게 근본적으로 해결할 방법이 없을까" 라는 의문이 나왔고, 제 의견으로는 대부분의 attack 이 HTTP 1.0 protocol 을 이용 (제작시의 간단함이 이유이겠죠.) 한다는 점을 착안하여, 막아본 것입니다. 또한 이렇게 해서 서버는 정상화가 되었고요.
현재, HTTP/1.0 을 계속 막을 것인지, 아니면 임시로 막을 것인지에 대한 결정은 나지 않았습니다.
다만, SE 쪽의 전설적인 얘기로는..
힘들게 튜닝하지 말지어라. 장비를 늘림으로서 모든 것이 해결될 것이다
라는 말이 있습니다. 즉, 일종의 "돈지랄" 이 가장 최선의 방법이라는 얘기입니다. 하지만 KLDP 에는 이런 방법이 힘들고, "몸지랄"을 해야 하는데, 생업이 존재하는 이유로 이도 힘들기 때문에 꽁수에 꽁수를 이용하는 것이 가장 최선의 방법이 되고 있는 것도 하나의 현실입니다.
사용자 분들께서는 쉽게 이런것이 있다고 던져 주시지만, 제 입장에서는 그걸 수용하는데 드는 시간이 무시할 수 없는 시간일 수도 있다는 것을 알아 주셨으면 합니다.
강수를 두셨네요. 다른 방법은 없을까요?
주기적인 크론작업(5-10분)으로 문제가 될만한 ip를 분석해서 자동차단하면 어떤가요?
완전한 해결책은 아니지만 모든 기능을 사용할 수 있을텐데요.
문제가 될 만한 IP 를
문제가 될 만한 IP 를 누가 판단을 해야 하는지가 문제 입니다. 사람이 해야 한다면, 결국에는 문제가 될 때 마다 해당 문제에 대한 스크립트를 만들어 주어야 합니다.
그리고, 분석을 해서 차단을 하는 경우라면, 실시간 분석이 아니라면 뒷북밖에는 되지 못합니다. 그렇게 운영을 하다 보면 항상 KLDP 는 부하를 가진채 운영을 할 수 밖에 없는 것이죠.
그런 조치를
그런 조치를 하셨군요.
그래서 그런지 몰라도, 사이트 반응속도가 좋습니다.
다른 분들이 문제를 일으킨 다면, 다른 조치도 필요하겠네요.
네 조치가 끝난 것은
네 조치가 끝난 것은 아닙니다. :-) 이번 조치는 ing... 일 뿐입니다.
squid는 HTTP/1.0을
squid는 HTTP/1.0을 쓰는군요..
설정에서 바꾸는 방법은 안보이는거 같구..
그냥 proxy 풀고 해야하겠네요..
__________________________________________________
좀 더 편한 방화벽 스크립트를 만들자...
__________________________________________________
모두 다 Hardy로 업그레이드 하고 있습니다.
squid 도 풀어
squid 도 풀어 놓았습니다. 필요하신 것이 있으면 User-Agent 만 기록해 주시면 반영해 드리고 있습니다.
다만, squid 의 user-agent 가 squid 라는 문자열을 가지고 있어야 합니다.
현재, 계속 로그 파일에서, HTTP/1.0 으로 들어오면서 403 을 발생하고 있는 User Agent 를 체크하고는 있습니다만.. 쉽지는 않네요. 만약 계속 접근이 안된다면 여기에 user-agent 를 남겨 주시면 바로 등록을 해 드리도록 하겠습니다.
더운데
더운데 수고많으시네요.
저두 갑자기 어제 오후부터 중국쪽에서 메일서버로 DOS 공격이 들어와서 어떻게 할까 고민하다가
C class 대역대를 하나씩 막으니 주변 대역대로 계속 옮겨다니며 들어오더군요.
IPT_RECENT와 IPT_CONNLIMIT로 방화벽에서 접속제한 설정했었는데
그래도 계속 조금씩 들어오는걸 보니 욱하는 마음에 GeoIP로 CN을 DROP 해버렸습니다.
정말 땐놈들의 끈질김에는 GeoIP밖에 없네요
어쩔수 없이 또 중국쪽 고객을 위해 오픈 해야겠지만 열면 또 DOS 공격 들어올건데 난감하네요
저는 직업이니 당연히 하는 거지만, 바쁜와중에도 남이 알아주지 않는 일에도 열심히 하시는 분들을 뵈면
존경스럽군요..
저의 정보입니다.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ko-KR; rv:1.7.13) Gecko/20060420 Firefox/1.0.8 Asianux/1.0.8-1.4.1hs
Via: 1.1 none:8080 (squid/2.5.STABLE3)
__________________________________________________
좀 더 편한 방화벽 스크립트를 만들자...
__________________________________________________
모두 다 Hardy로 업그레이드 하고 있습니다.
PSP는 잘됩니다.
의외로 문제없이 잘되네요.:)
from bzImage
It's blue paper
from bzImage
It's blue paper
초기화면의 KLDP Wiki
초기화면의 KLDP Wiki 중계가 안되고 있어서 확인해 보니 이 조치 때문에 막혔던 것 같습니다. 그래서 httpd 설정파일에 drupal을 추가시켜 두었더니 잘 되는군요. :-)
댓글 달기