System Compleat.

'Varnish'에 해당되는 글 3건

  1. Blog 를 굴리면서. (2)
  2. Global, 혹은 Cache 에 대한 시스템적 고민 (2)
  3. Protect from DDoS with Proxy, Varnish

Blog 를 굴리면서.

Stories
( 정윤진, yjjeong@rsupport.com )

최근 블로그를 그냥 장난처럼 운영 하면서 보면, 어제 오늘 블로그에 유입되는 경로의 대부분이 nginx 의 검색어를 기반으로 네이버의 상위에 랭크되어 넘어 오시는 분들이 많은 듯 하다.

아마 최근의 DDoS 공격과 관련하여 Reverse-Proxy 의 구성에 대해 어디선가 알아보고 오신듯 하다.  

DDoS 는, 그 방어에 대한 준비가 기술적인 요인 뿐만 아니라 경영진의 이해도 함께 필요하기 때문에, 통상은 공격 당하기 전에 준비한다기 보다는, 일단 일이 터져서 서비스가 불가능해져 그 위기감을 경영진이 느끼게 되었을 때 부랴부랴 준비하는 경향이 많지 않나 싶다.

언제나 사전에 경고하게 되더라도, 결국엔 비용앞에 무너지는 직업이다 보니 이제는 그러려니, 하면서 일 터질때는 이렇게 저렇게 하자 하고 혼자 마음속으로만 준비하곤 한다.

뜬금 없지만, Nginx 도 있지만 Varnish 도 좋다고 웬지 조심스럽게 말해보고 싶다는.. ㅋ

사용자 삽입 이미지

Going home, Winstorm.

* 위의 사진은 내용과는 큰 관계가 없..;;


여러가지의 방어 기법들이 있겠지만, 결국 많은 가능성을 함께 생각하여 보아야 그 대비가 가능 해 질 것도 같고, 이번처럼 대규모의 공격이 간단히 도메인을 변경해서 처리가 가능했다고 하는 걸 보면 내가 보았던 통상적인 공격들과는 좀 다른가 보다.

어쨌든, 복잡한 서비스에서 하나의 메인 페이지와 그 내부의 컨텐츠 들이 모두 동일한 도메인과 uri 에서 서비스 되고 있다면, 페이지의 구조상 선택 가능한 방법이 매우 줄어드는 것도 사실인 듯 하고.  아파치를 굴리는 서비스에서 mod_expires 정도는 설치 해 두어야 CC 공격 ( Command Center 아님 ㅋ) 을 제외한 많은 공격에서 보다 자유로워 질 수도 있다.

특별한 구조는 없으며, 몇년전에 Dos 에 대한 방어로 이슈가 되었던 Null Zero Routing 이라던가 하는 방법도 필요에 따라선 쓰일 수도 있고, reverse-proxy, 도메인의 동적인 분리 또는 A 레코드 변경을 위한 짧은 TTL 로의 수정 등, 방법들은 이미 많이 알려졌다.
공격 형태가 다양 할 뿐.


뭐 어쨌든, 위의 이미지는 내용과는 별로 상관 없지만 또 그게 재미니깐.  집에 가는 길에 회사의 과장님 차에 신세 지고 이런 저런 이야기를 나누다가 한컷 했다.

또 다른 유입 경로를 보자면, '잘 지내나요 청춘' 에 대한 검색도 있기도 하고, 별로 없을 것 같던 ARC GIS 에 대한 64비트에서의 설치도 제법 된다.

일본에서 본의 아니게 욕먹은 것도 있기는 하지만 그것도 나름 재미있는 사건이었고.

사용자 삽입 이미지

Office View


비오는 날은 참 공기가 신선하고 좋다. 비가 주륵 주륵 내리고 있는 것을 보자면, 어떤 분들은 근심이 더 많을 수도 있지만 뭔가 마음속에서 씻겨 내려가는 듯한 기분이 들고,
음악 틀고 커피 한잔의 여유 속에 비가 그쳐 갈 때 쯤 어딘가에서 나는 풀냄새도 좋다.

다만 어떤 동네에서는 비린내가 나는 경우도... 쿨럭.;;


어떤 마음으로 블로그질 하자는 것도 없이, 그냥 시스템에서 나오는 이슈나 살면서 찍는 사진들에 대해 간단히 아무데서나 보자는 목적에서 시작한 블로그 질이지만,  준호형 처럼 HTML 이나 JS 를 예술로 써서 멋들어진 페이지를 만들 수도 없는 일이고. 

