목차

소개

배경 정보

성공적인 캡처 체크리스트

스니퍼 도구

Mac OS X 무선 스니핑 도구

공항

공항공사

tcpdump

Wi-Fi 진단

에어툴

Windows 7 및 3.4를 사용한 무선 스니핑(더 이상 사용되지 않음)

소개

스니퍼 모드에서 Cisco LAP(Lightweight Access Point)를 사용한 무선 스니핑

소개

컨피그레이션 단계

1단계. WLC / AP 측

2단계. 스니퍼 사이드: Wireshark

3단계. 스니퍼측: OmniPeek

Cisco® Autonomous(IOS) AP를 사용한 무선 스니핑

캡처 파일을 TAC 서비스 요청에 업로드

스니퍼 분석

802.11 스니퍼 캡처 분석 - 물리적 레이어

소개: 무선 패킷 캡처의 물리적 레이어 정보

무선 패킷 헤더 - 예

802.11 스니퍼 캡처 분석 - Wireshark 필터링

소개

Wireshark 필터링-wlan

목표

사전 요구 사항

무선 스니퍼 추적을 캡처해야 하는 이유

무선 스니퍼 캡처 필터를 사용해야 하는 이유

디스플레이 필터 및 캡처 필터를 사용하는 경우

필터링 방법

메뉴 모음

기본 도구 모음

필터 도구 모음

Packet List 창

Packet Details 창

Packet Bytes 창

상태 표시줄

초기 상태 표시줄

캡처 필터 사용

필터 표시

색상 필터 규칙 사용

802.11 스니퍼 캡처 분석 - 관리 프레임 및 개방형 인증

소개

802.11 - 프레임 및 개방형 인증

802.11 클라이언트 인증 프로세스

관리 프레임

컨트롤 프레임

데이터 프레임

참조

802.11 스니퍼 캡처 분석 - PSK 또는 EAP를 사용하는 WPA/WPA2

WPA-PSK(TKIP)

WPA2-PSK(AES/TKIP)

Wireshark를 사용하여 무선 패킷 캡처를 통해 WPA2 AES 데이터를 해독하는 방법

요건:

Process

WPA/WPA2 엔터프라이즈

WPA(TKIP)/WPA2(AES)(dot1x 포함)(EAP-TLS)

802.11 스니퍼 캡처 분석 - 멀티캐스트

소개

솔루션

WLC의 IGMP 스누핑

멀티캐스트 모드 사용 지침

멀티캐스트 구성(멀티캐스트-멀티캐스트 모드 사용)

무선 LAN 컨트롤러

유선 네트워크의 멀티캐스트 컨피그레이션

패킷 캡처

토폴로지

MCAST 트래픽 생성기 도구

MCAST Generator의 Wired Wireshark 패킷 캡처

Mcast 패킷 생성기의 Windows Netmon 캡처

무선 클라이언트의 무선 인터페이스에서 Wireshark 캡처

무선 클라이언트의 무선 인터페이스에서 Netmon 캡처

802.11 스니퍼 캡처 분석 - 웹 인증

소개

구성 웹 인증

WLCC의 컨피그레이션

클라이언트가 연결을 시도했을 때의 클라이언트 디버그는 다음과 같습니다

참조:

소개

이 문서에서는 802.11 동작을 분석하고 문제를 해결하기 위해 적절한 무선 스니퍼 추적을 수집하는 프로세스를 설명합니다.

배경 정보

이 프로세스는 어렵고 시간이 많이 소요되는 작업일 수 있다. 이 프로세스를 간소화하고 가속화하는 데 도움이 되는 몇 가지 사항을 염두에 두어야 합니다. 무선 스니핑으로 무엇을 하고 싶은지 파악하는 데 도움이 됩니다. 무선 스니핑 디바이스 자체에서 볼 수 있듯이, 상공을 통해 원시 무선 프레임을 캡처하려는 경우

성공적인 캡처 체크리스트

1단계: 스니핑 디바이스, 클라이언트 디바이스 및 AP는 송신 또는 수신을 위해 RF 생성 라디오를 사용하므로 무선 스니퍼를 대상 디바이스(클라이언트 머신)에 가까이 배치하는 데 도움이 됩니다. 이를 통해 스니핑 디바이스에서 클라이언트 디바이스가 무선으로 수신하는 메시지에 대한 근사치를 캡처할 수 있습니다.

2단계: 별도의 장치를 사용하여 무선 스니퍼 역할을 수행합니다. 테스트 중인 디바이스(의 무선 추적을 받으려는 클라이언트 시스템)에서 실행 중인 경우 양호한 무선 스니퍼 추적을 수행할 수 없습니다.

3단계: 캡처를 설정하기 전에 클라이언트 디바이스에서 사용하는 802.11 채널 및 밴드를 정확하게 파악합니다. 관심 채널에 스니퍼 잠금 - 스니퍼의 스캔 채널 모드를 사용하지 마십시오!  (스캔 채널의 경우 스니퍼는 1초마다 채널에서 채널로 순환합니다. 이 기능은 사이트 설문조사나 비인가를 찾는 데 유용하지만 802.11 문제를 캡처하려고 할 때는 그렇지 않습니다.)

또한 클라이언트 디바이스가 다른 RF 채널 또는 밴드에 있는 다른 AP로 로밍할 수 있으므로 그에 따라 계획을 세워야 합니다. 일반적으로 802.11b/g(2.4GHz) 환경에서는 3개의 채널 스니퍼가 필요할 수 있습니다. 여기에는 스니핑 디바이스에서 각각 채널 1, 6 및 11로 설정된 3개의 무선 어댑터를 사용하는 것이 포함됩니다. USB 무선 어댑터는 이러한 설정 유형에 가장 적합합니다.

4단계: 5GHz 문제를 해결하면 채널 수가 크게 증가합니다. 모든 채널을 캡처할 충분한 카드가 없기 때문에 주변 액세스 포인트의 4개 이하의 채널에서 테스트가 작동하는 것이 좋습니다.

5단계: 클라이언트가 한 채널에서 다른 채널로 로밍할 때 문제를 재현할 수 있는 경우 2 채널 스니프만으로도 충분합니다.  단일 채널 스니퍼만 사용할 수 있는 경우 roamed-to 채널을 스니핑하도록 합니다.

6단계: 항상 NTP에서 스니퍼를 동기화합니다.  패킷 캡처는 디버그 캡처 및 기타 유선 및/또는 무선 캡처와 통합해야 합니다.  타임스탬프가 1초라도 떨어지면 데이터 정렬이 훨씬 더 어려워집니다.

7단계:장기간(시간) 캡처하는 경우 스니퍼를 구성하여 30MB 정도 간격으로 새 캡처 파일을 잘라냅니다.  하드 드라이브를 채우지 않기 위해, 당신은 쓰여진 파일의 수에 상한을 두고자 한다.

참고: Linksys USB600N은 짧은 보호 간격으로 11n 패킷을 안정적으로 수집하지 않습니다. 짧은 보호 간격 패킷의 20~30%를 누락시킵니다. 필요한 경우 WLC 컨피그레이션을 느린 긴 보호 간격만 사용하도록 변경할 수 있습니다. 이는 일시적인 컨피그레이션 변경일 수 있습니다. 이 명령은 config 802.11 {a | b}11nsupport guard-interval {any | long}.

스니퍼 도구

OS X 10.6 이상의 Mac으로 무선 스니핑.

Mac OS X에는 무선 추적을 캡처하는 도구가 내장되어 있으므로 Mac에서 무선 스니핑이 잘 작동합니다.  그러나 실행 중인 OS X의 버전에 따라 달라집니다. 명령이 다를 수 있습니다. 이 문서에서는 OS X 10.6부터 최신 버전까지 다룹니다. Wi-Fi 진단은 최신 macbook에서 선호하는 방법입니다. 맥북 스니퍼는 최소한 스니핑 중인 클라이언트만큼 가능해야 한다는 것을 기억해야 합니다(802.11n 맥북이 있는 802.11ac 스마트폰 스니핑은 최적이 아님).

Mac OS X 무선 스니핑 도구

- 공항(10.6-10.8)

- 공항 시설(10.6 - 10.8)

- tcpdump(10.8)

- Wi-Fi 진단(10.7->10.12)

- Wireshark(10.6 - 10.8)

- 서드파티 툴: Airtool

공항

OS X 10.6(Snow Leopard) 이상을 실행하는 경우 명령줄 유틸리티 공항을 쉽게 사용할 수 있습니다.

다음 단계를 수행합니다.

- 명령 + 스페이스 바 키 콤보를 사용하여 화면 오른쪽 상단의 검색 대화 상자를 열고 단어 터미널을 입력합니다. 이렇게 하면 터미널 애플리케이션을 검색할 수 있습니다. 이 응용 프로그램을 선택하여 실행하십시오. 터미널 창이 나타날 수 있습니다.

- 터미널 창이 열리면 다음 명령을 실행하여 RF 채널 11에서 무선 스니퍼 추적을 캡처할 수 있습니다(802.11b/g).

sudo /usr/libexec/airported en1 sniff 11

몇 가지 기억해야 할 사항은 다음과 같습니다.

- 확인을 위해 계정 비밀번호를 입력하라는 프롬프트가 표시됩니다.

- 캡처 파일의 이름이나 출력을 저장할 위치를 지정할 수 없습니다.

- 캡처하는 동안 네트워크에 대한 무선 연결이 끊어집니다.

- Air를 사용하는 경우 무선 어댑터는 en1이 아니라 en0입니다.

추적이 완료되면 Cntl-C를 눌러 추적을 중지하고 유틸리티에 캡처 파일의 이름과 위치가 표시됩니다. 파일 형식은 Wireshark를 통해 MAC 또는 Windows에서 읽을 수 있는 표준 wireshark PCAP 파일입니다.

공항공사

Airport Utility는 스니퍼 프로그램이 아니지만 무선 LAN에 대한 정보를 제공할 수 있습니다. 또한 자체 채널을 설정할 수 없는 스니퍼 프로그램(tcpdump, Wireshark)에 중요한 기본 무선 채널을 설정할 수도 있습니다.

참고: 공항 유틸리티에 대한 경로가 너무 보기 흉하기 때문에 경로에 있는 디렉터리에서 해당 유틸리티에 대한 심볼 링크를 설정하는 것이 좋습니다. 예를 들어, # sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/sbin/airport를 입력합니다.

무선 채널 설정

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport —channel=48

표시되는 SSID/BSSID에 대한 정보 덤프

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s

SSID BSSID RSSI 채널 HT CC 보안(인증/유니캐스트/그룹)

테스트 00:24:97:89:cb:41 -53 11Y — WPA(PSK/TKIP/TKIP) WPA2(PSK/AES/TKIP)

Test2 00:24:97:89:cb:40 -53 11 N — WPA(PSK/TKIP/TKIP)

게스트 00:22:75:e6:73:df -64 6,-1 Y — WPA(PSK/AES,TKIP/TKIP) WPA2(PSK/AES,TKIP/TKIP)

현재 연결에 대한 자세한 정보

# sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I

agrCtlRSSI: -54

agrExtRSSI: 0

agrCtlNoise: -89

agrExtNoise: 0

상태: 실행 중

op 모드: 스테이션

lastTxRate: 300

maxRate: 300

lastAssocStatus: 0

802.11 인증: 열기

링크 인증: wpa2-psk

BSSID: 0:24:97:95:47:60

SSID: 게스트 네트워크

MCS: 15

채널: 36,1

tcpdump

Tcpdump는 패킷 캡처를 수행할 수 있는 OS X와 함께 제공되는 명령줄 유틸리티입니다(Wireshark와 함께 번들로 제공되는 tshark 유틸리티는 매우 유사함).  tcpdump를 사용하여 무선 패킷 캡처를 수행하려면

- 먼저, 채널을 설정한 후 공항 유틸리티를 사용합니다.

- 그런 다음 무선 패킷 캡처를 수행하고 파일에 저장합니다.  완료되면 Control/C를 입력하여 종료합니다.

예:

bash-3.2# tcpdump -I -P -i en1 -w /tmp/channel-11.pcap

tcpdump: 경고: en1: IPv4 주소가 할당되지 않았습니다.

tcpdump: en1에서 수신 대기, 링크 유형 IEEE802_11_RADIO(802.11 plus radiotap header), 캡처 크기 65535 바이트

