안경잡이개발자

728x90
반응형

  AWS RDS를 이용하여 만든 MySQL 서비스기본적으로 협정 세계표준시(UTC)를 따릅니다. 이는 우리 나라(Seoul)의 시간과는 차이가 있습니다. 우리 나라는 (GMT+9)를 채택하고 있습니다. 따라서 단순히 AWS RDS를 만들게 되면, 데이터베이스에 저장되는 시간이 현재 우리 나라의 시간과는 다르게 설정된다는 특징이 있습니다.


  따라서 다음과 같이 기본 설정으로 AWS RDS로 만든 데이터베이스에서 현재 시간을 출력하도록 하면 다른 나라 기준의 시간이 나오게 됩니다.



  이럴 때는 가장 먼저 AWS 콘솔의 RDS 서비스를 확인하여 자신의 데이터베이스를 선택합니다.



  [구성] 탭으로 가서 현재 해당 데이터베이스의 [파라미터 그룹]이 어떻게 설정되어 있는지 확인합니다. [파라미터 그룹]에는 해당 데이터베이스와 관련한 다양한 환경 설정 정보가 기록되어 있습니다.



  따라서 [파라미터 그룹] 탭으로 가서 해당 파라미터를 편집하시면 됩니다.



  바로 time_zone 속성의 값을 [Asia/Seoul]로 변경하는 것입니다.



  이후에 데이터베이스를 재부팅하면 기본 시간 설정이 서울(Seoul)을 기준으로 변경됩니다.



  이제 다시 현재 시간을 출력하도록 하면, 정상적으로 서울 기준의 시간이 출력됩니다.




728x90
반응형

728x90
반응형

※ IPtables 소개 ※


  IPtables는 UFW와 마찬가지로 우분투(Ubuntu) 서버에 포함되어 있는 기본적인 방화벽 도구(Tool)입니다. IPtables를 이용하면 매우 다양한 방화벽 설정이 가능하다는 점에서 활용도가 매우 높습니다. 우리는 방화벽 설정을 할 때 매우 많이 고민한 뒤에 적용해야 합니다. 특히 클라우드 서비스를 이용하지 않는 경우 자기가 직접 서버의 방화벽 설정을 해야합니다. 또한 자칫 잘못 관리하면 사용자들이 접속조차 불가능할 수 있기 때문에 많은 부분을 고려하면서 방화벽 설정을 진행해야 합니다.


  일단 IPtables를 이용하기 전에 UFW를 사용 중인 상태라면 UFW를 사용하지 않도록 처리합니다.


▶ UFW 비활성화: ufw disable


  그리고 IPtables를 이용할 때는 IPtables의 현재 설정 정보를 확인할 때는 --list 옵션을 사용합니다.


▶ IPtables 규칙 확인: iptables --list


  또한 기본적으로 방화벽 설정은 순차적으로 실행됩니다. 따라서 먼저 등록된 부분의 효력이 우선시 되기 때문에, 순서에 대해서 고려해야 합니다. 예를 들어 한 번 모든 패킷을 거부하는 설정이 진행되면 이후에 패킷을 허용하는 설정을 진행해도 의미가 없습니다.


  그리고 기본적으로 방화벽 설정은 입력하자마자 바로 적용되기 때문에 많은 고민을 한 뒤에 명령어를 입력해야 합니다. 더불어 방화벽 설정이 수정되었으면, 이를 실제로 적용하기 위해서 규칙을 저장해주는 것을 잊으시면 안 됩니다. 규칙을 저장(Save)하지 않으면 서버를 재부팅하면 설정이 초기화됩니다.


▶ 규칙 저장: service iptables save


  뿐만 아니라 규칙을 저장(Save)해 준 뒤에도 서버를 재부팅하면 규칙이 초기화 될 수 있습니다. 최신 버전의 우분투(Ubuntu)에서 자주 보이는 현상이며 이럴 때는 iptables-persistent 패키지를 이용하면 됩니다.


[ iptables-persistent 패키지 이용하기 ]


▶ 패키지 설치: sudo apt-get install iptables-persistent netfilter-persistent

▶ 저장: netfilter-persistent save

▶ 다시 로드: netfilter-persistent start


  위 저장 및 로드 명령어를 IPtables의 저장(Save) 명령 이후에 수행해주시면 됩니다. 그러면 서버를 재부팅해도 그대로 IPtables 규칙 설정 정보가 남아 있습니다.


