웹을 이용한 전자 상거래, 인터넷 뱅킹 등이 더욱더 증대되면서 이제 인터넷은 정보의 바다가 아니라 하나의 커다란 시장이라 부를 수도 있는 상황이다. 온라인 입금이나 최근에는 소액의 경우 휴대폰 결재를 선택하기도 하지만 뭐니뭐니 해도 국내 인터넷 쇼핑 이용자들이 가장 선호하는 수단은 신용 카드다. 그런데 바로 이점이 보안적인 허점을 가져오는 주 원인이 될 수 있다.

실제로 신용카드로 결제하는 경우 인터넷이라는 공용망을 타고 서버에 전송되는 고객의 신용카드 정보는 신용카드 번호, 유효기간 등을 포함하고 있기 때문에 실제 전자 상거래 시 필요한 대부분의 데이터가 언제 어떻게 도용될지도 모르는 위험에 노출되어 있는 것이다. 그렇다면 개인의 금융정보를 공용망인 인터넷상에서 보호할 것인가?

이 질문에 대한 답으로 현재 가장 많이 사용되는 방법이 SSL(Secure Socket Layer)이다.

1. SSL(Secure Socket Layer) 개념

SSL은 Netsape에서 개발된 프로토콜로서 1995년 히크만(Hickman)에 의해서 개발되었으며 현재 인터넷 사용자들에게 안전한 개인 정보를 교환하기 위한 사실상의 표준 프로토콜로 인정되어 많은 온라인 상거래에 사용되고 있다. SSL은 실제로 다양한 장점을 지닌 암호화 기법들을 사용해 세계 각국에서 사용되는 대부분의 암호화 기법들을 지원할 수 있다.
SSL은 버전 3.0 이후 IETF(Internet Engineering Task Force)에서 표준화되어 TLS(Transport Layer Security)로 명명되었지만 실제 그 내용은 SSL 3.과 TLSv1.0이 같으며 MS Explorer나 Netscape 등 대부분의 브라우저에서 지원하고 있다. SSL 프로토콜에서 사용되어질 수 있는 다양한 애플리케이션 프로토콜이 있지만 주로 사용되는 부분은 WEB(HTTP)이라고 볼 수 있다.

SSL 은 크게 3가지 기능들을 제공함으로 공개되어 있는 인터넷상에서 일어나는 트랜잭션의 기밀성(Privacy)을 보장한다.

○ Site Authentication

User가 선택한 상대편 Web Site를 인증한다는 의미다. 우리가 인터넷 뱅킹이나 인터넷 쇼핑몰을 사용할 때 상대편이 실제 신뢰할 수 있는 은행이나 쇼핑몰의 웹서버 인지를 인증한다는 것으로, 상대 사이트에 대한 신뢰성 있는 인증이 없다면 우리는 불확실한 누군가에게 우리의 금융정보를 넘기는 위험에 처하게 된다.

○ Data Privacy(기밀성)

전달되는 데이터가 도중에 누군가에 의해 판돈되지 않는 다는 것을 보장한다. SSL은 다양한 암호화 알고리즘을 사용하여 인터넷을 통해 전송되는 개인의 사적인 정보를 외부로부터 불법적인 판독을 막는다.

○ Data Integrity(무결성)

사용자의 브라우저로부터 상대방 웹서버까지 전달되는 동안 데이터가 도중에 누군가에 의해 변경되지 않도록 보장한다.

SSL은 위와 같은 요소들을 보장하여 보다 안전한 커뮤니케이션을 할 수 있도록 도와주며 또한 MS 익스플로러나 넷스케이프 등과 같이 널리 보급된 대부분의 웹브라우저와 웹서버들에서 지원된다. 웹브라우저가 SSL 통신을 하는지 여부는 브라우저 오른쪽 하단의 잠금쇠 표시를 가지고 판별할 수 있는데 경우에 따라서는 브라우저 대신에 다른 보안 애플리케이션이 대신하기도 한다.

HTTPS 는 SSL상에서 HTTP 를 구현한 형태로 실제 HTTP 가 기본 포트 80 을 사용하는 대신 HTTPS 는 433 포트를 사용한다.

