2017년 1월 30일 월요일

[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

2017년 1월 20일 금요일

[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

2017년 1월 19일 목요일

[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 메일 발송 테스트

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





2017년 1월 11일 수요일

[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


2017년 1월 10일 화요일

[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