※ IPtables 주요 명령어 ※


-A: 새로운 규칙을 추가합니다.

-D: 기존의 규칙을 삭제합니다.

-R: 새로운 규칙으로 대체합니다.

-P: 기존의 규칙을 변경합니다.

-F: 모든 규칙을 삭제합니다.


※ IPtables 주요 옵션 ※  


-p: 패킷의 포트 번호 혹은 프로토콜을 명시합니다.

-j: 패킷을 어떻게 처리할 지 명시합니다. (ACCEPT, DROP, LOG, REJECT)

-m: 확장 모듈을 활성화합니다. (ex) recent 모듈: 특정 시간 동안 특정 개수 이상의 패킷을 받았을 때를 처리할 수 있음

--dport: 패킷의 도착 포트 번호를 명시합니다.

--sport: 패킷의 발신 포트 번호를 명시합니다.


※ 자주 사용되는 예제 ※


1. 차단과 삭제


▶ 80번 포트 차단: iptables -A INPUT -p tcp --dport 80 -j DROP

▶ 80번 포트 차단 규칙 삭제: iptables -D INPUT -p tcp --dport 80 -j DROP

▶ 세 번째 라인의 규칙 삭제: iptables -D INPUT 3


2. 전체 방화벽 설정 초기화


iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT

iptables -P FORWARD ACCEPT

iptables -F


3. 방화벽 서비스 부팅 관련 명령


▶ 서비스 시작: service iptables start

▶ 서비스 정지: service iptables stop

▶ 서비스 재시작: service iptables restart

▶ 서비스 저장: service iptables save


※ DoS 공격 차단 시나리오 ※


  일반적으로 1초 동안 80번 포트에 똑같은 IP로 10번 이상의 SYN이 들어오는 경우는 적습니다. 따라서 10번 이상의 SYN이 들어오는 경우 이를 공격 시도로 판단할 수 있습니다. 그래서 그 이상의 패킷이 반복적으로 들어오는 경우 DROP 할 수 있도록 처리하는 경우가 많습니다. 이 때는 다음과 같은 명령어를 이용할 수 있습니다. (SSL이 적용된 서비스인 경우 443으로 설정해야 합니다.)


▶ 1초에 10번 이상 접근 저장 목적의 리스트 생성iptables -A INPUT -p tcp --dport 80 -m recent --set --name HTTP_Flood

▶ 1초에 10번 이상 접근 로깅iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 10 --name HTTP_Flood -j LOG --log-prefix "[Attack Detected]"

▶ 1초에 10번 이상 접근 차단: iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 10 --name HTTP_Flood -j DROP

▶ IPtables 규칙 확인: iptables --list

▶ 서비스 저장: service iptables save


  위 명령어가 수행되면, 각 IP를 가지는 사용자가 1초에 10번 이상 서버에 접근했을 때 해당 IP를 차단하게 됩니다. 차단된 IP에 대한 정보는 로그로 남게 되며 마지막으로 차단된 시간으로부터 1초 뒤에는 다시 접속이 가능합니다. 또한 경우에 따라서 HTTPS 포트(443번 포트)에 대한 방화벽 설정이 필요할 수 있습니다. 본인이 이용하고 있는 서비스를 잘 확인하는 것이 중요합니다.


[ HTTPS 예제 코드 ]


  동일 IP에서 1초에 25번 이상의 HTTP 및 HTTPS의 접근이 발생하면 차단하는 예제입니다.


iptables -A INPUT -p tcp --dport 80 -m recent --set --name HTTP_Flood

iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 25 --name HTTP_Flood -j LOG --log-prefix "[Flood Attack Detected]"

iptables -A INPUT -p tcp --dport 80 -m recent --update --seconds 1 --hitcount 25 --name HTTP_Flood -j DROP

iptables -A INPUT -p tcp --dport 443 -m recent --set --name HTTPS_Flood

iptables -A INPUT -p tcp --dport 443 -m recent --update --seconds 1 --hitcount 25 --name HTTPS_Flood -j LOG --log-prefix "[Flood Attack Detected]"

iptables -A INPUT -p tcp --dport 443 -m recent --update --seconds 1 --hitcount 25 --name HTTPS_Flood -j DROP

iptables --list

service iptables save

netfilter-persistent save

