08/11 — 웹·DNS·SSH
서비스는 목적 → 프로그램/데몬 → 설정 파일 → 핵심 지시어 → 검증·로그 순서로 연결해 익힌다. 이 단원은 HTTP 서비스를 제공하고 DNS로 이름을 찾으며 SSH로 관리하는 한 흐름이다. 설정은 구조 설명용이며 실서버에 적용하지 않는다.
1. 먼저 한 장으로 연결하기
| 서비스 | 목적 | 대표 포트 | 대표 데몬 |
|---|---|---|---|
| 웹 | 문서·API 응답 | HTTP TCP 80, HTTPS TCP 443 | Apache httpd / apache2 |
| DNS | 이름·주소·서비스 레코드 조회 | UDP·TCP 53 | BIND named |
| SSH | 암호화된 원격 접속·명령·전송 | TCP 22 | sshd |
패키지 도구로 설치 상태를, systemctl로 서비스 실행을, ss로 수신 소켓을, 클라이언트 요청으로 외부 접근과 응답 내용을 확인한다. 이 관찰을 설치 → 실행 → 수신 → 접속 → 응답의 흐름으로 연결한다.
2. HTTP와 Apache의 구조
브라우저가 요청 메서드·경로·헤더를 보내면 서버가 상태 코드·헤더·본문을 응답한다. GET은 조회, POST는 제출·처리 요청, HEAD는 GET과 유사하되 응답 본문을 받지 않는 방식이다. 2xx 성공, 3xx 이동, 4xx 요청·접근 문제, 5xx 서버 처리 문제라는 범주를 먼저 본다.
Apache는 모듈로 기능을 확장한다. MPM은 요청을 어떤 프로세스·스레드 구조로 처리할지 정한다. prefork는 프로세스 중심, worker는 스레드, event는 keep-alive 연결 처리 개선과 연결한다. Apache의 요청 처리 구조는 선택한 MPM으로 정한다.
| 항목 | RHEL/Rocky 대표 | Debian/Ubuntu 대표 |
|---|---|---|
| 패키지·서비스 | httpd | apache2 |
| 주 설정 | /etc/httpd/conf/httpd.conf | /etc/apache2/apache2.conf |
| 추가 설정 | /etc/httpd/conf.d/ | sites-available / sites-enabled 등 |
| 로그 디렉터리 | /var/log/httpd/ | /var/log/apache2/ |
실제 배포 구성·컨테이너는 다를 수 있다. ServerRoot는 서버 설정·관련 파일의 기준 경로, DocumentRoot는 웹으로 제공할 문서의 기준 경로다. 각 경로를 설정 기준과 웹 문서 기준으로 연결해 기억한다.
| 지시어 | 질문 |
|---|---|
| Listen | 어느 주소·포트에서 듣는가 |
| ServerName / ServerAlias | 어떤 이름의 요청인가 |
| DocumentRoot | 기본 문서가 어디 있는가 |
| DirectoryIndex | 디렉터리 요청의 기본 파일 |
| ErrorLog / CustomLog | 오류·접근 로그를 어디에 남기는가 |
| User / Group | 작업 프로세스가 어떤 OS 신분으로 실행되는가 |
| Include / IncludeOptional | 다른 설정을 어디서 읽는가 |
Listen은 서버의 수신 주소·포트를 정하고, 방화벽은 그 주소·포트로 향하는 통신의 허용 여부를 정한다. DocumentRoot를 바꿀 때 디렉터리 권한·SELinux 문맥도 함께 맞아야 한다. Apache 핵심 지시어
3. 경로 접근·가상호스트·인증
<Directory>는 파일시스템 경로, <Location>은 URL 공간, <Files>는 파일 이름 단위로 적용한다고 구별한다. AllowOverride는 .htaccess가 어떤 설정을 재정의할 수 있는가다. .htaccess의 적용 범위는 AllowOverride 설정으로 결정한다.
Apache 2.4에서는 Require all granted, Require all denied, Require ip 같은 접근 제어를 사용한다. 예전 Order·Allow·Deny 문법은 호환 모듈·버전 맥락으로 구별한다.
<VirtualHost *:80>
ServerName study.example.test
DocumentRoot "/srv/study"
<Directory "/srv/study">
Require all granted
</Directory>
</VirtualHost>문법 구조를 읽는 예제다. 같은 IP·포트에서 요청 이름에 따라 사이트를 고르는 것이 이름 기반 가상호스트다. DNS는 사이트 이름을 서버 주소로 연결하고, Apache의 ServerName·ServerAlias는 도착한 요청을 해당 가상호스트로 연결한다. 이름이 맞지 않을 때 첫 번째 해당 가상호스트가 기본 응답이 되는 경우도 있어 설정 순서가 중요하다. 이름 기반 가상호스트
웹 인증에서는 AuthType·AuthName·AuthUserFile·Require valid-user 같은 항목을 연결한다. htpasswd는 웹 Basic 인증용 사용자 파일을 관리하고, passwd는 Linux 계정의 암호를 관리한다. Basic 인증은 자격 정보를 Base64로 인코딩해 전달한다. 전송 중 자격 정보의 기밀성은 TLS를 적용한 HTTPS로 보호한다. Apache 인증·인가
HTTPS는 HTTP 위에 TLS를 쓰는 것이다. 서버 인증서·개인키·이름 일치·신뢰 체인·유효기간이 중요하다. SSLEngine, SSLCertificateFile, SSLCertificateKeyFile을 연결한다. 인증서는 서버 신원과 공개키를 전달하고, 개인키는 서버가 비밀로 보관해 자신의 키 소유를 증명하는 데 사용한다. Apache TLS
검증 명령은 apachectl configtest 또는 httpd -t, 가상호스트 확인은 apachectl -S 등을 사용한다. 문법 통과 뒤 실행 상태·소켓·응답·로그를 본다. 403이면 접근 제어·파일 권한·SELinux, 404면 경로·매핑, 5xx면 백엔드·모듈·실행 오류 등을 좁힌다.
4. DNS: 권한 서버와 재귀 resolver
DNS 이름은 오른쪽에서 왼쪽으로 계층이 이어진다. www.example.test.의 맨 끝 점은 루트까지 포함한 완전한 이름 표현과 연결한다.
권한 서버는 자신이 맡은 zone의 공식 데이터를 응답한다. 재귀 resolver는 사용자를 대신해 필요한 서버를 찾아 질의하고 캐시한다. 같은 DNS 프로그램도 설정에 따라 권한 데이터 응답과 재귀 조회의 두 역할을 수행할 수 있다.
- 정방향: 이름 → 주소.
- 역방향: 주소 → 이름. IPv4는 in-addr.arpa, IPv6는 ip6.arpa.
- zone: 한 권한 관리 범위의 DNS 데이터다. 하위 도메인을 위임하면 그 부분은 별도 zone으로 관리한다.
- TTL: 레코드의 캐시 유효시간이다. 캐시된 응답은 남은 TTL과 갱신 시점에 따라 새 데이터로 바뀐다.
| 레코드 | 뜻 |
|---|---|
| A / AAAA | IPv4 / IPv6 주소 |
| CNAME | 별칭이 가리키는 정식 이름 |
| NS | zone의 권한 네임서버 |
| MX | 메일 수신 서버. 낮은 preference 우선 |
| PTR | 역방향 이름 |
| SOA | zone 관리 메타데이터·serial·타이머 |
| TXT | 텍스트 정보 |
| SRV | 서비스의 대상·포트·우선순위 등 |
A는 IPv4 주소를, CNAME은 별칭의 대상 이름을 담는다. SOA serial은 zone 버전을 나타내므로 데이터 변경 시 함께 갱신한다. secondary는 serial로 변경 여부를 판단한다. refresh는 갱신 확인 주기, retry는 실패 후 재시도 간격, expire는 갱신 실패가 지속될 때 zone 데이터를 유효하게 제공할 기한이다. 일반 레코드 TTL은 응답 캐시의 유효시간을 정한다. DNS는 일반 질의에 UDP를 많이 쓰지만 TCP도 지원하고 zone 전송 등에 사용한다. BIND zone 설명
5. BIND 설정과 질의
RHEL 계열은 패키지 bind·데몬 named·/etc/named.conf·/var/named/를 대표 연결로 본다. Ubuntu는 bind9와 /etc/bind/ 구성이 흔하다.
zone "example.test" IN {
type master;
file "example.test.zone";
};시험 시대의 master/slave와 최신 문서의 primary/secondary는 같은 역할 계열의 용어다. 설정 parser가 지원하는 이름은 버전을 확인한다. named.conf는 세미콜론으로 문장을 끝내며 zone 파일의 주석·문법과 다르다.
| 항목 | 역할 |
|---|---|
| options | 서버 공통 설정 |
| directory | 상대 zone 파일 등의 기준 디렉터리 |
| listen-on | 수신 주소 |
| allow-query | 질의 허용 |
| recursion / allow-recursion | 재귀 기능·허용 대상 |
| forwarders | 질의를 전달할 서버 |
| allow-transfer | zone 전송 허용 대상 |
공개 권한 서버는 담당 zone의 공개 질의를 제공하고, 재귀 서비스는 허용된 클라이언트 범위로 제한한다. allow-query는 질의 응답 대상, allow-transfer는 zone 전체 전송 대상을 정한다. BIND 설정 참조
named-checkconf
named-checkzone example.test /var/named/example.test.zone
dig @192.0.2.53 www.example.test A
dig -x 192.0.2.10첫째는 설정 문법, 둘째는 zone 검사, 셋째는 특정 DNS 서버에 A 질의, 넷째는 역방향 질의다. 주소는 문서 예시용이며 실제 접속을 요구하지 않는다. 문법 검사 후에는 위임 관계·통신 허용·실제 응답 데이터를 각각 확인한다.
zone 파일에서 @는 현재 origin, 끝 점 없는 이름은 origin이 붙을 수 있다. 완전한 도메인 이름은 끝 점을 붙여 쓰고, 상대 이름은 origin과 결합한 결과로 읽는다. serial 증가·검사·재읽기·실제 질의를 한 흐름으로 연결한다.
6. SSH: 서버 신원과 사용자 신원
SSH는 암호화된 원격 셸·명령 실행을 제공한다. 클라이언트 ssh와 서버 sshd를 구별한다. scp·sftp도 SSH 계열 파일 전송과 연결하며 SFTP는 SSH 기반 파일 전송 프로토콜이고, FTPS는 FTP에 TLS를 적용한 방식이다.
SSH에서는 두 신원을 확인한다.
- 클라이언트가 서버의 host key를 확인: known_hosts.
- 서버가 사용자를 인증: 암호·공개키 등. authorized_keys.
known_hosts의 키가 바뀌었다는 경고는 서버 재설치일 수도, 다른 서버·중간자 문제일 수도 있다. 이유 확인 없이 지워 넘기지 않는다.
| 파일 | 역할 |
|---|---|
| /etc/ssh/sshd_config | 서버 설정 |
| /etc/ssh/ssh_config, ~/.ssh/config | 클라이언트 설정 |
| ~/.ssh/authorized_keys | 해당 계정에 로그인 허용할 공개키 |
| ~/.ssh/known_hosts | 접속했던 서버의 host key 신뢰 기록 |
| 개인키 파일 | 사용자 본인이 보호할 비밀키 |
공개키 인증에서는 서버의 authorized_keys에 공개키를 등록하고, 클라이언트는 자신이 보관한 개인키로 키 소유를 증명한다. ~/.ssh 700·authorized_keys 600처럼 소유권과 불필요한 쓰기 권한을 제한하는 전형적 설정을 이해한다. sshd
7. SSH 설정·포워딩·진단
| sshd 설정 | 역할 |
|---|---|
| Port / ListenAddress | 수신 포트·주소 |
| PermitRootLogin | root 직접 로그인 정책 |
| PasswordAuthentication | 암호 인증 정책 |
| PubkeyAuthentication | 공개키 인증 정책 |
| AllowUsers / AllowGroups | 허용 사용자·그룹 |
| MaxAuthTries | 인증 시도 제한 |
| X11Forwarding | X11 전달 |
| AllowTcpForwarding | TCP 포워딩 정책 |
PasswordAuthentication은 SSH의 password 인증 방식을 제어한다. keyboard-interactive·PAM 경로의 허용 여부도 함께 확인해 원하는 전체 인증 정책을 구성한다. 설정 변경 뒤에는 sshd -t로 검사하고, 원격 작업에서는 기존 접속을 유지한 채 새 세션 검증이 필요하다. 여기서는 실제 설정을 바꾸지 않는다. sshd_config
ssh -p는 포트, -i는 사용할 키, -v는 상세 진단이다. -L은 로컬 포워딩, -R은 원격 포워딩, -D는 동적 SOCKS 프록시와 연결한다. 포워딩의 허용 대상과 수신 범위는 서버 정책·사용자 권한으로 정하고, SSH가 전달 구간을 암호화한다. ssh
접속 거부는 소켓·주소·방화벽, 인증 실패는 계정·키·PAM·파일 권한·서버 로그로 좁힌다. TCP 연결은 sshd의 수신 포트와 연결되는 단계이고, 로그인은 이후 사용자 인증과 세션 준비까지 완료하는 단계다.
필기용 압축
- Apache httpd/apache2는 웹 응답(기본 TCP 80·443), BIND named는 DNS 응답(UDP·TCP 53), sshd는 SSH 접속(TCP 22)을 담당한다.
- Apache의 ServerRoot는 설정·관련 파일 기준 경로, DocumentRoot는 웹 문서 기준 경로다. Directory는 파일시스템 경로, Location은 URL 공간에 설정을 적용한다.
- Apache 2.4의 Require는 접근 허용 조건을 정한다. DNS가 이름을 주소에 연결하면 가상호스트 설정이 도착한 요청 이름을 사이트에 연결한다.
- 권한 DNS는 담당 zone 데이터를 응답하고 재귀 resolver는 대신 질의해 캐시한다. TTL은 캐시 유효시간, SOA serial은 zone 버전이다.
- A·AAAA는 주소, CNAME은 별칭의 대상 이름, MX는 메일 수신 서버, PTR은 역방향 이름, NS는 권한 서버를 지정한다.
- named-checkconf는 BIND 설정 문법, named-checkzone은 zone 데이터, dig는 실제 DNS 응답을 확인한다.
- known_hosts는 서버 host key 신뢰 기록, authorized_keys는 사용자 로그인 허용 공개키다. 개인키는 소유자가 비밀로 보관한다.
- SFTP는 SSH 기반 파일 전송, FTPS는 TLS를 적용한 FTP다. SSH의 -L은 로컬, -R은 원격, -D는 동적 포워딩이다.
- 서비스 확인은 문법 검사 → 실행 상태 → 수신 소켓 → 클라이언트 요청·응답 → 로그 대조로 이어진다.
회상점검 — 단원 끝 한 번
- 웹·DNS·SSH의 포트와 대표 데몬을 말해봐.
- ServerRoot·DocumentRoot, Directory·Location을 구별해봐.
- 이름 기반 가상호스트에서 DNS 설정과 Apache 설정이 둘 다 필요한 이유는?
- 권한 DNS와 재귀 resolver는 무엇이 다른가? TTL과 SOA serial은?
- A·AAAA·CNAME·MX·PTR·NS를 한 줄씩 설명해봐.
- named-checkconf·named-checkzone·dig는 각각 무엇을 검증하나?
- known_hosts·authorized_keys·개인키의 역할과 보관 주체는?
- sshd -t로 확인하는 대상은 무엇이며, 새 원격 로그인 확인까지 어떤 단계를 거치나?
출처·검증 범위
2026-09-09 작성. Apache 2.4 core·가상호스트·인증·TLS, BIND 9.18, OpenSSH 공식 매뉴얼을 참조했다. 모든 배포판 경로·지시어 조합·TLS 기본값을 전수 대조하거나 서비스를 띄워 검증한 상태는 아니다. 버전 차이가 있는 부분은 시험 대상과 구별했다. 기출 미사용, 예제 자체 작성. 사전 작성은 대화 학습 전달·숙달과 별개다.