^C

캡처된 897개 패킷

필터에서 수신한 968개 패킷

커널에 의해 삭제된 0개 패킷

bash-3.2#

Wi-Fi 진단

가장 쉬운 캡처 방법은 Wi-Fi 진단이라는 그래픽 프로그램을 사용하는 것입니다.

Alt 키를 누른 채 오른쪽 상단 wifi 아이콘(일반적으로 연결하려는 SSID를 선택하는 아이콘)을 클릭하여 액세스할 수 있습니다.

목록에서 Open Wireless 진단 옵션을 클릭합니다.

문제 해결에 대한 기본 보고서를 실행하는 창이 나타납니다. 일반적으로 이는 관심 사항이 아닙니다.

이 창을 계속 열어 두고 화면 상단의 메뉴 모음으로 이동합니다. Window를 클릭합니다. 다양한 툴 목록이 표시됩니다(사이트 설문조사 또는 신호 분석에 유용함). 무선 스니퍼 캡처의 범위에서 Sniffer 옵션에 관심이 있으면 클릭합니다.

그러면 기본 채널과 채널 폭을 선택하기만 하면 됩니다.

스니퍼 캡처는 Mac Os Sierra의 경우 데스크톱 또는 /var/tmp/에 저장되었습니다.

에어툴

여러 mac os x 버전을 지원하고 채널을 선택하는 데 더 쉬운 옵션으로 임베디드 스니핑 기능을 강화하는 일부 서드파티 툴도 있습니다. 한 가지 예는 Airtool입니다.

Windows 7 및 3.4를 사용한 무선 스니핑(더 이상 사용되지 않음)

소개

Microsoft 네트워크 모니터( 3.4)를 사용하면 표준 무선 어댑터를 사용하여 Windows 7에서 적절한 802.11a/b/g(또는 11n) 무선 스니핑을 수행할 수 있습니다.  OmniPeek에는 없지만 최신 버전(1.5 이상)의 Wireshark에서 저장된 파일을 읽을 수 있습니다. Microsoft에서 더 이상 지원하지 않으며 11n 및 11ac 어댑터에서 제대로 작동하지 않는 경우가 많습니다(대부분의 프레임이 누락됨).

Netmon 3.4는 XP SP3에서 지원되지만 XP를 실행할 때는 무선 스니핑을 지원하지 않습니다. Vista에서는 환경이 혼합됩니다.

이 문서의 Netmon 세부 섹션은 더 이상 사용되지 않으며 802.11ac 프레임을 안정적으로 캡처하지 않으므로 제거되었습니다.

Netmon을 사용하는 Windows의 무선 스니핑에서 세부 정보를 볼 수 있습니다.

스니퍼 모드에서 Cisco LAP(Lightweight Access Point)를 사용한 무선 스니핑

소개

Cisco WLC 및 LAP를 스니퍼 모드에서 유선 스니퍼와 함께 사용할 수 있습니다(Wireshark를 통한 최상의 결과). Omnipeek는 버전 10과 다르게 프로토콜을 해독합니다.

단일 유선 스니퍼는 여러 AP에서 패킷을 수집할 수 있으므로 다중 채널 추적을 실행하는 데 매우 유용합니다. 정적 시나리오의 경우 스니퍼 AP를 이동할 수 있는 경우 다른 스니핑 옵션에 대한 효과적인 대안으로 사용할 수 있습니다.

로밍 시나리오의 경우 일반적으로 스니퍼 AP는 클라이언트가 로밍하는 AP와 가까운 위치에 설치되며, 이는 클라이언트가 아닌 고정 AP의 "POV(point of view)"를 보고할 수 있습니다.

로밍 중에 클라이언트의 관점에서 RF를 확인하기 위해 테스트 클라이언트를 사용할 수 있는 여러 무선 NIC가 있는 랩톱으로 다중 채널 무선 추적을 캡처할 수 있습니다.

컨피그레이션 단계

1단계.  WLC / AP 측

다음은 스니퍼 모드 LAP를 사용하는 추적을 수집하기 위한 단계입니다.

스니퍼 모드에서 AP를 구성합니다.

AP가 재부팅될 수 있으며 클라이언트에 서비스를 제공할 수 없습니다. AP가 WLC에 다시 연결되면 AP의 라디오를 구성합니다(802.11b/g/n 또는 802.11a/n).

- 스니퍼 IP 주소 지정

- 채널 선택

- 스니핑 사용

스니퍼는 캡슐화된 802.11 트래픽을 수신하고 소스 포트 UDP/5555 및 목적지 UDP/5000이 있는 WLC 관리 IP 주소에서 airopeek 프로토콜을 사용합니다.

2단계. 스니퍼 사이드: Wireshark

Wireshark를 사용하여 트래픽을 수신하는 경우 다음 단계를 수행합니다.

- 스니핑 AP에서 오는 트래픽만 수신하도록 캡처 옵션을 설정합니다. 포트 UDP 5000에 대해서만 필터를 설정하는 경우, AP가 패킷을 프래그먼트화해야 하는 경우(PEEKREMOTE 캡슐화를 추가해야 하는 1500바이트 길이의 프레임을 스니핑한 경우) 캡처에서 IP 프래그먼트가 누락됩니다.

이 필터는 선택 사항이지만 모든 비무선 관련 트래픽을 캡처에서 제외하므로 권장됩니다. WLC가 UDP 포트로 트래픽을 전송하며 스니퍼 측에서 수신하는 애플리케이션이 없다고 가정해 보십시오. 그러면 WLC에서 수신한 각 패킷에 대해 ICMP 포트 도달 불가 응답이 발생합니다.

이것은 예상되지만, 필터는 쓸모 없는 이 트래픽을 제외하는 데 도움이되며, 추적이 더 크고 읽기 어렵게 만들 수 있습니다.

그런 다음 캡처를 시작합니다.

캡처된 트래픽은 다음과 같이 디코딩되어야 합니다. 802.11 트래픽을 보려면 PEEKREMOTE:

- 이제 802.11 트래픽을 표시할 수 있습니다.

이미지에 표시된 RF 정보(즉, 채널, 신호 강도, 노이즈 등)가 AP에 의해 추가됩니다.

3단계. 스니퍼측: OmniPeek

스니퍼 모드에서 WLC/AP의 트래픽 스트림 수신기로 OmniPeek를 사용하는 경우, 우선 Capture Options(캡처 옵션) 창의 Adapter(어댑터) 메뉴 아래에 Cisco Remote Adapter를 만들어야 합니다.

OmniPeek가 특정 WLC의 수신 트래픽을 필터링하지 않도록 하려면 적어도 하나의 어댑터가 필요합니다. 이름은 필수 필드이지만 IP Address 필드는 비워 둘 수 있습니다.

이 경우 OmniPeek는 UDP 포트에서 수신 대기하여 Wireless LAN Controller에서 데이터 스트림을 구체적으로 캡처하므로 트래픽(예: ICMP 포트 도달 불가)을 필터링할 필요가 없습니다.

캡처를 시작하기 전에 기본 OmniPeek 창에서 설정을 확인합니다.

이때 캡처를 시작할 수 있으며, 그 결과는 AP에서 보고한 RF 정보가 포함된 추적입니다.

참고: 기본적으로 OmniPeek 원격 어댑터는 AP 자체에서 보낸 타임스탬프를 선택합니다. 이 정보는 AP 클럭과 아무런 관련이 없으므로 결과 타임스탬프가 잘못될 수 있습니다. 단일 스니퍼 AP를 사용하는 경우 타임스탬프가 잘못될 수 있지만 최소한 일관성이 있습니다. 여러 AP를 스니퍼로 사용하는 경우(모든 AP가 자체 타임스탬프 정보를 보내므로 병합된 캡처에서 이상한 시간이 이동함) 더 이상 그렇지 않습니다.

솔루션

OmniPeek에 패킷 타임스탬프를 설정하기 위해 로컬 스니퍼 PC 시계를 사용하도록 명시적으로 지정할 수 있습니다.

이는 단일 및 다중 AP 시나리오를 모두 해결하며, OmniPeek를 실행하는 PC에 NTP 동기화 클럭이 있는 한 정확하고 일관된 타임스탬프를 제공합니다.

방법 단계:

OmniPeek에서 다음 단계를 수행합니다.

1. 도구 > 옵션 > 분석 모듈로 이동합니다.

2. cisco remote adapter를 검색한 다음 두 번 클릭하여 옵션을 표시합니다.

3. [시간 기록] 옵션을 클릭한 다음 확인을 클릭하고 캡처를 다시 테스트합니다.

Cisco® Autonomous(IOS) AP를 사용한 무선 스니핑

자동 AP를 사용하여 무선 패킷 캡처를 수집할 수 있습니다. 이 지침에는 에어 캡처를 수행하는 방법이 나열되어 있습니다.

1. 캡처를 수행할 dot11 라디오 인터페이스를 입력합니다. 스테이션 역할을 스니퍼로 설정하고 Wireshark를 실행할 수 있는 서버/PC IP를 추가하고 캡처를 수집한 다음 채널을 선택합니다. monitor frames 명령으로 지정하는 포트는 AP가 캡처를 전송하는 대상 UDP 포트일 수 있습니다.

명령을 사용합니다

목적

1단계

정수 {d0 | d1}

무선 인터페이스를 구성하기 위한 인터페이스 컨피그레이션 명령 모드를 시작합니다.

2단계

스테이션 역할 스니퍼

스니퍼로 스테이션 역할을 변경합니다.

3단계

채널 번호

스니퍼 모드에서 작동할 채널을 선택합니다.

4단계

닫히지 않음

인터페이스 종료를 반대로 합니다.

5단계

종료

인터페이스 컨피그레이션 명령 모드를 종료합니다.

6단계

스니퍼 ip 주소 목적지 ip 포트 번호

AP가 모든 패킷을 리디렉션할 IP 주소 및 포트 번호를 설정합니다. 1024~65535 사이의 포트 번호에서 IP 주소를 지정할 수 있습니다.

7단계

wireshark 활성화

엔드포인트에서 Wireshark를 사용하는 경우 Wireshark 헤더가 패킷에 추가됩니다.

샘플 설정:

ap(config)# int d0

ap(config)-if# 스테이션 역할 스니퍼

ap(config)# 채널 11

ap(config)# 종료 안 함

ap(config)# 종료

ap(config)# sniffer ip-address 10.10.1 30 port 555

ap(config)# wireshark 활성화

2. 서버/PC에서 Wireshark를 시작합니다. Capture(캡처) > Options(옵션)로 이동합니다. 이더넷 NIC(LAN)를 선택하고 필터를 추가하여 1단계에서 지정한 UDP 포트로 트래픽만 캡처합니다.

3. Wireshark 캡처를 시작합니다.

캡처 파일을 TAC 서비스 요청에 업로드

캡처 파일이 너무 커서 이메일로 보낼 수 없는 경우, TAC 서비스 요청에 업로드할 수 있습니다.

https://tools.cisco.com/ServiceRequestTool/query/

SR 번호를 입력한 다음 파일 업로드를 클릭합니다.

스니퍼 분석

무선 캡처를 분석하려면 나열된 링크를 참조하십시오. 각 문서는 이전 문서를 기반으로 작성되므로 순서대로 읽을 수 있도록 설계되었습니다.  무선 추적을 읽을 때 802.11 무선 사양을 이해하는 것이 좋습니다.  이러한 문서는 패킷 흐름과 무선 추적에서 찾을 내용을 이해하는 데 도움이 됩니다. 802.11 무선 사양을 가르치기 위한 것이 아닙니다.

802.11 스니퍼 캡처 분석 - 물리적 레이어

소개: 무선 패킷 캡처의 물리적 레이어 정보

캡처된 패킷에는 프레임 데이터의 복사본이 포함되어 있지만 각 프레임 앞에 프레임이 캡처된 방법에 대한 정보를 제공하는 메타데이터 헤더가 추가됩니다.  유선 패킷에서는 메타데이터가 많지 않습니다. 프레임 번호, 패킷이 캡처된 날짜, 패킷의 길이입니다.  유선 패킷 분석을 수행할 때 물리적 레이어에 대해 너무 큰 관심을 갖는 경우는 거의 없습니다. 비트 오류율이 1010이면, 일반적으로 캡처된 비트가 해당 비트라고 가정합니다.

