[Linux] Crontab

리눅스 crontab은 특정 시간에 특정 작업을 수행시키는데 사용된다.

1. crontab 기본

# crontab -e

-> 크론탭 설정 

# crontab -l

-> 크론탭 설정 확인

# crontab -d

-> 크론탭 삭제

* * * * * ls -al

-> 기본 사용법 " * * * * * 시간에 ls -al 명령어를 실행한다."

2. 주기 결정

*               *                  *               *                  *

분(0-59)　　시간(0-23)　　일(1-31)　　월(1-12)　　　요일(0-7)

3. 주기별 예제

3.1. 매분 실행

# 매분 test.sh 실행

* * * * * /home/script/test.sh

3.2. 특정 시간 실행

# 매주 금요일 오전 5시 45분에 test.sh 를 실행

45 5 * * 5 /home/script/test.sh

3.3. 반복 실행

# 매일 매시간 0분, 20분, 40분에 test.sh 를 실행

0,20,40 * * * * /home/script/test.sh

3.4. 범위 실행

# 매일 1시 0분부터 30분까지 매분 tesh.sh 를 실행

0-30 1 * * * /home/script/test.sh

3.5. 간격 실행

# 매 10분마다 test.sh 를 실행

*/10 * * * * /home/script/test.sh

3.6. 조금 복잡하게 실행

# 5일에서 6일까지 2시,3시,4시에 매 10분마다 test.sh 를 실행

*/10 2,3,4 5-6 * * /home/script/test.sh

4. cron 사용 팁

- 한 줄에 하나의 명령만 쓴다.