졸리니깐 글도 두서도 없고 뭐 재미도 별로 읍고 ㅋ 
비오면 이래 되는 듯.

사용자 삽입 이미지

Surisan Station, 4th Line



집에 와서는 또 현희형과 한참 서비스에 대해서 이런 저런 이야기를 많이 했는데
이렇게 즐거울 수가 없는 듯. 
무언가를 이야기 했을 때 받아주는 사람이 있고, 또 그 이야기를 들으면서 그 타당성에 대해서 생각 해 보고.  내가 맞다고 생각하는 것과 또 현희형이 맞다고 생각 하는 것에 대해 언뜻 우리는 무한 루프를 잠깐 돌았던 것 같지만, 결국은 같은 이야기를 하고 있었고 그게 또 좋은 서비스의, 또 현희형은 잘 모르겠고 나의 생각의 틀을 넓히는 것 같아서.

어디서 또 이런 분을 만날 수 있을까 싶은 생각.



주저리 주저리 썼지만,
뭔가 오늘 하루를 정리 하고 싶었더랬지만,
결국 정리 한 건 별로 없는 듯 하고

청춘이라기에는 쬐끔 민망한
또 하루가 지난다.

김광석의 서른 즈음에 보다는
박정현의 'No Break' 가 더 흥얼거려지는 요즘


이러고 있다.. ㅋ

( 정윤진,  bluebird_dba@naver.com )

Global, 혹은 Cache 에 대한 시스템적 고민

Techs
( 정윤진, yjjeong@rsupport.com )

간혹 그런 생각이든다.
'과연 시스템적으로 단순한 웹 서비스 구조에서 글로벌을 감안 할때, 메인 시스템 인프라와 같은 규모의 시스템이 지역적으로 필요 할 것인가'

이에 대한 답은 서비스의 동작에 따라 다르겠지만, 단순 컨텐츠의 경우 CDN 등을 이용하는 숱하고 숱한 방법들은 이미 많다.
하지만, 정적 컨텐츠 이외의 동적 컨텐츠가 많은 지역별 거점을 중심으로 운용되는 서비스의 경우에 시장성이 불투명하지만 일부 고객을 위해 서비스를 지속해야 하는경우, 제일 고민 되는 부분은 역시 시스템 및 관리를 위한 비용, 소위 말하는 TCO 가 관건이 되지 않을까.

미국에 메인 센터가 있고, 유럽에 일부 고객이 발생되기 시작한 시점에 사업 규모로서는 유럽에 미국만큼 큰 센터를 두는게 맞겠지만, 아직 얼마만큼의 고객이 확보 될지 모르는 지역에 대규모의 인프라 비용을 투자하는건 아무래도 리스크가 따르기 마련이다.

이런 경우의 해법이 무엇일까 하는 부분은 서비스의 유형별로 많이 다르겠지만, 일반적 웹 서비스에서 이런 질문은 이렇게 치환 될 수 있을 것이다.
'네트웍 회선 품질이 현저한 지역에 고품질의 서비스가 필요한 경우, 어떻게 해결 할 수 있을까?'

파일 전송을 주로 하는 서비스라면 CDN 과 같은 글로벌 업체를 통하는 방법외에는 답을 찾기 쉽지 않다. 하지만 채팅이나, image 서버를 별도로 구성한 웹 서비스의 경우, css 나 js, html 등의 몇 kb 전송에도 수초가 걸리는 상황이라면,  답은 Proxy 에서 찾을 수 있지 않을까.

웹 - WAS - DB 의 경우에는, GeoIP 를 사용할 수 있는 DNS 또는 웹 서버를 사용하여 웹 서버 자체를 글로벌하게 운용하여 답을 찾을 수도 있다.  또는, 웹 서버 자체가 많이 무겁다면, 효율적으로 Cache 를 수행하는 NginX 나 Varnish 등을 통해 적절한 프락싱을 통해 비슷한 해답을 얻을 수도 있을 것이다.