무선은 전적으로 또 다른 이야기입니다. 물리적 레이어는 유선 네트워크보다 복잡하고 위험합니다.  상위 레이어를 기준으로 캡처를 분석하기 전에 일반적으로 캡처가 수행된 물리적 레이어를 이해하는 것이 좋습니다.  물리적 레이어가 제대로 작동하지 않으면 상위 레이어는 결코 기회를 가질 수 없습니다.

물리적 레이어 특성은 특히 다음과 같은 사항에 유의해야 합니다.

신호 강도(RSSI, 신호 강도, 신호/노이즈 비율)  일반적으로 RSSI에 주력하는 것이 가장 좋습니다(제공되는 경우). 스니핑 어댑터가 패킷을 수신한 전력 레벨(dBm):

- RSSI < -90dBm: 이 신호는 수신기가 수신할 수 있는 신호 경계에서 매우 약합니다.

- RSSI -67dBm: Cisco가 VoWLAN을 지원하기에 적합하다고 생각하는 것의 가장자리인 매우 강력한 신호입니다.

- RSSI > -55dBm: 매우 강력한 신호입니다.

- RSSI > -30dBm: 스니퍼가 송신기 바로 옆에 있습니다.

채널(주파수). 무선 LAN은 3개에서 25개 정도의 다양한 채널을 지원할 수 있으므로, 캡처한 채널을 정확히 아는 것이 중요합니다.  특정 AP에서 스니프를 가져오려는 경우에는 해당 AP의 채널에 스니프를 잠그고 캡처가 해당 채널에 있는지 검증합니다. 그렇지 않으면 캡처가 무가치할 수 있습니다.

.

데이터 속도는 1Mbps에서 최대 300Mbps까지 가능합니다.  데이터 전송이 항상 송신기에서 수신기로 전송되는 것이 아닌 이유를 이해하려면 어떤 데이터 속도가 사용되고 있는지 알아야 합니다.  -80dBm의 "한계" RSSI는 54Mbps로 변조된 패킷에 대해 매우 잘 작동할 수 있지만 6Mbps에서는 만족스러울 수 있습니다.

무선 패킷 헤더 - 예

상이한 무선 스니퍼들은 상이한 메타데이터 헤더 포맷들을 사용하여 무선 물리 계층을 인코딩할 수 있다.  정보의 정확성은 사용 중인 특정 어댑터 하드웨어 및 드라이버에 따라 달라집니다.  잡음과 같은 일부 값들은 일반적으로 고려된다.

이러한 샘플은 데이터 속도, 주파수 및 RSSI 필드가 강조 표시됩니다.

Mac OS X 10.7 무선 진단(Broadcom 어댑터)

OS X 10.7은 Wireshark에서 다음과 같은 Radiotap v0 헤더를 사용합니다.

OmniPeek 6.8(Ralink USB 어댑터)

Wireshark에서 OmniPeek 캡처는 다음과 같은 Airopeek 헤더를 사용합니다.

Wireshark(1.6.x 기준)는 OmniPeek 캡처에서 모든 무선 메타데이터를 디코딩하는 방법을 알지 못합니다. OmniPeek 자체에서 볼 수 있는 동일한 프레임에는 신호 dBm, 노이즈 레벨 및 노이즈 dBm이 표시됩니다.

Netmon 3.4

무선 파일을 Wireshark 열로 적용.

무선 필드를 열로 적용한 경우 무선 스니프가 발생하는 상황을 훨씬 쉽게 이해할 수 있습니다. 그 방법은 다음과 같습니다.

1. 패킷 세부사항 섹션에서 관심 분야를 찾은 다음(필요한 경우 먼저 해당 헤더 섹션을 확장합니다) 마우스 오른쪽 버튼으로 클릭합니다.  열로 적용을 선택합니다.

2. 신규 열이 나타납니다.  이제 열 머리글을 마우스 오른쪽 단추로 클릭하고 열 세부 정보 편집을 선택하여 열의 크기를 조정하고 이름을 바꾼 다음 원하는 대로 열을 이동할 수 있습니다.

3. 다른 관심 열에 대하여 반복합니다.  이제 캡처의 물리적 레이어 측면을 더 효과적으로 처리할 수 있습니다.

4. 새 열을 적용한 후 다음에 Wireshark를 실행하면 열을 사용할 수 있습니다. 열이 표시되지 않으면 열 머리글을 마우스 오른쪽 단추로 누르고 표시된 열을 선택합니다.

802.11 스니퍼 캡처 분석 - Wireshark 필터링

소개

'802.11 스니퍼 캡처 분석 - Wireshark 필터링

Wireshark 필터링-wlan

목표

이 문서에서는 wireshark를 설정하는 방법을 안내하고 wireshark 필터라고 하는 wireshark 프로그램 내에서 다양한 도구를 사용하는 흥미로운 패킷을 분석하는 데 도움이 될 수 있습니다.

사전 요구 사항

Wireshark 툴 자체는 잘 알고 있고 프로토콜, 네트워크의 토폴로지 및 스니퍼 추적을 위해 고려할 데이터 포인트를 이해하지 못한다면 문제 해결 프로세스를 완료하는 데 도움이 되지 않습니다. 이는 유선 네트워크용이든 무선 네트워크용이든, 패킷을 네트워크에 올리기 전에 무선 네트워크를 통해 패킷을 캡처하는 경우에 적용됩니다. 무선 mac 주소의 스트리핑은 AP에서 수행합니다.

무선 스니퍼 추적을 캡처해야 하는 이유

유선 스니퍼 추적을 사용하지만 흥미로운 패킷을 찾을 수 없는 유선 네트워크에서 트래픽 또는 데이터를 검사할 때 누락되는 위치를 알아야 합니다. 의심스러운 경우, 무선이 제대로 작동하거나 작동하지 않는(허공에 누락) 최초 출처 지점을 통과했는지까지 확인할 수 있습니다. AP에서 DS 또는 배포 시스템에 전달하거나 AP가 유선 측에 전달하거나 번역할 수 없는 경우, AP가 공중에 제대로 전달하지 못한 것입니다. 그런 다음 무선 스니퍼 추적을 사용하여 무선 네트워크 문제를 식별하고 현지화하는 것이 중요합니다.

무선 스니퍼 캡처 필터를 사용해야 하는 이유

네트워크 관련 문제의 트러블슈팅에 있어서 많은 종속 관계가 있으며, 모든 것이 계층화된 모델에서 작동하며 각 데이터 레이어는 그 하위 레이어에 따라 달라집니다. 여러 구성 요소 또는 네트워크 요소가 있으며, 장치의 구성 및 적절한 작동 덕분에 원활한 네트워크 운영이 가능해집니다. 작동 중인 네트워크가 작동을 멈추면 문제를 지역화하기 위한 논리적 접근 방식이 필요합니다. 일단 파악되면 정확한 실패 지점을 찾기가 어렵다. 그런 상황에서, 저격수는 우리의 원조에 온다. 이러한 트러블슈팅 프로세스는 최상의 접근 방식에도 불구하고, 트러블슈팅 기술에 대한 지식이 있는 경우에도 복잡해질 수 있습니다. 문제는 네트워크 장치를 통해 이동하는 패킷을 캡처할 경우 대용량 파일을 보유할 수 있으며, 패킷 세부 정보가 많이 포함된 상태로 충분히 오래 캡처할 경우 1G에 도달할 수도 있다는 것입니다. 이렇게 많은 양의 데이터를 사용하면 문제를 정확히 파악하는 데 시간이 많이 소요될 수 있으며 매우 어려운 작업이 될 수 있습니다. 필터링은 문제를 신속하게 찾아내고 원치 않는 트래픽을 제거하며 한 번에 집중하기 위해 변수를 줄이는 데 도움이 됩니다. 이렇게 하면 수집된 트래픽에서 흥미로운 트래픽이 있는지 없는지 여부를 빠르게 찾을 수 있습니다.

- Display Filters(디스플레이 필터) - 많은 정보를 캡처한 후 원하는 패킷만 시각화할 수 있도록 지원합니다.

- Capture Filters(캡처 필터) - 처음부터 관심 있는 패킷이 무엇인지 알고 해당 패킷만 캡처합니다.

- 패킷 색칠을 위한 필터 - 디스플레이 필터 또는 캡처 필터를 강화하기 위한 시각적 보조 수단으로 사용되거나, 상위 레벨 접근 방식을 위해 다양한 색상으로 여러 패킷을 분류하기 위해 필터 없이 사용할 수 있습니다.

디스플레이 필터 및 캡처 필터를 사용하는 경우

검색할 내용을 알고 해당 이벤트에 대한 트래픽을 실행할 때 이를 확인하려고 할 때는 캡처 필터를 사용하는 것이 좋습니다. 교통 체증이 심한 환경에서 두 시간 이상 실행할 때 캡처됩니다. 이렇게 하면 수집된 데이터를 파일 크기 측면에서 적절한 크기로 유지하는 데 도움이 됩니다.

문제의 원인이 무엇인지 확실하지 않은 지점에 있으며 동작 임의 특성인 경우, 문제 발생 패턴의 가능한 기간 내에서 패킷 캡처를 1~2시간 정도 실행하고 모든 트래픽을 캡처합니다. 그런 다음 검색 중인 정보만 시각화하려면 Display filters를 사용합니다. 이 사용 외에도 모든 캡처 및 색상 지정 규칙을 사용하여 패킷 흐름을 쉽게 분류하거나 구분할 수 있도록 서로 다른 색상으로 할당된 특정 유형의 패킷에 대한 주의를 끌 수 있습니다.

필터링 방법

일반적인 wireshark 스니퍼 추적 내의 다양한 필드를 이해해야 합니다. 이를 분류하고 각 필드를 정의합니다.

Filtering을 사용하기 위해 알아야 할 3가지 항목에 집중합니다.

- 캡처 필터

- 필터 표시

- 색 규칙 필터

자세한 내용을 살펴보기 전에 wireshark에 대한 스니퍼 캡처 창의 예를 살펴보겠습니다.

메뉴 모음

철사 상어 창의 메뉴 표시줄입니다.

여기에는 다음 항목이 포함됩니다.

- 파일 - 이 메뉴에는 캡처 파일을 열고 병합하는 항목, 저장/인쇄/캡처 내보내기가 포함되어 있습니다.

Wireshark를 종료하기 위한 것입니다.

- Edit(수정) - 이 메뉴에는 패킷을 찾거나, 시간 참조를 찾거나, 하나 이상을 표시하는 항목이 포함되어 있습니다.

패킷, 구성 프로필 처리, 환경 설정(잘라내기, 복사, 붙여넣기)

(현재 구현되지 않음).

- View(보기) - 이 메뉴는 캡처된 데이터의 표시를 제어하며,

패킷, 글꼴의 확대/축소 기능, 별도의 창에 패킷 표시, 확장 및

패킷 세부사항의 트리를 축소합니다.

- 이동 - 이 메뉴에는 특정 패킷으로 이동할 항목이 포함되어 있습니다.

- Capture(캡처) - 이 메뉴에서는 캡처를 시작 및 중지하고 캡처 필터를 편집할 수 있습니다.

- Analyze(분석) - 이 메뉴에는 표시 필터를 조작하거나, 를 활성화 또는 비활성화하는 항목이 포함되어 있습니다.

프로토콜 분류, 사용자 지정 디코딩 구성, TCP 스트림 사용

- 통계 - 이 메뉴에는 요약을 포함하는 다양한 통계 창을 표시하는 항목이 포함되어 있습니다

프로토콜 계층 구조 통계를 표시하는 등 많은 작업을 수행합니다.

기타.

- 텔레포니 - 이 메뉴에는 다양한 텔레포니 관련 통계 창을 표시하는 항목이 포함되어 있습니다.

미디어 분석, 플로우 다이어그램, 프로토콜 계층 구조 통계 표시,

훨씬 더.

- 도구 - 이 메뉴에는 방화벽 생성 방법과 같이 Wireshark에서 사용할 수 있는 다양한 도구가 포함되어 있습니다

ACL 규칙.

- Internals(내부) - 이 메뉴에는 Wireshark 내부 정보를 표시하는 항목이 포함되어 있습니다.