SSL은 다양한 어플리케이션들을 지원하기 위해 각각의 응용된 어플리케이션 프로토콜을 가지고 있는데, 이는 SSL의 구조를 보면 이해하기 쉽다. SSL은 OSI 7 계층에서 5 계층인 Session Layer에 속하며, 지원 가능한 프로토콜은 어플리케이션 레이어 상에 위한 하부 프로토콜로 한정될 수 밖에 없는데 HTTP, IMAP, FTP, NNTP 등이다.

2. SSL 동작 원리

SSL이 수행되는 단계는 총 3가지로 분류된다.

○ SSL Server Authentication

사용자의 웹브라우저가 상대방의 웹서버를 인증하는 단계이다.

SSL을 지원하는 웹브라우저는 표준 공용키 암호화 기법을 사용하여 서버의 인증서와 공용 ID를 실제로 브라우져가 신뢰하는 인증기관(Trusted CA)으로부터 발급받았는지 여부를 인증하는 기능을 내장하고 있다.

○ SSL Client Authentication

웹서버가 자신에게 요청한 클라이언트를 인증하는 단계이다.

서버 인증 시에 사용했던 동일한 기법으로 인증하는데 서버에 내장된 SSL 지원 소프트웨어나 서버 앞에 배치된 SSL 하드웨어는 클라이언트의 인증서와 공용 ID 를 실제로 서버가 신뢰하는 인증기관(Trusted CA)으로부터 발급 받았는지 여부를 인증하는 기능을 내장하고 있다.

○ Encrypt Connection

서로에 대한 인증단계 이후 정상적으로 종결되면 클라이언트와 서버사이에 교환되는 모든 데이터는 사적인 내용을 보호하기 위한 암호화를 요구받는다. 또한 SSL커넥션을 통해 암호화된 데이터 역시 전송 중 변경을 방지(Message Integrity)하기 위해 Hash 알고리즘이라고 불리는 기술에 의해 보호된다.

위의 3가지 단계를 기반으로 실제로 구현되는 순서는 다음과 같으며, 다음 순서를 진행하기에 앞서 SSL 또한 TCP 프로토콜에 기반을 두고 있으므로 반드시 TCP 3 Handshake는 이루어져 있어만 한다.

A. 클라이언트는 서버에게 Client Hello Message를 전송
일반적으로 브라우저를 통해 서버에게 SSL 연결 요청을 하기 위한 초기 단계이다.

B. 서버는 클라이언트로 Server Hello Message와 서버 인증서를 전송하며, 만약 클라이언트 인증서가 필요한 경우에 인증서 요청도 함께 전송

서버는 클라이언트가 자신이 적합한 서버인지를 인증할 수 있도록 공신력 있는 기관으로부터 발급받은 자신의 공인 인증서를 발송한다. 이때 일반적으로 서버 인증서와 함께 서버의 공용키가 클라이언트측에 전달된다. 만약 클라이언트에 대한 인증을 필요로 하는 트랜잭션이라면 이에 대한 요청도 함께 발송한다.

C. 클라이언트는 암호화에 사용되는 세션 키와 함께 클라이언트에서 지원하는 Cipher Suite를 서버로 전송하며, 서버가 인증서를 요청한 경우에는 클라이언트의 인증서도 함께 전송

서버의 인증서에 대해 클라이언트는 브라우저내에 저장되어 있는 신뢰기관으로부터의 발급여부를 확인하고 암호화에 사용될 Session Key를 생성해 서버 공용키로 Session Key를 암호화 하여 서버에게 전달한다. 또한 암호화된 Session Key와 함께 브라우저가 지원할 수 있는 Chiper Suite, 즉 암호화 기법 리스트와 함께 서버측에서 클라이언트의 인증서를 요청한 경우 스스로의 인증서를 발송한다.

