말똥이의 블로그

iwinv를 버릴 수 밖에 없었던 이유 본문

IT/정보글

iwinv를 버릴 수 밖에 없었던 이유

ryush00 2017.05.13 08:00

Iwinv. Iwinv인지 IWINV인지 iWINV인지는 모르겠다.  3월달, 블로터 기사로 iwinv AWS 대항할 만한 IaaS 클라우드 서비를 오픈한다는 이야기를 보았다. 당시는 베타 기간이라 문제가 있어도 그러려니 했다.

 

처음에는 방화벽 설정 관련해서 혼란이 있었다. 분명 WEB UI 방화벽의 설정을 변경해서 접속을 허용시켰는데, 접속 허용이 됐다. 전화까지 해가며 답변받은 내용은 서버 측에서 iptables 설정을 줘야 한다는 . 아니 방화벽이 이미 있는데 이중으로 설치한건지 의문이었다.

 

어느 서버 메모리가 임계치를 초과했다고 모니터링한게 연락이 와서 봤더니, 진짜 80% 먹고 있었다. (당시 2기가짜리 클라우드 서버를 사용하고 있었다) 급하게 서버 업그레이드를 진행했는데… 작업중 상태에서 진행이 됐다. 당시 새벽이었는데, 당시 일하시던 분이 오류를 발견한 것인지 나에게 전화를 거셨다. 내일 아침에 해결 예정이라고. 또한 해결 완료.

 

그런데 역시 비지떡인 걸까? 점점 서비스를 사용해가며 문제점이 많아졌다.

 

전에 메모리가 부족하다고 뜨는 이상해서 서버에서 남은 메모리 보는 명령어를 이용해서 비교해 봤다. 분명 충분한 메모리가 남아있는데 모니터링 상으로는 계속 메모리가 초과했다고 뜬다. 이런건지 아직까지도 모르겠다.

 

그리고 디도스 공격이 왔다. 디도스가 오면 8시간 동안 해당 서버에 접속할 없도록 정책을 두고 있다고 하며, 8시간동안 해당 서버가 사용이 불가능했다. 동일 서버가 2 이상 디도스 공격을 받으면 서버가 해지된다고 한다. 일단 임시방편으로 서버 이미지를 떠서 비상용 서버를 2 만들었다. . 가격을 봐서도 정도까지는 봐줄 했다. 마인리스트 상에서 모든 끝점을 웹서버가 아닌, 핑서버 쪽으로 옮겨서 해커가 실제 서버의 아이피를 알기 힘들도록 수정까지 했다. 그런데도, 마인리스트는 다시 디도스 공격을 받았다. 다행히 번째 공격당한 서버는 2번째 비상용 서버였다. (서버는 1번째 비상용 서버로 운영 중이었음) 확인해보니 인터넷 아이피를 하나하나 긁어가는 봇이 iwinv 서버 아이피 대역을 긁어가 마인리스트 웹서버가 노출되어 버린 모양이다. 443 포트에 접속해서 HTTPS 인증서 정보까지 긁어가는 바람에 웹서버 아이피가 노출되어 버린 거다.

 

문제를 해결하려 WEB UI 상에서의 방화벽 설정을 건들던 , 이상한 점을 발견했다. INBOUND 방화벽의 설정을 무시하고, 모든 INBOUND 포트가 열려 있었다. 주말이 끝나기만을 기다리며 문의해 결과, OUTBOUND ALL 허용으로 설정해 놓은 문제라더라. () OUTBOUND에서 포트를 열면 INBOUND 같이 열리게 설계되어 있나 보다. 완벽한 보안을 위해서는 인터넷을 끊어야 하는 걸까?

 

저렴한 가격, 괜찮은 성능이었던 iwinv 사용하면 안될 같다는 생각이 순간이었다. 예전에 쓰던 구글 클라우드로 돌아가자. 끝점 기능도 추가되었고, 이제 일본 서버를 이용해도 아무 지장이 없다. 한국 서버가 없는 아쉬울 .

 

디도스가 오지 않고 가벼운 개인 프로젝트를 운영하거나 개발 서버를 위해서는 iwinv 괜찮을지 몰라도, 서비스 용으로 사용하기엔 무리인 하다. 실제로 iwinv측이 광고하는 내용도 고급 서비스가 필요하다면 클라우드v 사용하라는 내용이 있었다.

 

구글 클라우드는 디도스 방어도 알아서 태니, 썩일 일은 없겠지. 돈이 많이 나올 .

5 Comments
댓글쓰기 폼