- Help(도움말) - 이 메뉴에는 사용자를 돕기 위한 항목(예: 몇 가지 기본 도움말, 수동)이 포함되어 있습니다.

다양한 명령줄 도구의 페이지, 일부 웹 페이지에 대한 온라인 액세스,

대화에 대한 일반적인 내용입니다.

기본 도구 모음

기본 도구 모음을 사용하면 자주 사용하는 항목에 빠르게 액세스할 수 있습니다. 이 도구 모음은 사용자가 사용자 지정할 수 없지만, 화면에 더 많은 패킷 데이터를 표시하는 데 필요한 공간이 있는 경우 보기 메뉴를 사용하여 숨길 수 있습니다. 메뉴에서처럼 현재 프로그램 상태에 유용한 항목만 사용할 수 있습니다. 다른 항목은 회색으로 표시됩니다. 예를 들어 캡처 파일을 로드하지 않은 경우 캡처 파일을 저장할 수 없습니다.

필터 도구 모음

필터 도구 모음을 사용하면 표시 필터를 빠르게 편집하고 적용할 수 있습니다.

Filter(필터): 필터 구성 대화 상자, Capture Filters(캡처 필터) 및 Display Filters(디스플레이 필터) 대화 상자를 표시합니다.

- 영역의 입력을 필터링하여 표시 필터 문자열 식을 입력하거나 편집합니다. 입력하는 동안 필터 문자열의 구문 검사가 수행됩니다. 불완전하거나 잘못된 문자열을 입력하면 배경이 빨간색으로 변하고 올바른 문자열을 입력하면 녹색이 됩니다. 목록에서 이전에 입력한 필터 문자열을 선택하려면 풀다운 화살표를 클릭합니다. 풀다운 목록의 항목은 프로그램이 다시 시작된 후에도 계속 사용할 수 있습니다.

- 이 필드에서 내용을 변경한 후에는 Apply(적용) 버튼(또는 Enter/Return 키)을 눌러 이 필터 문자열을 화면에 적용하는 것을 잊지 마십시오. 이 필드는 현재 적용된 필터가 표시되는 위치이기도 합니다.

- 표현식: 표현식 추가...라는 중간 단추는 [필터 표현식] 대화 상자에 설명된 프로토콜 필드 목록에서 표시 필터를 편집할 수 있는 대화 상자를 엽니다.

- Clear는 현재 표시 필터를 재설정하고 편집 영역을 지웁니다.

- 편집 영역의 현재 값을 새 표시 필터로 적용합니다.

Packet List 창

패킷 목록 창에는 현재 캡처 파일의 모든 패킷이 표시됩니다.

패킷 목록의 각 라인은 캡처 파일의 한 패킷에 해당합니다. 이 창에서 라인을 선택하면 Packet Details(패킷 세부사항) 및 Packet Bytes(패킷 바이트) 창에 더 자세한 정보가 표시됩니다.

Packet Details 창

패킷 세부 정보 창에는 현재 패킷(Packet List 창에서 선택됨)이 더 자세한 형태로 표시됩니다.

Packet Bytes 창

Packet bytes 창에는 현재 패킷의 데이터(Packet List 창에서 선택)가

hexdump 스타일입니다.

상태 표시줄

상태 표시줄에는 정보 메시지가 표시됩니다. 일반적으로 왼쪽에는 컨텍스트 관련 정보가 표시되고, 가운데 부분에는 현재 패킷 수가 표시되며, 오른쪽에는 선택한 컨피그레이션 프로필이 표시됩니다. 텍스트 영역 사이의 핸들을 드래그하여 크기를 변경합니다.

초기 상태 표시줄

캡처 파일이 로드되지 않은 상태에서 이 상태 표시줄이 표시됩니다. 예를 들어 Wireshark가 시작된 경우입니다.

탭 레이블의 컨텍스트 메뉴(마우스 오른쪽 단추 클릭)에는 사용 가능한 모든 페이지의 목록이 표시됩니다. 이 기능은 창의 크기가 모든 탭 레이블에 비해 너무 작은 경우 유용합니다.

상태 표시줄

상태 표시줄에는 정보 메시지가 표시됩니다. 일반적으로 왼쪽에는 컨텍스트 관련 정보가 표시되고, 가운데 부분에는 현재 패킷 수가 표시되며, 오른쪽에는 선택한 컨피그레이션 프로필이 표시됩니다. 텍스트 영역 사이의 핸들을 드래그하여 크기를 변경합니다.

로드된 캡처 파일이 있는 상태 표시줄

- 왼쪽에는 캡처 파일, 이름, 크기 및 캡처된 동안의 경과 시간에 대한 정보가 표시됩니다.

- 왼쪽의 색칠된 글머리 기호는 현재 로드된 캡처 파일에서 발견된 최고 전문가 정보 레벨을 보여줍니다. 이 아이콘 위에 마우스를 올려 놓으면 전문가 정보 수준에 대한 텍스트 설명이 표시됩니다. 이 아이콘을 클릭하면 전문가 정보 대화 상자가 표시됩니다.

- 중간 부분에는 캡처 파일의 현재 패킷 수가 표시됩니다.

다음 값이 표시됩니다.

- Packets - 캡처된 패킷 수

- Displayed(표시됨) - 현재 표시 중인 패킷 수입니다.

- Marked - 표시된 패킷의 수

- Dropped - 삭제된 패킷 수(Wireshark가 모든 패킷을 캡처할 수 없는 경우에만 표시됨)

- Ignored - 무시된 패킷 수(패킷이 무시되는 경우에만 표시됨)

- 오른쪽에는 선택한 컨피그레이션 프로필이 표시됩니다. 상태 표시줄의 이 부분을 클릭하면 사용 가능한 모든 컨피그레이션 프로필이 포함된 메뉴가 나타나며, 이 목록에서 선택하면 컨피그레이션 프로필이 변경됩니다.

캡처 필터 사용

Capture Interfaces(인터페이스 캡처) 옵션을 클릭하고 PC의 네트워크에서 실행 중인 패킷을 캡처하는 데 사용되는 드롭다운 메뉴에서 Network adapter(네트워크 어댑터)를 선택합니다. Capture Filters(캡처 필터)를 클릭하고 필터 이름과 필터 문자열을 입력하거나 상자에 알려진 필터 문자열을 직접 입력합니다. 그리고 버튼을 누르세요 이제 와이어 상어 스니퍼 프로그램은 모든 유형의 프로토콜의 실시간 패킷의 거대한 흐름 사이에서만 관심 있는 패킷을 캡처합니다.

필터 표시

캡처된 파일을 로드했으면 이제 관심 있는 패킷을 표시하거나 관심 없는 패킷을 피하도록 필터를 설정합니다. 이 작업은 단순 필터 식 또는 논리 연산자를 사용하여 복잡한 필터 문자열을 구성하는 식의 조합을 통해 수행할 수 있습니다.

Analyze를 클릭합니다. Display Filter(필터 표시)를 선택합니다.

이 예에서는 노란색으로 강조 표시된 영역에서 802.11 무선 패킷 캡처 추적의 비컨 패킷만 필터링하는 필터를 생성합니다.

표시 필터와 마찬가지로 Find packet(패킷 찾기)을 클릭한 후 필터를 적용하여 특정 패킷을 찾을 수 있습니다.

Filter(필터) 버튼을 찾고 필터 상자에 필터 값을 입력합니다. 문자열을 모르는 경우 더 자세히 파고 filter(필터)를 클릭한 다음 New(새로 만들기) 버튼을 누르고 필터 문자열의 이름을 지정하고 필터 문자열을 적용하거나 상자에 입력합니다. 특정 필터 스프링을 모르는 경우 이를 구성하고 다양한 프로토콜 옵션이 있는 표현식 버튼을 선택할 수 있습니다.

원하는 옵션을 선택하고 확장하면 선택할 수 있는 옵션이 더 많이 제공됩니다.

Logical operator(논리 연산자) 상자를 선택하여, 입력할 값을 입력하고 필터를 적용하는 데 사용할 수 있습니다.

다양한 비교 연산자를 사용하는 값을 비교하는 표시 필터를 작성할 수 있습니다.

색상 필터 규칙 사용

Wireshark에서 사용할 수 있는 매우 유용한 메커니즘은 패킷 색상화입니다. 필터에 따라 패킷을 컬러화하도록 Wireshark를 설정할 수 있습니다. 그러면 원하는 패킷을 강조할 수 있습니다. Wireshark를 설정하여 만들려는 필터에 따라 패킷을 색상화할 수 있습니다. 그러면 (일반적으로) 관심 있는 패킷을 강조할 수 있습니다.

이 예에서 패킷은 언급된 필터에 따라 비컨(Beacon), 확인 응답(Acknowledgement), 프로브 응답(Probe Response) 및 인증 취소(Deauthentication)에 대해 색상이 지정됩니다.

View를 클릭합니다. 기본 도구 모음에서 색상 지정 규칙 또는 색상 지정 규칙 편집을 선택합니다.

이렇게 하면 색상 지정 규칙이 열리고 새로 만들기 또는 편집을 사용하여 새 색상 지정 필터를 추가할 수 있습니다. 패킷을 선택하거나 필터 문자열을 편집하고 원하는 색상을 할당하거나 조정합니다.

색상 편집 대화 상자에서 색상 필터의 이름을 입력하고 필터 텍스트 필드에 필터 문자열을 입력합니다. Edit Color Filter 대화 상자는 beacon 및 wlan.fc.type_subtype == 8 값을 표시합니다. 이는 컬러 필터의 이름이 Beacon이고 필터가 비컨 필터 문자열인 wlan.fc.type_subtype == 8 유형의 프로토콜을 선택할 수 있음을 의미합니다. 이러한 값을 입력한 후에는 필터 표현식과 일치하는 패킷의 전경색과 배경색을 선택할 수 있습니다. 전경색.. 또는 배경색...을 클릭하여 이 작업을 수행합니다.

매우 유용한 기능은 예시에 나와 있는 것처럼 필터를 "tac80211color" 파일로 내보내거나 컬러링 필터를 구성하고 저장하는 것입니다. 가져올 수 있습니다. 문제 해결 폴더에 여러 개의 색상 규칙 파일을 만들고 문제를 해결할 때마다 편의상 템플릿으로 사용할 수 있습니다.

혁신적으로 생각하고 라우팅, wlan, 스위칭 등의 색상 필터 템플릿 파일을 맞춤 설정할 수 있습니다. 색상 필터 파일을 선택하고 문제 해결에 따라 가져오기만 하면 됩니다.

Support Forum - Coloring Rules(지원 포럼 - 색상 규칙)를 다운로드하고 사용할 수 있는 색상 규칙이 있습니다.

이는 wireshark packets 창의 마지막 모양이 컬러 필터 파일 다음에 나타나는 모양입니다

tac80211color를 가져와서 적용합니다.

802.11 스니퍼 캡처 분석 - 관리 프레임 및 개방형 인증

소개

802.11 스니퍼 캡처 분석 - 관리 프레임 및 개방형 인증

802.11 - 프레임 및 개방형 인증

802.11 패킷 분석기를 사용하는 무선 LAN 네트워크를 분석하거나 문제를 해결하려면 다양한 802.11 프레임 유형을 철저히 파악하여 wlan 네트워크에서 문제 영역의 원인을 지역화할 수 있는 포인터를 찾아야 합니다. NIC(Radio Network Interface Card)와 액세스 포인트 간의 통신을 모니터링할 수 있는 omnipeek 및/또는 wireshark와 같은 툴을 사용하는 wlan 스니퍼 추적을 사용합니다. 무선 LAN 작동 중에 발생하는 각 프레임 유형을 파악하고 네트워크 문제를 해결해야 합니다. WLAN RF 환경에서는 무선 전송 조건이 동적으로 변경될 수 있으므로 WLAN에서 조정이 큰 문제가 됩니다. 관리 및 제어 패킷은 이러한 조정 기능 전용입니다.

RF 환경과 관련하여 wlan 네트워크에서 발생하는 wlan 문제의 원인을 찾으려면 보안 없이 개방형 인증을 사용하여 wlan 네트워크를 테스트하는 것이 가장 좋습니다. 이러한 접근 방식을 사용할 경우 RF 연결 문제가 표면화되며 더 강력한 암호화 및 OSI 계층의 상위 계층으로 이동하기 전에 이 문제를 해결할 수 있습니다. 802.11 사양의 인증은 사용자를 인증하는 대신 무선 스테이션 또는 장치를 인증하는 데 기반을 둡니다.

