소개
Linux 에서의 네트워크 트래픽 분석 및 보안 원격 액세스 실습에 오신 것을 환영합니다. 네트워크 활동을 모니터링하고 통신을 보호하는 방법을 이해하는 것은 모든 시스템 관리자, 개발자 또는 보안 애호가에게 중요한 기술입니다.
이 실습에서는 강력한 명령줄 도구 모음을 직접 사용해 볼 것입니다. 다음을 배우게 됩니다:
netstat및 그 현대적인 후속 도구인ss를 사용하여 활성 네트워크 연결 및 수신 대기 중인 서비스를 검사합니다.tcpdump를 사용하여 실시간 네트워크 패킷을 캡처하고 분석합니다.ssh를 사용하여 자신의 컴퓨터에 안전한 원격 연결을 설정합니다.dig및 DNSSEC 를 사용하여 DNS 응답의 무결성을 확인합니다.
이 실습이 끝나면 이러한 필수 네트워킹 유틸리티와 Linux 시스템을 관리하고 보호하는 데 있어 해당 유틸리티의 역할에 대한 실질적인 이해를 갖게 될 것입니다.
Netstat/SS 로 활성 네트워크 연결 검사하기
이 단계에서는 시스템에서 활성 네트워크 연결 및 수신 대기 중인 포트를 확인하는 방법을 배웁니다. 이는 어떤 서비스가 실행 중이며 네트워크를 통해 액세스 가능한지 이해하는 데 기본적입니다. 두 가지 일반적인 도구인 netstat과 ss를 사용할 것입니다.
먼저, 고전적이고 널리 알려진 유틸리티인 netstat을 사용해 보겠습니다. netstat을 포함하는 net-tools 패키지는 실습 설정 중에 설치되었습니다.
다음 명령을 실행하여 수신 대기 중인 모든 TCP (-t) 및 UDP (-u) 포트를 이름 확인 없이 숫자 형식 (-n) 으로 나열하고 수신 대기 소켓 (-l) 에만 집중합니다:
netstat -tuln
이와 유사한 출력을 볼 수 있습니다. 여러분을 위해 시작된 SSH 서버 (포트 22) 및 Python 웹 서버 (포트 8000) 항목과 포트 3001 및 3002 의 추가 서비스에 주목하십시오:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3002 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.11:37199 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
udp 0 0 127.0.0.11:60120 0.0.0.0:*
udp 0 0 0.0.0.0:3001 0.0.0.0:*
이제 netstat의 현대적인 대체 도구인 ss를 사용해 보겠습니다. 일반적으로 더 빠르고 더 자세한 정보를 제공합니다. 명령과 플래그는 매우 유사합니다.
ss -tuln
출력 형식은 약간 다르지만 동일한 필수 정보, 즉 포트 22, 3001, 3002 및 8000 에서 수신 대기 중인 서비스와 일부 내부 Docker 서비스가 표시됩니다:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.11:60120 0.0.0.0:*
udp UNCONN 0 0 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:3001 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:3002 0.0.0.0:*
tcp LISTEN 0 5 0.0.0.0:8000 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.11:37199 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
이러한 명령을 사용하면 시스템의 네트워크 관련 서비스를 신속하게 파악할 수 있습니다.
Tcpdump 로 로컬 네트워크 트래픽 캡처하기
이 단계에서는 강력한 명령줄 패킷 분석기인 tcpdump를 사용하여 실시간으로 네트워크 트래픽을 캡처하고 검사합니다. 이는 네트워크 문제를 디버깅하거나 프로토콜이 작동하는 방식을 이해하는 데 매우 유용합니다.
먼저 트래픽 캡처에 사용할 수 있는 네트워크 인터페이스를 확인해 보겠습니다.
sudo tcpdump -D
출력에는 사용 가능한 인터페이스가 나열됩니다. lo는 "루프백" 인터페이스로, 동일한 머신 내에서 네트워크 통신에 사용됩니다 (예: localhost에 연결). 기본 네트워크 인터페이스인 eth1을 포함한 다양한 인터페이스를 볼 수 있습니다:
1.eth1 [Up, Running, Connected]
2.any (Pseudo-device that captures on all interfaces) [Up, Running]
3.lo [Up, Running, Loopback]
4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
5.nflog (Linux netfilter log (NFLOG) interface) [none]
6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
7.dbus-system (D-Bus system bus) [none]
8.dbus-session (D-Bus session bus) [none]
로컬 웹 서버에 대한 요청을 보기 위해 루프백 인터페이스 (lo) 에서 트래픽을 캡처할 것입니다. 이를 위해 두 개의 터미널이 필요합니다.
현재 터미널에서 다음 tcpdump 명령을 실행합니다. 이 명령은 lo 인터페이스에서 수신 대기하고 (-i lo) 5 개의 패킷을 캡처한 후 중지합니다 (-c 5).
sudo tcpdump -i lo -c 5
이제 터미널 탭 표시줄의 + 아이콘을 클릭하여 새 터미널을 엽니다. 이 새 터미널에서 curl을 사용하여 로컬 웹 서버에 요청을 보내 네트워크 트래픽을 생성합니다.
curl http://localhost:8000
첫 번째 터미널로 다시 전환합니다. tcpdump가 curl 요청과 관련된 패킷을 캡처했음을 볼 수 있습니다. 출력은 TCP 핸드셰이크 및 데이터 전송을 보여주는 다음과 유사하게 표시됩니다:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lo, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:57:14.158058 IP localhost.57272 > localhost.8000: Flags [S], seq 2025143228, win 65495, options [mss 65495,sackOK,TS val 1006286113 ecr 0,nop,wscale 7], length 0
14:57:14.158072 IP localhost.8000 > localhost.57272: Flags [S.], seq 403368374, ack 2025143229, win 65483, options [mss 65495,sackOK,TS val 1006286113 ecr 1006286113,nop,wscale 7], length 0
14:57:14.158083 IP localhost.57272 > localhost.8000: Flags [.], ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
14:57:14.158129 IP localhost.57272 > localhost.8000: Flags [P.], seq 1:79, ack 1, win 512, options [nop,nop,TS val 1006286113 ecr 1006286113], length 78
14:57:14.158133 IP localhost.8000 > localhost.57272: Flags [.], ack 79, win 511, options [nop,nop,TS val 1006286113 ecr 1006286113], length 0
5 packets captured
24 packets received by filter
0 packets dropped by kernel
특정 트래픽을 생성하지 않고 tcpdump를 실행하면 로그에서 볼 수 있듯이 백그라운드 DNS 쿼리 및 기타 시스템 통신을 볼 수 있습니다. 이는 정상적인 시스템 동작이며 적극적으로 브라우징하지 않을 때도 시스템이 다양한 네트워크 통신을 유지하고 있음을 보여줍니다.
성공적으로 라이브 네트워크 트래픽을 캡처하고 보았습니다.
SSH 를 이용한 안전한 원격 액세스 시연
이 단계에서는 SSH(Secure Shell) 를 사용하여 안전한 원격 액세스를 하는 방법을 배웁니다. 암호 기반 인증보다 더 안전한 키 기반 인증을 구성하여 자신의 머신 (localhost) 에 로그인할 것입니다. openssh-server는 이미 시작되었습니다.
먼저 SSH 키 쌍 (개인 키 및 공개 키) 을 생성해야 합니다. 2048 비트 길이의 RSA 키를 생성할 것입니다. -f 플래그는 키를 저장할 파일을 지정하고, -N ""는 이 실습에서 편의를 위해 빈 암호 구문 (passphrase) 을 설정합니다.
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -N ""
이 명령은 ~/.ssh 디렉토리 안에 id_rsa(개인 키) 와 id_rsa.pub(공개 키) 를 생성합니다.
다음으로, 자신의 사용자가 이 키를 사용하여 로그인할 수 있도록 공개 키를 authorized_keys 파일에 추가해야 합니다. 이 파일은 로그인할 수 있도록 허용된 모든 공개 키를 나열합니다.
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
보안을 위해 SSH 는 .ssh 디렉토리 및 해당 파일에 대한 엄격한 권한을 요구합니다. 올바르게 설정되었는지 확인해 보겠습니다. 설정 스크립트에서 이미 올바른 권한으로 이러한 파일을 생성했지만, 이러한 명령을 아는 것은 좋은 습관입니다.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
이제 모든 설정이 완료되었습니다. localhost에 대한 보안 연결을 테스트할 수 있습니다. 이 명령은 원격 끝 (자신의 머신) 에서 echo "Hello from SSH"를 실행하고 결과를 출력합니다.
ssh labex@localhost 'echo "Hello from SSH"'
처음 연결할 때 호스트의 지문 (fingerprint) 을 확인하라는 메시지가 표시될 수 있습니다. yes를 입력하고 Enter 를 누르세요. 그러면 echo 명령의 출력이 표시됩니다.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Hello from SSH
SSH 를 사용하여 안전한 키 기반 인증을 성공적으로 구성하고 사용했습니다.
Dig 를 사용하여 DNSSEC 확인
이 단계에서는 dig (Domain Information Groper) 를 사용하여 DNS 쿼리를 수행하고 DNSSEC(DNS Security Extensions) 에 대해 알아봅니다. DNSSEC 는 DNS 데이터에 암호화 서명을 추가하여 DNS 스푸핑으로부터 보호하는 데 도움이 됩니다.
먼저 labex.io에 대한 표준 DNS 쿼리를 수행하여 IP 주소를 확인해 보겠습니다.
dig labex.io
출력에는 쿼리 세부 정보와 가장 중요한 A 레코드 (IP 주소) 가 포함된 ANSWER SECTION이 표시됩니다. labex.io는 로드 밸런싱을 위해 여러 IP 주소를 가지고 있음을 알 수 있습니다:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9789
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 10 IN A 104.26.10.219
labex.io. 10 IN A 104.26.11.219
labex.io. 10 IN A 172.67.72.162
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:16 CST 2025
;; MSG SIZE rcvd: 85
이제 동일한 쿼리를 수행하되, +dnssec 옵션을 추가하여 DNSSEC 관련 데이터를 제공하도록 DNS 해석기 (resolver) 에 요청해 보겠습니다.
dig labex.io +dnssec
출력에는 OPT PSEUDOSECTION 에 추가적인 DNSSEC 관련 정보가 포함되어 있으며, DNSSEC 가 요청되었음을 보여줍니다 (do 플래그는 "DNSSEC OK"를 의미합니다). 그러나 flags 섹션에 ad(Authenticated Data) 플래그가 포함되어 있지 않음에 유의하십시오:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> labex.io +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1042
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;labex.io. IN A
;; ANSWER SECTION:
labex.io. 5 IN A 172.67.72.162
labex.io. 5 IN A 104.26.11.219
labex.io. 5 IN A 104.26.10.219
;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:21 CST 2025
;; MSG SIZE rcvd: 108
ad 플래그가 없는 것은 DNSSEC 정보가 요청되었지만, 해석기가 서명을 검증할 수 없었거나 해당 도메인이 DNSSEC 를 활성화하지 않았음을 나타냅니다.
DNSSEC 를 사용하는 잘 알려진 다른 도메인인 icann.org를 시도하여 다시 확인해 보겠습니다.
dig icann.org +dnssec
다시 출력에서 헤더를 검사합니다:
; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> icann.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54437
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f (".......")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;icann.org. IN A
;; ANSWER SECTION:
icann.org. 10 IN A 192.0.43.7
;; Query time: 72 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Aug 05 14:58:26 CST 2025
;; MSG SIZE rcvd: 77
이전 쿼리와 유사하게 응답에 ad 플래그가 없습니다. 이는 이 환경의 DNS 해석기가 DNSSEC 검증을 수행하고 있지 않음을 나타내며, 이는 컨테이너화되거나 가상화된 환경에서 일반적인 구성으로, DNS 해석기가 표준 시스템 해석기와 다르게 구성될 수 있습니다.
요약
실습을 완료하신 것을 축하드립니다! 여러 필수적인 Linux 네트워킹 및 보안 도구에 대한 실질적인 경험을 쌓으셨습니다.
이 실습에서는 다음을 배웠습니다.
netstat및ss를 사용하여 실행 중이고 연결을 기다리는 네트워크 서비스가 무엇인지 검사하는 방법.tcpdump를 사용하여 특정 인터페이스에서 실시간 네트워크 패킷을 캡처하여 트래픽을 분석하는 방법.- 키 기반 인증을 사용하여
ssh를 구성하고 안전한 원격 액세스를 위해 사용하는 방법. dig를 사용하여 도메인 이름 시스템 (DNS) 을 쿼리하고 DNSSEC 개념을 이해하는 방법, DNSSEC 정보를 요청하고 결과를 해석하는 방법을 포함합니다.
이러한 기술은 모든 Linux 환경을 관리, 문제 해결 및 보안하는 데 매우 중요합니다. 이러한 강력한 도구가 제공하는 다양한 옵션을 계속 탐색해 보시기 바랍니다.