netfilter-persistent start


  [ Tip ] 포트를 잘 확인하세요! CloudFlare를 이용하여 인증서가 없는 경우 80번 포트로 방화벽을 설정해야 합니다. 또한 1초에 2번 이상의 접근을 막는다는 것은 사실상 아예 접근을 못하게 한다는 것과 같습니다. 1초에 10회 이상의 정도로 막는 것이 좋습니다.


[ 저장된 로그 확인 ]


  우분투(Ubuntu)에서 기본적으로 IPtables 관련 로그는 /var/log/kern.log의 위치에 저장됩니다. 따라서 일반적으로 다음과 같은 명령어로 로그에 기록되어 있는 공격 시도 패킷을 확인할 수 있습니다.


grep -r "Attack Detected" /var/log/kern.log

728x90
반응형

728x90
반응형

※ UFW 기본 설정 ※


  우분투(Ubuntu)에서는 기본적으로 UFW라는 툴이 설치되어 있어 방화벽을 쉽게 설정할 수 있습니다. 다만 기본적으로 우분투의 UFW 방화벽은 비활성화 상태이므로 UFW를 활성화 처리 해 줄 필요가 있습니다. 


  UFW는 기본적으로 모든 인 바운드(In-Bound) 패킷을 차단하므로 외부에서 우리 우분투 서버에 접근할 수 없습니다. 따라서 SSH에 해당하는 22번 포트는 열어 준 상태로 활성화를 시켜주셔야 합니다. 단순히 UFW를 활성화 처리 해주고 서버를 재부팅하면 서버 자체에 아예 접속이 불가능하게 되는 낭패를 볼 수 있으므로 유의하셔야 합니다.


  ufw status: UFW 방화벽 상태 확인하기

  ufw allow 22: UFW 방화벽 22번 포트 허용하기

  ufw enable: UFW 방화벽 활성화 하기

  ufw disable: UFW 방화벽 비활성화 하기

  ufw reset: UFW 설정 초기화 하기


※ UFW 룰(Rule) 설정 ※


  UFW를 활성화(Enable) 처리 하면, 기본 설정으로 모든 인 바운드 패킷을 차단하므로 외부에서 우리 우분투 서버에 접근할 수 없습니다. 따라서 UFW 활성화 이후에는 룰 설정을 진행해야 합니다. 자주 사용되는 룰 설정 방법은 다음과 같습니다.


  ufw show raw: UFW 방화벽 룰(Rule) 확인하기

  ufw allow [포트 번호]: 특정 포트 허용하기

  ufw deny [포트 번호]: 특정 포트 거부하기

  ufw delete allow [포트 번호]: 특정 포트 허용하기 설정을 제거하기

  ufw delete deny [포트 번호]: 특정 포트 거부하기 설정을 제거하기


※ 실 서버로 활용할 때 ※


  만약 클라우드 서비스를 이용하지 않고 서버를 직접 관리하고 있다면 방화벽 설정은 필수에 가깝습니다. 다만 클라우드 서비스를 이용할 때 클라우스 서비스 단에서도 방화벽 설정을 할 수 있으므로 UFW 설정이 필요 없을 수 있답니다. 그럼에도 더욱 다채로운 방화벽 설정을 위해 UFW나 iptables 등의 유틸리티를 이용할 수 있습니다. (그런 경우 클라우드 서비스와 방화벽 설정을 흡사하게 진행해야 합니다.)


※ iptables와 함께 사용할 때 ※


  기본적으로 iptables를 이용하여 방화벽 설정을 할 때는 UFW는 사용하지 않도록 처리하는 것이 일반적입니다.

728x90
반응형

728x90
반응형

※ 취약점 설명 및 고려사항 ※


  로그인 기능을 포함해 다양한 주요 인증 기능을 구현할 때에는 인증 시도 횟수를 제한해야 합니다. 주요기관의 소프트웨어 개발보안 가이드를 보면 로그인 시도 횟수를 3~5번 이내로 제한하고 이를 초과하여 로그인에 실패하는 경우 추가 입력값을 요구하거나 계정잠금을 수행하도록 설계해야 한다고 나옵니다.


※ 적용 예시 ※


  현재 SMS 인증 API의 데이터베이스 컬럼은 다음과 같이 구성되어 있습니다.


- member_tel: 핸드폰 번호

- sms_token: 인증 번호