802.11 사양 클라이언트 인증 프로세스에 따라, 이들은 위에 언급 한 바와 같은 트랜잭션입니다.

1. 액세스 포인트는 인접한 wlan 클라이언트에서 수신하는 비콘 프레임을 지속적으로 전송합니다.

2. 클라이언트는 모든 채널에서 자체 프로브 요청 프레임을 브로드캐스트할 수도 있습니다.

3. 범위 내 액세스 포인트는 프로브 응답 프레임으로 응답합니다.

4. 클라이언트는 액세스에 가장 적합한 액세스 포인트(AP)를 결정하고 인증 요청을 보냅니다.

5. 액세스 포인트가 인증 응답을 보냅니다.

6. 인증에 성공하면 클라이언트는 연결 요청 프레임을 액세스 포인트에 보냅니다.

7. 액세스 포인트가 연결 응답으로 회신합니다.

8. 이제 클라이언트가 액세스 포인트에 트래픽을 전달할 수 있습니다.

802.11 클라이언트 인증 프로세스

무선 링크를 관리 및 제어하는 무선 상에서 발생하는 802.11 MAC Layer 2 통신에는 3가지 유형의 프레임이 사용됩니다.

관리 프레임, 제어 프레임 및 데이터 프레임입니다. 이러한 프레임이 무엇으로 구성되어 있는지 자세히 알아보고 wlan 스니퍼 추적을 사용하는 동안 wlan 문제를 더 잘 분석할 수 있습니다.

관리 프레임

802.11 관리 프레임을 통해 스테이션은 통신을 설정하고 유지 관리할 수 있습니다. 관리 패킷은 인증, 연결 및 동기화를 지원하는 데 사용됩니다.

다음은 일반적인 802.11 관리 프레임 하위 유형입니다.

- 인증 프레임: wlan 토폴로지 내의 네트워크 멤버십을 나타내는 프레임입니다. 802.11 인증은 액세스 포인트가 무선 NIC의 ID를 허용하거나 거부하여 리소스를 생성하는 프로세스입니다. 인증은 네트워크에서 보내고 받는 기능을 제한합니다. 디바이스가 802.11 WLAN에 연결을 시도하는 첫 번째 단계입니다. 기능은 관리 패킷의 교환에 의해 처리됩니다. 인증은 관리 패킷의 요청/응답 교환에 의해 처리됩니다. 교환되는 패킷 수는 사용된 인증 방법에 따라 달라집니다.

wlan.fc.type_subtype == 0x0b

NIC는 ID가 포함된 인증 프레임을 액세스 포인트로 전송하여 프로세스를 시작합니다. 개방형 시스템 인증(기본값)을 사용하는 경우 무선 NIC는 하나의 인증 프레임만 전송하고 액세스 포인트는 승인(또는 거부)을 나타내는 응답으로 인증 프레임에 응답합니다. 연결된 인증 ID가 있습니다. 이 ID는 네트워크에 연결할 때 현재 스테이션이 자체적으로 인증되는 이름입니다.

- Deauthentication frame(인증 해제 프레임): 스테이션이 보안 통신을 종료하려는 경우 다른 스테이션에 인증 해제 프레임을 보내는 알림 패킷입니다. 인증 스테이션(BSS 또는 기능적 등가물)과의 단방향 통신이며 수락해야 합니다. 그것은 즉시 효력을 발휘합니다.

wlan.fc.type_subtype == 0x0c

- 연결 요청 프레임: 802.11 연결을 통해 액세스 포인트는 무선 NIC에 대한 리소스를 할당하고 이 NIC와 동기화할 수 있습니다. NIC는 액세스 포인트에 연결 요청을 전송하여 연결 프로세스를 시작합니다. 이 프레임에는 NIC(예: 지원되는 데이터 속도) 및 연결할 네트워크의 SSID에 대한 정보가 전달됩니다. 연결 요청을 받은 액세스 포인트는 NIC와의 연결을 고려하며, (허용되는 경우) 메모리 공간을 예약하고 NIC에 대한 연결 ID를 설정합니다. 패킷은 발신자의 현재 연결을 표시할 수 있습니다. 연결 및 재연결은 요청/응답 관리 패킷에 의해 처리됩니다.

wlan.fc.type_subtype == 0x0

- 연결 응답 프레임: 액세스 포인트는 연결을 요청하는 라디오 NIC에 대한 수락 또는 거부 알림을 포함하고 요청자의 연결 ID를 포함하는 연결 응답 프레임을 보냅니다. 액세스 포인트가 무선 NIC를 수락하는 경우 프레임에는 연결 ID 및 지원되는 데이터 전송률과 같은 연결에 대한 정보가 포함됩니다. 연결의 결과가 긍정적일 경우 무선 NIC는 액세스 포인트를 활용하여 네트워크의 다른 NIC 및 액세스 포인트의 디스트리뷰션 측에 있는 시스템과 통신할 수 있습니다.

wlan.fc.type_subtype == 0x01

- 재연결 요청 프레임: 이 프레임은 연결 요청과 비슷하지만 용도가 다르며 클라이언트 로밍에서 주로 유용합니다. 무선 NIC가 현재 연결된 액세스 포인트에서 로밍하고 더 강력한 비컨 신호가 있는 다른 액세스 포인트를 찾으면 무선 NIC가 재연결 프레임을 새 액세스 포인트로 보냅니다. 그러면 새 액세스 포인트가 무선 NIC로의 전송을 기다리는 이전 액세스 포인트의 버퍼에 계속 있을 수 있는 데이터 프레임의 전달을 조정합니다. 성공적으로 연결하려면 발신자가 이미 인증되어야 합니다.

wlan.fc.type_subtype == 0x02

- 재연결 응답 프레임: 액세스 포인트는 재연결을 요청하는 라디오 NIC에 수락 또는 거부 알림이 포함된 재연결 응답 프레임을 보냅니다. 연관 프로세스와 유사하게, 프레임은 연관 ID 및 지원되는 데이터 레이트와 같은 연관에 관한 정보를 포함한다.

- Disassociation frame(연결 해제 프레임): 연결을 종료하려는 경우 스테이션이 다른 스테이션에 연결 해제 프레임을 보냅니다. 예를 들어, 정상적으로 종료되는 무선 NIC는 연결 해제 프레임을 전송하여 액세스 포인트에 NIC의 전원이 꺼져 있음을 알릴 수 있습니다. 그런 다음 액세스 포인트는 메모리 할당을 취소하고 연결 테이블에서 무선 NIC를 제거할 수 있습니다. 연결 해제는 액세스 포인트 또는 디바이스에서 간단하게 선언하는 것입니다.

Disassociation 패킷만 적용하고 찾는 데 사용되는 필터는 wlan.fc.type_subtype == 0x0a입니다.

- 비콘 프레임: 액세스 포인트는 주기적으로 비콘 프레임을 전송하여 존재를 알리고, 범위 내에 있는 무선 NIC에 대한 액세스 포인트에 대한 BSS, SSID 및 기타 매개변수와 멤버 스테이션을 동기화하는 데 도움이 되는 타임스탬프와 같은 정보를 릴레이합니다. 이 프레임의 목적은 CF(Contention Free Period)의 시작을 알리는 것이며 폴링에 의해 액세스 포인트에 전송 권한이 부여되는 것입니다. 무선 NIC는 지속적으로 모든 802.11 무선 채널을 검사하고 신호를 수신하여 연결할 최상의 신호 및 가용성을 가진 액세스 포인트를 선택합니다.

비컨 패킷만 적용하고 찾는 데 사용되는 필터는 wlan.fc.type_subtype == 0x08입니다.

- 프로브 요청 프레임: 스테이션 또는 클라이언트가 활성화되거나 PC에서 활성화된 WLAN 카드가 활성화되며 다른 스테이션 또는 액세스 포인트에서 정보를 얻어야 할 때 프로브 요청 프레임을 보냅니다. 무선 NIC가 프로브 요청을 보내 어떤 액세스 포인트가 범위 내에 있는지 확인한 후, SSID 및 클라이언트 요청 데이터 전송률과 일치하는 범위의 모든 액세스 포인트를 찾기 위해 클라이언트가 지원하는 모든 채널에서 프로브 요청 프레임이 전송됩니다...클라이언트가 최적의 액세스 포인트를 선택하기 위해 지원되는 데이터 전송률 및 액세스 포인트 로드 등 다양한 요소를 가중하여 연결할 액세스 포인트를 결정하고 프로브 응답으로 Ap에서 응답을 받은 후 802.11 네트워크의 인증 단계로 이동하는 것은 클라이언트에 달려 있습니다. 이 메커니즘 지원은 또한 로밍 스테이션이 새 액세스 포인트 검색에 연결된 상태로 셀 간에 이동하는 기능을 지원하는 데 도움이 됩니다.

Probe 요청 패킷만 적용하고 찾는 데 사용되는 필터는 wlan.fc.type_subtype ==0x04입니다.

- 프로브 응답 프레임: 프로브 요청에 대한 응답으로 일치 기준이 있는 APS는 동기화 정보 및 액세스 포인트 로드를 포함하며 기능 정보, 지원되는 데이터 속도 등이 포함된 프로브 응답 프레임으로 응답합니다.

Probe 요청 패킷만 적용하고 찾는 데 사용되는 필터는 wlan.fc.type_subtype ==0x05입니다.

컨트롤 프레임

802.11 제어 프레임은 스테이션 간의 데이터 프레임 전달을 지원합니다. 다음은 일반적인 802.11 제어 프레임 하위 유형입니다.

- RTS(Request to Send) 프레임: RTS/CTS 기능은 선택 사항이며, 숨겨진 스테이션이 동일한 액세스 포인트와 연결된 경우 발생하는 프레임 충돌을 줄입니다. 스테이션은 데이터 프레임을 전송하기 전에 필요한 양방향 핸드셰이크의 첫 번째 단계로 RTS 프레임을 다른 스테이션에 전송합니다.

wlan.fc.type_subtype == 0x1B

- ACK(Acknowledgement) 프레임: 데이터 프레임을 수신한 후, 수신 스테이션은 오류를 이용하여 프로세스를 점검하여 오류 유무를 감지합니다. 수신 스테이션은 오류가 발견되지 않으면 ACK 프레임을 송신 스테이션에 전송한다. 송신 스테이션이 일정 시간 후에 ACK를 수신하지 못하면 송신 스테이션은 프레임을 재전송할 수 있다.

wlan.fc.type_subtype == 0x1D

데이터 프레임

이 프레임들은 모바일 스테이션과 액세스 포인트 간에 기본적인 WLAN 통신이 이미 설정된 후 게임 후반부에 제공되는 프레임입니다. 항상 분석을 위해 802.11 데이터 프레임에 도달하며, 일반적으로 프레임 본문 내의 상위 레이어의 프로토콜과 데이터가 와이어에 도달하는 경우 무선으로 확인하고 분석합니다. 이러한 프레임은 프레임 본문 내의 웹 페이지, 프린터 제어 데이터 등과 같은 상위 레이어에서 데이터 패킷을 전송합니다.

wlan.fc.type_subtype == 0x20

패킷 분석기에서 802.11 데이터 프레임 내에서 프레임 바디의 내용을 관찰하여 관심 있는 트래픽을 확인할 수 있습니다.

참조

- IEEE 802.11 포켓 레퍼런스 가이드

- Cisco 지원 포럼

- Cisco 보안 액세스

802.11 스니퍼 캡처 분석 - PSK 또는 EAP를 사용하는 WPA/WPA2

WPA-PSK(TKIP)

1. 무선 네트워크가 있음을 알리고 무선 네트워크에 대한 모든 정보(데이터 속도, 채널, 보안 암호, 키 관리 등)를 포함하기 위해 비콘 프레임을 주기적으로 전송합니다.

2.AP로부터 정보를 얻기 위해 STA에 의해 프로브 요청이 전송됩니다.

3.프로브 응답 AP는 STA로부터 프로브 요청 프레임을 수신한 후, 능력 정보, 지원되는 데이터 속도 등을 포함하는 프로브 응답 프레임으로 응답합니다.

