이번 실습에서는 오래된 분산 서비스 거부 공격 도구인 Trinoo의 구조를 실습 환경에서 확인했다.

실제 인터넷 환경이 아닌 수업용 폐쇄 네트워크에서 Master와 Agent의 역할, 두 시스템이 서로 어떻게 통신하는지, 그리고 명령이 전달되었을 때 네트워크 트래픽이 어떻게 변화하는지를 확인하는 것이 목적이다.

1. 실습 환경

이번 실습에서는 두 대의 CentOS 가상머신을 사용했다.

Linux16 : Master
Linux17 : Agent

실습 당시 주소는 환경에 따라 다르게 설정될 수 있으므로 각 시스템에서 직접 IP를 확인했다.

구조를 그림으로 보면 다음과 같다.

        관리자
          │
          ▼
     [ Linux16 ]
        Master
          │
          │ 명령 전달
          ▼
     [ Linux17 ]
        Agent
          │
          │ 테스트 트래픽
          ▼
     [ 실습 대상 ]

Trinoo는 기본적으로 Master와 Agent가 나뉘어 동작하는 구조다.

Master는 명령을 전달하고, Agent는 전달받은 명령에 따라 실제 네트워크 동작을 수행한다.

2. Master와 Agent의 역할

Master

Master는 관리자가 접속하여 Agent에게 명령을 전달하는 역할을 한다.

즉,

사용자
 ↓
Master
 ↓
Agent

순서로 명령이 전달된다.

실습에서는 Linux16을 Master로 사용했다.

Agent

Agent는 Master의 명령을 기다리는 프로세스다.

Master에서 명령이 전달되면 Agent가 해당 작업을 수행한다.

실습에서는 Linux17을 Agent로 사용했다.

Agent는 한 대뿐 아니라 여러 대가 연결될 수 있는 구조이기 때문에 과거 DDoS 도구들이 이런 구조를 사용했다.

             Master
                │
       ┌────────┼────────┐
       ▼        ▼        ▼
    Agent1   Agent2   Agent3

여러 Agent가 동시에 같은 대상에 트래픽을 보내면 네트워크 부하가 크게 증가할 수 있다.

3. 실습 파일 준비

Linux16과 Linux17 양쪽에 강사가 제공한 실습 파일을 준비했다.

압축 파일 내부에는 Master와 Agent 프로그램을 구성하는 소스코드와 설정 파일 등이 포함되어 있었다.

먼저 별도의 디렉터리를 생성한 뒤 압축 파일을 해제했다.

구조는 대략 다음과 같았다.

trinoo/
 ├─ master/
 ├─ daemon/
 ├─ password
 └─ 기타 소스 파일

master 디렉터리에는 Master 프로그램과 관련된 소스가 들어 있고,

daemon 디렉터리에는 Agent 역할을 수행하는 프로그램의 소스가 들어 있다.

4. 설정 파일 확인

실습 파일에는 Master와 Agent 사이에서 사용되는 인증 관련 설정도 포함되어 있었다.

수업에서는 해당 내용을 확인하여 Master와 Agent가 어떤 방식으로 인증하고 통신하는지 확인했다.

여기서 중요한 점은 단순히 실행 파일 하나가 동작하는 것이 아니라,

Master 설정
+
Agent 설정
+
인증 정보
+
네트워크 주소

가 서로 맞아야 정상적으로 통신할 수 있다는 점이다.

5. Linux16 - Master 구성

Linux16에서는 Master 프로그램을 구성했다.

Master 쪽 소스코드는 별도의 큰 수정 없이 실습 환경에 맞춰 컴파일했다.

컴파일 후 생성된 실행 파일을 확인하고 Master 프로세스를 실행했다.

실행 이후에는 프로세스 목록을 확인하여 Master가 정상적으로 동작하고 있는지 확인했다.

개념적으로는 다음 과정이다.

Master 소스 확인
       ↓
컴파일
       ↓
