VMware 에서 설치한 CentOS 6.4 를 이미지를 복제한 뒤에, 네트워크를 설정하다보면 다음과 같은 오류가 발생합니다.
$ service network restart Shutting down loopback interface:[OK] Bringing up loopback interface:[OK] Bringing up interface eth0:Device eth0 does not seem to be present, delaying initialization. [FAILED]
이는 가상화 이미지를 복제할 때 ethernet adapter 의 MAC 주소가 바뀌기 때문에 발생하는 것입니다.
CentOS 에서는 이 때 ethernet adapter 를 새로 한개 더 추가해서 eth0 가 아닌 eth1 로 잡습니다.
이는 다음과 같이 확인해 볼 수 있습니다.
$ ls /sys/classs/net eth1lo
불필요한 ethernet adapter 를 삭제해주기 위해서, 장치 관리자가 자동으로 생성한 규칙 파일을 편집합니다.
해당 파일은 /etc/udev/rules.d/70-persistent-net.rules 입니다.
$ vi /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key.
실제로 가상화 이미지의 ethernet adapter 의 MAC 주소를 확인해보면 00:0c:29:da:06:f2 로확인될것입니다.
위의 파일 내용에서 NAME="eth0" 항목을 삭제하고, NAME="eth1" 의 이름을 "eth0" 으로 바꿉니다.
# This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key.
HTTP에서 HTTPS로 전환하기 위한 완벽 가이드 HTTPS 설정은 경험이 부족한 사용자에게는 어려울 수 있다. 여러 단계를 거쳐야 하고 암호화와 서버 구성에 관한 지식이 필요하기 때문에 복잡한 작업으로 여겨진다. 여기서는 HTTPS 설정에 필요한 구성 요소와 단계에 대해 설명한다. 호스팅 공급 업체가 HTTPS 인증서를 제공하는 경우는 설정이 더 쉽다(제어판에서 모든 작업을 쉽고 빠르게 수행할 수 있다). 리눅스와 유닉스 아파치 HTTP 서버와 엔진엑스Nginx뿐만 아니라 윈도우 IISInternet Information Server의 관리자나 cPanel 사용자를 위한 지침도 소개한다. 기본적인 내용부터 시작해보자.
HTTP, HTTPS, HTTP/2, SSL, TLS – 도대체 뭐가 뭔지? 클라이언트와 서버 간 통신 과정을 설명하는 데 사용되는 약어가 많다. 이러한 약어의 개념을 모르는 사람은 혼동해서 사용하기 쉽다. HTTPHypertext Transfer Protocol는 클라이언트와 서버 양쪽에서 통신할 수 있도록 구현해야 하는 기본 통신 프로토콜로, 요청과 응답, 세션, 캐싱, 인증 등을 다룬다. 프로토콜과 HTML 관련 작업은 CERN에서 팀 버너스 리Tim Berners-Lee와 그 팀이 1989년에 시작했다. 첫 번째 공식 프로토콜 버전(HTTP 1.0)은 1996년에 발표됐고, 곧이어 1997년에 현재 널리 사용되는 버전(HTTP 1.1)이 나왔다. HTTP는 브라우저와 서버 사이에서 정보를 평문으로 전송하므로 정보가 전달되는 네트워크에서 전송되는 정보를 엿볼 수 있다. 이런 보안 문제로 인해 클라이언트와 서버가 먼저 암호화 통신 채널을 설정한 다음 평문 HTTP 메시지를 전송함으로써 정보 유출을 막는 HTTPSHTTP Secure가 소개되었다. 암호화 채널은 이전에 SSLSecure Socket Layer이라고 불렸던 TLSTransport Layer Security 프로토콜을 사용해서 만든다. 흔히 SSL과 TLS를 혼용했으나 SSL 3.0은 TLS 1.0으로 대체되었다. SSL은 넷스케이프가 개발한 프로토콜인 반면 TLS는 IETF 표준이다. 현재 SSL(1.0, 2.0, 3.0)의 모든 버전은 여러 가지 보안 문제로 사용되지 않고 대부분의 브라우저에서 경고를 표시한다. 현재 TLS 버전(1.0, 1.1, 1.2)을 사용하고 있으며 1.3 버전은 초안이다. 1996년과 1997년에 현재의 안정적인 인터넷 버전(HTTP 1.1, SSL과 TLS는 선택)이 등장했으며 현재 대부분의 웹사이트가 이 버전에서 운영되고 있다. HTTP는 민감하지 않은 트래픽(예: 뉴스 기사)에 이용되고 HTTPS는 민감한 트래픽(예: 인증, 전자상거래)에 이용된다. 하지만 프라이버시에 관심이 높아지면서 구글 크롬과 같은 웹 브라우저는 이제 HTTP 웹사이트를 ‘안전하지 않음’으로 표시하고 HTTP의 앞날에 경고를 보내고 있다. HTTP 프로토콜의 다음 업그레이드 버전인 HTTP/2는 점점 많은 웹사이트에 적용되고 있으며 지연을 줄이고 성능과 보안 향상을 위해 새 기능(압축, 멀티플렉싱, 우선순위 지정)을 추가했다. HTTP 버전 1.1에서는 보안 연결이 선택이지만(HTTP와 HTTPS는 서로 독립적) HTTP/2에서는 사실상 필수다. 표준으로는 HTTP/2에서 TLS를 선택적으로 정의했지만 대부분의 브라우저 공급 업체는 HTTP/2와 TLS만 지원한다고 명시했다. HTTPS에서 제공하는 것 HTTPS로 전환을 고민하는 이유부터 살펴보자. HTTPS는 다음 세 가지 주요 이유 때문에 사용한다. • 기밀성 HTTPS는 인터넷과 같은 공공 매체에서 두 참여자 간의 통신을 보호한다. 예를 들어, HTTPS가 없다면 와이파이Wi-Fi 액세스 포인트Access Point를 운영하는 사람은 액세스 포인트를 사용하는 사람이 온라인에서 무언가를 구입할 때 신용카드와 같은 개인정보를 볼 수도 있다. • 무결성 HTTPS는 변조되지 않은 정보로 목적지에 도달하게 한다. 예를 들어, 와이파이가 웹사이트에 광고를 추가하거나, 대역폭을 절약하고자 이미지 품질을 저하시키거나, 읽는 기사의 내용을 변조할 수 있지만 HTTPS는 웹사이트를 변조할 수 없도록 한다. • 인증 HTTPS를 통해 웹사이트의 진위 여부를 확인할 수 있다. 예를 들어, 와이파이 액세스 포인트을 운영하는 사람이 가짜 웹사이트를 브라우저에 보낼 수도 있다. HTTPS는 example.com이라는 웹사이트가 실제로 example.com인지 확인한다. 일부 인증서는 yourbank.com이 YourBank.Inc라는 걸 알리기 위해 해당 웹사이트의 법적 신원을 검사하기도 한다. 암호 기술의 핵심 기밀성, 무결성, 인증이 HTTPS에만 한정된 것은 아니다. 이러한 특징은 암호 기술의 핵심 개념이다. 이제부터는 각 특징에 대해서 들여다보자. 기밀성 기밀성Confidentiality은 프라이버시다. 즉, 기밀성은 인증되지 않은 제3자가 정보를 읽지 못하도록 보호한다. 그 과정은 보통 평문plaintext이라고 하는 읽을 수 있는(들을 수 있거나 볼 수 있는) 정보 형식을 암호문ciphertext이라고 하는 뒤죽박죽 된 읽을 수 없는 정보 형식으로 변환하는 작업을 거친다. 이 과정을 암호화encryption라고 한다. 반대의 과정(암호문을 다시 읽을 수 있는 평문으로 전환)을 복호화decryption라고 한다. 정보를 암호화하고 복호화하는 방법(암호 함수cipher functions 또는 알고리즘)은 많다. 두 명의 당사자가 통신하려면 다음 두 가지에 동의해야 한다. 1. 통신에 사용할 알고리즘(암호 함수) 2. 선택한 방법으로 사용할 매개변수 또는 암호, 규칙(예: 시크릿secret) 암호화에는 두 가지 주요 방법이 있다. • 대칭 양쪽 당사자가 공통 비밀 키를 공유한다. • 비대칭 당사자 중 한쪽이 비밀 키와 공개 키의 쌍, 공개 키 인프라(PKI) 기반을 갖는다. 대칭형 방식은 양쪽 당사자가 공유한 시크릿에 의존하는데, 전송자는 정보를 암호화하는 데 사용하고 수신자는 동일한 방식과 키를 사용해 복호화한다(‘대칭 키 암호화’ 그림 참조). 이 방법의 문제는 양쪽 당사자가 서로 물리적인 만남 없이 시크릿을 협상(교환)하는 방법이라서 일종의 보안 통신 채널이 필요하다.
대칭 키 암호화 (이미지 확대) 공개 키와 개인 키의 개념을 기반으로 하는 비대칭 방식은 대칭 방식의 문제를 해결한다. 두 가지 키 중 하나로 평문을 암호화하면 다른 보완 키를 사용해야만 복호화할 수 있다. 이를테면 서로 안전하게 통신하고 싶은 두 당사자 앨리스와 밥이 있다고 가정하자(앨리스와 밥은 모든 튜토리얼과 보안 매뉴얼에 항상 등장하는 허구의 인물이므로 여기서는 그러한 전통을 따랐다). 앨리스와 밥은 공개 키와 개인 키의 쌍을 가졌다. 개인 키는 각 소유자만 알고 있으며 공개 키는 누구든 사용할 수 있다. 앨리스가 밥에게 메시지를 보내고 싶다면, 앨리스는 밥의 공개 키를 얻어 평문을 암호화하고 암호문을 밥에게 보낸다. 밥은 자신의 개인 키를 사용해 암호문을 복호화한다. 밥이 앨리스에게 회신하고 싶다면, 앨리스의 공개 키를 얻어서 평문을 암호화해 암호문을 보낸다. 엘리스는 자신의 개인 키를 사용해 그 암호문을 복호화한다.
비대칭 암호화 (이미지 확대) 언제 대칭 암호화를 사용하고, 언제 비대칭 암호화를 사용할까? 비대칭 암호화는 클라이언트와 서버 간 시크릿을 교환할 때 사용한다. 실생활에서는 양방향 비대칭 통신이 필요하지 않다. 당사자 중 한쪽이(서버라고 하자) 일련의 키를 가지고 있으므로 암호화된 메시지를 받을 수 있다는 것만으로 충분하다. 이는 공개 키로 암호화한 정보는 개인키를 사용해야만 복호화되기 때문에 클라이언트에서 서버로 향하는 단방향으로만 정보를 보호한다. 그러므로 서버에서만 그 정보를 복호화할 수 있다. 반대 방향은 보호되지 않는다. 서버의 개인 키로 암호화된 정보는 공개 키를 가진 누구든지 복호화할 수 있다. 상대편(클라이언트라고 하자)은 서버의 공개 키를 사용해 무작위로 생성된 세션 시크릿을 암호화해 통신을 시작한다. 그 다음 암호문을 다시 서버로 보내고, 서버는 다시 자신의 개인 키로 복호화하면 그 시크릿을 갖게 된다. 대칭 암호화는 비대칭 암호화보다 훨씬 빠르기 때문에 전송 중인 실제 데이터를 보호하는 데 사용된다. 앞서 교환한 시크릿으로 정보를 가진 두 당사자(클라이언트와 서버)만 해당 정보를 암호화하고 복호화할 수 있다. 이 때문에 핸드셰이크handshake의 첫 비대칭 부분이 키 교환이라고 불리며, 실제 암호화된 통신은 사이퍼 메서드cipher methods라는 알고리즘을 사용한다. 무결성 HTTPS로 해결하는 또 다른 문제는 데이터 무결성integrity이다. 즉, (1)전체 정보가 잘 도착했으며, (2)전송 중에 누가 변조하지 않았음을 보장한다. 정보가 잘 전송되었음을 보장하기 위해 메시지 다이제스트message digest 알고리즘을 사용한다. 교환된 각 메시지의 메시지 인증 코드message authentication codes, MAC 계산은 암호화 해싱 프로세스다. 예를 들어 MAC(태그라고도 한다) 획득은 실질적으로 다음의 작업이 불가능(보통 사용하는 용어는 ‘실행 불가능infeasible’)하게 하는 방식이다. • 태그에 영향을 끼치지 않고 메시지 변경하기 • 두 개의 다른 메시지에 동일한 태그 생성하기 • 프로세스를 거꾸로 돌려 태그에서 원래 메시지 획득하기 인증 인증authentication은 어떨까? 공개 키 인프라의 실제 애플리케이션이 갖는 문제는 양쪽 당사자가 (물리적으로 떨어져 있는) 상대편이 실제로 누구인지 알 방법이 없다는 것이다. 그래서 상대편의 신원을 보증하기 위해 상호 신뢰할 수 있는 제3자, 즉 인증 기관certificate authority, CA이 필수다. 인증 기관은 example.com이라는 도메인 이름(고유한 식별자)이 공개 키 XXX와 연결되어 있음을 기술한 인증서를 발행한다. 경우에 따라서는(조금 뒤 설명하는 EV와 OV 인증서) 인증 기관은 그 도메인을 특정 회사가 통제하는지도 확인한다. 이 정보는 인증 기관 X(인증서 발행)에서 보증하고, 이 보증은 날짜 Y(시작일)와 날짜 Z(만료일)사이에서 유효하다. 이 모든 정보는 HTTPS 인증서라는 문서 하나에 들어간다. 이해를 돕기 위해 나라에서 국민에게 발행하는 ID나 여권을 예로 들면, 해당 정부를 신뢰하는 모든 신뢰 당사자는 ID를 가진 사람의 신원 또한 수용한다(가짜 ID인 경우는 이 예의 범위 밖이다). 인증 기관은 인증서를 서명하기 위해 신뢰된 조직이다. 윈도우와 맥OS, iOS, 안드로이드 등의 운영체제뿐만 아니라 파이어폭스 브라우저는 신뢰된 인증서 목록을 갖고 있다. 사용하는 브라우저에서 신뢰하는 인증 기관을 확인할 수 있다. • 파이어폭스 설정 → 개인 정보 및 보안 → 인증서 → 인증서 보기 → 인증 기관 • 윈도우 제어판 → 인터넷 옵션 → 내용 → 인증서 → 신뢰할 수 있는 인증 기관/중간 인증 기관 • 맥 응용 프로그램 → 유틸리티 → 키체인 접근 → 카테고리 내 인증서
신뢰 사슬Chain of trust (이미지 확대) 목록에 없는 다른 인증 기관도 추가할 수 있는데, 이는 자체 서명된 인증서와 같은 사설 인증서를 사용할 때 유용하다(뒤에서 다룬다). 대개 일반적인 상황에서 서버 쪽에서만 클라이언트에 신원을 증명한다. 예를 들어, 전자상거래 웹사이트와 고객의 관계에서 해당 웹사이트만 인증서가 필요하다. 전자 정부와 같은 경우는 서비스를 요청하는 서버와 클라이언트 모두 자신의 신원을 증명해야 한다. 이는 양쪽 당사자 모두 다른 당사자를 인증하는 데 인증서를 사용해야 한다는 뜻이다(이 설정 또한 이 글의 범위 밖이다). HTTPS 인증서 유형 HTTPS 인증서에는 여러 유형이 있으며 다음과 같이 나눌 수 있다. 1. 신원 검증 1. DVDomain validated 가장 일반적인 유형의 인증서인 DV 인증서는 도메인이 특정 공개 키와 일치하는지 확인한다. 브라우저는 서버와 보안 연결을 수립하고 닫힌 자물쇠를 표시한다. 이 표시를 클릭하면 ‘현재 웹사이트는 소유자 정보를 제공하지 않고 있습니다’를 보여준다. 도메인 외의 다른 특별한 요구 사항은 없다. DV 인증서는 해당 도메인에 대한 알맞은 공개 키인지를 간단히 확인하며, 브라우저에서는 법적 신원을 보여주지는 않는다. DV 인증서는 무료이거나 저렴(10달러/년)하다(아래 Let’s Encrypt와 Cloudflare 부분 참고). 2. EVExtended validation EV 인증서는 웹사이트의 법적 신분을 검증한다. EV 인증서는 가장 신뢰할 수 있는 유형의 인증서다. 인증 기관에서 도메인을 관리하는 이의 법적 신원을 확인한 후 얻을 수 있다. 법적 신원은 다음의 조합으로 확인한다. • 도메인 관리(예: DV 인증서) • 회사가 등록되었고 현재 유지 상태인지 확인할 수 있는 공인된 사업 기록 • D&B(Dunn and Bradstreet), 세일즈포스 connect.data.com, 전화번호부 등에 등재된 자영업 정보 • 확인 전화 • 인증서의 모든 도메인 이름 검사(와일드카드는 EV 인증서에서 명시적으로 금지). 닫힌 자물쇠 표시뿐만 아니라 EV HTTPS 인증서는 URL 앞에 검증된 법적 신원의 이름(등록된 회사)을 표시한다. iOS 사파리와 같은 일부 기기는 검증된 법적 신원만 표시하고 전체 URL은 무시한다. 해당 표시를 클릭하면 이름과 주소 같은 조직에 대한 자세한 정보를 보여준다. 비용은 연간 150달러에서 300달러 정도다. 3. OVOrganization validated EV처럼 OV 인증서는 웹사이트의 법적 신분을 검증한다. 하지만 EV 인증서와 달리 OV HTTPS 인증서는 UI에서 확인된 법적 이름을 표시하지는 않는다. 결과적으로 OV 인증서는 높은 검증 요구 사항 대비 사용자에게 보여주는 이점이 없기 때문에 인기가 덜하다. 가격은 연 40달러에서 100달러 정도다. 2. 다루는 도메인 수 이전 HTTPS 인증서는 일반적으로 CN 필드에서 하나의 도메인을 다뤘다. 나중에 ‘주체 대체 이름Subject Alternative Name, SAN’ 필드가 추가되어 하나의 인증서에서 추가적인 도메인을 다루도록 허용했다. 요즘 만드는 모든 HTTPS 인증서는 동일하다. 단일 도메인 인증서에도 해당 단일 도메인에 대한 SAN(그리고 그 도메인의 www 버전에 대한 두 번째 SAN)이 있다. 하지만 많은 인증서 공급 업체는 여전히 과거의 관행을 이유로 단일 도메인과 다중 도메인 HTTPS 인증서를 팔고 있다. 1. 단일 도메인 가장 흔한 인증서 유형으로 example.com과 http://www.example.com와 같은 도메인 이름에 유효하다. 2. 다중 도메인(UCC/SAN) UCCUnified Communications Certificate 또는 SAN 인증서로 알려진 인증서 유형으로 도메인의 목록을 다룰 수 있다(지정된 제한까지). 단일 도메인에 대한 제한은 없으며 다른 도메인과 하위 도메인을 혼합할 수 있다. 가격은 보통 정해진 도메인의 수(3~5개)에 추가 비용을 지불하면 더 많이(최대 한도까지) 포함할 수 있는 옵션을 제공한다. 웹사이트의 인증서를 검사하는 클라이언트는 주 도메인뿐만 아니라 모든 추가 도메인을 확인하기 때문에 웹사이트와 관련된 도메인 사용을 권장한다. 3. 와일드카드 이 유형의 인증서는 주 도메인뿐만 아니라 하위 도메인(*.example.com)의 수를 제한 없이 다룬다(예: example.com, http://www.example.com, mail.example.com, ftp.example.com 등). 제한 사항은 주 도메인의 하위 도메인만 다룬다는 점이다. 다음 표에서 사용 가능한 다양한 HTTPS 인증서를 정리했다. 인증서 유형 DV OV EV (Domain validated) (Organization validated) (Extended validation) HTTPS HTTPS에서 법적 소유자 검증 HTTPS 검증 법적 소유자 정보가 브라우저에 표시 단일 도메인 example.com, http://www.example.com 다중 도메인 mail.example.com, example.net, example.org 등. 사전 정의된 목록, 지정된 최대 제한까지 (보통100) 와일드카드 *.example.com는 example.com의 모든 하위 도메인을 뜻한다. N/A. 모든 이름은 인증서에 명시적으로 포함해야 하고 CA에서 검사해야 한다. 구성 요약하면 HTTPS의 네 가지 구성 요소는 다음의 암호화를 필요로 한다. 1. 초기 키 교환 비대칭(개인 키와 공개 키) 알고리즘을 사용한다. 2. 신원 인증서(인증 기관에서 발행한 HTTPS 인증서) 이 인증서는 비대칭(개인 키와 공개 키) 알고리즘을 사용한다. 3. 실제 메시지 암호화 대칭(미리 공유한 시크릿) 알고리즘을 사용한다. 4. 메시지 다이제스트 암호 해싱 알고리즘을 사용한다. 이들 각 구성 요소는 서로 다른 키 크기를 사용하는 일련의 알고리즘(이들 알고리즘 중 일부는 사용하지 않음)이 있다. 일부 핸드셰이크의 경우 클라이언트와 서버가 사용할 방식의 조합(수십 개의 공개 키(키 교환) 알고리즘 중 하나, 수십 개의 대칭 키(암호) 알고리즘 가운데 하나와 3개의 메시지 다이제스트(해싱) 알고리즘(2개는 사용 안 함) 가운데 하나를 선택해 수백 가지 조합)에 대한 동의를 요구한다. 예를 들어 ECDHE-RSA-AES256-GCM-SHA384 설정은 해당 키를 ECDHEElliptic Curve Diffie-Hellman Ephemeral 키 교환 알고리즘을 사용해 교환한다는 뜻이다. 인증 기관은 RSARivest-Shamir-Adleman 알고리즘을 사용해 인증서를 서명한다. 대칭 메시지 암호화는 256비트 키와 GCM 운영 모드를 갖는 AESAdvanced Encryption Standard 암호를 사용한다. 메시지 무결성은 384비트 다이제스트를 사용하는 SHA 보안 해싱 알고리즘을 사용해 검증한다(포괄적인 알고리즘 조합 목록을 사용할 수 있다.) 따라서 몇 가지 구성을 선택할 수 있다. 암호화 스위트 사용할 암호화 스위트cipher suite를 결정하는 일은 호환성과 보안 사이의 균형이다. • 이전 브라우저와 호환성은 이전 암호화 스위트를 지원하는 서버가 필요하다. • 하지만 대다수의 이전 암호화 스위트는 더 이상 안전하지 않다. OpenSSL은 암호 강도가 가장 안전한 것에서 가장 약한 것 순서로 위에서 아래로 지원 조합을 나열한다. 클라이언트와 서버 간의 초기 핸드셰이크 동안 양쪽 당사자가 지원하는 조합과 일치하는 것을 발견할 때까지 협상하기 때문에 이런 방식으로 설계했다. 가장 보안이 좋은 조합을 먼저 시도하고 다른 방법이 없다면 점차 더 약한 조합을 쓴다. 서버에서 사용할 암호화 방법을 조언할 때 매우 유용하고 권장하는 자료는 뒤에서 실제 서버 구성에 다룰 모질라 SSL 구성 생성기다. 키 유형 ECCElliptic Curve Cryptography 인증서는 RSA 인증서보다 더 빠르고 CPU를 덜 쓰는데, 특히 모바일 클라이언트에는 이런 점이 중요하다. 하지만 아마존의 클라우드프론트CloudFront나 헤로쿠Heroku와 같은 일부 서비스는 이 글을 쓰는 시점에 아직 ECC 인증서를 지원하지 않는다. 256 비트 ECC 키면 충분하다. RSARivest Shamir Adleman 인증서는 더 느리지만 오래된 다양한 서버와 호환된다. RSA 키는 더 크므로 2048비트 RSA 키가 최소한이다. 4096비트 이상의 RSA 키는 성능에 좋지 않다. 이 인증서는 2048비트 중간 인증 기관에서 서명할 수도 있어 추가적인 보안에 상당한 손상을 준다. 앞서 기술한 내용이 가변적이라는 점과 키 크기의 제약 사항을 주목했을 것이다. 한 서버에서 과부하를 주는 요인이 다른 서버에서는 그렇지 않을 수 있기 때문이다. 성능에 미치는 영향을 확인하는 최선의 방법은 실제 웹사이트와 실제 방문자로 서버의 부하를 모니터링하는 것이다. 시간의 흐름에 따라 성능이 바뀔 것이다. 절차 HTTPS 인증서를 얻으려면 다음 단계를 거쳐야 한다. 1. 개인 키와 공개 키 쌍을 만들고 조직과 공개 키에 관한 정보를 포함하는 CSRCertificate Signing Request을 준비한다. 2. 인증 기관에 연결해 CSR 기반 HTTPS 인증서를 요청한다. 3. 서명된 HTTPS 인증서를 획득하고 웹 서버에 인증서를 설치한다. 개인 키와 공개 키, CSR과 서명된 HTTPS 인증서 등 공개 키 인프라(PKI)의 다른 구성 요소를 포함하는 일련의 파일이 존재한다. 복잡성을 더 높이는 방편으로 동일성 여부를 확인하는 데 다른 당사자는 다른 이름(그리고 파일 확장자)을 사용한다. 정보를 저장하기 위한 두 가지 인기 있는 형식에는 DER과 PEM이 있다. DER은 바이너리이며, PEM은 base64 인코딩된(텍스트) DER 파일이다. 기본적으로 윈도우는 DER 형식을 직접 사용하며, 오픈소스 진영(리눅스, 유닉스)은 PEM 형식을 사용한다. 두 가지 형식 서로 간에는 변환할 수 있는 도구(OpenSSL)가 있다. 설명 과정에서 예제로 사용할 파일은 다음과 같다. • example.com.key 이 PEM 형식 파일은 개인 키를 포함한다. 확장자 .key는 표준이 아니므로 일부에서는 사용한다. 시스템 슈퍼 유저만이 보호하고 접근할 수 있다. • example.com.pub 이 PEM 형식 파일은 공개 키를 포함한다. 이 파일은 개인 키에서 생성될 수 있기 때문에 실제로는 필요하지 않다. 여기서는 설명 목적으로 포함시켰다. • example.com.csr 이 파일은 인증서 서명 요청이다. 조직 정보와 서버의 공개 키를 포함하는 PEM 형식 파일을 HTTPS 인증서를 발행하는 인증 기관에 보내야 한다. • example.com.crt 이 HTTPS 인증서는 인증 기관이 서명한 것이다. 이 파일은 PEM 형식 파일이며 서버의 공개 키와 조직 정보, 인증 기관 서명, 유효기간, 만료 날짜 등이 들어 있다. 확장자 .crt는 표준이 아니다. 다른 일반적인 확장자는 .cert와 .cer을 포함한다. 파일 이름(그리고 확장자)는 표준이 아니다(원하는 어떤 것도 가능하다). 어떤 구성 요소가 무슨 기능을 하는지 분명하게 보여야 한다고 생각하기 때문에 이 명명 규칙을 선택했다. 명령과 서버 구성 파일에서 적합한 키 인증서를 참조한다면 프로세스 전체에서 어떤 명명 규칙이든 사용할 수 있다. 개인 키는 특정 길이(여기서는 2048비트 사용)의 문자열을 무작위로 생성한 것으로 다음과 같다. —–BEGIN RSA PRIVATE KEY—– MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv /+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06 XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6 HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3 5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu —–END RSA PRIVATE KEY—– ‘개인 키를 비공개로 유지하자.’ 이 말은 매우 제한된 권한(600)으로 보호하고 누구에게도 드러내지 말라는 의미다. 여기에 대응하는 공개 키는 다음과 같다. —–BEGIN PUBLIC KEY—– MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik 6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5 e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg NQIDAQAB —–END PUBLIC KEY—– CSRCertificate Signing Request은 다음과 같다. —–BEGIN CERTIFICATE REQUEST—– MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG 9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3 OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2 tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+ ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ aQY= —–END CERTIFICATE REQUEST—– 이 특정 CSR은 서버의 공개 키와 영국 런던을 기반으로 하는 기업 ACME에 관한 자세한 정보, 도메인 이름 example.com를 포함한다. 마지막으로 서명된 HTTPS 인증서는 다음과 같다. —–BEGIN CERTIFICATE—– MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8 dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS 7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat 5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi mNU= —–END CERTIFICATE—– 모든 부분은 연결되어 있으며 서로 일치해야 한다. 마지막 인증서는 설명 목적으로만 생성한 것이다. 공인된 인증 기관에서 서명하지 않았기 때문에 자체 서명 인증서라고 한다. 다음은 cPanel과 리눅스, FreeBSD, 윈도우에서 설정 단계를 설명한다. 이는 모든 종류의 인증서에 유효한 범용 절차다. 무료 DV 인증서를 얻고 싶다면 아래 나오는 Let’s Encrypt와 Cloudflare 부분에서 따라야 하는 절차에 대해 설명할 것이다. 1단계: 개인 키와 CSR 만들기 다음 예제에서 호환성을 위해 2048비트 RSA 인증서를 사용한다. 서버 공급 업체에서 이를 지원한다면(예: 헤로쿠나 AWS를 사용하지 않는 경우) ECC를 사용하는 편이 좋다. CPANEL 1. 호스트의 cPanel에 로그인한다. 2. 아래로 스크롤해서 ‘Security’을 찾고 ‘SSL/TLS’를 클릭한다.
cPanel ‘Security’ 섹션 (이미지 확대) 3. 이제 ‘SSL/TLS Manager’ 홈으로 넘어왔다. ‘Private Keys(KEY)’를 클릭해 새로운 개인 키를 만든다.
cPanel ‘SSL/TLS Manager’ (이미지 확대) 4. 페이지를 ‘Generate, Paste or Upload a new Private Key’로 리디렉션한다. ‘Key Size’ 드롭다운 메뉴에서 ‘2048-bit’를 선택하고 ‘Generate’를 클릭한다.
cPanel ‘Private Key’ 관리 (이미지 확대) 5. 새 개인 키가 생성되고 확인 화면이 나타난다.
cPanel 개인 키 확인 (이미지 확대) 6. ‘Private Keys’ 홈으로 다시 돌아가면 새로운 키 목록을 보게 된다.
새로 생성된 키가 있는 cPanel ‘Private Keys’ (이미지 확대) 7. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificate Signing Requests(CSR)’를 클릭해 새로운 인증서 요청을 만든다.
cPanel ‘SSL/TLS Manager’ (이미지 확대) 8. 이제 ‘Generate New Certificate Signing Request’ 양식이 표시된다. 이전에 만든 개인 키를 선택하고 필드를 채운다. 모든 질문에 알맞은 답을 적고(서명된 인증서에 공개), HTTPS 인증서를 요청하는 도메인 이름과 정확히 일치해야 하는 ‘Domains’ 섹션에 특별히 주의한다. 최상위 수준 도메인만(example.com) 포함한다(CA는 보통 www 하위 도메인(예: http://www.example.com) 역시 추가한다). 작업을 마치고 나면 ‘Generate’ 버튼을 클릭한다.
cPanel ‘Generate New Certificate Signing Request’ 양식 (이미지 확대) 9. 새로운 CSR이 생성되고 확인 화면이 표시된다.
cPanel CSR 확인 (이미지 확대) 10. ‘Certificate Signing Request’ 홈으로 돌아가면 새로운 CSR 목록이 보인다.
생성된 새로운 CSR이 있는 cPanel ‘Certificate Signing Request’ (이미지 확대) 리눅스, FREEBSD OpenSSL이 설치되었는지 다음 명령을 사용해 확인한다. openssl version 아직 설치되지 않았다면 명령줄을 열고 해당 플랫폼에 대한 OpenSSL을 설치한다. • 데비안, 우분투 및 클론 sudo apt-get install openssl • 레드햇, CentOS 및 클론 sudo yum install openssl • FreeBSD make -C /usr/ports/security/openssl install clean 그 다음 다음 명령으로 개인 키와 CSR을 생성한다. openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr 개인 키가 생성되고 CSR에 대한 몇 가지 질문을 요청받는다. Generating a 2048 bit RSA private key ……………………+++ ……………………………………………………….+++ writing new private key to ‘example.com.key’ —– You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ‘.’, the field will be left blank. 모든 질문에 알맞은 답을 제공하고(서명된 인증서에 공개), HTTPS 인증서를 요청하는 도메인 이름과 정확히 일치해야 하는 ‘Common Name’ 섹션에 특별히 주의한다. 최상위 수준 도메인만(example.com) 포함한다. CA는 보통 www 하위 도메인(예: http://www.example.com) 역시 추가한다. Country Name (2 letter code) [AU]:GB State or Province Name (full name) [Some-State]:London Locality Name (eg, city) []:London Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc. Organizational Unit Name (eg, section) []:IT Common Name (e.g. server FQDN or YOUR name) []:example.com Email Address []:admin@example.com Please enter the following ‘extra’ attributes to be sent with your certificate request A challenge password []: An optional company name []:
윈도우의 IIS(INTERNET INFORMATION SERVER) 1. 시작 → 관리 도구 → IIS(인터넷 정보 서비스) 관리자를 실행하고 서버 이름을 클릭한다. 가운데 열에서 ‘Server Certificates’를 더블 클릭한다.
오른쪽 열에서 ‘Create Certificate Request’ 클릭 (이미지 확대) 3. 도메인 이름과 일치해야 하는 ‘Common Name’에 주의하면서 조직의 세부 내용을 입력하고 ‘Next’를 클릭한다.
조직의 세부 내용 입력 창 (이미지 확대) 4. ‘Cryptographic Service Provider’에서는 기본값을 사용하고, ‘Bit length’를 2048로 설정한다.
‘Bit length’를 2048로 설정 (이미지 확대) 5. 생성된 CSR을 저장할 위치를 지정하고 ‘Finish’를 클릭한다.
생성된 CSR을 저장할 위치 지정 후 ‘Finish’ 클릭 (이미지 확대) 2단계: HTTPS 인증서 얻기 웹사이트 인증서를 얻기 위해 먼저 HTTPS 인증서 공급 업체로부터 HTTPS 인증서 크레딧(DV, OV, EV, 단일 사이트, 멀티 사이트, 와일드 카드)을 구매한다. 인증서 크레딧 구매 뒤 선택한 도메인에 구매한 크레딧을 쓸 인증서 서명 요청을 해야 한다. BEGIN CERTIFICATE REQUEST와 END CERTIFICATE REQUEST를 포함해 전체 CSR 텍스트 제공(필드에 붙여 넣기 하거나 업로드)을 요청받는다. EV나 OV 인증서를 받고 싶다면 인증서 요청자의 법적 신원을 제공해야 한다. 또한 확인을 위해 회사와 관련된 추가 문서를 제출해야 한다. 인증서 등록 기관은 요청(그리고 모든 지원 문서)을 검증한 다음 서명된 HTTPS 인증서를 발행한다. HTTPS 인증서 얻기 호스팅 공급 업체나 HTTPS 등록 기관에 따라 제품과 등록 절차가 다를 수 있으나 일반적으로 비슷한 방식이다. 1. HTTPS 인증서 공급 업체를 찾는다. 2. 인증서 유형(DV, OV, EV, 단일 사이트, 멀티 사이트, 와일드 카드)을 선택하고 ‘Add to cart’를 클릭한다. 선호하는 지급 방법을 지정하고 지불을 완료한다. 3. 도메인에 새로운 HTTPS 인증서를 활성화한다. 인증서 서명 요청을 붙여 넣거나 업로드할 수 있다. 시스템은 CSR에서 인증서 세부 사항을 뽑아낸다. 4. ‘Domain Control Validation’이라는 방식을 선택하라는 요청을 받는다. 이메일이나 HTML 파일(HTTP 기반) 업로드, 도메인 영역 파일(DNS 기반)에 TXT 레코드를 추가를 통해 수행한다. 5. 검증이 완료되고 HTTPS 인증서가 발행될 때까지 잠깐 기다린다. 서명된 HTTPS 인증서를 다운로드한다. 자체 서명 인증서 인증 기관을 통하지 않고 스스로 인증서를 서명할 수도 있다. 이 인증서는 다른 인증서만큼이나 암호화 방법으로 우수하기 때문에 테스트 목적으로는 좋으나, 브라우저에서는 신뢰하지 않으므로 보안 경고를 표시한다. 어떤 것이라도 클레임이 포함할 수 있지만 제 3의 당사자의 검증은 통과하지 못한다. 사용자가 해당 웹사이트를 신뢰한다면 인증서를 저장하고 향후 방문에서 신뢰하도록 브라우저에서 예외를 추가할 수 있다. 앞의 예제 인증서는 자체 서명된 인증서다. example.com 도메인용으로 사용할 수 있으며 유효기간 내에서 잘 동작한다. OpenSSL을 사용할 수 있는 모든 플랫폼에서 자체 서명 인증서를 만들 수 있다. openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt 자체 서명 인증서를 사용할 수 있다면 서버에 이 인증서를 설치해야 한다. 같은 공급 업체의 호스팅과 HTTPS 등록 서비스를 사용하고 있다면(많은 호스팅 공급 업체가 HTTPS 인증서를 판매한다), 웹사이트용으로 새로 구매한 HTTPS 인증서를 설치하고 활성화하는 자동화된 절차가 있을 것이다. 다른 곳에서 호스팅 중 이라면 인증서를 다운로드하고 인증서를 사용할 수 있도록 서버를 구성해야 한다. 3단계: 웹사이트에 HTTPS 인증서 설치하기 CPANEL 1. ‘SSL/TLS Manager’ 홈으로 다시 돌아간다. ‘Certificates(CRT)’를 클릭해서 새로운 인증서를 가져온다.
cPanel ‘SSL/TLS Manager’ (이미지 확대) 2. HTTPS 등록 기관에서 받은 인증서 파일의 내용을 붙여 넣기 하거나 ‘Browse’ 버튼을 사용해 인증서를 업로드한다.
cPanel의 새로운 HTTPS 인증서 가져오기 (이미지 확대) 3. HTTPS 인증서 내용을 붙여 넣을 때 내용이 분석되며, 확인을 위한 평문 값이 표시된다. 내용을 검토하고 ‘Save Certificate’ 버튼을 클릭한다.
cPanel의 HTTPS 인증서 검토와 확인 (이미지 확대) 4. 새로운 HTTPS 인증서를 저장하면 다음과 같은 확인 화면이 나타난다.
cPanel HTTPS 인증서 확인 (이미지 확대) 5. ‘Certificates(CRT)’ 홈으로 다시 돌아가면, 새로운 HTTPS 인증서 목록이 표시된다.
새로운 HTTPS 인증서 목록이 있는 cPanel (이미지 확대) 6. ‘SSL/TLS Manager’ 홈으로 돌아간다. ‘Install and Manage SSL for your website(HTTPS)’를 클릭해 기존 웹사이트에 새로운 인증서를 할당한다.
cPanel ‘SSL/TLS Manager’ (이미지 확대) 7. ‘Install an SSL Website’ 양식이 표시된다. ‘Browse Certificates’ 버튼을 클릭하고 HTTPS 인증서를 선택한다. 드롭다운 메뉴에서 웹사이트 도메인을 선택하고 ‘Certificate’와 ‘Private Key’ 필드가 채워졌는지 확인한다.
cPanel ‘Install an SSL Website’ (이미지 확대) https://www.example.com으로 액세스할 수 있는지 확인한다. 웹사이트가 잘 동작하면 영구적으로 HTTP 트래픽을 HTTPS로 리디렉션하고 싶을 것이다. 그렇게 하려면 웹사이트 루트 폴더의 .htaccess 파일(아파치 웹 서버의 경우)에 몇 줄의 코드를 넣어야 한다. RewriteEngine On
RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] .htaccess 파일이 이미 존재한다면 기존 RewriteEngine On 지시문 바로 다음 RewriteCond와 RewriteRule 줄만 붙여 넣는다. 리눅스, FREEBSD 생성한 개인 키(example.com.key)와 인증서 서명 요청(example.com.csr), 유효한 HTTPS 인증서(example.com.crt)를 적절한 위치에 넣는다. • 데비안, 우분투 및 클론, FreeBSD cp example.com.crt /etc/ssl/certs/cp example.com.key /etc/ssl/private/cp example.com.csr /etc/ssl/private/ • 레드햇, CentOS 및 클론 cp example.com.crt /etc/pki/tls/certs/cp example.com.key /etc/pki/tls/private/cp example.com.csr /etc/pki/tls/private/restorecon -RvF /etc/pki0 파일은 루트가 소유해야 하며 600이라는 퍼미션 설정으로 보호해야 한다. • 데비안, 우분투 및 클론 chown -R root. /etc/ssl/certs /etc/ssl/privatechmod -R 0600 /etc/ssl/certs /etc/ssl/private • 레드햇, CentOS 및 클론 chown -R root. /etc/pki/tls/certs /etc/pki/tls/privatechmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private • FreeBSD chown -R root:wheel /etc/ssl/certs /etc/ssl/privatechmod -R 0600 /etc/ssl/certs /etc/ssl/private 아파치 웹사이트의 HTTPS 버전을 활성화하는 절차는 다음과 같다. • mod_ssl이 서버에 설치되었는지 확인한다. • 획득한 HTTPS 인증서(.crt) 파일을 서버로 업로드한다. • 아파치 서버 구성 파일을 편집한다. mod_ssl을 확인하는 것으로 시작한다. 운영체제에 따라 다음 구문 중 하나가 동작해야 한다. apache2 -M | grep ssl or httpd -M | grep ssl mod_ssl이 설치됐으면 다음과 같은 결과가 표시된다. ssl_module (shared) Syntax OK 약간 다른 유사한 결과가 나올 수도 있다. mod_ssl이 없거나 활성화되지 않는 경우 운영체제에 따라 다음 작업을 시도해본다. • 데비안, 우분투 및 클론 sudo a2enmod sslsudo service apache2 restart • 레드햇, CentOS 및 클론 sudo yum install mod_sslsudo service httpd restart • FreeBSD (SSL 옵션 선택) make -C /usr/ports/www/apache24 config install cleanapachectl restart 아파치 구성 파일을 편집한다(httpd.conf). • 데비안, 우분투 /etc/apache2/apache2.conf • 레드햇, CentOS /etc/httpd/conf/httpd.conf • FreeBSD /usr/local/etc/apache2x/httpd.conf Listen 80 Listen 443
프록시(Proxy)란 보통 대리인을 뜻하는 영어 단어이다. 일반적으로 브라우저로 웹서핑을 하면 브라우저를 실행하고 있는 컴퓨터와 서버 컴퓨터간의 1 대 1 직접 연결이 이뤄진다. 프록시는 우선 그러한 1 대 1 접속이 이뤄질 수 없는 환경에서 또는 1 대 1 접속을 허용해서는 안되는 환경에서 유용하게 쓰인다. 주로 방화벽 장비에 프록시 서버를 설치하고, 방화벽 뒤에 있는 PC가 프록시를 경유해 웹서핑 또는 FTP 다운로드를 받는다. 여기서 프록시는 그야말로 대리인이다. PC의 브라우저가 보내는 요청을 받아 서버에게 전달하고, 서버에서 받는 내용을 다시 브라우저에도 보내준다.
현재 대두분의 회사나 관공서의 경우 대역폭의 절감과 보안강화 그리고 웹서핑 속도를 높이기 위한 노력을 끊임없이 하고 있다. 이런 기능이 구현된 몇몇 프록시 서버 프로그램이 시장에 선보였는데 이 프로그램들은 몇 가지 문제점을 가지고 있었다. 첫 번째는 오픈소스가 아니라는 점이고 두 번째는 ICP를 지원하지 않는다는 것이다. ICP는 이웃하는 캐시에 특정요청 정보가 존재하는지 정보를 교환하는데 사용되며 인접해 있는 다른 캐시서버에 먼저 저장돼 있는 캐시정보를 전송받아 사용할 수 있도록 하는 것이다.
그러나 이러한 것을 Squid는 두 가지 모두를 충족해주고 오히려 그 이상의 효과를 기대할 수 있게 해주었다. 또한 프록시의 부가적인 이익이로는 대역폭을 경제적으로 사용할 수 있게 해 준다는 것이다. 프록시는 최근 사람들이 공통적으로 방문한 사이트를 디렉토리에 저장해 두었다가 같은 URL에 대한 요청이 들어오면 서버에 연결하지 않고도 디렉토리에서 읽어 즉시 브라우저에게 보내준다.
여기서는 웹서버 성능의 최적화를 위해 두 가지 다른 방법으로 Squid 서버를 설치하고 설정하는 방법에 대해 알아본다.
첫 번째 웹서버 성능을 극대화하고 httpd 가속서버로 구성하는 것이다. Squid가 가속서버로 동작할 때 상당한 효과를 얻을 수 있다.
두 번째는 일반적인 프록시 캐싱서버로 구성하는 것이다. 이렇게 구성함으로써 회사 또는 조직내의 모든 사용자들로 하여금 Squid를 통해서만 인터넷에 접근하도록 할 수 있다. 이것은 상당한 보안효과와 시스템 자체의 속도를 향상 시킬 수 있다. 또한 Suqid 자체 설정을 통해 인터넷의 접속제한 여부를 설정할 수도 있다. 이렇게 구성함으로써 유해사이트도 간단히 접근제어할 수 있는 것이다.
Squid에서의 보안과 최적화는 일단 다른 응용프로그램의 더 이상 추가가 필요없다는 점이다. 기본 설치된 프로그램만으로도 효율적으로 보안을 강화시킬 수 있고 Squid 자체의 최적화도 가능하다.
1. Squid 캐시 디렉토리 마운트 제어
Squid의 캐시정보가 기록되는 디렉토리를 설정함으로써 한층 강화된 보안성능을 구현할 수 있다. 시스템 내에서 어떠한 바이너리도 실행할 수 없고, 문자나 특별한 블록장치를 인식하지 않기 위해서 다음과 같이 설정한다. 여기서는 /var/spool 이라는 파티션이 기존에 정의되있는 것으로 가정하였다.
보안적인 측면을 더욱 강화하기 위해서 Squid의 설정 파일을 불변설정한다. 아래와 같이 한다면 관리자가 직접 해제하지 않는 이상 파일의 수정, 추가가 불가능하다.
#chattr +i /etc/squid/squid.conf
만약 수정, 추가가 필요할때는 -i 옵션을 사용하면 된다.
Squid의 성능을 강화하고 최적화하는 방법으로 가장 중요한 부분이 메모리이다. Squid 자체는 CPU보다는 메모리 자원에 의존한다. 그러므로 가능한 충분한 메모리를 확보하도록 한다. 또한 Squid가 사용하는 캐시의 읽고 쓰는 속도를 향상하기 위해 IDE보다는 스카시 하드디스크를 사용하는 것이 좋다.
다음 단계는 Squid 서버를 용도에 맞게 설정하는 일이다. Squid의 설정 파일은 /etc/squid/squid.conf에 위치하게 된다. squid.conf 파일을 어느 정도 용도에 맞게 설정하느냐에 따라 성능향상의 폭을 높일 수 있다. 처음으로 웹 가속모드를 설정하고 그 다음은 프로시 캐싱모드로 작동하도록 설정하겠다.
먼저 squid.conf는 앞서 언급한 Squid의 주 설정 파일이다. 파일의 내용을 자세히 보면 알겠지만 상당히 많은 옵션이 제공되고 있으나 실제로는 주요 몇 개의 옵션만 수정하면 된다. 또한 자세한 설명으로 별로 어렵지 않게 응용할 수도 있다. squid.conf 파일의 주요 내용은 다음과 같다.
http_port 80
icp_port 0
cache_mem 8 MB
cache_dir ufs /var/spool 100 16 256
emulate_httpd_log on
acl all src 0.0.0.0/0.0.0.0
http_access allow localhost
httpd_accel_host 201.111.132.32
httpd_accel_port 80
buffered_logs on
옵션별로 자세히 설명을 하자면,
http_port 80
'http_port' 80 옵션은 HTTP 클라이언트가 요청했을 경우 Squid가 응답할 소켓 주소이다. 디폴트 포트는 3128이고 만약가속모드로 동작하는 Squid의 경우는 80번 포트를 사용해야 한다.
icp_port 0
'icp_port'는 Squid가 ICP 쿼리를 인접하는 캐시로부터 주고 받을 포트를 정의한다. 디폴트는 3103이며 사용하지 않을 경우는 0으로 설정한다. Squid 웹 가속모드로 사용할 경우에는 0으로 해 사용하지 않는 상태로 설정한다.이유는 Squid가 웹 가속모드로 작동할 경우 ICP를 사용하면 그 만큼 Squid에 불필요한 자원을 낭비하기 때문이다.
cache_mem 8 MB
'cache_mem'옵션은 In-Transit objects, hot Objects, Negative-Cached objects을 캐싱하기 위해 지원되는 메모리를 지정하는 옵션이다. 기본은 8MB이다.
cache_dir ufs /var/spool 100 16 256
'cache_dir ufs /var/spool/squid 100 16 256'은 Squid가 사용할 캐시 디렉토리 정의와 디스크용량, 디렉토리 수를 정의한다. 기본적으로 /var/spool 디렉토리를 사용하지만 디스크 용량이 여의치 않다면 특정 디렉토리로 변경 사용할 수 있다. 그 다음에 열거되는 수는 첫 번째, 앞에서 정의한 디렉토리의 용량을 설정한다. 따라서 /var/spool 디렉토리가 사용할 디스크용량은 100MB이다. 16과 256은 각각 캐시 디렉토리에서 생성할 하위 디렉토리 수 16과 첫 번째 하위 디렉토리에서 생성될 두 번째 하위 디렉토리 수 256이다.
emulate_httpd_log on
'emulate_httpd_log on'옵션은 Squid 자체가 많은 'httpd' 프로그램이 사용하는 로그포맷에 따라 로그를 남기도록 하는 설정이다. 따라서 Squid 자체도 별도의 웹로그 분석 툴로 로그 분석 보고서를 만들 수 있다.
acl all src 0.0.0.0/0.0.0.0
http_access allow
위의 두 옵션은 Squid 서버에 접근제어 설정에 사용하는 옵션이다. 현재는 웹 가속모드로 설정하기 때문에 따른 접근제한을 두지 않았다. 물론 다른 목적으로 Squid 서버를 구성할 때에는 이옵션을 적절히 제한해야만 한다.
httpd_accel_host 201.111.132.32
httpd_accel_port 80
'httpd_accel_host'는 실제 웹서버의 가속을 위하여 사용된다. 201.111.132.32로 Squid 서버가 웹가속 해주게 된다. 'httpd_accel_port 80'은 설명할 필요 없이 해당 포트를 정의한 것이다.
buffered_logs on
실제로 중요한 작동을 하는 옵션은 아니다. 로그 기록시 사용되는 시스템 자원을 절약함으로써 약간의 속도 향상을 기대할 수 있는 옵션이다.
프록시 캐싱모드로 Squid 설정
프록시 캐싱모드는 앞서 말한 웹 가속모드와는 완전히 다른 개념이다. Squid를 프록시 캐싱모드로 사용한다면 해당 네트워크의 모든 가입자가 Squid를 통해야만 인터넷 및 다른 네트워크로 접근할 수 있는 것이다. 또한 별도의 설정으로 내부 사용자들의 사이트 방문지나 연결시간 등을 제어할 수 있다.
앞서 설정한 웹 가속모드와 비슷하게 squid.conf를 수정하면 된다. 다만 접근제어 옵션부분만 자신의 네트워크 상황에 맞게 수정하면 된다. 프록시 캐싱모드에서는 접근제어목록(ACL)을 사용한다. 이 옵션으로 원본주소, 목적지주소, 원본도메인, 목적지도메인, 시간등을 제한 설정할 수 있고 자세한 내용은 squid.conf의 내용을 참조바란다.
Squid is a proxy/cache application with a variety of configurations and uses. This guide will cover using Squid as an HTTP proxy. Please note that unless you follow the last section of the guideAnonymizing Traffic, this will not anonymize your traffic to the outside world, as your originating IP address will still be sent in the X-Forwarded-For header. Additionally, the traffic is not encrypted and will still be visible on your local network. If you are looking for a solution that offers greater security, you may want to look at our guide to Setting up an SSH Tunnel or Deploy VPN Services with OpenVPN.
This guide is written for a non-root user. Commands that require elevated privileges are prefixed with sudo. If you’re not familiar with the sudo command, you can check our Users and Groups guide.
Installing Squid
Squid is available in the CentOS repositories. To ensure your system is up-to-date and install Squid run the following commands:
1 2
sudo yum update sudo yum install squid
Copy the original configuration file to keep as a backup:
Squid Proxy can be used as an HTTP proxy to bypass local network restrictions, or mask your true location to the world.
Basic Setup
This section covers the easiest way to use Squid as an HTTP proxy, using only the client IP address for authentication.
Edit the Squid configuration file and add the following lines: /etc/squid/squid.conf
1
acl client src 12.34.56.78 # Home IP http\_access allow client
Be sure to replace client with a name identifying the connecting computer, and 12.34.56.78 with your local IP address. The comment # Home IP isn’t required, but comments can be used to help identify clients.
Once you’ve saved and exited the file, start Squid:
1
sudo service squid restart
At this point you can configure your local browser or operating system’s network settings to use your Linode as an HTTP proxy. How to do this will depend on your choice of OS and browser. Once you’ve made the change to your settings, test the connection by pointing your browser at a website that tells you your IP address, such as ifconfig, What is my IP, or by Googling What is my ip.
Additional clients can be defined by adding new acl lines to /etc/squid/squid.conf. Access to the proxy is granted by adding the name defined by each acl to the http_access allow line.
Advanced Authentication
The following configuration allows for authenticated access to the Squid proxy service using usernames and passwords.
You will need the htpasswd utility. If you’ve installed Apache on your Linode, you will already have it. Otherwise run:
1
sudo yum install httpd-tools
Create a file to store Squid users and passwords, and change ownership:
Once you’ve saved and exited the file, restart Squid:
1
sudo service squid restart
At this point, you can configure your local browser or operating system’s network settings to use your Linode as an HTTP proxy. You will need to specify that the server requires authentication, and provide the username and password. How to do this will depend on your choice of OS and browser. Once you’ve made the settings change, test the connection by pointing your browser at a website that tells you your IP address, such as ifconfig, What is my IP, or by Googling What is my ip.
To remove a user’s access to the proxy, you must delete their entry in the squid_passwd file. Each user is represented in the file on a single line in the format of user:passwordhash : /etc/squid/squid_passwd
1
user1:gh48gfno user2:9b83v5hd
If you are using Nano, the command Control+k will remove the entire line where the cursor rests. Once you’ve saved and exited the file, restart Squid:
1
sudo service squid restart
Anonymizing Traffic
In order to mask your IP address from servers you connect to, you will need to add the following lines to the Squid configuration file.
forwarded_for off request_header_access Allow allow all request_header_access Authorization allow all request_header_access WWW-Authenticate allow all request_header_access Proxy-Authorization allow all request_header_access Proxy-Authenticate allow all request_header_access Cache-Control allow all request_header_access Content-Encoding allow all request_header_access Content-Length allow all request_header_access Content-Type allow all request_header_access Date allow all request_header_access Expires allow all request_header_access Host allow all request_header_access If-Modified-Since allow all request_header_access Last-Modified allow all request_header_access Location allow all request_header_access Pragma allow all request_header_access Accept allow all request_header_access Accept-Charset allow all request_header_access Accept-Encoding allow all request_header_access Accept-Language allow all request_header_access Content-Language allow all request_header_access Mime-Version allow all request_header_access Retry-After allow all request_header_access Title allow all request_header_access Connection allow all request_header_access Proxy-Connection allow all request_header_access User-Agent allow all request_header_access Cookie allow all request_header_access All deny all
Once you’ve saved and exited the file, restart Squid:
1
sudo service squid restart
More Information
You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.
Squid is a proxy server for caching and filtering web content . Squid proxy is used by various organisation and internet providers to reduce bandwidth and to increase response time .
Squid proxy service will cache the requested web-content and re-using it for the further request of the same content .
In the above diagram, squid proxy will cache the webcontent of krizna.com from the ISP during the first request and it will deliver the cached content for the further requests of krizna.com without requesting from ISP. This will reduce bandwidth and will increase response time as the content is delivered from the local network.
Update yum repositories and packages by typing the below command
[root@leela ~]# yum update
Step 1 » Install squid package and dependencies using the below command
[root@leela ~]# yum install squid
» By default squid configuration file “/etc/squid/squid.conf” will contains recommended minimum configuration and squid caching feature will work without making any changes . Recommended minimum configuration will looks like the below
# Example rule allowing access from your local networks. # Adapt to list your (internal) IP networks from where browsing # should be allowed acl localnet src 10.0.0.0/8# RFC1918 possible internal network acl localnet src 172.16.0.0/12# RFC1918 possible internal network acl localnet src 192.168.0.0/16 # RFC1918 possible internal network acl localnet src fc00::/7# RFC 4193 local private network range acl localnet src fe80::/10# RFC 4291 link-local (directly plugged) machines
acl SSL_ports port 443 acl Safe_ports port 80# http acl Safe_ports port 21# ftp acl Safe_ports port 443# https acl Safe_ports port 70# gopher acl Safe_ports port 210# wais acl Safe_ports port 1025-65535# unregistered ports acl Safe_ports port 280# http-mgmt acl Safe_ports port 488# gss-http acl Safe_ports port 591# filemaker acl Safe_ports port 777# multiling http acl CONNECT method CONNECT
# Deny requests to certain unsafe ports http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports http_access deny CONNECT !SSL_ports
# We strongly recommend the following be uncommented to protect innocent # web applications running on the proxy server who think the only # one who can access services on "localhost" is a local user #http_access deny to_localhost
# # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed http_access allow localnet http_access allow localhost
# And finally deny all other access to this proxy http_access deny all
# Squid normally listens to port 3128 http_port 3128
# We recommend you to use at least the following line. hierarchy_stoplist cgi-bin ?
# Uncomment and adjust the following to add a disk cache directory. #cache_dir ufs /var/spool/squid 100 16 256
# Leave coredumps in the first cache dir coredump_dir /var/spool/squid
# Add any of your own refresh_pattern entries above these. refresh_pattern ^ftp:144020%10080 refresh_pattern ^gopher:14400%1440 refresh_pattern -i (/cgi-bin/|\?) 00%0 refresh_pattern .020%4320
Step 2» Now start squid service
[root@leela ~]# service squid start
and type this below command to start squid service automatically while booting.
[root@leela ~]# chkconfig --levels 235 squid on
Step 3 » Setup your web browser to access Internet through proxy server on port 3128 .
IE : Tools » Internet options »Connections » LAN settings » Choose “Use a proxy server for your LAN”» Type your Proxy server ip (192.168.1.11 ) and port no 3128
Firefox : Options / Preferences » Advanced » Network » Settings » Choose “Manual proxy configuration ”» Type your Proxy server ip (192.168.1.11 ) and port no 3128
Step 4 » Browse some sites and check the access log file on proxy server
and add the following line “http_access deny blockip” to http_section to deny the access to the acl “blockip” .
1 2 3 4 5 6 7 8 9 10
# Recommended minimum Access Permission configuration: # # Only allow cachemgr access from localhost http_access allow manager localhost # Deny access to blockip ACL http_access deny blockip # Deny access to blocksites ACL http_access deny blocksites # Deny access to blockkeywords ACL http_access deny blockkeywords
» Allow Full access to specific Ipaddress :
You can allow specific ip address to gain full access without blocking sites and keywords . just create a file “/etc/squid/allowip.squid ” and add the ip address one per line and create an acl “allowip” and acl type “src” in the acl section
#!/bin/sh # squid server IP SQUID_SERVER="192.168.1.11" # Interface connected to Internet INTERNET="eth0" # Interface connected to LAN LAN_IN="eth1" # Squid port SQUID_PORT="3128" # DO NOT MODIFY BELOW # Clean old firewall iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X # Load IPTABLES modules for NAT and IP conntrack support modprobe ip_conntrack modprobe ip_conntrack_ftp # For win xp ftp client #modprobe ip_nat_ftp echo 1 > /proc/sys/net/ipv4/ip_forward # Setting default filter policy iptables -P INPUT DROP iptables -P OUTPUT ACCEPT # Unlimited access to loop back iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT # Allow UDP, DNS and Passive FTP iptables -A INPUT -i $INTERNET -m state --state ESTABLISHED,RELATED -j ACCEPT # set this system as a router for Rest of LAN iptables --table nat --append POSTROUTING --out-interface $INTERNET -j MASQUERADE iptables --append FORWARD --in-interface $LAN_IN -j ACCEPT # unlimited access to LAN iptables -A INPUT -i $LAN_IN -j ACCEPT iptables -A OUTPUT -o $LAN_IN -j ACCEPT # DNAT port 80 request comming from LAN systems to squid 3128 ($SQUID_PORT) aka transparent proxy iptables -t nat -A PREROUTING -i $LAN_IN -p tcp --dport 80 -j DNAT --to $SQUID_SERVER:$SQUID_PORT # if it is same system iptables -t nat -A PREROUTING -i $INTERNET -p tcp --dport 80 -j REDIRECT --to-port $SQUID_PORT # DROP everything and Log it iptables -A INPUT -j LOG iptables -A INPUT -j DROP
Step 3 » just run the script
[root@leela ~]# sh /root/squidfw.sh
and add the below line to “/etc/rc.local” to run the script during startup
sh /root/squidfw.sh
Step 4 (Updated) » Change default gateway ip to squid server ip on the user machines .
Now users can access Internet without setting proxy in the browser settings.
That’s it , hope this article will help you to learn little things about configuring squid proxy on centos 6.
1. Proxy 서버에 대하여 Proxy는 자신을 통해서 다른 네트워크에 간접적으로 접속할 수 있도록 해주는 컴퓨터 혹은 프로그램을 가리킨다. 요청을 중계하는 일을 하는 컴퓨터 혹은 프로그램으로 이해하면 된다. 이때 중계하는 프로그램을 proxy 프로그램이라고 한다. proxy 프로그램은 서버로서 작동하기 때문에 일반적으로 proxy 서버라고 한다.
proxy는 중계 목적, 중계 위치, 중계 방법에 따라서 다양한 종류가 있다. proxy 서버를 구축하는 이유는 다음과 같다. 1. 보안 : 익명의 사용자가 서버에 직접 접근하는 것을 막는다. 2. 속도 : proxy 서버는 사용자의 요청을 cache 해서, 동일한 요청이 들어오면 cache의 자원을 반환한다. 이는 서비스의 속도를 높여준다. 3. ACL : 사이트 접근에 대한 접근 정책을 정의할 수 있다. 4. Log/Audit : 회사내 직원의 인터넷 사용을 레포팅 할 수 있다. 반대로 인트라넷의 사용을 레포팅할 수도 있다. 5. 지역 네트워크의 제한을 우회하기 위해서 : 보안상의 이유로 80번 외에는 포트를 막아 놓는 경우가 있는데, 이러한 제한을 우회해서 원하는 다른 서비스를 이용할 수 있다.
2. Proxy 종류 2.1 Forward Proxy 일반적으로 사용하는 프록시 방식이다. 프록시 서버는 클라이언트와 애플리케이션 서버 사이에 위치한다. 클라이언트가 타겟 서버인 애플리케이션에 서비스를 요청할 때, 프록시 서버로 요청을 보낸다. 그러면 프록시 서버가 타겟 서버로 요청을 중계한다.
2.2 Reverse Proxy Reverse라는 용어 때문에 헛갈릴 수 있다. 기본적인 구성은 Forward Proxy와 동일하지만, 클라이언트는 Proxy Server 배후에 있는타겟 서버의 URL(:12)이 아닌 Proxy Server의 URL로 요청한다.
Desktop PC는 배후에 있는 mail.a.com 이 아닌 Proxy Server의 URL인 http://www.abc.com을 요청한다. 요청을 받은 Proxy Server는 URI에 맵핑된 애플리케이션 서버로 중계를 한다. 그러므로 애플리케이션 서버는 외부로 부터 감추어지게 되는 효과를 얻게 된다. 애플리케이션 서버의 정보가 외부로 부터 감추어진 다는 이점외에, 분산 처리 시스템을 만들 수 있다는 장점도 있다. Proxy Server이 요청을 분산하는 역할을 할 수 있기 때문이다. 2.3 Open Proxy Open Proxy는 모든 인터넷 사용자가 액세스할 수 있는 프록시 서버다. 수백에서 수천정도의 오픈 프록시가 익명으로 운영되고 있는 것으로 알려져 있다. 오픈 프락시를 이용하면 자신의 IP를 숨길 수 있다. 중국같은 나라는 정치적인 이유로 외부 사이트 접근을 막는 경우가 있는데, 공개 프록시를 이용하면 접근할 수 있다.
3. 공개 소프트웨어를 이용한 proxy server 구축 위에 언급한 3가지 종류의 proxy server를 모두 구축해봐야 겠다. 구축 후 활용법에 대해서 고민을 해봐야지. AWS VPC 환경에서 테스트하기로 했다. 3.1 HAproxy를 이용한 Reverse proxy server 구축 흔히 볼 수 있는 프락시 서버 형태는 Reverse proxy server이다. Reverse proxy server를 이용해서 로드밸런서를 구현할 수 있기 때문이다. 클라이언트가 reverse proxy server로 요청을 보내면 proxy server는 이 요청을 내부에 있는 실제 서비스 서버에 요청을 전달한다. Proxy server에는 두 개 이상의 서비스 서버가 붙을 수 있으므로 결과적으로 요청을 분산해서 처리하는 효과를 얻을 수 있다. Haproxy를 이용하는 주된 목적이 reverse proxy server 타입으로 작동하게 함으로써, 로드밸런싱 기능을 구현하는 것이기도 하다. 다음과 같은 환경을 구축하기로 했다.
1. Haproxy 서버 인스턴스를 하나 만든다. 이 인스턴스는 EIP를 가진다. 유저는 EIP를 주소로 haproxy 서버에 요청을 보낼 수 있다. 2. 두 개의 Apache 웹 서버를 만든다. 이들 웹서버는 80번 포트로 서비스한다. 3. Haproxy는 유저의 요청을 두 개의 웹 서버로 분산해서 보내는 것으로 로드밸런싱 환경을 만든다. 로드밸런싱 방식으로 roundrobin을 사용했다.
각 호스트의 주소 정보는 다음과 같다.
호스트 사설 IP 공인 IP Haproxy 10.10.101.50 11.11.11.11 apache01 10.10.102.188 apache02 10.10.102.189
Haproxy의 서버의 설정이다. 설명은 주석으로 대신했다. global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global mode http option httplog option dontlognull contimeout 5000 clitimeout 50000 srvtimeout 50000 # HTTP 에러 코드별로 에러정보를 남기도록 설정했다. errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http # 로드밸런싱할 웹 서버들의 목록 listen apache-cluster mode http balance roundrobin option httpclose option forwardfor # haproxy 서버의 bind 주소는 80번 bind *:80 # 두개의 웹 서버로 로드밸런싱한다. server apache01 10.10.102.188:80 maxconn 32 server apache02 10.10.102.189:80 maxconn 32 Haproxy 서버의 EIP로 테스트를 테스트를 하면 된다. $ wget http://11.11.11.11/ --2013-12-14 00:39:32-- http://54.249.28.65/ 접속 11.11.11.11:80... 접속됨. HTTP request sent, awaiting response... 200 OK Length: 177 [text/html] Saving to: ‘index.html’ 100%[=============================================================>] 177 --.-K/s in 0s 2013-12-14 00:39:33 (30.2 MB/s) - ‘index.html’ saved [177/177] apache01과 apache02의 로그를 보자. # tail /var/log/apache02/access.log 10.10.101.50 - - [13/Dec/2013:15:38:13 +0000] "GET / HTTP/1.1" 200 444 " # tail /var/log/apache01/access.log 10.10.101.50 - - [13/Dec/2013:15:38:09 +0000] "GET / HTTP/1.1" 200 444 "-" 모두 haproxy의 IP가 찍힌걸 확인할 수 있다. Haproxy가 HTTP 요청을 대신 전달했기 때문에, apache 로그파일에 haproxy의 IP가 찍힌건 상식적인 결과다. 접근한 클라이언트의 IP 정보는 haproxy 로그를 봐야 확인할 수 있다. 만약 웹 서버에서 클라이언트의 IP를 확인하고 싶다면 X-Forwared-For를 사용하면 되겠다.
3.2 Apache웹 서버를 이용한 Forward proxy server 구축 Forward proxy server 테스트를 위해서 다음과 같은 환경을 만들었다.
HAProxy를 설치했던 인스턴스에 apache 웹서버를 설치하고 mod_proxy를 이용해서 forward proxy 설정을 한다. VPC에 인스턴스 하나 만들어서 w3m으로 forward proxy의 작동을 테스트 하기로 했다. 3.3 Open proxy server 구축
4. Open SSH를 이용한 Proxy Server 구축 OpenSSH는 BSD기반의 SSH 서버/클라이언트 프로그램이다. 이 프로그램을 이용하면 매우 간단하게 - 그리고 별도의 비용 없이 - Proxy Server 환경을 구축할 수 있다. 저렴한 비용이라는 장점외에 Proxy Over SSL환경을 구축함으로써 강력한 데이터 보안 환경을 구축할 수 있다는 장점도 가진다. 4.1 Port forwarding Proxy Server SSH는 port forwarding를 이용해서 SSH 터널을 만들고 이 터널을 이용해서 데이터를 중계한다.
1. Application Server는 SSH 클라이언트를 이용해서 Proxy Server:8080에서 Application Server:80으로 SSH 터널을 뚫는다. 2. Home PC는 8080에서 SSH Proxy:8080으로 향하는 터널을 뚫는다. 결과적으로 Home PC:8080에서 Application server:8080까지 SSH 터널이 뚫리게 되고, 이 터널을 통해서 데이터 통신을 하게 된다. 물론 Proxy Server에는 ssh서버가 떠 있어서 이들 포트를 중계한다.
4.1.1 구축 테스트 - Linux 테스트를 할려면 최소 2대의 컴퓨터가 있어야 할 것이다. 여기에서는 virtualbox(:12)를 이용해서 가상화 환경을 만들어서 proxy 테스트를 했다. virtualbox로 실행한 컴퓨터가 애플리케이션 서버역할을 한다. 운영체제는 우분투 리눅스로 아파티 웹서버가 설치되어 있다. proxy server 역할을 하는 컴퓨터의 IP는 192.168.1.119이다. 1. ssh 클라이언트를 이용해서 ssh 터널을 생성한다. 8080 포트로 향하는 데이터를 80 포트, 즉 웹 서버로 보내겠다는 의미다. app-server # ssh -R 8080:localhost:80 yundream@192.168.56.1 hhhhh 이것으로 proxy server와 애플리케이션 서버간에 SSH 터널이 개설되었다. • Home PC와 proxy server사이에 SSH 터널을 만든다. home-pc # ssh -L 8080:localhost:8080 yundream@192.168.1.119 localhost의 8080으로 향하는 데이터를 prox server의 8080으로 보내겠다는 의미다. 이제 웹 브라우저로 테스트하면 된다. 주소는 http://localhost:8080으로 하면 된다. 원칙적으로 애플리케이션 서버는 사설망 환경이므로 서비스 접근을 할 수가 없으나, proxy server의 중계로 웹 서비스를 받는 걸 확인할 수 있을 것이다. 4.1.2 구축 테스트 - Windows 윈도에서는 공개 ssh 클라이언트인 putty를 이용해서 SSH 터널을 뚫을 수 있다. 1. proxy server의 주소는 192.168.1.119이다.
보낸 사람 Linux 2. Connection > SSH > Tunnels에서 터널을 설정한다. 1. source port는 8080 이다. 2. destination은 localhost:8080이다. 3. 보낸 사람 Linux 3. 로그인을 한다. 4. 브라우저를 이용해서 테스트 한다. 주소는 http://localhost:8080이다.
4.2 SOCKS 기반 Proxy 서버 구축 포트 포워딩 기반의 프록시 서버는 간단하게 구축할 수 있다. 하지만, 서비스 포트를 다양하게 할 수 없다는 단점이 있다. 여러 서비스를 이용하기 위해서는 서비스 개수만큼 SSH 터널을 뚫어야 한다. 하나의 SSH 터널에서 동적으로 서비스 포트를 이용할 수 있다면 어떨까. openssh는 dynamic port forwading 기능을 지원한다. 이 기능을 이용하면 클라이언트는 SOCKS proxy를 설정하는 것으로 다양한 서비스를 이용할 수 있다. ie, firefox와 같은 웹 브라우저를 이용해서 많은 네트워크 프로그램들이 SOCKS를 지원한다.
• proxy server : 8080 포트를 연다. -D 는 dynamic port forwarding 옵션이다. # ssh -D 8080 yundream@application.server • Home PC : 8080 포트로 터널을 만든다. # ssh -L 8080:localhost:8080 yundream@proxy.server 이제 Home PC에서는 socks를 이용해서 Application에 서비스를 요청할 수 있다. 이 경우 클라이언트 프로그램이 socks를 지원해야 한다. 대부분의 웹 브라우저는 socks를 지원한다. 혹은 tsocks와 같은 프로그램을 이용해서 클라이언트 설정 없이, socks 위에서 클라이언트를 실행할 수도 있다. # tsocks w3m http://192.168.56.5 # tsocks ssh yundream@192.168.56.5 4.3 장점 openssh를 이용해서 proxy 서버를 구현할 때 얻을 수 있는 장점은 다음과 같다. 1. 때때로 openssh는 가난한 자를 위한 프록시 서버라고 불려지기도 한다. 그만큼 저렴하고 간단하게 구축 할 수 있다는 의미다. 2. OpenSSL›기반의 강력한 암호화 알고리즘을 지원한다. 3. PAM 모듈을 개발해서, 자체 인증 환경을 갖출 수 있다. 4. 운영체제에 관계 없이 사용할 수 있는 서버/클라이언트가 준비되어 있다.
he dot permission is the SELinux permissions that remain after SELinux is disabled. In this article, we will explain "How to remove dot in Linux permissions".
Why is there a dot (.) at the end of permission field in Linux? Did you just encountered a dot (.) at the end of Linux permission field of file and directory, something like below? # ls -l /etc/ total 2240 drwxr-xr-x.4 root root 4096 May 7 2021 acpi -rw-r--r--.1 root root 44 Aug 16 12:47 adjtime -rw-------.1 root root 7333 Mar 21 2017 aide.conf -rw-r--r--.1 root root 1529 Apr 1 2020 aliases drwxr-xr-x.2 root root 4096 Aug 16 18:26 alternatives -rw-------.1 root root 541 Aug 9 2019 anacrontab And you are wondering what the hell is that dot(.) ? As we all are familiar with the permission field but never read anything about dot field. From info '(coreutils) ls invocation' GNU 'ls' uses a '.' character to indicate a file with an SELinux security context, but no other alternate access method. A file with any other combination of alternate access methods is marked with a '+' character. So this should give you a clear idea that dot (.) represents that the target file or directory has some SELinux security context while if you see plus (+) sign then that particular file or directory has ACL applied. ALSO READ:Learn Linux wheel group usage [With Examples]
Remove dot (.) from Linux Permission field Now that we know the meaning of dot (.) field in permission, let us learn how to remove them:
Prerequisite - Disable SELinux To remove point permissions on Linux, SELinux must be disabled first because as we just learned that the dot (.) is added due to SELinux. First, let's check the SELinux status. Run the following command in terminal: Advertisement (If SElinux Enabled) [foc@almalinux8 ~]$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 [foc@almalinux8 ~]$ getenforce Enforcing (If SElinux Disabled) [foc@almalinux8 ~]$ sestatus SELinux status: disabled[foc@almalinux8 ~]$ getenforce Disabled If SElinux is enabled, then you can disable it by changing the status in /etc/selinux/config file: [foc@almalinux8 ~]$ sudo nano /etc/selinux/config The following lines are updated in this file: SELINUX=disabled Then reboot the server to activate the changes: [foc@almalinux8 ~]$ sudo reboot Finally, you can see that the active Selinux is disable. [foc@almalinux8 ~]$ getenforce Disabled[foc@almalinux8 ~]$ sestatus SELinux status: disabled
Verify Linux Permissions field As you can see we have disabled SELinux but still the dot (.) field is still there and is not removed yet. This would mean that some security context from SELinux is still applied to these files. [foc@almalinux8 ~]$ ls -ld /etc/yum.repos.d/* -rw-r--r--.1 root root 1019 Jun 22 13:31 /etc/yum.repos.d/almalinux-appstream.repo -rw-r--r--.1 root root 983 Jun 22 13:31 /etc/yum.repos.d/almalinux-baseos.repo -rw-r--r--.1 root root 947 Jun 22 13:31 /etc/yum.repos.d/almalinux-crb.repo -rw-r--r--.1 root root 983 Jun 22 13:31 /etc/yum.repos.d/almalinux-extras.repo -rw-r--r--.1 root root 1103 Jun 22 13:31 /etc/yum.repos.d/almalinux-highavailability.repo -rw-r--r--.1 root root 947 Jun 22 13:31 /etc/yum.repos.d/almalinux-nfv.repo We can either use ls --context or ls -Z to list the files along with context data from SELinux. As you can see, the files have some security context assigned due to which we see a dot(.) in the permission field: Advertisement [foc@almalinux8 ~]$ ls -Z /etc/yum.repos.d/* system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-appstream.repo system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-baseos.repo system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-crb.repo system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-extras.repo system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-highavailability.repo system_u:object_r:system_conf_t:s0/etc/yum.repos.d/almalinux-nfv.repo
ALSO READ:How to PROPERLY change mount point name in Linux Remove Dot in Linux Permissions We will use the setfattr command to remove the dot field in the permissions. This command used to set extended attributes of filesystem objects in Linux. Let's remove the permission by running the following command in the terminal: [foc@almalinux8 ~]$ setfattr -h -x security.selinux /etc/yum.repos.d/* Here, • -x name, --remove=name Remove the named extended attribute entirely. • -h, --no-dereference Do not follow symlinks. If pathname is a symbolic link, it is not followed, but is instead itself the inode being modified. Then let's list the permissions again and see that dot(.) has been successfully removed: [foc@almalinux8 ~]$ ls -ld /etc/yum.repos.d/* -rw-r--r--1 root root 1019 Jun 22 13:31 /etc/yum.repos.d/almalinux-appstream.repo -rw-r--r--1 root root 983 Jun 22 13:31 /etc/yum.repos.d/almalinux-baseos.repo -rw-r--r--1 root root 947 Jun 22 13:31 /etc/yum.repos.d/almalinux-crb.repo -rw-r--r--1 root root 983 Jun 22 13:31 /etc/yum.repos.d/almalinux-extras.repo -rw-r--r--1 root root 1103 Jun 22 13:31 /etc/yum.repos.d/almalinux-highavailability.repo -rw-r--r--1 root root 947 Jun 22 13:31 /etc/yum.repos.d/almalinux-nfv.repo Now when we list again using the -Z parameter, then we see question (?) mark appears instead of permissions which means that no security context found: [foc@almalinux8 ~]$ ls -Z /etc/yum.repos.d/* ?/etc/yum.repos.d/almalinux-appstream.repo ?/etc/yum.repos.d/almalinux-baseos.repo ?/etc/yum.repos.d/almalinux-crb.repo ?/etc/yum.repos.d/almalinux-extras.repo ?/etc/yum.repos.d/almalinux-highavailability.repo ?/etc/yum.repos.d/almalinux-nfv.repo
Recursively remove dot (.) from Linux Permission We showed how to remove dot permissions from files under a directory. But removing it from the whole system in this way is a difficult option. We will use the find command to delete the dot permissions in bulk. ALSO READ:Linux find File using the command-line [8 Different Ways] For example, under /var/log, the permissions are active: Advertisement [foc@almalinux8 ~]$ ls -ld /var/log/* drwxr-xr-x.2 root root 4096 Aug 11 17:10 /var/log/anaconda drwx------.2 root root 23 Aug 11 17:11 /var/log/audit -rw-------.1 root root 0 Sep 6 07:44 /var/log/boot.log -rw-------.1 root root 121192 Aug 13 00:00 /var/log/boot.log-20220813 -rw-------.1 root root 15055 Aug 15 22:14 /var/log/boot.log-20220815 -rw-------.1 root root 2213 Aug 16 00:00 /var/log/boot.log-20220816 -rw-------.1 root root 14479 Sep 5 09:26 /var/log/boot.log-20220905 -rw------- 1 root root 100042 Sep 6 07:44 /var/log/boot.log-20220906 Then we run the following command, which will find the ones under this directory and remove the permissions: [foc@almalinux8 ~]$ sudo find /var/log/ -type d,f -exec setfattr -x security.selinux {} \; After the find command, you can run the command by typing the directory whose permission you want to remove. The /var/log directory permissions are as follows: [foc@almalinux8 ~]$ ls -ld /var/log/* drwxr-xr-x 2 root root 4096 Aug 11 17:10 /var/log/anaconda drwx------ 2 root root 23 Aug 11 17:11 /var/log/audit -rw------- 1 root root 0 Sep 6 07:44 /var/log/boot.log -rw------- 1 root root 121192 Aug 13 00:00 /var/log/boot.log-20220813 -rw------- 1 root root 15055 Aug 15 22:14 /var/log/boot.log-20220815 -rw------- 1 root root 2213 Aug 16 00:00 /var/log/boot.log-20220816 -rw------- 1 root root 14479 Sep 5 09:26 /var/log/boot.log-20220905 -rw------- 1 root root 100042 Sep 6 07:44 /var/log/boot.log-20220906
Summary For more information about Setfattr, you can visit the man page. Or you can view the man page by running the following command in terminal: [foc@almalinux8 ~]$ man setfattr NAME setfattr - set extended attributes of filesystem objects SYNOPSIS setfattr [-h] -n name [-v value] pathname... setfattr [-h] -x name pathname... setfattr [-h] --restore=file -x name, --remove=name Remove the named extended attribute entirely. -h, --no-dereference Do not follow symlinks. If pathname is a symbolic link, it is not followed, but is instead itself the inode being modified.