- 주석을 사용한다. ( ex. #----( 내용 )----# )

   

5. cron logging

* * * * * /home/script/test.sh > /home/script/test.sh.log 2>&1

6. crontab 백업

crontab -l > /home/bak/crontab_bak.txt

50 23 * * * crontab -l > /home/bak/crontab_bak.txt

[출처]

http://jdm.kr/blog/2

[Network] X-Forwarded-For

< XFF 사용하는 이유 >

XFF 는 HTTP Header 중 하나로 HTTP Server 에 요청한 clinet 의 IP 를 식별하기 위한 사실상의 표준이다.

웹 서버나 WAS 앞에 L4 같은 Load balancers 나 Proxy server, caching server, HTTP 서버용 WAS Connector(웹로직 커넥터 - mod_wl, 톰캣 커넥터 - mod_jk 등) 등이 있을 경우 이런 제품들은 웹서버/WAS 에 HTTP 나 전용 프로토콜(AJP)로 요청을 보낸후에 받은 결과를 가공하여 클라이언트에 재전송하게 된다.

이로 인해 처리한 웹 서버나 WAS에서 request.getRemoteAddr(); 등으로 클라이언트 IP를 얻을 경우 L4 나 Proxy 의 IP 를 얻게 되는데 이는 원하는 결과가 아니다.

X-Forwarded-For는 이 문제를 해결하기 위해 사용하는 http header 로 squid caching server 에서 처음 사용되었다.

다음과 같이 콤마를 구분자로 client 와 proxy IP 가 들어가게 되므로 첫번째 IP 를 가져오면 클라이언트를 식별할 수 있다.

X forwarded for 는 클라이언트에서 들어오는 IP를 로그에 남기도록 설정하시기 위한 작업으로, WebServer에 로그포맷을 적용하려면 L4에서 X forwarded for 헤더정보로 Client IP를 실어서 보낼 수 있도록 설정을 미리 해두어야 한다.

1. X-Forwared-For

X-Forwarded-For 요청 헤더는 HTTP 또는 HTTPS 로드 밸런서를 사용할 때 클라이언트의 IP 주소를 식별하는데 도움이 된다.

로드 밸런서는 클라이언트와 서버 간의 트래픽을 가로 채기 때문에 서버 액세스 로그에는 로드 균형 조정기의 IP 주소만 포함된다.

클라이언트의 IP 주소를 보려면 X-Forwarded-For 요청 헤더를 사용하면된다.

Elastic Load Balancing은 클라이언트의 IP 주소를 X-Forwarded-For 요청 헤더에 저장하고 서버에 헤더를 전달한다.

X-Forwarded-For 요청 헤더는 다음 형식을 취한다.

X-Forwarded-For : clientIPAddress

다음은 IP 주소가 203.0.113.7인 클라이언트에 대한 X-Forwarded-For 요청 헤더의 예이다.

X-Forwarded-For : 203.0.113.7

다음은 IPv6 주소가 2001:DB8: :21f:5bff:febf:ce22:8a2e 인 클라이언트에 대한 X-Forwarded-For 요청 헤더의 예이다.

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

요청이 여러 프록시를 거치는 경우 X-Forwarded-For 요청 헤더의 clientIPAddress 다음에는 로르 밸런서에 도달하기 전에 요청이 통과하는 각 연속 프록시의 IP주소가 온다.

따라서, 가장 오른쪽의 IP 주소는 가장 최근의 프록시의 IP주소이고 가장 왼쪽의 IP 주소는 원래 클라이언트의 IP 주소이다. 이 경우 X-Forwarded-For 요청 헤더는 다음 형식을 취한다.

X-Forwarded-For : OriginatingClientIPAddress, proxy1-IPAddress, proxy2-IPAddress

2. X-Forwarded-Proto

X-Forwarded-Proto 요청 헤더는 클라이언트가 로드 밸런서에 연결하는데 사용한 프로토콜(HTTP 또는 HTTPS)을 식별하는데 도움을 준다.

서버 액세스 로그에는 서버와 로드 밸런서 간에 사용되는 프로토콜만 포함된다. 

클라이언트와 로드 밸랜서 간에 사용되는 프로토콜에 대한 정보는없다.

클라이언트와 로드밸런서 간에 사용되는 프로토콜을 결정하려면 X-Forwarded-Proto 요청 헤더를 사용해야한다. 

Elastic Load Balancing은 클라이언트와 로드 밸런서 간에 사용되는 프로토콜을 

X-Forwarded-Proto 요청 헤더에 저장하고 헤더를 서번에 전달한다.

응용 프로그램 또는 웹 사이트는 X-Forwarded-Proto 요청 헤더에 저장된 프로토콜을 사용하여 해당 URL로 리다이렉션되는 응답을 렌더링 할 수 있다.

X-Forwarded-Proto 요청 헤더는 다음 형식을 취한다.

X-Forwarded-Proto : originatingProtool

다음 예는 클라이언트에서 HTTPS 요청으로 시작된 요청에 대한 X-Forwarded-Proto 요청 헤더를 포함한다.

X-Forwarded-Proto : https

3. X-Forwarded-Port

X-Forwarded-Port 요청 헤더는 클라이언트가 로드 밸런서에 연결하는데 사용한 포트를 식별하는데 도움이 된다.

[출처]

http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html
http://blog.naver.com/murmurmm/220290265177

[Linux] 리눅스 sendmail 설치 및 설정

1. sendmail 

- 리눅스 메일 서버 소프트웨어

1.1 구성 파일 목록

2. sendmail 설치

2.1 확인

2.2 설치

2.3 확인_2

2.4 서비스 시작

3. sendmail 설정 (메일 발송)

3.1 sendmail.mc 수정

--> 주석을 넣어준다.

3.2 sendmail.cf 생성/보존

3.3 서비스 재시작

3.4 포트 확인

3.5 메일 발송 테스트

텔넷 접속이 안될 경우 텔넷을 설치해야한다.

[Network] SSL / TLS 차이

TLS(Transport Layer Security)

- 인터넷에서의 정보를 암호화해서 송수신하는 프로토콜

- 넷스케이프에서 개발한 SSL(Secure Sockets Layer) 기반 기술

- 국제 인터넷 표준화 기구에서 인증받은 프로토콜

- 표준에 명시된 명칭은 TLS

- 최신 버전인 TLS 1.0은 SSL 버전 3.0으로부터 발전한 업그레이드를 제공

- IETF에서 SSLv3를 기반으로 표준화

- 아래의 프로토콜 및 암호 요구사항이 변경: 필수

- Diffie-Hellman key agreement

- Digital Signature Standard

- 3DES encryption

- HMAC 사용

SSLv3

1. 넷스케이프에서 개발, 표준 아님

2. 아래의 프로토콜 및 암호 요구사항: 옵션

- Diffie-Hellman key agreement

- Digital Signature Standard

- 3DES encryption

암호화 프로토콜은 보안 연결을 제공하여 두 당사자가 사생활 보호와 데이터 무결성을 가지고 서로 통신할 수 있게 해준다.

TLS 프로토콜은 SSL 프로토콜에서 발전한 것이다.

두 프로토콜의 주요 목표는 기밀성, 데이터무결성, 사용자 인증을 제공하는 것이다.

두 프로토콜이 유사하긴 하지만 SSL 3.0과 TLS의 다양한 버전이 상호 운용되지 않는다는 점은 상당한 차이점이다.

TLS 작동 방법

1. 정의

- 인터넷을 사용한 통신에서 보안까지 다루게 되다보면, 서버와 클라이언트 서로가 신뢰할 수 있는 자임을 확인할 수 있어야 한다.

- 서로간의 통신 내용이 제 3자에 의해 도청되는 것을 방지해야 한다.

- 서로 자신을 신뢰할 수 있음을 알리기 위해 전자서명이 포함된 인증서를 사용한다.

2. 통신과정

- 사용할 프로토콜의 버전에 동의

- 암호화 알고리즘 선택

- 디지털 인증서 교환 및 유효성 검증에 의한 상호 인증

- 공유 비밀 키 생성을 위한 키 분배 문제점을 막아주는 비대칭 암호화 기술 사용

- 그런 다음 SSL 또는 TLS는 메시지의 대칭 암호화에 공유 키를 사용하며, 이는 비대칭 암호화 보다 더 빠름

통신과정

[출처]

http://soul0.tistory.com/214

[암호화] 블록기반 암호화 모드(ECB, CBC, CFB, OFB, CTR)

블록기반 암호화 모드

1. 전자 부호표(ECB, Electric Code Book)

- 암호화가 가장 간단하고 기밀성이 낮은 모드

- 장점 : 병행수행, 오류전파 없음, 짭은 메시지에 적합
- 단점 : 분리된 블록의 공격, 블록 사이즈 보다 작으면 안됨
- 평문 : 암호문 = 1 : 1

2. 암호 블록 연쇄 모드(CBC, Cipher  Block Chaining mode)

- 앞의 암호문 블록과 다음 평문 블록을 XOR하여 체인처럼 암호화
- 최초 동작을 위해서는 초기화 벡터(IV)가 필요
- 장점 : 긴 메시지에 사용
- 단점 : 블록 사이즈 안에서만 작동, 모든 동작은 순차적

3. 암호 피드백 모드 (CFB, Cipher-FeedBack mode)

- 한 단계 앞의 암호문 블록을 암호 알고리즘의 입력으로 사용하며 이것과 평물 블록을 XOR해서 암호문 블록을 만듬
- 장점 : 블록보다 작은 크기의 데이터에서도 동작 가능
- 단점 : 재전송 공격 가능

4. 출력 피드백 모드(OFB, Output-FeedBack mode)

- 초기화 벡터(IV)를 암호화하여 평문과 XOR 함
- 장점 : 병렬처리 가능, 스트림 형식 암호문
- 단점 : 오류가 발생하면 전체 암호문에 영향

5. 카운터 모드(CTR, CounTeR mode)

- 블록을 암호화할 때 1씩 증가해 가는 카운터를 암호화해서 키 스트림을 만듬
- 카운터를 암호화한 비트열과 평문 블록과의 XOR을 취한 결과가 암호문 블록이 됨
- 장점 : 암호화/복호화의 사전 준비 가능, 같은 구조, 병렬 처리 가능
- 단점 : 1비트가 반전되면 다른 블록에서 1비트가 반전

[출처]

http://bluehatsecurity.tistory.com/70

[DB] 정형 데이터, 비정현 데이터, 반정형 데이터

정형 데이터

- 관계DB 처럼 스키마 형식에 맞게 저장된 데이터

반정형 데이터

- 관계형 데이터베이스나 다른 형태의 데이터 테이블과 연결된 정형 구조의 데이터 모델을 준수하지 않는 정형 데이터의 한 형태

- 태그 등 시맨틱 구분요소가 있음

비정형 데이터

- 구조가 일정하지 않은 데이터

- 주로 관계형 모델에 잘 맞지 않는 데이터

- 규격화된 데이터 필드에 저장되지 않은 데이터

[출처]

http://zetawiki.com/wiki/%EC%A0%95%ED%98%95%EB%8D%B0%EC%9D%B4%ED%84%B0,_%EB%B0%98%EC%A0%95%ED%98%95%EB%8D%B0%EC%9D%B4%ED%84%B0,_%EB%B9%84%EC%A0%95%ED%98%95%EB%8D%B0%EC%9D%B4%ED%84%B0#cite_note-2

[보안이슈] 리눅스 컴퓨터 암호화하는 KillDisk 악성코드 변종 발견

리눅스 컴퓨터 암호화하는 KillDisk 악성코드 변종 발견

기사 요약

- 리눅스 컴퓨터를 암호화한 후 엄청난 몸값을 요구하는 KillDisk 악성코드 변종 발견

- 다수의 산업용 제어 시스템이 리눅스 기반의 운영체제를 사용하고 있으므로 이러한 시스템에 대한 대비책 마련이 시급

- 랜섬웨어의 경우 윈도우 시스템 내의 데이터 파일뿐만 아니라 다양한 IoT 기기와 산업용 기기까지 공격 범위가 넓어짐

- 관련자들을 대상으로 한 철저한 보안 교육 및 시스템 유지 보수와 패치를 완벽하게 수행함과 동시에 신뢰할 수 있는 보안 솔루션을 사용하는 것이 매우 중요하며, 시스템 문제 발생 시 이를 빠른 시간에 복구할 수 있는 재난 복구 능력을 갖추는 것도 필요

[출처]

http://www.dailysecu.com/news/articleView.html?idxno=17998

[Network] VPN(Virtual Private Network)

VPN 이란?

가상 사설망(Virtual private network, VPN)은 공중 네트워크를 통해 한 회사나 몇몇 단체가 내용을 바깥 사람에게 드러내지 않고 통신할 목적으로 쓰이는 사설 통신망이다.

내가 다니는 회사에 중요한 서버들이 있다고 하자.

이 서버를 회사내에서는 접속이 가능하고 비교적 보안도 유지시킬 수 있지만 우리가 출장을 가거나 해서 호텔등에서 우리 회사의 서버로 접속하는 경우가 있을 수 있다.

우선 이를 위해서는 회사 서버가 외부에서 연결되도록 열여 주어야 하는 문제가 생긴다(해커들의 공격 대상이 될수 있다).

더욱이 호텔에서 회사 서버로 연결할 경우 호텔의 망관리자나 다른 호텔 넷트웍 사용자가 마음만 먹으면 내가 접속하는 서버와 내가 읽고 보내는 정보를 엿볼 수 있게 된다.

이것을 막기 위해 우리는 ssh같은 방식으로 Shell을 접근하거나 SSL로 웹서버를 접속한다.

그러나 우리가 사용하고자 하는 서비스가 Samba나 회사의 DBMS등이면 단순이 하나의 프로토클을 암호화 하는 것으로 문제는 쉽게 해결되지 않는다. 그리고 설정또한 상당히 복잡해 진다.

우리는 Point-to-Point 암호화, 즉 내 컴퓨터에서 회사 서버로 주고 받는 모든 패킷의 암호화가 필요한 것이고 이를 위해서는 VPN이 필요한 것이다.

다시 강조하자면 VPN은 SSH 터널이나 SSL 터널같이 하나의 포트를 암호화 한다음 포워딩하는 것이 아닌 전체 패킷을 암호화 한다음 서버와 통신하는 것이다.

 [출처]

https://ko.wikipedia.org/wiki/%EA%B0%80%EC%83%81_%EC%82%AC%EC%84%A4%EB%A7%9D

https://wiki.kldp.org/wiki.php/OpenVPN

[AWS] EC2 Windows Server 생성

AWS에서 EC2 Windows Server를 만드는 방법은 Linux 서버를 만드는 방법과 동일하다.

Windows Server 생성히 완료 되면 Connect를 클릭한다.

Download Remote Desktop File를 클릭한 후 Get Password에 들어간다.

Remote Desktop은 Windows Server에 접속할 수 있는 파일이다.

키 파일을 넣은 후 Decrypt Password를 클릭한다.

Windows Server에 접속할 수 있는 Password를 확인할 수 있을 것이다.

이제 Remote Desktop File로 Windows Server에 접속 할 수 있다.