실행 파일 생성
       ↓
Master 실행
       ↓
프로세스 확인

6. Linux17 - Agent 구성

Linux17은 Agent 역할을 담당한다.

Agent에서는 Master의 IP 주소를 알고 있어야 하기 때문에 실습 환경에 맞게 Agent의 설정을 수정했다.

즉 Agent 입장에서는

"내가 어느 Master와 통신해야 하는가?"

를 지정해 주는 과정이라고 이해하면 된다.

수정 후 Agent 프로그램을 다시 컴파일하고 실행했다.

7. Agent 프로세스 확인

Agent 실행 후에는 프로세스가 정상적으로 올라왔는지 확인했다.

실습에서는 프로세스 목록을 조회하여 Agent 관련 프로세스가 존재하는지 확인했다.

구조적으로 보면:

Linux17
  │
  └─ Agent daemon 실행 중
          │
          └─ Master 명령 대기

상태가 되는 것이다.

만약 정상적으로 통신되지 않는 경우에는 기존 Agent 프로세스를 종료한 뒤 다시 실행하여 상태를 확인했다.

8. Master 실행 및 접속

Agent 준비가 끝난 뒤 Linux16에서 Master를 실행했다.

Master 역시 백그라운드에서 동작하는 데몬 형태로 동작하며, 별도의 관리 접속을 통해 명령을 전달하는 구조였다.

관리 화면에 접속하면 Trinoo의 명령 인터페이스를 확인할 수 있었다.

여기까지 완료되면 구조상

Master 실행
      +
Agent 실행
      +
Master ↔ Agent 통신

이 준비된 상태다.

9. Agent 검색

Master에서는 현재 연결 가능한 Agent가 존재하는지 확인하는 기능이 있다.

이를 통해 Master가 Agent를 정상적으로 인식하는지 확인했다.

정상적인 경우:

Master
   │
   └── Agent 발견

상태가 된다.

Agent가 나타나지 않는 경우에는 다음과 같은 내용을 점검했다.

Agent 프로세스 실행 여부
Master IP 설정
두 시스템의 네트워크 연결
방화벽
IP 주소
프로세스 재실행

10. Master와 Agent 관계 이해

이 부분이 처음에는 조금 헷갈릴 수 있었다.

일반적인 서버/클라이언트 구조와 비교하면 상황에 따라 역할이 달라 보일 수 있기 때문이다.

실습에서는 개념적으로 다음처럼 이해했다.

관리자
  │
  ▼
Master
  │
  ▼
Agent

Master는 Agent에게 작업을 지시한다.

Agent는 Master의 명령을 기다렸다가 해당 작업을 수행한다.

따라서 전체 시스템에서는 Master가 제어 역할, Agent가 실행 역할을 담당한다.

11. Wireshark 준비

Master와 Agent의 통신이 정상적으로 이루어지는 것을 확인한 후 Wireshark를 실행했다.

VMware 환경이었기 때문에 해당 가상 네트워크 인터페이스를 선택하여 패킷을 캡처했다.

실습 전에 별도의 필터를 지정하지 않고 전체 패킷 흐름을 관찰했다.

Wireshark 실행
      ↓
VMware 가상 네트워크 선택
      ↓
패킷 캡처 시작

12. 테스트 트래픽 발생

폐쇄된 실습 환경에서 강사의 지시에 따라 테스트 트래픽을 발생시켰다.

Master에서 Agent로 명령이 전달되자 Agent가 네트워크 트래픽을 발생시키는 것을 확인할 수 있었다.

Wireshark 화면에서는 평상시와 비교하여 패킷 수가 급격하게 증가하는 모습을 볼 수 있었다.

개념적으로 보면:

Master
   │
   │ 명령
   ▼
Agent
   │
   │ 다량의 패킷
   ▼
Test Target

형태이다.

13. Wireshark에서 관찰한 결과