4.802.11 인증은 액세스 포인트가 무선 NIC의 ID를 허용하거나 거부하는 프로세스입니다. NIC는 ID가 포함된 인증 프레임을 액세스 포인트로 전송하여 프로세스를 시작합니다. 개방형 시스템 인증(기본값)을 사용하는 경우 무선 NIC는 하나의 인증 프레임만 전송하고 액세스 포인트는 수락(또는 거부)을 나타내는 응답으로 인증 프레임에 응답합니다.:

a.Dot11 인증 요청:

b.Dot11 인증 응답:

5. 802.11 연결을 통해 액세스 포인트는 무선 NIC에 대한 리소스를 할당하고 무선 NIC와 동기화할 수 있습니다. NIC는 액세스 포인트에 연결 요청을 전송하여 연결 프로세스를 시작합니다. 이 프레임에는 NIC(예: 지원되는 데이터 속도) 및 연결할 네트워크의 SSID에 대한 정보가 전달됩니다.

a.Dot11 연결 요청:

연결 요청을 받은 액세스 포인트는 NIC와의 연결을 고려하며, (허용되는 경우) 메모리 공간을 예약하고 NIC에 대한 연결 ID를 설정합니다.

b.Dott11 연결 응답:

6.4방향 핸드셰이크. 이 단계에서 PTK가 생성되고 PSK가 PMK로 사용되어 다음 값을 구성합니다.

a.AP가 ANonce와 함께 802.1x 인증 프레임을 전송합니다. STA는 이제 PTK를 구성하기 위한 모든 정보를 갖는다:

b.STA는 SNonce 및 MIC를 사용하여 802.1x 인증 프레임으로 응답합니다.

c.AP는 새 MIC 및 시퀀스 번호가 있는 GTK를 사용하여 802.1x 프레임을 구성합니다. 이 시퀀스 번호는 다음의 멀티캐스트 또는 브로드캐스트 프레임에서 사용되므로, 수신 STA는 기본 리플레이 검출을 수행할 수 있다:

d.STA ACK 전송:

이 시점부터 모든 데이터가 암호화되어 전송됩니다.

WPA2-PSK(AES/TKIP)

그 과정은 이전 절과 상당히 동일하다. 다른 정보만 강조 표시됩니다.

1.WPA2 AP 관리 프레임에는 유니캐스트 암호 그룹, AKM 정보 및 GTK 암호 그룹을 포함하는 RSN 요소가 포함됩니다(AES와 TKIP를 모두 선택한 경우 GTK에 대해 보다 강력한 암호화 방법을 사용할 수 있음).

2. 4방향 핸드셰이크 중에 유형 필드에 WPA2에 대한 버전 정보가 프레임에 포함됩니다.

참고: 4방향 핸드셰이크 키 교환 프레임이 추적에 포함되고 PSK가 알려진 경우 WEP/WPA-PSK/WPA2-PSK 암호화된 무선 트래픽을 해독할 수 있습니다.

wireshark에서 무선 트래픽을 암호화하려면 Preferences(환경 설정)-> Protocols(프로토콜)->IEEE 802.11로 이동하여 PSK 정보를 제공하고 Enable decryption(암호 해독 활성화) 옵션을 선택합니다.

WPA/WPA2 암호화 트래픽을 해독하려면 다음 형식으로 키를 지정합니다.

wpa-psk:PSK:SSI

참고: wireshark에서 특정 STA의 WLAN 트래픽을 필터링하려면 WLAN Statistic(WLAN 통계) 옵션을 사용할 수 있습니다.

특정 STA의 트래픽을 필터링하려면 Statistics(통계) > WLAN Traffic(WLAN 트래픽)으로 이동합니다. SSID 목록에서 STA가 연결된 해당 SSID를 선택하고 STA를 기반으로 필터를 적용합니다.

Wireshark를 사용하여 무선 패킷 캡처를 통해 WPA2 AES 데이터를 해독하는 방법

요건:

1. 캡처가 .pcap 형식입니다.

2. 프레임은 802.11 형식으로 표시됩니다.

3. Over The Air Capture가 수집된 WLAN의 SSID 이름 및 PSK를 확인합니다.

4. 키: 4 EAPOL 4 way 핸드셰이크를 캡처합니다.

이를 위해 가장 정확한 프로세스는 캡처를 시작한 다음 0에서 프로세스를 포착하기 위해 클라이언트를 인증하지 않는 것입니다. 즉, 4방향 EAPOL 핸드셰이크를 포함할 수 있습니다.

프레임이 PEEKREMOTE와 같은 다른 형식 내에 있는 경우 해당 프레임을 디코딩하는 데 필요할 수 있습니다. PEEKREMOTE 프레임을 디코딩하는 방법에 대한 섹션을 참조하십시오.

Process

Wireshark에서 캡처가 열리면 Edit(편집) > Preferences Menu(기본 설정 메뉴)로 이동합니다.

Protocols(프로토콜) 메뉴로 이동하여 IEEE 802.11을 찾습니다.

IEEE 802.11 섹션에서 Enable Decryption(해독 활성화) 확인란을 선택하고 Decryption Keys(해독 키) 레이블 옆의 Edit...(편집..) 버튼을 클릭합니다.

편집 메뉴에서 창 왼쪽에 있는 새로 만들기 단추를 클릭합니다.

키 유형에서 wpa-psk를 선택합니다.

키를 얻기 위해서는 암호 해독 프로세스가 수행되는 SSID 및 PSK의 정확한 이름을 아는 것이 중요합니다.

이 두 값을 가지고 다음 웹 사이트로 이동하여 이 두 요소를 기반으로 키를 생성합니다.

- WPA PSK(원시 키) 생성기

지정된 필드에 SSID 이름 및 PSK를 입력합니다. 필드에 입력한 문자열은 SSID 및 PSK에 대해 정의된 것과 같아야 합니다.

값을 정의했으면 Generate PSK(PSK 생성)를 클릭합니다. 그러면 키가 생성되어 복사되고 Wireshark로 돌아갑니다.

생성된 키를 Key 필드에 붙여 넣습니다. OK(확인)를 클릭합니다.

그런 다음 Preferences 화면에서 Apply를 클릭합니다. 캡처가 디코딩되기 시작합니다.

디코딩되면 이전에 암호화된 802.11 패킷의 내용을 볼 수 있습니다.

WPA/WPA2 엔터프라이즈

1. dot1x (PEAP)가 있는 WPA(TKIP)/WPA2(AES)

이 프로세스에서는 802.11 관리 프레임에서 AKM 메서드 및 PTK/GTK와 AP 알림 특성을 제외하고 이전과 동일한 단계를 사용합니다.

1. 이 예에서 AP는 dot1x 인증을 사용하는 WPA(TKIP)/WPA2(AES)를 광고하며, PSK 인증의 경우 이 필드에 PSK가 포함되는지 여부와 상관없이 AKM에 대한 RSN 및 WPA 태그 특성 모두에 WPA 값이 포함됩니다. 또한 이 예에서는 TKIP가 WPA에 사용되고 AES가 WPA2에 사용됩니다.

b. STA는 AP가 광고하는 인증 방법 및 암호 그룹 중 하나를 선택합니다. 이 경우 AES가 포함된 WPA2가 선택되었습니다. RSN IE 매개변수에서 확인할 수 있습니다.

c. dot11 연결에 성공하면 dot1x 인증이 발생합니다. 이 프로세스에서는 STA가 신청자와 AAA 서버 간의 인증 및 인증서 교환 정보를 위해 어떤 EAP 방법을 사용하는지 볼 수 있습니다.

d. dot1x 인증에 성공하면 PMK는 AAA 서버의 Access-Accept 메시지에서 AP로 전송되며 동일한 PMK가 클라이언트에서 파생됩니다. 다음 4방향 핸드셰이크가 발생하고 PTK와 GTK가 성립합니다.

WLC와 AAA 서버 간의 RADIUS 교환:

일반 흐름도:

WPA(TKIP)/WPA2(AES)(dot1x 포함)(EAP-TLS)

이 인증 유형이 이전과 다른 점은 클라이언트가 "Client Hello" 메시지에서 인증서를 제공하고 인증서를 기반으로 클라이언트와 AAA 서버 간에 상호 인증이 수행된다는 것입니다.

STA와 WLC 간의 EAP 교환:

WLC와 AAA 서버 간의 RADIUS 교환:

일반 흐름도:

2.WPA(TKIP)/WPA2(AES)(dot1x 포함)(FAST)

dot1x 인증 단계만 이전 예와 약간 다릅니다. dot11 연결 dot1x 인증이 성공하면 AP는 dot1x ID 요청을 STA에 전송하고 STA는 ID 응답을 제공합니다. 응답은 사용 중인 PAC 프로비저닝(대역 내 PAC 프로비저닝(0단계) 또는 대역 외 PAC 프로비저닝)에 따라 달라집니다. 대역 내 프로비저닝의 경우 PAC는 AAA 서버에서 클라이언트로 전송됩니다. 클라이언트가 PAC를 가지고 있으면 이 지점에서 TLS 터널 설정이 시작되는 EAP-FAST 1단계로 이동합니다(1단계).

TLS 터널이 설정되면 내부 인증 방법(2단계)이 암호화된 터널 내부에서 시작됩니다. 인증에 성공하면 PMK는 AAA 서버에서 AP로 Access-Accept 메시지로 전송됩니다. STA에서 dot1x 교환을 기반으로 동일한 키가 파생됩니다. 이 키(PMK)는 STA와 AP 사이의 통신을 보호하는 데 사용될 수 있는 4-방향 핸드셰이크 동안 PTK를 계산하는 데 사용된다.

일반 흐름도:

802.11 스니퍼 캡처 분석 - 멀티캐스트

소개

멀티캐스트 스니핑

솔루션

컨트롤러는 두 가지 모드로 멀티캐스팅을 수행합니다.

- 유니캐스트 모드 — 이 모드에서는 컨트롤러가 컨트롤러에 연결된 모든 AP에 모든 멀티캐스트 패킷을 유니캐스트합니다. 이 모드는 비효율적이지만 멀티캐스트를 지원하지 않는 네트워크에 필요할 수 있습니다.

- 멀티캐스트 모드 — 이 모드에서 컨트롤러는 LWAPP 멀티캐스트 그룹에 멀티캐스트 패킷을 전송합니다. 이 방법은 컨트롤러 프로세서의 오버헤드를 줄이고 유니캐스트 방법보다 훨씬 효율적인 패킷 복제 작업을 네트워크로 전환합니다.

- 컨트롤러 GUI 또는 CLI를 사용하는 멀티캐스트 모드를 활성화할 수 있습니다.

WLC의 IGMP 스누핑

컨트롤러 소프트웨어 릴리스 4.2에서는 IGMP 스누핑을 도입하여 멀티캐스트 패킷을 보다 효율적으로 전달합니다. 이 기능이 활성화되면 컨트롤러는 클라이언트에서 IGMP 보고서를 수집하고, 보고서를 처리하며, 레이어 3 멀티캐스트 주소 및 VLAN 번호를 확인한 후 IGMP 보고서에서 고유한 MGID(Multicast Group ID)를 생성하고, 인프라 스위치에 IGMP 보고서를 전송합니다. 컨트롤러는 클라이언트로부터 보고서를 수신한 인터페이스 주소로 소스 주소와 함께 이러한 보고서를 전송합니다.

그런 다음 컨트롤러는 AP의 액세스 포인트 MGID 테이블을 클라이언트 MAC 주소로 업데이트합니다. 컨트롤러는 특정 멀티캐스트 그룹에 대한 멀티캐스트 트래픽을 수신하면 이를 모든 AP에 전달합니다. 그러나 해당 멀티캐스트 그룹을 수신 대기하거나 해당 멀티캐스트 그룹에 가입하는 활성 클라이언트가 있는 AP만 해당 특정 WLAN에서 멀티캐스트 트래픽을 전송합니다. IP 패킷은 인그레스 VLAN 및 대상 멀티캐스트 그룹에 대해 고유한 MGID와 함께 전달됩니다. 레이어 2 멀티캐스트 패킷은 인그레스 인터페이스에 대해 고유한 MGID와 함께 전달됩니다.