- sms_date: 인증 시도 날짜


  가장 간단한 구현 방법은 [최근 10분 이내에 3회 이상 요청한 핸드폰 번호인지 체크]하여 10분 이내에 3회 이상 요청을 했다면 잠금 처리를 할 수 있도록 하는 것입니다. 따라서 다음과 같은 SQL 구문을 이용하면 좋습니다. (MySQL 기준)


SELECT COUNT(*) as cnt

FROM {SMS 인증 테이블}

WHERE sms_date > date_sub(now(), interval 600 second)

AND member_tel = {핸드폰 번호};


  위 소스코드를 이용하면 최근 10분 이내에 SMS 인증 요청이 몇 번 발생했는지 확인할 수 있습니다. 그래서 컨트롤러(Controller)에서는 다음과 같은 형태로 처리할 수 있습니다. (PHP, REST API 기준)


$member_tel = $this->input_check('member_tel');

$result = $this->model_member->check_sms_repeat($member_tel );

if($result >= 3) {

$this->output->set_status_header(503); // 최근 10분 이내에 3회 이상 요청하여 잠금 처리 된 핸드폰 번호입니다.

exit;

}




728x90
반응형

728x90
반응형

  AWS EC2를 이용하다 보면 AWS EC2 인스턴스의 성능을 초기에 낮게 설정하여 다양한 프로그램을 돌리고, 서버를 운영하기에 벅찬 상황에 처할 수 있습니다. 예를 들어 쿠버네티스와 같은 모듈을 서버에서 돌리고자 할 때는 기본 인스턴스 유형인 t2.micro와 같은 성능으로는 서버가 감당하지 못할 수 있습니다. 그래서 AWS EC2 인스턴스의 성능을 변경할 필요가 있을 때가 있답니다.


  사실 일반적으로 사용하는 유형에 한해서는 인스턴스의 성능을 변경하는 것은 어렵지 않습니다. 저는 다음과 같은 t2.micro 인스턴스 유형을 사용하고 있는 서버의 인스턴스 유형을 변경해보도록 하겠습니다.



  다음과 같이 일단 기존에 동작하던 인스턴스를 [중지] 시켜주세요.



  인스턴스가 완전히 중지 상태가 되면 해당 인스턴스를 우클릭 하여 [인스턴스 설정] - [인스턴스 유형 변경]에 들어갑니다.



  저는 다음과 같이 한 단계 높은 성능인 t2.small 인스턴스로 변경하겠습니다.



  이후에 다시 인스턴스를 시작해주시면 됩니다.




  인스턴스가 구동된 이후에 해당 인스턴스에 접속하여 free 명령어를 입력해 보니, 실제로 메모리 용량이 늘어나 있는 것을 확인할 수 있었습니다. 이와 같이 AWS EC2는 매우 간단한 과정으로 인스턴스의 유형을 변경할 수 있도록 해줍니다.



728x90
반응형

728x90
반응형

  AWS EC2는 재미있는 특징이 있습니다. 그것은 바로 기본적으로 EC2 인스턴스를 생성하여 서버를 구동시키면 그것은 고정 IP가 아니라는 점입니다. 따라서 탄력적 IP(Elastic IP)를 이용해 고정 IP를 할당 받아서 사용할 수 있습니다. 탄력적 IP를 이용하지 않으면, 인스턴스(서버)를 중지하고 다시 실행시키면 IP가 변경되어 버리는 대참사가 일어납니다.


  실제로 운영 중인 서버인 경우, 서버를 중지(STOP) 했다가 다시 켰을 때 IP가 변경되어 버리면 매우 귀찮은 일이 발생할 수 있습니다. 따라서 일반적으로 고정 IP를 할당 받기 위해서 탄력적 IP라는 것을 이용합니다. 탄력적 IP를 만들어 놓기만 하고, 사용하지 않더라도 과금이 되기 때문에 탄력적 IP는 꼭 필요한 만큼만 생성하여 바로 사용할 수 있도록 해야 합니다.


  따라서 한 번 실제로 구동 중인 AWS EC2 인스턴스에 탄력적 IP를 적용해보도록 하겠습니다. 현재는 탄력적 IP가 배정되지 않고, AWS가 임시로 할당해 준 퍼블릭 IP가 사용되고 있는 것을 확인할 수 있습니다.



  탄력적 IP를 할당 받아 사용하기 위해서는 [탄력적 IP] 탭으로 이동하여 [새 주소 할당] 버튼을 누르시면 됩니다.



  바로 한 번 할당을 진행하겠습니다.




  할당 이후에는 해당 탄력적 IP를 선택하신 뒤에 [주소 연결] 버튼을 눌러서 특정한 EC2 인스턴스에 연결할 수 있습니다.



  이후에 기존에 존재하던 AWS EC2 인스턴스를 선택하여 해당 탄력적 IP를 적용할 수 있도록 하겠습니다.




  결과적으로 다음과 같이 탄력적 IP가 적용된 것을 확인할 수 있습니다.