앞에서의 예와 같이, 미국에 수억의 시스템이 있다.  이를 일본과 유럽에 서비스 하고 싶다면, 일본과 미국에 저렴한 서버 호스팅 또는 , 가능한 경우 Amazon 의 EC2 와 같은 서비스에 서버를 한대 둔다.  여기에 NginX 나 Varnish 를 올리고, 필요한 경우 memcached 등과 같은 로직에 녹여 낼 수 있는 캐슁 툴 및 opcode 레벨의 cache 를 지원하는 각종 자원을 사용하거나, 아니면 아주 단순하게 squid 등의 오래된 고전적인 proxy를 통하여, OS 또는 시스템의 자체 Cache 를 믿고 서비스 하는 방법- 


뭐, 이미 이러한 방법을 수행하고 있는 업체도 많겠지만 중요한건 저렴한 비용으로 어느정도 동적인 컨텐츠에 대한 지역별 분산을 노릴 수 있는 잇점이 있다. 

아직 테스트 해 보진 않았지만, 일본에서 네이버와 같은 ( 네이버는 URL 구조가 좀 복잡하지만 ) 웹 서비스에 대해 squid 만 돌려 보아도 그 효과는 순식간에 나타난다.
뭐, 일부 사람들은 CDN 과 같은거 아니냐  라고 할 수 도 있지만, 틀린말은 아니다.
다만 CDN 을 운용하면서 발생 하는 비용이  직접 서버를 간단하게 구성해서 운용하는 비용보다 저렴 하지는 않을 것으로 생각된다.

똑같은 요청을 반복해서 처리 ( 단순 Static 한 컨텐츠가 아닌, 일부 동적인 자원에 대해서도 장기적으로는 동일한 요청에 대한 응답이므로 ) 하는 정도로 시장성이 충분 해 질 때 까지 지역적 서비스를 선별적으로 빠르게 할 수 있다면, ( 물론 로그인과 같은 DB Connect 가 발생하는 액션은 여전히 느리겠지만 ) Comet 이나 간단한 채팅,  css 또는 html, php 와 같은 자원에 대해서는 환상적인 현지 고객의 만족을 얻어 낼 수 있을 것이다.


역시, 오픈소스는 조합하기 나름인가 보다.

Protect from DDoS with Proxy, Varnish

Techs
( 정윤진  yjjeong@rsupport.co.kr )

서비스를 운영하다 보면, 심심치 않게 종종 발생하는 DDoS 공격을 볼 수 있다.
이 DDoS 공격은, 정말 아무리 좋은 회사의 L7 방화벽 장비를 이용해도 결국 Edge 레벨에서의 방어이기 때문에 IDC에서 너네 골치아프니 나가라 하면 눈물을 머금고 다른 데이터 센터를 향해 떠돌이 신세로 전락하는 경우가 많다.

내 생각에 가장 최선의 DDoS 방어 기법은, 회선 속도 자체가 서버 Down 을 발생 시키지 않을 만큼의 낮은 대역폭이거나,  아니면 정말 화끈하게 분산 구조를 충분히 적용하여 100Gbps 이상의 트래픽을 견디어 낼 수 있는 인프라를 가지는 방법밖에 없다.  전자의 경우 적당히 저렴한 사양의 장비와 잘 구성된 서버만 있다면 Edge 레벨에서의 방어를 통해 어느정도 서비스 Down은 막아 낼 수 있으며 얼마 되지 않는 트래픽 때문에 IDC에서 쫒겨 나지도 않는다. , 후자의 경우는 100Gbps 이상의 트래픽을 공격자가 유발시키기 이전에는 절대 서비스가 정지하지 않는다.

하지만, 대체 누가 100Gbps 이상의, 아니면 충분히 타협해서 50Gbps 이상의 공격을 잘 견디어 낼 수 있겠는가.

이에 대한 방책은 DNS 의 우회를 통한 Proxy Farm 의 구성이 아닌가 싶다.  다만 이러한 방법으로도 역시 서비스가 정지할 가능성은 있어서, 내 생각에 최선의 해법은 공격자로 의심되는 좀비PC 의 트래픽을 선별해서 Proxy 로 가도록 우회 시키는 것이 좋다고 본다.

자, 그럼 대체 어떻게 Proxy Farm 을 구성해야 하며, 어떻게 공격 클라이언트를 구분지을 것인가.

답은, iptables + varnish 의 조합으로 가능하지 않을까 싶다.

일단 저렴한 가격의 FTTH 또는 10M 미만의 회선을 받도록 하고, 여기에 LVS 등과 같은
로드밸런서를 붙인다.  이 로드밸런서 아래의 Real Server 들은 모두 Varnish 로 구성하도록 하고 이 아래에 서비스 서버와 동일한 웹서버를 두던지, 아니면 Varnish 자체가 Proxy 동작하므로 실제 서비스하고 있는 서버의 IP 를 박아준다.