D. 서버는 Chiper Suite를 받아들이고(또는 거부하고) Finished message를 클라이언트로 전송한 후 데이터 전송단계로 이동
서버는 클라이언트로부터 클라이언트 브라우저가 지원하는 암호화 기법 리스트를 받고 클라이언트에게 종결 메시지를 보내고 데이터 전송단계로 돌입한다. 여기까지 정상적으로 완료가 되면 클라이언트가 생성한 Session Key를 클라이언트와 서버가 모두 공유하게 된다.
E. 클라이언트는 최종메시지를 서버로 전송하고 데이터 전송단계로 이동

위 단계까지 정상적으로 완료되면 클라이언트는 종결 메시지를 서버에 보내고 실제 데이터를 전송하기 위한 단계로 돌입한다.
F. 상호 합의한 사이퍼 수트에 의해서 암호화된 메시지를 교환

앞 단계에서 서로 나누어 가진 Session Key로 암호화 된 데이터를 교환하게 된다.

3. SSL 암호화

SSL이 수행되는 단계에 보면 Session Key라는 것이 등장한다. Session Key는 한마디로 클라이언트 측에서 생성하여 서버로 전달된 하나의 키로, 하나의 동일한 키를 클라이언트와 서버가 각각 보관함으로 이후 전달되는 암호화된 데이터를 복호화 할 수 있도록 한다. 이 Session Key의 생성 및 전달 과정에 대한 보다 깊은 이해는 사실상 암호화 기법에 대한 이해를 그 바탕으로 한다.

이번에는 주로 SSL에 대한 개략적인 부분만 다루고 있기 때문에 암호화에 대한 부분은 간단하게만 살펴보도록 하겠다.
SSL 수행단계에서 교환되는 Session Key는 비밀키 암호화(Secret key cryptography). 즉, 대칭적 암호화에서 사용되는 키로서 하나의 키를 양쪽 상대방이 각기 나누어 가짐으로써 하나의 키로 암호화한 데이터를 송신측에서 전송하면 수신측에서 암호화 시 사용한 동일한 키로 복호화하는 단순한 구조를 가진다.

비밀키 암호화 기법은 그 사용이 간단하고 속도가 빠른 반면 크게 두 가지 문제를 가지고 있다.

첫번째는 어떻게 동일한 키를 서버와 클라이언트가 서로 공유하여 가질 것인가이며,

두번째는 서버측에서 볼 때 하나의 클라이언트당 각기 다른 세션키가 필요하기 때문에 어떻게 키를 관리할 것인가다.

위와 같은 문제 때문에 등장한 것이 공개키 암호화 즉 비대칭키 암호화 기법이다. 이 암호화 기법은 비밀키와 공개키라고 불리는 각기 다른 키로 구성된 한 쌍의 키를 클라이언트와 서버가 나누어 가지고 비밀키로 암호화된 데이터는 그와 같은 쌍이 공개키로만 복호화되는 알고리즘을 제공하고 있다.  이 암호화 기법은 비밀키 암호화 시 발생하는 키 교환의 문제를 해결해 주었다. 그러나 각기 나누어 갖은 한 쌍의 키를 가진 상대방에 대한 인증에 대한 문제와 암호화/복호화 과정에 많은 부하가 걸리는 단점을 가지고 있다. 따라서 실제로 SSL 수행의 경우 이 두 가지 암호화 기법과 PKI 기반의 디지털 인증서를 사용한 인증을 혼합하여 사용할 수 있다.
먼저 디지털 인증서(Digital Certificate) 교환을 통해 상대방을 인증, 공개키 암호화의 약점을 줄였으며 서버에서 클라이언트로 전달된 서버의 공개키로 클라이언트에서 생성된 세션키를 암호화하여 서버로 전달하는 공개키 암호화 기법을 사용하여 비밀키 암호화의 키 교환 문제를 없앴고 세션키가 전달된 후 세션키를 통해 실제 데이터를 암호화/복호화함으로 공개키 암호화 시 발생하는 부하로 인한 서비스 지연현상을 방지할 수 있다.
참고로 SSL에서 세션키를 통해 암호화하는 암호화 기법으로는 DES, 3DES, RC2, RC4등이 있고 40비트부터 168비트까지 사용된다. 메시지 무결성(Message Integrity) 보장을 위해 사용되는 Hash 알고리즘으로는 MD5나 SHA1.등이 주로 사용 된다.

