git commit을 진행할 때 username이 root 계정으로 설정되는 경우
일반적으로 최신 리눅스 운영체제에는 깃(Git)이 기본적으로 설치되어 있습니다. 그래서 상당수 개발자 분들은 리눅스 환경에서 개발을 진행한 뒤에 곧 바로 깃 허브(Git Hub)에 커밋(Commit)을 진행하는 경우가 많습니다.
이 경우 바로 깃에 커밋을 진행하면 다음과 같이 root 계정으로 커밋이 진행될 수 있습니다.
이 경우 실제로 해당 리눅스 서버에서 깃(Git) 환경설정이 어떻게 진행되어 있는지 확인해야 합니다.
git config --list
저는 확인 결과 어떠한 환경설정도 이루어지지 않은 상태인 것을 알 수 있었습니다. 따라서 이 때는 계정(user.name)과 이메일(user.email) 설정을 진행해주시면 됩니다. 저는 다음과 같이 제 깃 허브(Git Hub) 계정과 동일하게 계정명과 계정 이메일을 설정해주었답니다.
git config --global user.name "{계정명}"
git config --global user.email {계정 이메일}
이후에 다시 커밋을 진행하면 다음과 같이 정상적으로 자신의 깃 허브 계정으로 출력되는 것을 확인할 수 있습니다.
'기타' 카테고리의 다른 글
git filter-branch 명령 되돌리는 방법 (실행 취소) (0) | 2019.04.09 |
---|---|
윈도우 커맨드(Command) 줄 바꾸기 & 줄 합치기 (0) | 2019.04.06 |
웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자 (0) | 2019.04.05 |
Git Archive 명령을 이용해 소스코드만 추출하기 (0) | 2019.04.03 |
깃(Git) 커미터(Committer) 이름 변경하는 방법 (1) | 2019.04.02 |
웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자
웹 아카이브(Web Archive)는 다양한 웹 사이트의 기록을 남겨주는 역할을 수행하는 서비스입니다. 웹 아카이브의 크롤러는 다양한 웹 사이트를 돌아다니며 정적 페이지를 기록해준다는 특징이 있습니다. 웹 아카이브는 정적 페이지만을 기록하기 때문에 웹 사이트의 기본적인 디자인을 과거와 동일하게 보여준다는 특징이 있습니다. 하지만 로그인/회원가입과 같은 동적인 기능은 제공하지 못합니다.
▶ 웹 아카이브(Web Archive): https://web.archive.org/
웹 아카이브 사이트에 접속하면 다음과 같이 페이지 주소를 입력하는 창이 존재합니다.
한 번 다음과 같이 저는 저의 개인 웹 사이트를 확인해보도록 하겠습니다.
웹 사이트를 입력하면, 해당 웹 사이트에 대한 날짜별 아카이브 정보를 확인할 수 있습니다.
저는 한 번 달력을 눌러 2018년 2월 8일자의 아카이브를 확인해보도록 하겠습니다.
그러면 위와 같이 웹 사이트의 아카이브를 확인할 수 있습니다. 재미있는 점은, 웹 아카이브 서비스는 정적 페이지에 한해서 페이지 이동 기능도 제공한다는 것입니다. 실제로 저는 [로그인] 페이지로 이동해보았습니다.
다만 웹 사이트의 동적인 기능은 제공할 수 없기 때문에 실제로 [로그인]을 수행하면 다음과 같이 페이지를 찾을 수 없다는 메시지가 등장하는 페이지가 나오게 됩니다.
'기타' 카테고리의 다른 글
윈도우 커맨드(Command) 줄 바꾸기 & 줄 합치기 (0) | 2019.04.06 |
---|---|
git commit을 진행할 때 username이 root 계정으로 설정되는 경우 (0) | 2019.04.06 |
Git Archive 명령을 이용해 소스코드만 추출하기 (0) | 2019.04.03 |
깃(Git) 커미터(Committer) 이름 변경하는 방법 (1) | 2019.04.02 |
구글 애드센스(Google Adsense) 광고비 입금 받는 일자 늦추는 방법 (1) | 2019.02.26 |
Git Rebase 명령을 이용해 특정한 커밋 수정/삭제 하기
깃(Git)의 rebase 명령은 커밋 내역을 수정하고자 할 때 사용할 수 있습니다. 커밋 메시지를 수정할 때 가장 많이 사용되는 것 중 하나입니다. 가장 먼저 실습을 위해 기본적인 커밋(Commit)을 몇 번 진행하겠습니다.
하나의 깃 프로젝트를 생성합니다.