명령을 실행하기 전에는 비교적 적은 수의 패킷이 보였지만, 테스트가 시작되자 매우 많은 패킷이 연속적으로 발생했다.

평상시

packet
packet
packet


테스트 시작 후

packet packet packet packet packet
packet packet packet packet packet
packet packet packet packet packet
...

즉, DDoS가 왜 서버뿐만 아니라 네트워크 자체에도 부담을 줄 수 있는지를 패킷 수준에서 확인할 수 있었다.

14. 실습 종료

패킷 변화를 충분히 확인한 뒤 실습을 종료했다.

Agent와 Master 프로세스를 종료하고 가상머신을 종료했다.

특히 이런 프로그램은 실습이 끝난 뒤 계속 실행해 둘 필요가 없으므로 반드시 프로세스가 종료되었는지 확인하는 것이 중요하다.

트래픽 관찰 완료
      ↓
Agent 종료
      ↓
Master 종료
      ↓
VM 종료

15. 이번 실습에서 이해한 Trinoo 구조

Trinoo의 핵심 구조를 다시 정리하면 다음과 같다.

          사용자
             │
             ▼
        ┌─────────┐
        │ Master  │
        └────┬────┘
             │
       명령 전달
             │
      ┌──────┼──────┐
      ▼      ▼      ▼
   Agent   Agent   Agent
      │      │      │
      └──────┼──────┘
             │
        Network Traffic
             │
             ▼
          Target

Master가 직접 모든 패킷을 보내는 것이 아니라, 여러 Agent에게 명령을 전달하고 Agent들이 동작하는 구조라는 것이 핵심이다.

16. Master / Agent 정리

구분역할

Master	Agent에게 명령 전달
Agent	Master의 명령을 받아 실제 작업 수행
관리자	Master에 접속하여 제어
Wireshark	발생하는 네트워크 패킷 관찰
Target	폐쇄 실습환경에서 트래픽을 확인하는 대상

17. 실습 중 문제가 발생했을 때 확인할 것

Master에서 Agent가 확인되지 않을 경우 다음 항목을 확인한다.

Linux16과 Linux17이 서로 통신되는가?
IP 주소가 맞는가?
Agent 설정에 Master 주소가 정확한가?
Agent 프로세스가 실행 중인가?
Master 프로세스가 실행 중인가?
방화벽 또는 네트워크 설정에 문제가 없는가?

가장 먼저 두 시스템 사이의 기본적인 네트워크 연결을 확인하는 것이 중요하다.

18. 실습에서 알게 된 점

이번 실습에서 가장 중요했던 것은 DDoS 도구 자체의 사용법보다는 분산 구조가 어떻게 구성되는지를 이해하는 것이었다.

단일 프로그램이 혼자 동작하는 것이 아니라,

Master
   ↓
Agent
   ↓
Network

형태로 여러 시스템이 연결될 수 있다는 점을 확인했다.

또한 Wireshark를 통해 실제 패킷을 관찰하면서 트래픽이 짧은 시간 안에 크게 증가하는 모습을 확인할 수 있었다.

이러한 구조를 이해하면 반대로 보안 관점에서 비정상적인 트래픽 증가, 지속적인 UDP 트래픽, 의심스러운 데몬 프로세스, 알 수 없는 제어 연결 등을 탐지하는 것이 왜 중요한지도 이해할 수 있다.

핵심 요약

Linux16 = Master
Linux17 = Agent

Master
  ↓
Agent에게 명령 전달
  ↓
Agent가 네트워크 동작 수행
  ↓
Wireshark에서 패킷 증가 확인

이번 실습을 통해 Master와 Agent 기반의 분산형 공격 구조와 네트워크 패킷 변화를 확인했다.

실습이 끝난 뒤에는 관련 프로세스를 종료하고 가상머신도 종료하여 실습 환경을 정리했다.

저작자표시 (새창열림)

Lsung

리눅스 실습 - Trinoo 구조 이해 및 네트워크 트래픽 분석