http://webs.co.kr/?document_srl=19896

RADIUS 서버(인증 서버)를 구축하기 위해서는 다음과 같은 파일이 필요하다

◎ files

• freeradius-server-2.1.10.tar.gz
• openssl-1.0.0c.tar.gz
• freeradius-server-2.1.10_eap-aka_patch.diff (aka 인증 패치)

◎ OpenSSL 설치

OpenSSL은 리눅스 설치시 함께 설치되며 보통 Binary 형태로 설치 된 경우가 많기에 그냥 새롭게 설치해준다.(이전에 설치한 binary RPM은 삭제하지 않고 소스를 설치하는 것이 좋다)

Openssl 압축 해제 및 설치

# tar vxzf openssl-1.0.0c.tar.gz

# ./config shared –prefix=/usr/local/opensssl

# make

# make install

◎ Freeradius 설치

Openssl 압축 해제 및 설치

# tar vxzf freeradius-server-2.1.10.tar.gz

# ./configure –with-openssl-includes=/usr/local/openssl/include \      –with-openssl-libraries=/usr/local/openssl/lib \      –prefix=/usr/local

◎ 인증서 만들기

인증서를 만드는 이유는 802.1x 프레임워크에서 인증 알고리즘으로 EAP-TLS, PEAP를 사용하기 위함이다.   EAP-TLS, PEAP 모두 양방향 인증 방식으로 Supplicant 는 Authentication Server 를 인증하고 Supplicant는 Authentication Server 를 인증한다. EAP-TLS 의 경우는 양쪽 다 인증서가 필요하다. 하지만 AP를 사용할때마다 인증서를 준비해야 하는 Supplicant의 불편을 덜어주고자 나온것이 PEAP 이다.

먼저 인증서를 만들기 위해서는 인증서 생성시 필요한 기본 정보들을 등록해야한다. 설치된 경로로 이동한다.

# cd /usr/local/etc/raddb/certs/

아래의 경로에는 다음과 같은 파일들이 있을 것이다.

[root@localhost:/usr/local/etc/raddb/certs]$ ls

Makefile  README  bootstrap*  ca.cnf  client.cnf  server.cnf  xpextensions

위 파일에서 확장자가 cnf 인것을 수정한다.

수정 파일 총 3개(ca.cnf  client.cnf  server.cnf)를 변경하면 된다.

아래는 예시이다.

countryName     = KR

stateOrProvinceName = KOREA

localityName        = Seoul

organizationName    = MMC Technology

emailAddress        = XXX@mmctech.com

commonName      = “MMC”

젤 먼저 countryName은 2개의 문자로 구성되어지고 그다음 나온 stateOrProvinceName 에서 풀로 적어준다. localityName은 지역명을 간단히 적고

나머지는 회사명/이메일 등을 넣으면 된다.

그외 input_password와 output_password가 있는데 인증서 설치시 필요한 것이니, 변경하면 기억해두도록하자.

input_password      = whatever

output_password     = whatever

이제 인증서를 생성해야하는데 기본적으로 client쪽 인증서가 생성되지 않는다 따라서, Makefile에 아래와 같이 변경한다.

.PHONY: all

–     all: index.txt serial dh random server ca

+  all: index.txt serial dh random server ca client

그런 다음 인증서를 생성한다.

[root@localhost:/usr/local/etc/raddb/certs]$ make

그러면 다음과 같이 파일들이 생성 될것이다

인증서버 설정

다음으로 상위 디렉토리로 가서 기본 인증 방식을 tls로 변경한다.

[root@localhost:/usr/local/etc/raddb/certs]$ cd ..

[root@localhost:/usr/local/etc/raddb]$ vi eap.conf

AP 등록 및 Client User 등록

” Clients.conf “ 파일에 아래와 같이 추가한다.

[root@localhost:/usr/local/etc/raddb]$ vi clients.conf