하나의 텍스트 파일을 추가한 뒤에 커밋(Commit)합니다.


이후에 텍스트 파일에 내용을 작성한 뒤에 커밋(Commit)합니다.


이후에 해당 텍스트 파일을 삭제한 뒤에 다시 커밋(Commit)합니다.


이후에 새로운 텍스트 파일을 생성한 뒤에 커밋(Commit)합니다.


이제 깃 로그를 확인해 보시면 다음과 같이 총 4번의 커밋이 이루어져 있는 것을 확인할 수 있습니다. 저는 중간에 있는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.

커밋 메시지를 수정할 때에도 git rebase 명령어를 사용할 수 있습니다. -i 옵션을 붙이면 상호작용(Interactive) 모드로 에디터가 열리게 됩니다. 저는 HEAD를 기준으로 3개까지의 커밋을 확인하도록 해보겠습니다.
git rebase -i HEAD~3

그러면 다음과 같이 커밋 내역이 차례대로 출력됩니다. 이제 여기에서 수정하고자 하는 커밋에 대한 내용을 에디터에 적어주면 되는 방식입니다.

커밋 메시지를 바꾸고 싶을 때는 reword 키워드를 이용하면 됩니다. 저는 [Delete Example 1.txt] 커밋의 메시지를 수정해보도록 하겠습니다.

그러면 다음과 같이 새로운 에디터가 또 열리게 됩니다. 이제 여기에서 커밋 메시지를 바꾸어주면 됩니다.

결과적으로 다시 로그(Log)를 확인했을 때 다음과 같이 커밋 메시지가 변경된 것을 확인할 수 있습니다.

그렇다면 특정 커밋 자체를 삭제하고 싶을 때는 어떻게 하면 될까요? 마찬가지로 git rebase 명령어를 이용하면 됩니다. 다만, 다른 사람과 함께 작업하는 경우 커밋 자체를 삭제하는 것은 권장되지 않습니다. 충돌이 발생할 수 있어요. 그래도 경우에 따라서는 필요할 수 있는 기능이므로 다루어보도록 하겠습니다.

커밋 자체를 삭제하고 싶을 때는 drop 키워드를 이용하면 됩니다.

결과적으로 삭제 이후에는 해당 커밋 내역이 아예 증발하게 됩니다.

이제 폴더를 확인해 보시면 실제로 해당 커밋 자체가 존재하지 않았던 것처럼 처리된 것을 확인할 수 있습니다.
'Git으로 시작하는 협업과 오픈소스 프로젝트' 카테고리의 다른 글
이미 작성된 Git Commit의 날짜와 시간을 변경해보자! (2) | 2019.04.06 |
---|---|
깃(Git) 환경설정(config)에 대해서 알아보자! (0) | 2019.04.06 |
Git 프로젝트 소개글(README.md) 작성하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 11강] (0) | 2018.12.23 |
Git 로그 다루기 [Git으로 시작하는 협업과 오픈소스 프로젝트 10강] (0) | 2018.12.23 |
Git 원격 저장소 관리하기 [Git으로 시작하는 협업과 오픈소스 프로젝트 9강] (0) | 2018.12.23 |
Git Archive 명령을 이용해 소스코드만 추출하기
깃 아카이브(Git Archive) 명령은 깃 프로젝트에서 소스코드만 추출하고 싶을 때 사용할 수 있습니다. 일반적으로 프로젝트의 소스코드를 간단히 다운로드 받아 사용하는 입장에서 사용할 수 있는 명령입니다.
가장 많이 사용되는 형태는 다음과 같습니다.
git archive --format=zip {추출할 브랜치} -o {저장할 파일 이름}
저는 다음과 같이 master 브랜치 및 development 브랜치의 소스코드를 추출해보았습니다.