참고: IGMP 스누핑은 2000 Series 컨트롤러, 2100 Series 컨트롤러 또는 Cisco Integrated Services Router용 Cisco Wireless LAN Controller Network Module에서 지원되지 않습니다.

멀티캐스트 모드 사용 지침

네트워크에서 멀티캐스트 모드를 활성화할 때 다음 지침을 사용하십시오.

Cisco Unified Wireless Network 솔루션은 특정 목적을 위해 일부 IP 주소 범위를 사용합니다. 멀티캐스트 그룹을 구성할 때 이러한 범위에 유의하십시오. 권장하지 않지만 모든 멀티캐스트 주소를 LWAPP 멀티캐스트 그룹에 할당할 수 있습니다. 여기에는 OSPF, EIGRP, PIM, HSRP 및 기타 멀티캐스트 프로토콜에서 사용하는 예약된 링크 로컬 멀티캐스트 주소가 포함됩니다.

관리상 범위가 지정된 블록(239/8)에서 멀티캐스트 주소를 할당하는 것이 좋습니다. IANA는 239.0.0.0~239.255.255.255 범위를 개인 멀티캐스트 도메인에서 사용할 관리 범위 주소로 예약했습니다. 추가 제한 사항은 메모를 참조하십시오. 이러한 주소는 RFC 1918에 정의된 10.0.0.0/8과 같은 예약된 프라이빗 IP 유니캐스트 범위와 본질적으로 유사합니다. 네트워크 관리자는 인터넷의 다른 곳과 충돌할 염려 없이 도메인 내에서 이 범위의 멀티캐스트 주소를 자유롭게 사용할 수 있습니다. 이 관리 또는 개인 주소 공간은 엔터프라이즈 내에서 사용해야 하며, 해당 AS(Autonomous Domain)에서 해당 나가기 또는 항목이 차단되어 있어야 합니다.

참고: 239.0.0.X 주소 범위 또는 239.128.0.X 주소 범위를 사용하지 마십시오. 이러한 범위의 주소는 링크 로컬 MAC 주소와 중첩되며, IGMP 스누핑이 설정된 경우에도 모든 스위치 포트를 플러딩합니다.

Cisco에서는 엔터프라이즈 네트워크 관리자가 특정 멀티캐스트 애플리케이션의 범위를 제한하기 위해 이 주소 범위를 엔터프라이즈 네트워크 내의 더 작은 지리적 관리 범위로 세분화할 것을 권장합니다. 그러면 (대역폭이 풍부한) 캠퍼스를 떠나는 고속 멀티캐스트 트래픽이 방지되고 WAN 링크가 혼잡해집니다. 또한 컨트롤러 및 무선 네트워크에 도달하지 못하도록 고대역폭 멀티캐스트를 효율적으로 필터링할 수 있습니다.

컨트롤러에서 멀티캐스트 모드를 활성화할 때 컨트롤러에서 LWAPP 멀티캐스트 그룹 주소를 구성해야 합니다. AP는 IGMP(Internet Group Management Protocol)를 사용하여 LWAPP 멀티캐스트 그룹에 가입합니다.

- Cisco 1100, 1130, 1200, 1230, 1240 AP는 IGMP 버전 1, 2, 3을 사용합니다. 그러나 Cisco 1000 Series AP는 IGMP v1만 사용하여 멀티캐스트 그룹에 참가합니다.

- 멀티캐스트 모드는 레이어 3 LWAPP 모드에서만 작동합니다.

- 모니터 모드, 스니퍼 모드 또는 비인가 탐지기 모드의 AP는 LWAPP 멀티캐스트 그룹 주소에 가입하지 않습니다.

- 버전 4.1 이하를 실행하는 컨트롤러를 사용할 경우 모든 컨트롤러에서 동일한 멀티캐스트 주소를 사용할 수 있습니다. 버전 4.2 이상을 실행하는 컨트롤러를 사용하는 경우 컨트롤러에서 구성된 LWAPP 멀티캐스트 그룹이 네트워크에서 사용되는 각 컨트롤러마다 달라야 합니다.

- 버전 4.1 이하의 컨트롤러를 사용하는 경우 멀티캐스트 모드는 게스트 터널링, 사이트별 VLAN 또는 RADIUS를 사용하는 인터페이스 재정의와 같은 서브넷 간 모빌리티 이벤트에서 작동하지 않습니다. 유선 LAN에서 레이어 2 IGMP 스누핑/CGMP 기능을 비활성화하면 멀티캐스트 모드가 이러한 서브넷 모빌리티 이벤트에서 작동합니다.

이후 버전, 즉 4.2 이상에서는 멀티캐스트 모드가 게스트 터널링과 같은 서브넷 간 모빌리티 이벤트 전반에서 작동하지 않습니다. 그러나 RADIUS를 사용하는 인터페이스 재정의(IGMP 스누핑이 활성화된 경우에만 해당) 및 사이트별 VLAN(액세스 포인트 그룹 VLAN)과 함께 작동합니다.

- 컨트롤러는 UDP 포트 번호 12222, 12223 및 12224으로 전송된 모든 멀티캐스트 패킷을 삭제합니다. 네트워크의 멀티캐스트 애플리케이션이 해당 포트 번호를 사용하지 않는지 확인합니다.

- 멀티캐스트 트래픽은 802.11a 네트워크에서 6Mbps로 전송됩니다. 따라서 여러 WLAN에서 1.5Mbps로 전송하려고 하면 패킷 손실이 발생합니다. 그러면 멀티캐스트 세션이 중단됩니다.

멀티캐스트 구성(멀티캐스트-멀티캐스트 모드 사용)

Multicast - Multicast를 선택하고 그룹을 구성하면 모빌리티 그룹의 각 WLC에서 고유한 주소를 사용할 수 있습니다.

L3 디바이스에서 멀티캐스트 라우팅을 활성화하고 이러한 VLAN에서 PIM을 활성화합니다.  관리, AP-Manger, AP가 있는 VLAN 및 멀티캐스트 스트림을 수신하는 클라이언트가 있는 VLAN입니다.

예:

VLAN 40은 WLC 관리이고, VLAN 40은 AP용이며, VLAN 50은 클라이언트가 있는 곳입니다. 따라서 이러한 모든 SVI에서 멀티캐스트 명령을 실행해야 합니다.

모든 Multicast show 명령을 실행하여 AP에 대한 그룹이 제대로 구축되었는지 검증합니다(예: show ip mroute, show ip igmp groups).

WLC에서 IGMP 스누핑을 활성화할 수도 있습니다. WLC는 수신한 IGMP 메시지에 대한 자체 스누핑 테이블을 보유하므로 누가 스트림을 요청하는지 알 수 있습니다.

무선 LAN 컨트롤러

WLC에서 Global Multicast를 활성화하고 WLC에서 Enable Multicast - Multicast 모드를 활성화합니다.

클라이언트가 멀티캐스트 조인을 전송하면 WLC MGID에서 이를 볼 수 있습니다.

유선 네트워크의 멀티캐스트 컨피그레이션

전역 멀티캐스트 라우팅을 구성한 다음 각 인터페이스에서 PIM을 활성화합니다.

6504-WLCBUG#sh 실행 | i 멀티캐스트

ip 멀티캐스트 라우팅

6504-WLCBUG#sh int vla 50 실행

구성을 빌드하는 중...

현재 컨피그레이션: 119바이트

!

인터페이스 Vlan50

설명 // WLAN DHCP 풀 VLAN //

ip 주소 172.16.1.1 255.255.255.0

ip pim dense-mode

끝

6504-WLCBUG#sh run int vla 40

구성을 빌드하는 중...

현재 컨피그레이션: 121바이트

!

인터페이스 Vlan40

설명 // 관리 Vlan //

ip 주소 10.105.135.136 255.255.255.128

ip pim dense-mode

끝

6504-WLCBUG#sh ip pim interface vlan 40

주소 인터페이스 버전/Nbr 쿼리 DR

DR 모드 수 Intvl 이전

10.105.135.136 Vlan40 v2/D 0 30 1 10.105.135.136

6504-WLCBUG#sh ip pim interface vlan 50

주소 인터페이스 버전/Nbr 쿼리 DR DR

이전 모드 수 Intvl

172.16.1.1 Vlan50 v2/D 0 30 1 172.16.1.1

6504-WLCBUG#sh ip mroute

IP 멀티캐스트 라우팅 테이블

플래그: D - Dense, S - Sparse, B - Bidir 그룹, s - SSM 그룹, C - 연결됨,

L - 로컬, P - 정리됨, R - RP-비트 집합, F - 등록 플래그,

T - SPT 비트 집합, J - SPT 조인, M - MSDP 생성 항목,

X - 프록시 가입 타이머 실행, A - MSDP 광고 후보,

U - URD, I - 소스별 호스트 보고서 수신,

Z - Multicast Tunnel, z - MDT-data group sender,

Y - Joined MDT-data group, y - MDT-data 그룹으로 전송

V - RD 및 벡터, v - 벡터

발송 인터페이스 플래그: H - Hardware switched, A - Assert winner

타이머: 가동 시간/만료

인터페이스 상태: Interface, Next-Hop 또는 VCD, State/Mode

(*, 239.255.255.255), 4d17h/00:02:03, RP 0.0.0.0, 플래그: DC

수신 인터페이스: Null, RPF nbr 0.0.0.0

발송 인터페이스 목록:

Vlan40, 전달/고밀도, 4d17h/00:00:00

(*, 239.254.0.3), 2w1d/00:02:07, RP 0.0.0.0, 플래그: DC

수신 인터페이스: Null, RPF nbr 0.0.0.0

발송 인터페이스 목록:

Vlan40, 전달/고밀도, 3d10h/00:00:00

(*, 224.0.1.40), 2w1d/00:02:13, RP 0.0.0.0, 플래그: DCL

수신 인터페이스: Null, RPF nbr 0.0.0.0

발송 인터페이스 목록:

Vlan11, 전달/고밀도, 2w1d/00:00:00

패킷 캡처

토폴로지