이렇게 서버들의 구성이 끝나게 되면, 다음은 Redirect 처리다.

네임서버를 직접 운영하고 있다면, 네임 서버를 한대 더 증설하고 환경을 사설망으로 바꿔서 DNAT 처리를 하던, 공인 망에서 SLB 를 하던, 앞단에 iptables 를 올릴 서버를 한대 더 구성한다.  이쯤에서 이미 눈치 챘겠지만,  새로 만든 BIND 서버는 우리가 서비스하는 a.com 이라는 도메인에 대한 A 레코드를 새로 구성한 Proxy Farm 의 공인 IP 로 지정한다.

자, 그럼 iptables 의 조건에 걸리도록 하려면 어떻게 해야 하는가.
답은, 실 서비스 도메인인 a.com 에 대한 TTL 값을 굉장히 짧게 주는 것이다.
이후, 네임 서버 앞쪽의 iptables 에서 udp 53을 dest로 하는 패킷에 대해 특정 시간안에 많은 요청이 있게 되면 지정해 둔 내부의 네임서버로 포워딩 되도록 룰을 설정한다. 
충분한 테스트를 수행하고, 적절한 count 로 설정해야 훗날 방비가 됨은 물론이겠다.
또한, 좀비 PC 들의 공격이 우리나라에서 발생되는지, 아니면 중국등 외국에서 발생되는지를 파악해서 만약 한국 전용 서비스인데 중국등지에서 공격이 온다면, geoip 를 사용한 iptables 정책으로도 수용 가능 하겠다.

이와 함께 조정해야 할 것은, 웹 서버의 Keep alive timeout 에 대한 지정이다.  정상적인 사용자의 경우 브라우저를 통해 서비스 받을 것이기 때문에 별 문제가 없으리라 생각된다.

자, 그럼 이제 끝났는가?  아니다.
DDoS 공격을 위한 좀비들의 공격에서 보다 더 자유로워 지려면 실 서비스 구간에도 준비해야 한다.  앞서 적용한 iptables 를 동일하게 서비스 구간에도 준비하여 준다.


사실, 이 방법은 내가 만든 카더라 아이디어다.  이 아이디어의 요지는, 다음과 같다.

1.  공격자의 IP를 솎아 내고, 지정한 패턴으로 공격이 발생하는 경우 해당 클라이언트IP를
     Proxy Farm 으로 보낼 수 있어야 한다.

2. Proxy Farm 은 비교적 성능이 출중한 Varnish 를 사용하도록 한다.

3. 애초에 DNS 레벨에서 응답을 Proxy 쪽으로 줄 수 있어야 한다.
    실 서비스 망에서 처리하려 하는경우, 대역폭 문제로 IDC에서 쫒겨 날 가능성이 있다.

4. L7 레벨로 처리하지 않아도 된다.  단순 IP 레벨에서 요청에 대한 횟수 제한 조건만으로
   처리하여 장비 비용에 대한 부담을 줄인다.

5. 모든 DDoS 공격은 평생 지속되지 않는다.  공격 발생시 바로 신고하여 향후 피해를 줄인다.

6. 대역폭이 100M 미만이라면, 그냥 DDoS 전용 방어 장비를 구입하는것도 방법이다.


이런 방법을 수행하기 위해 iptables 와 proxy 서버를 예로 들었지만, 보다 좋은 방법이 있을 수도 있다.  애초에 L7 방화벽등이 있다면, 사용 가능한 많은 방법이 존재 할 것이다.
또는 이미 nginx 나 varnish 등을 실 서비스에 이용하고 있다면 보다 유연한 방어를 수행 할 수 있다.

한번 쯤은 이런 대책없는 공격에 대해 고민해 보고, 테스트를 통해 나만의 계획을 가질 수 있지 않을까 한다.

훗, 정작 Varnish 자체에 대한 이야기는 없어서, 다음에 다시 소개해야겠다.
내가 이래.. ㅎ


기타 구체적인 각 서버의 설정 등은, 다음의 링크를 참조 한다.

참고자료.
http://varnish.projects.linpro.no/

http://www.netfilter.org/

http://www.techsupportforum.com/networking-forum/security-firewalls/284749-iptables-conditional-redirect.html