다만 단순히 추출하면 Git 프로젝트 내에 압축 파일이 존재하게 되므로 ../{저장할 파일 이름} 형태로 추출하는 것이 일반적입니다.

'기타' 카테고리의 다른 글
git commit을 진행할 때 username이 root 계정으로 설정되는 경우 (0) | 2019.04.06 |
---|---|
웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자 (0) | 2019.04.05 |
깃(Git) 커미터(Committer) 이름 변경하는 방법 (1) | 2019.04.02 |
구글 애드센스(Google Adsense) 광고비 입금 받는 일자 늦추는 방법 (1) | 2019.02.26 |
Firefox를 이용해 ESNI를 적용하는 방법 (1) | 2019.02.15 |
깃(Git) 커미터(Committer) 이름 변경하는 방법
간혹 깃(Git)을 이용하다 보면 커미터(Committer)의 이름을 바꾸고 싶을 때가 있습니다. 혹은 깃 계정이 변경되거나 해서 이전 계정으로 커밋되어 있는 내용을 현재 계정으로 변경해야 할 때가 존재할 수 있습니다.
저의 경우는 깃으로 소스코드를 작성할 때 이메일을 잘못 설정해서 다음과 같이 계정 이름만 ndb796이고, 이메일은 이상하게 등록되어 있는 상태였습니다. 따라서 이메일을 바르게 다시 작성할 필요가 있었습니다.

이 때는 가장 먼저 해당 깃 프로젝트를 클론 하시면 됩니다. 그리고 해당 깃 프로젝트 경로로 들어갑니다.
git clone {깃 프로젝트} cd {깃 프로젝트}

이후에 깃(Git) 로그를 확인하여 잘못된 계정으로 커밋되어 있는 내용을 확인합니다.
git log
저는 다음과 같이 ndb796@email.com이라는 이상한 이메일로 커밋이 되어 있는 상태였습니다.

따라서 리눅스(Linux) 환경을 기준으로 다음과 같은 명령어를 넣으시면 됩니다.
git filter-branch --env-filter ' OLD_EMAIL="{예전 이메일}" CORRECT_NAME="{현재 이름}" CORRECT_EMAIL="{현재 이메일}" if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ] then export GIT_COMMITTER_NAME="$CORRECT_NAME" export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL" fi if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ] then export GIT_AUTHOR_NAME="$CORRECT_NAME" export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL" fi ' --tag-name-filter cat -- --branches --tags
저는 ndb796@email.com으로 작성되어 있는 커밋을 ndb796@naver.com으로 변경했습니다.

위 명령어 입력 이후에 다시 깃(Git) 로그를 확인해 보니 다음과 같이 정상적으로 변경되어 있는 것을 확인할 수 있었습니다.
git log

이제 변경된 내용을 강제로 푸시하시면 됩니다. 다만, 강제로 푸시하실 때에는 원하지 않은 커밋 내용이 반영될 여지가 있기 때문에 유의할 필요가 있습니다. 다음의 명령어로 마스터(Master) 브랜치의 변경된 내역을 푸시할 수 있습니다.
git push --force --tags origin 'refs/heads/master'

푸시 이후에 실제로 깃 허브(Git Hub)에 가보시면 다음과 같이 커밋 내역이 수정되어 있는 것을 확인할 수 있습니다.

깃 수정이 완료된 이후에는 임시적으로 클론(Clone)을 수행했던 해당 깃 프로젝트 폴더를 제거합니다.