다음은 인증해줄 사용자(Supplicant)들을 등록하는 과정이다.   같은 디렉토리에 users 파일이 그것이다.이 파일에는 인증과정을 거쳐 Authenticator(AccessPoint) 를 사용할 수 있는 사용자(Supplicant) 를 등록하면 되는데 이때 사용자 아이디는 Supplicant 인증서를 만들때 입력한 commonName 이다.

[root@localhost:/usr/local/etc/raddb]$ vi users

이제 RADIUS 서버를 실행시키면 된다.

위의 LD어쩌고 저쩌고는 Radius 서버 데몬을 실행하기 위한 공유 라이브러리 경로를 지정하는 것이다 매번지정하기 귀찮으니까 프로파일에 추가하거나 스크립터를 만드는 것이 편하다. 아래는 스크립터를 만드는방법이다.

[root@localhost:/usr/local/etc/raddb]$ vi /usr/local/sbin/run-radius

[root@localhost:/usr/local/etc/raddb]$ chmod 755 /usr/local/sbin/run-radius

[root@localhost:/usr/local/etc/raddb]$ run-radius -X

Windows 2000/XP 환경설정 – Client

가장 먼저  할것은 인증 서버에서 만든 Supplicant 인증서를 PC 로 다운받아 인증서를 설치해야 한다. 그러기 위해서 ca.der, client.p12 를 Supplicant 로 사용되는 일반 PC 에 다운받아 설치하면 된다.client.p12 은 파일명 그대로 client certificate 즉 Supplicant 인증서를 말하며. ca.der의 용도는 root CA 인증서로 이 Supplicant 인증서를 signature 한 인증서이다. 

먼저 root CA 인증서인 root.der 을 설치한다.  PC 로 다운받은 ca.der 을 더블클릭한다. 그러면 인증서 정보가 첫 화면에 보이는데 여기서 “발급자” 항목을 보면 이전에 root CA 인증서 만들때 사용한 commonName 이 보일것이다. 그 화면에서”인증서 설치” 버튼을 클릭한다. “인증서 저장소” 단계에서 “모든 인증서를  다음 저장소에 저장”을 선택하고 “찾아보기” 버튼을 클릭하여 나타난 목록에서 “신뢰된 루트  인증 기관”을 선택하고 확인을 눌러 설치 작업을 마친다.

 이번에는 Supplicant 인증서인client.p12 를 설치합니다. 마찬가지로 client.p12 을 더블클릭하여 암호 화면까지 이동한다. “암호” 항목에 인증서 만들떄 사용한 암호값인 whatever 를 입력하고 다음으로 넘어갑니다.. 이번에도 “인증서 저장소” 화면이 나타나는데 이때는 “인증서 종류 기준으로 인증서 저장소를  자동으로 선택” 을  선택하여 완료한다.

이로써, Freeradius 를 구동하기 위한, 모든 설정이 끝났습니다

AKA인증 관련 내용은 트래백을 참고하세요

사전 작업

• rpm-build 설치
• rpm-build를 위한 GPG Key 생성

프로그램 작성

실습을 위해 world를 출력하는 hello 스크립트를 작성해보자.

mkdir hello-1.0.0
cat <<EOF > hello-1.0.0/hello
#!/bin/bash
echo world
EOF
sh hello-1.0.0/hello

[builduser@jmnote ~]$ mkdir hello-1.0.0
[builduser@jmnote ~]$ cat <<EOF > hello-1.0.0/hello
> #!/bin/bash
> echo world
> EOF
[builduser@jmnote ~]$ sh hello-1.0.0/hello
world

압축

[builduser@jmnote ~]$ tar czvf hello-1.0.0.tar.gz hello-1.0.0/
hello-1.0.0/
hello-1.0.0/hello

SPEC 파일 작성

 hello.spec 문서를 참고하십시오.

hello.spec 파일(새파일)을 열어서 hello.spec의 내용으로 채우고 저장.

[builduser@jmnote ~]$ vi hello.spec

rpm 빌드