유선 PC ----------- 6500 스위치 -------- WISM ------- AP ))(((( 무선 클라이언트 )

Vlan 50 Vlan 40 Vlan 40 Vlan 40 Vlan 50

MCAST 트래픽 생성기 도구

유선 PC에서 멀티캐스트 스트림 - 연속 UDP 패킷을 생성하는 데 사용됩니다.

MCAST Generator의 Wired Wireshark 패킷 캡처

Mcast 패킷 생성기의 Windows Netmon 캡처</h=5>

MCAST Receiver Tool은 무선 클라이언트에서 소스(유선 PC)로부터 멀티캐스트 트래픽을 수신하는 데 사용됩니다.

무선 클라이언트의 무선 인터페이스에서 Wireshark 캡처

무선 클라이언트의 무선 인터페이스에서 Netmon 캡처

802.11 스니퍼 캡처 분석 - 웹 인증

소개

Cisco WLC의 웹 인증 스니퍼 문제 해결

웹 인증 프로세스

웹 인증은 컨트롤러가 특정 클라이언트에서 DHCP 관련 패킷/DNS 관련 패킷을 제외한 IP 트래픽을 허용하지 않도록 하는 레이어 3 보안 기능이며, 사전 인증 ACL을 통해 허용되는 트래픽을 제외하고 클라이언트가 올바른 사용자 이름과 비밀번호를 올바르게 제공했습니다. 웹 인증은 인증 전에 클라이언트가 IP 주소를 가져올 수 있도록 허용하는 유일한 보안 정책입니다. 서 플리 컨 트 또는 클라이언트 유틸리티 없이 간단한 인증 방법입니다. 웹 인증은 WLC에서 로컬로 또는 RADIUS 서버를 통해 수행할 수 있습니다. 웹 인증은 일반적으로 게스트 액세스 네트워크를 구축하려는 경우에 사용됩니다.

웹 인증은 컨트롤러가 클라이언트에서 첫 번째 TCP HTTP(포트 80) GET 패킷을 가로챌 때 시작됩니다. 클라이언트의 웹 브라우저에서 이 범위를 확인하려면 클라이언트가 먼저 IP 주소를 얻고 웹 브라우저에 대한 URL을 IP 주소로 변환(DNS 확인)해야 합니다. 이렇게 하면 웹 브라우저가 HTTP GET을 전송할 IP 주소를 알 수 있습니다.

WLAN에 웹 인증이 구성된 경우 컨트롤러는 DHCP 및 DNS 트래픽을 제외하고 클라이언트에서 오는 모든 트래픽(인증 프로세스가 완료될 때까지)을 차단합니다. 클라이언트가 첫 번째 HTTP GET을 TCP 포트 80으로 전송하면 컨트롤러는 클라이언트를 처리하기 위해 https://10.10.10.1/으로 리디렉션합니다. 이 프로세스는 결국 로그인 웹 페이지를 표시합니다.

- 웹 브라우저를 열고 URL(예: http://www.google.com)을 입력합니다.  클라이언트는 대상의 IP를 가져오기 위해 이 URL에 대한 DNS 요청을 보냅니다. WLC는 DNS 요청을 DNS 서버로 우회하고 DNS 서버는 DNS 회신으로 응답합니다. DNS 회신에는 대상 http://www.google.com의 IP 주소가 포함되어 있으며, 이 주소는 무선 클라이언트로 전달됩니다

- 그런 다음 클라이언트는 대상 IP 주소로 TCP 연결을 열려고 시도합니다. IP 주소 http://www.google.com으로 향하는 TCP SYN 패킷을 전송합니다

- WLC는 클라이언트에 대해 구성된 규칙을 가지고 있으므로 http://www.google.com에 대한 프록시 역할을 할 수 있습니다. TCP SYN-ACK 패킷을 클라이언트로 다시 전송하며, 소스는 http://www.google.com의 IP 주소로 합니다. 클라이언트는 TCP ACK 패킷을 다시 전송하여 3방향 TCP 핸드셰이크를 완료하고 TCP 연결이 완전히 설정됩니다.

- 클라이언트는 http://www.google.com으로 향하는 HTTP GET 패킷을 전송합니다. WLC는 이 패킷을 인터셉트하여 리디렉션 처리를 위해 전송합니다. HTTP 애플리케이션 게이트웨이는 HTML 본문을 준비하고 클라이언트가 요청한 HTTP GET에 대한 응답으로 다시 전송합니다. 이 HTML을 사용하면 클라이언트가 WLC의 기본 웹 페이지 URL(예: <Virtual-Server-IP>/login.html)로 이동합니다.

- 클라이언트는 IP 주소로 TCP 연결을 닫습니다(예: http://www.google.com)

- 이제 클라이언트가 http://10.10.10.1/login.html으로 이동하려는 경우 WLC의 가상 IP 주소로 TCP 연결을 열려고 시도합니다. 10.10.10.1에 대한 TCP SYN 패킷을 WLC에 전송합니다.

- WLC는 TCP SYN-ACK로 응답하고 클라이언트는 핸드셰이크를 완료하기 위해 TCP ACK를 WLC에 다시 보냅니다.

- 클라이언트는 로그인 페이지를 요청하기 위해 /login.html에 대해 10.10.10.1로 향하는 HTTP GET을 전송합니다.

- 이 요청은 WLC의 웹 서버까지 허용되며 서버는 기본 로그인 페이지로 응답합니다. 클라이언트는 사용자가 가서 로그인할 수 있는 브라우저 창에서 로그인 페이지를 수신합니다.

구성 웹 인증

계속 진행하여 구성합니다.

토폴로지

무선 클라이언트는 스위치에 연결된 WLC에 등록된 AP에 연결되며, 이 AP는 DNS, 라우팅, L3 연결이 구성된 라우터에 연결됩니다.

DNS 역할을 할 라우터

3825#sh run | i host

hostname 3825

ip host www.google.com 192.168.200.1

ip host www.yahoo.com 192.168.200.200.2

ip host www.facebook.com 192.168.200.200.3

3825#sh run | i dns

dns-server 172.16.16.1

ip dns server

3825#sh run | b dhcp

ip dhcp excluded-address 172.16.16.1 172.16.16.5

!

ip dhcp pool webauth-sniffer

network 172.16.16.0 172.16.255.0

default-router 172.16.16.1

dns-server 172.16.16.1

WLCC의 컨피그레이션

- WLAN으로 이동한 다음 NEW로 이동하여 세부사항을 입력합니다.

- NO L2 인증을 위해 WLAN을 구성합니다.

- WEBAUTH를 사용하여 L3 인증을 위한 WLAN을 구성합니다.

- 컨피그레이션 후 이렇게 볼 수 있습니다.

- Security(보안) 탭으로 이동하여 Local net users(로컬 네트워크 사용자)를 생성합니다.

- 클라이언트 자격 증명을 입력합니다.

- Security(보안) > Webauth(웹 인증) 탭으로 이동하고 웹 인증 유형==Internal/External redirect/Custom(내부/외부 리디렉션/사용자 지정)을 선택합니다.

- 클라이언트를 연결합니다.

- IP 주소를 가져온 다음 브라우저를 열고 웹 주소를 입력합니다.

- 클라이언트는 사용자 이름 및 암호를 입력 하는 웹 인증 페이지로 리 디렉션 됩니다.

- 로그인에 성공하면 클라이언트가 리디렉션 페이지로 리디렉션됩니다.

다음은 클라이언트가 연결을 시도할 때의 패킷 캡처입니다.

클라이언트는 다음을 수행합니다.

- DHCP

- DNS

- WTTP

클라이언트의 IP 주소는 172.16.16.7입니다. 클라이언트가 192.168.200.1에 액세스하는 웹 서버의 URL을 확인했습니다. 보시다시피, 클라이언트는 3방향 핸드셰이크를 수행하여 TCP 연결을 시작한 다음 패킷 576으로 시작하는 HTTP GET 패킷을 보냈습니다. 컨트롤러가 패킷을 가로채고 코드 200으로 회신합니다. 코드 200 패킷에는 리디렉션 URL이 있습니다.

클라이언트가 HTTPS 로그인 페이지를 가져옵니다.

클라이언트가 인증서 수락

그런 다음 클라이언트는 리디렉션 URL에 대한 HTTPS 연결을 시작하고 이를 컨트롤러의 가상 IP 주소인 10.10.10.1에 전송합니다. 클라이언트는 SSL 터널을 가져오기 위해 서버 인증서를 검증하거나 무시해야 합니다. 여기서 클라이언트는 인증에 성공한 후 Facebook.com에 액세스하려고 시도하며 TCP 세션이 문제 없이 시작됩니다.

클라이언트가 연결을 시도했을 때의 클라이언트 디버그는 다음과 같습니다

Cisco Controller) >

(Cisco Controller) >show debug

MAC address ................................ 00:21:5c:8c:c7:61

Debug Flags Enabled:

dhcp packet enabled.

dot11 mobile enabled.

dot11 state enabled

dot1x events enabled.

dot1x states enabled.

pem events enabled.

pem state enabled.

CCKM client debug enabled.

webauth redirect enabled.

May 18 13:43:50.568: 00:21:5c:8c:c7:61 Adding mobile on LWAPP AP a8:b1:d4:c4:35:b0(0)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Association received from mobile on AP a8:b1:d4:c4:35:b0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Changing ACL 'MNGMNT' (ACL ID 0) ===> 'none' (ACL ID 255) --- (caller apf_policy.c:1633)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying site-specific IPv6 override for station 00:21:5c:8c:c7:61 - vapId 1, site 'default-group', interface 'webauth-sniffer'

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Applying IPv6 Interface Policy for station 00:21:5c:8c:c7:61 - vlan 300, interface id 4, interface 'webauth-sniffer'

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (8): 130 132 139 150 12 18 24 36 0 0 0 0 0 0 0 0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 STA - rates (12): 130 132 139 150 12 18 24 36 48 72 96 108 0 0 0 0

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Initializing policy

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 START (0) Change state to AUTHCHECK (2) last state AUTHCHECK (2)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 AUTHCHECK (2) Change state to L2AUTHCOMPLETE (4) last state L2AUTHCOMPLETE (4)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) DHCP Not required on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1for this client

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Not Using WMM Compliance code qosCap 00

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Plumbed mobile LWAPP rule on AP a8:b1:d4:c4:35:b0 vapId 1 apVapId 1

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 0.0.0.0 L2AUTHCOMPLETE (4) Change state to DHCP_REQD (7) last state DHCP_REQD (7)

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfMsAssoStateInc

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 apfPemAddUser2 (apf_policy.c:223) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Idle to Associated

*apfMsConnTask_0: May 18 13:43:50.568: 00:21:5c:8c:c7:61 Scheduling deletion of Mobile Station: (callerId: 49) in 1800 seconds

*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 Sending Assoc Response to station on BSSID a8:b1:d4:c4:35:b0 (status 0) ApVapId 1 Slot 0

*apfMsConnTask_0: May 18 13:43:50.569: 00:21:5c:8c:c7:61 apfProcessAssocReq (apf_80211.c:5272) Changing state for mobile 00:21:5c:8c:c7:61 on AP a8:b1:d4:c4:35:b0 from Associated to Associated

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) State Update from Mobility-Incomplete to Mobility-Complete, mobility role=Local, client state=APF_MS_STATE_ASSOCIATED

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) pemAdvanceState2 4494, Adding TMP rule

*apfReceiveTask: May 18 13:26:46.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Adding Fast Path rule

type = Airespace AP - Learn IP address

on AP a8:b1:d4:c4:35:b0, slot 0, interface = 1, QOS = 0

ACL Id = 255, Jumbo Fr

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4

*apfReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 DHCP_REQD (7) Successfully plumbed mobile rule (ACL ID 255)

*pemReceiveTask: May 18 13:43:50.570: 00:21:5c:8c:c7:61 0.0.0.0 Added NPU entry of type 9, dtlFlags 0x0

*pemReceiveTask: May 18 13:43:50.571: 00:21:5c:8c:c7:61 Sent an XID frame

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 310,vlan 0, port 1, encap 0xec03)

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP processing DHCP DISCOVER (1)

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP requested ip: 192.168.226.44

*DHCP Socket Task: May 18 13:43:50.689: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP processing DHCP OFFER (2)

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.690: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.691: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to STA

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP received op BOOTREQUEST (1) (len 314,vlan 0, port 1, encap 0xec03)

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP processing DHCP REQUEST (3)

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP op: BOOTREQUEST, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.704: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP requested ip: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP successfully bridged packet to DS

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP received op BOOTREPLY (2) (len 308,vlan 300, port 1, encap 0xec00)

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP processing DHCP ACK (5)

*DHCP Socket Task: May 18 13:43:50.705: 00:21:5c:8c:c7:61 DHCP op: BOOTREPLY, htype: Ethernet, hlen: 6, hops: 0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP xid: 0xf665da29 (4133870121), secs: 0, flags: 0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP chaddr: 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP ciaddr: 0.0.0.0, yiaddr: 172.16.16.7

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP siaddr: 0.0.0.0, giaddr: 0.0.0.0

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 DHCP server id: 172.16.16.1 rcvd server id: 172.16.16.1

*DHCP Socket Task: May 18 13:43:50.706: 00:21:5c:8c:c7:61 Static IP client associated to interface webauth-sniffer which can support client subnet.

*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 Adding Web RuleID 22 for mobile 00:21:5c:8c:c7:61

*DHCP Socket Task: May 18 13:43:50.708: 00:21:5c:8c:c7:61 172.16.16.7 DHCP_REQD (7) Change state to WEBAUTH_REQD (8) last state WEBAUTH_REQD (8)

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Fast Path rule (contd...) 802.1P = 0, DSCP = 0, TokenID = 1506 IPv6 Vlan = 300, IPv6 intf id = 4

*apfMsConnTask_0: May 18 13:44:43.347: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Successfully plumbed mobile rule (ACL ID 255)

(Cisco Controller) >*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created for mobile, length = 5

*emWeb: May 18 13:47:39.321: 00:21:5c:8c:c7:61 Username entry (Cisco) created in mscb for mobile, length = 5

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_REQD (8) Change state to WEBAUTH_NOL3SEC (14) last state WEBAUTH_NOL3SEC (14)

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 apfMsRunStateInc

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 172.16.16.7 WEBAUTH_NOL3SEC (14) Change state to RUN (20) last state RUN (20)

*emWeb: May 18 13:47:39.322: 00:21:5c:8c:c7:61 Session Timeout is 1800 - starting session timer for the mobile

참조:

- IEEE 802.11 표준

- Cisco 지원 포럼 참조

- 맥북에서 캡처 수집