'기타' 카테고리의 다른 글
웹 사이트 저장소! 웹 아카이브(Web Archive)를 살펴보자 (0) | 2019.04.05 |
---|---|
Git Archive 명령을 이용해 소스코드만 추출하기 (0) | 2019.04.03 |
구글 애드센스(Google Adsense) 광고비 입금 받는 일자 늦추는 방법 (1) | 2019.02.26 |
Firefox를 이용해 ESNI를 적용하는 방법 (1) | 2019.02.15 |
XML, JSON, YAML 형식 내용 정리 및 비교 분석 (0) | 2019.01.20 |
AWS S3 사용 방법 및 Cloud Front 적용해보기
AWS S3는 스토리지 서비스(Storage Service)입니다. 쉽게 말하자면 특정한 사진, 동영상 등의 파일을 저장하기 위해 사용할 수 있는 서비스입니다. 사용 예시는 매우 광범위합니다. 게시판 웹 사이트를 개발 할 때 이미지 파일만을 S3에 저장할 수 있으며, 특정한 로고 사진 등을 S3에 저장하여 사용자가 빠르게 사진 파일을 다운로드 받도록 처리하는 등의 작업이 가능합니다.
S3에서 객체(Object)란 저장되는 파일을 의미하고, 버킷(Bucket)은 파일이 저장될 프로젝트를 의미합니다.
AWS S3 서비스에 파일 올리기
바로 한 번 AWS S3 서비스를 이용해 보도록 하겠습니다.

AWS S3에서는 [버킷 만들기] 버튼을 눌러서 버킷을 생성할 수 있습니다. 쉽게 말하면 하나의 프로젝트를 생성해주는 것입니다.

- [버킷 이름]은 다른 서버와 겹치지 않는 고유한 이름이 되어야 합니다.
- 리전(Region)은 일반적으로 S3을 사용하는 사용자와 가까운 위치가 되도록 설정합니다. 다만 저는 Cloud Front의 성능을 측정하기 위해서 EU(런던)으로 설정했습니다.

이후에 [권한 설정] 탭에서는 실습을 위하여 일단 간단히 퍼블릭(Public) 공간에서 누구든지 접속할 수 있도록 하겠습니다. 따라서 권장 사항으로 제시되어 있는 모든 권한 정책에 체크를 풀어줍니다.

이후에 만들어진 S3 버킷을 확인합니다.

이후에 실습을 위하여 두 개의 파일을 이용하겠습니다. 약간 무거운 파일(5 MB 파일)과 가벼운 파일(1KB 미만)을 준비했습니다. 이 두 개의 파일을 버킷 내에 업로드하여 확인하고자 합니다.
Example.zip
5.20MB
.txt
0.00MB
이후에 [개요] 탭으로 가서 실제로 파일을 업로드할 수 있습니다.

두 개의 파일을 올린 이후에 업로드를 진행하면 됩니다.

두 파일이 올라간 이후에는 언제든지 다운로드 할 수 있습니다.

이제 사용자 입장에서 해당 파일을 다운로드 받는다고 가정하겠습니다. 특정한 파일을 누르면 퍼블릭(Public)에서 접근 가능한 URL 경로를 확인할 수 있습니다.

하지만 실제로 해당 경로에 접속을 해보면 접근 불가(Access Denied)라고 출력되는 것을 알 수 있습니다.

따라서 S3는 개별적으로 파일을 선택하여 [퍼블릭으로 설정]을 눌러 퍼블릭 형태로 설정할 수 있습니다. 한 번 해당 파일을 퍼블릭으로 설정해보도록 하겠습니다.

[퍼블릭으로 설정] 버튼을 누르시면 됩니다.

[퍼블릭으로 설정]한 이후에는 다시 해당 경로로 접속했을 때 내용을 확인할 수 있습니다.

버킷 정책 수정하기
다만 이렇게 일일히 파일을 [퍼블릭으로 설정]하는 것을 귀찮은 작업이 될 수 있습니다. 따라서 특정한 범위의 파일에 대해서 전부 한꺼번에 [퍼블릭으로 설정]하는 방법도 있습니다. [권한] 탭으로 가서 [버킷 정책]을 수정하여 버킷 내에 모든 파일들이 퍼블릭(Public)에서 접근이 가능하도록 설정할 수 있습니다. 다만 여기에 들어가는 내용은 [정책 생성기]를 통해 생성할 수 있습니다.