728x90
반응형

728x90
반응형

  가끔 자신이 AWS EC2로 운영하고 있는 서버의 지역(Region)을 바꾸고 싶을 때가 있습니다. 저는 다음과 같이 기존의 서버를 [오하이오] 지역에서 운영하고 있는 상태였습니다. 이를 [서울] 지역으로 옮기는 것이 목표입니다.



※ 인스턴스로 이미지 만들기 ※


  AWS EC2를 이용하는 경우 특정한 인스턴스의 지역을 바로 바꾸는 것은 불가능합니다. 그 대신, 인스턴스의 복제품을 옮겨서 다른 지역에서 실행하는 방법을 채택해야 합니다. 다시 말해서 기존에 운영하던 서버를 그대로 이미지화 하는 것이 먼저입니다. 따라서 인스턴스를 우클릭 하여 [이미지] - [이미지 생성]을 눌러서 이미지를 만드시면 됩니다.



  이미지를 생성할 때는 이름을 설정하여 만들 수 있습니다.



  이미지 생성 이후에 약 10분 가량이 지난 뒤에는 [AMI] 탭으로 이동하셨을 때 이미지가 성공적으로 생성되어 있는 것을 확인할 수 있습니다. 다만 이렇게 만들어진 이미지 또한 지역 별로 저장됩니다. 따라서 [오하이오]의 AMI로 생성되어 있답니다. 여기에서 멘붕이 오실 수 있는데요. 침착하세요. AMI는 다행히도 말 그대로 데이터에 불과하기 때문에 다른 지역으로 복사할 수 있습니다.



  우클릭 하여 [AMI 복사] 버튼을 눌러주세요.



  이후에 다음과 같이 AMI를 서울(Seoul) 지역으로 복사하시면 됩니다.




  복사 이후에는 해당 복사된 지역(서울)으로 이동하여 확인해보도록 하겠습니다.



  다음과 같이 [AMI] 탭에서 이미지가 만들어지고 있는 것을 확인할 수 있습니다. 일반적으로 사용 가능한 상태가 되려면 5분 이내의 시간이 소요될 수 있습니다.



※ 복사된 이미지로 인스턴스 새롭게 만들기 ※


  이제 이렇게 만들어진 이미지를 이용하여 서울 지역에 인스턴스를 만들겠습니다. 복사된 이미지로 인스턴스를 만들게 되면, 기존의 서버를 그대로 복사하여 이용할 수 있기 때문에 사실상 그대로 서버를 이전한 것과 같습니다.



  다만 인스턴스를 만들 때는 [나의 AMI] 탭으로 가서 아까 자신이 만들어 준 이미지를 선택해서 만들어 주셔야 합니다.



  저는 다음과 같이 해당 AMI로 인스턴스를 만들겠습니다.



  확인해 보시면 성공적으로, 기존의 서버 인스턴스가 새로운 지역(Region)에서 돌아가게 된 것을 확인할 수 있습니다.



※ 남아 있는 데이터 삭제하기 ※


  서버 이전이 완료되었으면, 기존의 지역에 있던 모든 서버 정보 등의 데이터를 삭제하여 정리해 줄 필요가 있습니다. 사용되지 않는 서버를 계속 가지고 있으면 불필요한 과금이 청구될 수 있기 때문입니다.



  먼저 저는 다음과 같이 인스턴스를 [종료]하여 삭제해주었습니다.



  이후에 [AMI] 탭에서 이미지 파일도 삭제해줍니다.



  그리고 스냅샷 및 기타 데이터를 전부 제거하시면 됩니다.



  결과적으로 다음과 같이 말끔히 다 지운 상태로 만들어 주시면 됩니다.


728x90
반응형