[builduser@jmnote ~]$ rpmbuild hello.spec
error: File /home/builduser/rpmbuild/SOURCES/hello-1.0.0.tar.gz: No such file or directory

→ 빌드를 위한 폴더 구조를 만들기 위해 rpmbuild를 실행 (오류 발생하지만 무시)

[builduser@jmnote ~]$ cp hello-1.0.0.tar.gz rpmbuild/SOURCES/
[builduser@jmnote ~]$ cp hello.spec rpmbuild/SPECS/
[builduser@jmnote ~]$ cd rpmbuild/SPECS/
[builduser@jmnote SPECS]$ rpmbuild --sign -ba hello.spec
Enter pass phrase:

→ rpm-build를 위한 GPG Key 생성에서 입력했던 Passphrase 값 입력

Pass phrase is good.
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.hUcv0F
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ cd /home/builduser/rpmbuild/BUILD
... (생략)
+ cd hello-1.0.0
+ rm -rf /home/builduser/rpmbuild/BUILDROOT/hello-1.0.0-1.el6.x86_64
+ exit 0

[builduser@jmnote SPECS]$ cd ../RPMS/x86_64/
[builduser@jmnote x86_64]$ ll
total 4
-rw-rw-r--. 1 builduser builduser 2546 May 17 02:24 hello-1.0.0-1.el6.x86_64.rpm

→ 그럴싸한 rpm 파일이 생성되었다.

rpm 설치 및 확인

• root 계정에서 진행

[root@zetawiki ~]# rpm --import /home/builduser/RPM-GPG-KEY-builduser
[root@zetawiki ~]# cp /home/builduser/rpmbuild/RPMS/x86_64/hello-1.0.0-1.el6.x86_64.rpm ~
[root@zetawiki ~]# rpm -ivh hello-1.0.0-1.el6.x86_64.rpm
Preparing...                ########################################### [100%]
   1:hello                  ########################################### [100%]

[root@zetawiki ~]# rpm -qa hello
hello-1.0.0-1.el6.x86_64
[root@zetawiki ~]# which hello
/usr/local/bin/hello
[root@zetawiki ~]# rpm -qf /usr/local/bin/hello
hello-1.0.0-1.el6.x86_64
[root@zetawiki ~]# hello
world

같이 보기

• 리눅스 rpm-build 설치
• hello.spec
• 리눅스 rpm
• YUM 저장소 만들기

사전 작업

긴 실습 (rpm 만들기 포함)

• rpm 패키지 만들기 실습
• createrepo 설치
• 아파치 설치

짧은 실습 (rpm 만들기 미포함)^[1]

• RPM-GPG-KEY 파일 만들기
• createrepo 설치
• 아파치 설치

저장소 생성

• DOCUMENT_ROOT 아래에 /repo/Packages 폴더를 만든다.

[root@zetawiki ~]# mkdir -p /var/www/html/repo/Packages
[root@zetawiki ~]# cp hello-1.0.0-1.el6.x86_64.rpm /var/www/html/repo/Packages/
[root@zetawiki ~]# createrepo -v /var/www/html/repo/
Spawning worker 0 with 1 pkgs
Worker 0: reading Packages/hello-1.0.0-1.el6.x86_64.rpm
Workers Finished
Gathering worker results
 
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Starting other db creation: Sun Jun  8 14:39:05 2014
Ending other db creation: Sun Jun  8 14:39:05 2014
Starting filelists db creation: Sun Jun  8 14:39:05 2014
Ending filelists db creation: Sun Jun  8 14:39:05 2014
Starting primary db creation: Sun Jun  8 14:39:05 2014
Ending primary db creation: Sun Jun  8 14:39:05 2014
Sqlite DBs complete

[root@zetawiki ~]# cp /home/builduser/RPM-GPG-KEY-builduser /var/www/html/repo/
[root@zetawiki ~]# curl http://127.0.0.1/repo/RPM-GPG-KEY-builduser
-----BEGIN PGP PUBLIC KEY BLOCK-----
... (생략)
-----END PGP PUBLIC KEY BLOCK-----

다른 컴퓨터에서 테스트

접속 확인