[정책 생성기] 버튼을 눌러서 S3 접근을 위한 설정을 할 수 있습니다. 다음과 같이 [S3 Bucket Policy]를 선택한 뒤에 Principal에는 *을 넣습니다. AWS Service에는 [Amazon S3]를 넣습니다. 이후에 Actions에 [GetObject]를 넣습니다.
이는 해당 URL을 알고 있는 모든 주체(Principal)가 객체에 접근할 수 있는 것을 의미합니다. 또한 객체(Object) 즉, 파일을 다운로드 할 수 있도록 설정하겠다는 의미입니다.

그리고 Resource에는 자신의 AWS S3 고유 경로를 넣은 뒤에 접근할 수 있는 파일의 URL을 설정합니다. 파일의 URL로 /*라고 넣어주게 되면 해당 버킷 내의 모든 객체에 접근할 수 있도록 하겠다는 의미입니다.

이제 [Generate Policy] 버튼을 눌러서 실제로 정책을 생성할 수 있습니다.

이제 생성된 정책 내용을 복사하여 [버킷 정책]의 내용으로 붙여넣기 합니다.

이제 [퍼블릭으로 설정]을 진행하지 않은 Example.zip 파일에 대해서도 URL 경로에 접속하면 다운로드를 받을 수 있게 되었습니다. 다시 말해 모든 파일에 누구든지 접근하여 다운로드 받을 수 있도록 설정한 것입니다.

실제로 다음과 같이 다운로드가 이루어지는 것을 확인할 수 있습니다.

Cloud Front 적용하기
이제 Cloud Front을 이용하여 더 빠르게 리소스를 제공할 수 있도록 하겠습니다. 따라서 Cloud Front 콘솔로 이동합니다. 그리고 [Create Distribution]을 누릅니다.

이후에 배포하고자 하는 대상(Origin Domain Name)으로 우리의 S3를 설정합니다.

이후에 기본 설정으로 바로 [Create Distribution]을 눌러 배포를 진행합니다.

이후에 다음과 같이 처리 진행 중(In Progress) 상태인 것을 확인할 수 있습니다.

약 20분의 시간이 흐른 뒤에 배포 완료(Deployed) 상태가 된 것을 확인할 수 있습니다.

이제 다음과 같이 클라우드 프론트의 URL을 이용해 index.txt를 확인할 수 있게 되었습니다. 맨 처음에 특정 리소스에 접근하려고 하면 아직 CDN 서버에 퍼지지 않았기 때문에 [Miss from cloudfront]라는 캐시를 확인할 수 있습니다.

이후에 두 번째 접속을 할 때부터는 [Hit from cloudfront]이라는 캐시(X-Cache) 메시지를 확인할 수 있습니다. 다시 말해서 Cloud Front를 거쳐서 리소스를 다운로드 받게 된 것입니다.

이상으로 AWS S3 및 Cloud Front의 기본적인 사용법을 알아보았습니다.
'AWS' 카테고리의 다른 글
AWS EC2 인스턴스를 이미지(AMI)로 만들어 그대로 저장하기 (0) | 2019.04.09 |
---|---|
AWS 람다(Lambda)로 Python 서버 API 구현하기 ① Hello World (0) | 2019.04.09 |
AWS RDS로 만든 MySQL 기준 시간을 한국 시간으로 설정하는 방법 (0) | 2019.03.27 |
AWS EC2 인스턴스 성능(사양) 변경하는 방법! (인스턴스 유형 변경) (0) | 2019.03.19 |
AWS EC2에 탄력적 IP(Elastic IP)를 이용해 고정 IP 부여하기 (0) | 2019.03.19 |
AWS RDS로 만든 MySQL 기준 시간을 한국 시간으로 설정하는 방법
AWS RDS를 이용하여 만든 MySQL 서비스는 기본적으로 협정 세계표준시(UTC)를 따릅니다. 이는 우리 나라(Seoul)의 시간과는 차이가 있습니다. 우리 나라는 (GMT+9)를 채택하고 있습니다. 따라서 단순히 AWS RDS를 만들게 되면, 데이터베이스에 저장되는 시간이 현재 우리 나라의 시간과는 다르게 설정된다는 특징이 있습니다.
따라서 다음과 같이 기본 설정으로 AWS RDS로 만든 데이터베이스에서 현재 시간을 출력하도록 하면 다른 나라 기준의 시간이 나오게 됩니다.
이럴 때는 가장 먼저 AWS 콘솔의 RDS 서비스를 확인하여 자신의 데이터베이스를 선택합니다.
[구성] 탭으로 가서 현재 해당 데이터베이스의 [파라미터 그룹]이 어떻게 설정되어 있는지 확인합니다. [파라미터 그룹]에는 해당 데이터베이스와 관련한 다양한 환경 설정 정보가 기록되어 있습니다.
따라서 [파라미터 그룹] 탭으로 가서 해당 파라미터를 편집하시면 됩니다.
바로 time_zone 속성의 값을 [Asia/Seoul]로 변경하는 것입니다.
이후에 데이터베이스를 재부팅하면 기본 시간 설정이 서울(Seoul)을 기준으로 변경됩니다.
이제 다시 현재 시간을 출력하도록 하면, 정상적으로 서울 기준의 시간이 출력됩니다.
'AWS' 카테고리의 다른 글
AWS 람다(Lambda)로 Python 서버 API 구현하기 ① Hello World (0) | 2019.04.09 |
---|---|
AWS S3 사용 방법 및 Cloud Front 적용해보기 (1) | 2019.04.01 |
AWS EC2 인스턴스 성능(사양) 변경하는 방법! (인스턴스 유형 변경) (0) | 2019.03.19 |
AWS EC2에 탄력적 IP(Elastic IP)를 이용해 고정 IP 부여하기 (0) | 2019.03.19 |
AWS EC2 인스턴스 지역 변경하기 (이미지를 활용한 방법) (0) | 2019.03.19 |
우분투(Ubuntu) 리눅스 서버에서 IPtables를 활용해 방화벽 설정하기
※ 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
[ 저장된 로그 확인 ]
우분투(Ubuntu)에서 기본적으로 IPtables 관련 로그는 /var/log/kern.log의 위치에 저장됩니다. 따라서 일반적으로 다음과 같은 명령어로 로그에 기록되어 있는 공격 시도 패킷을 확인할 수 있습니다.
grep -r "Attack Detected" /var/log/kern.log
'시큐어 코딩(Secure Coding)' 카테고리의 다른 글
ModSecurity 2를 이용해 Apache 로그 관리 및 방화벽 설정하기 (0) | 2019.04.16 |
---|---|
우분투(Ubuntu) 리눅스 서버에서 UFW를 활용해 방화벽 설정하기 (0) | 2019.03.26 |
서버 개발 보안 가이드 - 인증 수행 제한 (0) | 2019.03.26 |
우분투(Ubuntu) 리눅스 서버에서 UFW를 활용해 방화벽 설정하기
※ 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는 사용하지 않도록 처리하는 것이 일반적입니다.
'시큐어 코딩(Secure Coding)' 카테고리의 다른 글
ModSecurity 2를 이용해 Apache 로그 관리 및 방화벽 설정하기 (0) | 2019.04.16 |
---|---|
우분투(Ubuntu) 리눅스 서버에서 IPtables를 활용해 방화벽 설정하기 (0) | 2019.03.26 |
서버 개발 보안 가이드 - 인증 수행 제한 (0) | 2019.03.26 |
서버 개발 보안 가이드 - 인증 수행 제한
※ 취약점 설명 및 고려사항 ※
로그인 기능을 포함해 다양한 주요 인증 기능을 구현할 때에는 인증 시도 횟수를 제한해야 합니다. 주요기관의 소프트웨어 개발보안 가이드를 보면 로그인 시도 횟수를 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;
}
'시큐어 코딩(Secure Coding)' 카테고리의 다른 글
ModSecurity 2를 이용해 Apache 로그 관리 및 방화벽 설정하기 (0) | 2019.04.16 |
---|---|
우분투(Ubuntu) 리눅스 서버에서 IPtables를 활용해 방화벽 설정하기 (0) | 2019.03.26 |
우분투(Ubuntu) 리눅스 서버에서 UFW를 활용해 방화벽 설정하기 (0) | 2019.03.26 |