[root@CentOS63 ~]# nc -z 135.79.246.80 80
Connection to 135.79.246.80 80 port [tcp/http] succeeded!

[root@CentOS63 ~]# curl http://135.79.246.80/repo/RPM-GPG-KEY-builduser
-----BEGIN PGP PUBLIC KEY BLOCK-----
... (생략)
-----END PGP PUBLIC KEY BLOCK-----

repo 등록

echo '[my-first-repo]
name=My First Repo
baseurl=http://서버주소/repo
gpgkey=http://서버주소/repo/RPM-GPG-KEY-builduser
enabled=1
gpgcheck=1' > /etc/yum.repos.d/my-first-repo.repo
yum repolist

[root@CentOS63 ~]# echo '[my-first-repo]
> name=My First Repo
> baseurl=http://135.79.246.80/repo
> gpgkey=http://135.79.246.80/repo/RPM-GPG-KEY-builduser
> enabled=1
> gpgcheck=1' > /etc/yum.repos.d/my-first-repo.repo

[root@CentOS63 ~]# yum repolist
... (생략)
repo id        repo name                                        status
base           CentOS-6 - Base                                   6,367
epel           Extra Packages for Enterprise Linux 6 - x86_64   10,899
extras         CentOS-6 - Extras                                    14
my-first-repo  My First Repo                                         1
updates        CentOS-6 - Updates                                1,009
repolist: 18,290

→ 패키지를 1개 가진 my-first-repo가 보인다.

hello 패키지 설치

======================================================================
 Package     Arch         Version           Repository           Size
======================================================================
Installing:
 hello       x86_64       1.0.0-1.el6       my-first-repo       2.5 k
 
Transaction Summary
======================================================================
Install       1 Package(s)
 
Total download size: 2.5 k
Installed size: 23  
Is this ok [y/N]: y

... (생략)
Installed:
  hello.x86_64 0:1.0.0-1.el6                                          
 
Complete!

[root@zetawiki ~]# rpm -qa hello
hello-1.0.0-1.el6.x86_64

[root@zetawiki ~]# hello
world

같이 보기

• rpm 패키지 만들기 실습
• 리눅스 createrepo 설치
• Daum repo 설정

7.1 설정 최적화 검사

http://www.serverchk.com/

http://www.dnsreport.com/에서 검사

# named-checkconf /etc/named.conf

7.2Options 튜닝하기

Bind8이 보안상 취약하여 Bind8에서 사용하는 옵션이 대부분입니다.

Bind9버전에서는 일부분은 보안취약점이 개선되어 기본으로 적용되어 있어 오류로 표시되는 옵션이 있으므로,

messages파일보고 불필요하면 제거하도록 한다. (진한 부분은 공통으로 설정이 필요한부분이다.)

# vi/etc/ Named.conf

options {

directory “/var/named”;

// pid-file “/var/named/named.pid”;// named pid 파일을 남길 위치

// statistics-file “/var/named/named.stats”;// 통계정보를 남길 위치

memstatistics-file “/var/named/named.memstats”; // 메모리 통계정보 파일을 위치

dump-file “/var/adm/named.dump”; // 네임서버의 메모리 상태 정보 파일 위치

version “Unknown !!”;

edns-udp-size 512 ;

check-names master ignore ;// 필수 권장설정

check-names slave ignore ;// 권장설정

에러 형식:

다음은 버전8의 기본값

check-names master fail; // 언더바가 들어가더라도 현재는 정상 응답한다

check-names slave warn; // 언더바가 들어가더라도 현재는 경고만 보내주고 응답한다

Check-names response ignore;// 언더바가 들어가더라도 현재는 정상 응답한다

오류에 대해 무시하고 질의에 대한 응답을 하도록 한다.

Check-names response ignore;

notify no;

Allow-notify { 203.231.124.15; };

multiple-cnames yes;

maintain-ixfr-base yes;

transfer-format many-answers;

serial-queries 100 ;

listen-on { 203.231.124/24; };

};

7.3 Bind버전확인하기

# dig txt chaos version.bind.

# dig @200.1.1.1 txt chaos version.bind.

7.4 질의제한:

7.4.1 해당 DNS서버의 named.conf 에 질의를 허용할 IP블록을 등록한다.

# more/etc/named.conf

7.5 개별도메인에 Notify허용법

named.conf 의 option부분에notify no; 라고 한경우 Master가 Slave에 정보변경시 바로 notify를 하지 않고, SOA레코더값이 지정되어 있는시간에 전송요청을 한다.

만약  option부분에는 no로 되어 있으나 특정도메인은 notify목록에 추가하려면zone구문에서 also-notify라는 서버구문을 이용한다.

allow-transfer { none; };

};

7.6IXFR – BIND 8.2.3이상, 다음은 BIND8에서의 IXFR설정법입니다.

동적 업데이트만 이용해 영역데이터를 수정할때만 문제없이 동작

7.7 포워더 설정.

options {

forwarders { 168.126.63.1; 203.255.112.34; };

};

options {

forwarders { 168.126.63.1; };

forward only;

};

7.8 영역포워드 – (BIND 8.2부터, BIND 9.1.0부터)

7.8.1  귀하의 Cache DNs에서 yejin.pe.kr사이트만 정상적으로 레졸루션 되지 않을시 우선조치

해당 사이트 질의시 다른 네임서버에게 포워드하여 해당 네임서버가 응답하도록함.

7.8.2 Yahoo.com등 특정사이트가 접속이 안될때 -Name:www.yahoo.akadns.net

네임서버에서 yahoo의 네임서버인 akaff 찾을땐 특정 IP로 포워드 한다.

Forward하는법.

7.8.3 설정 파일 전체에 영향을 미치는 options구문속의 forwarder설정을 무력화시키기.

로컬에 있는 도메인을 forwarder인 외부에 질의하게 되는 부분을 해결.

7.9 비재귀적 네임서버 (네임서버 전용인 경우 설정함)

options {

recursion no;

options {

fetch-glue no ;

7.10 엉터리 네임서버 이용금지. – blackhole설정

이 목록에 있는 네임 서버에는 질의를 보내지도 않고 이들이 보내는 질의에도 응답하지 않는다.

목록에 있는 네임서버에는 질의를 보내지도 않고, 보내는 질의에도 응답하지 않는다

또는

7.11네임서버별 영역전송 개수 제한

transfers-per-ns 4;

7.12 영역 전송 시간 제한

max-transfer-time-in 180;

7.13 청소주기

cleaning-interval 120;

실행된 로그내용:

12-May-2005 13:44:29.123 maintenance: info: Cleaned cache of 123874 RRsets
// named 데몬에서 잡고 있는 메모리가 이 설정에 의해 줄거나 하지는 않으며 이미 잡혀 있는 메모리 자체에 있는 데이타를 날리고 제 사용하는 방식을 택하고 있는 것으로 보입니다.

7.14 인터페이스주기

interface-interval 0;

7.15 통계주기

statistics-interval120;

7.16 부정적 TTL시간

max-ncache-ttl 3600;

7.17 질의제한:

1) 해당 DNS서버의 named.conf 에 질의를 허용할 IP블록을 등록한다.

외부에서 사용못하도록함.

# more/etc/named.conf

or

7.18리졸빙 네임서버를 더욱 안전하게 운영

options {

use-id-pool yes ;

};

7.19 Zone Transfer 제어 – 인가 받지 않은 영역 전송금지

용도: 서버로부터 영역을 zone transfer할수 있는 사용자들은 영역의 모든 호스트를 보게됨으로서 보안상 설정을 함.(BIND8을 기준으로 작성됨.)

특정 IP블록에서만 Zone Transfer를 할수 있도록함.

Zone transfer는 일반적으로 slave에서 Master의 zone을 가져가므로 slave의 ip-address나 블록을 넣어준다.

설정법

#파일위치:/etc/named.conf,// 환경 설정파일은 options 안에 정의

Slave서버의 zone구문은zone-transfer가 일어나지 않으므로 다음과 같이 설정한다.