이 제조업체의 장비에 대한 온라인 과정에서 MikroTik을 구성하는 방법을 배울 수 있습니다. 이 과정의 저자는 인증된 MikroTik 트레이너입니다. 기사 끝 부분에서 자세한 내용을 읽을 수 있습니다.
이 기사는 ICMP 트래픽을 차단하는 것이 얼마나 위험한지에 대한 질문에 답합니다.
ICMP는 논쟁의 핵심이다
많은 네트워크 관리자는 ICMP(인터넷 제어 메시지 프로토콜)가 보안 위험이므로 항상 차단되어야 한다고 생각합니다. 프로토콜에 일부 관련 보안 문제가 있으므로 일부 요청을 차단해야 한다는 것은 사실입니다. 모든 ICMP 트래픽을 차단합니다!
ICMP 트래픽에는 많은 중요한 기능이 있습니다. 그 중 일부는 문제 해결에 유용하고 다른 일부는 네트워크가 제대로 작동하는 데 필요합니다. 다음은 알아야 할 ICMP 프로토콜의 몇 가지 중요한 부분입니다. 네트워크를 통해 이를 가장 잘 라우팅하는 방법을 고려해야 합니다.
에코 요청 및 에코 응답
IPv4 – 에코 요청(Type8, Code0) 및 에코 응답(Type0, Code0)
IPv6 – 에코 요청(Type128, Code0) 및 에코 응답(Type129, Code0)
우리 모두는 ping이 문제 해결을 위한 첫 번째 도구 중 하나라는 것을 잘 알고 있습니다. 예, 하드웨어에서 ICMP 패킷 처리를 활성화하면 이제 호스트를 검색할 수 있지만 이미 포트 80에서 수신 대기하고 클라이언트 요청에 대한 응답을 보내고 있지 않습니까? 물론 네트워크 가장자리에 DMZ를 두고 싶다면 이러한 요청도 차단하세요. 그러나 네트워크 내에서 ICMP 트래픽을 차단하면 보안이 강화되지 않고, 불필요하게 복잡한 문제 해결 프로세스(“게이트웨이가 네트워크 요청에 응답하는지 확인하십시오.”, “아니요, 하지만 난 아무 말도 안 할 테니까 전혀 속상하지 않아요!"
요청이 특정 방향으로 진행되도록 허용할 수도 있다는 점을 기억하세요. 예를 들어, 네트워크의 Echo 요청이 인터넷으로 이동하고 Echo가 인터넷에서 네트워크로 응답하도록(그 반대는 불가능) 장비를 구성하십시오.
패킷 조각화가 필요함(IPv4) / 패킷이 너무 큼(IPv6)
IPv4 – (유형3, 코드4)
IPv6 – (유형2, 코드0)
ICMP 프로토콜의 이러한 구성 요소는 TCP 프로토콜의 필수 부분인 PMTUD(Path MTU Discovery)의 중요한 구성 요소이기 때문에 매우 중요합니다. 두 호스트가 TCP MSS(최대 세그먼트 크기) 값을 두 대상 간의 통신 경로를 따라 가장 작은 MTU와 일치하는 값으로 조정할 수 있습니다. 패킷 경로를 따라 송신자 또는 수신자보다 최대 전송 단위가 더 작은 노드가 있고 이 충돌을 감지할 수 있는 수단이 없는 경우 트래픽은 조용히 폐기됩니다. 그리고 당신은 커뮤니케이션 채널에서 무슨 일이 일어나고 있는지 이해하지 못할 것입니다. 즉, "당신에게 즐거운 날이 올 것입니다."
조각화하지 마십시오. ICMP는 통과하지 못합니다!
Don't Fragment(조각화 안 함) 비트가 설정된 IPv4 패킷(대부분!) 또는 인터페이스를 통해 전송하기에는 너무 큰 IPv6 패킷(IPv6에서는 라우터에 의한 조각화가 없음을 기억)을 전송하면 라우터가 패킷을 삭제하게 됩니다. 다음 ICMP 오류로 전송 소스에 대한 응답을 생성합니다. 조각화 필요( 조각화 필요) 또는 패키지가 너무 큼( 패킷 너무큰). 이러한 오류가 있는 응답을 보낸 사람에게 반환할 수 없는 경우 ACK 패킷 전달에 대한 확인 응답이 없는 것으로 해석합니다( 승인)은 수신기에서 정체/손실로 간주되며 패킷 재전송 소스도 폐기됩니다.
이러한 문제의 원인을 식별하고 신속하게 해결하기는 어렵습니다. TCP 핸드셰이크 프로세스는 작은 패킷을 포함하기 때문에 잘 작동하지만 대량 데이터 전송이 발생하면 전송 소스가 없기 때문에 전송 세션이 정지됩니다. 오류 메시지를 받습니다.
패킷 전달 경로 탐색
RFC 4821은 네트워크 트래픽 참가자가 패킷 경로 검색을 사용하여 이 문제를 해결하는 데 도움을 주기 위해 설계되었습니다. (경로 MTU 검색(PLPMTUD). 표준을 사용하면 최대 데이터 양을 감지할 수 있습니다. (최대 전송 단위(MTU)유용한 데이터 블록의 최대 크기를 점차적으로 늘려 프로토콜을 통해 한 번의 반복으로 전송할 수 있습니다. (최대 세그먼트 크기(MSS), 송신기에서 수신기까지의 경로를 따라 패킷을 조각화하지 않고 가능한 최대 크기를 찾기 위해. 이 기능은 ICMP(인터넷 제어 메시지 프로토콜)를 통해 오류 응답을 적시에 수신해야 한다는 의존도를 줄여주며 대부분의 네트워크 장치 스택 및 클라이언트 운영 체제에서 사용할 수 있지만 불행하게도 가능한 최대 크기에 대한 데이터를 직접 얻는 것만큼 효율적이지는 않습니다. 전송된 패킷 중 이 ICMP 메시지가 전송 소스로 돌아갈 수 있도록 허용해 주세요.
패킷 전송 시간이 초과되었습니다.
IPv4 – (유형11, 코드0)
IPv6 – (유형3, 코드0)
Traceroute는 두 호스트 간의 네트워크 연결 문제를 해결하고 경로의 각 단계를 자세히 설명하는 데 매우 유용한 도구입니다.
IP 프로토콜에 대한 데이터 패킷 수명이 포함된 패킷을 보냅니다. (수명(TTL)동일한 1 첫 번째 라우터가 패킷이 수명을 초과했다는 오류 메시지(자체 IP 주소 포함)를 보내도록 합니다. 그런 다음 TTL 2 등으로 패킷을 보냅니다. 이 절차는 패킷 경로를 따라 각 노드를 탐지하기 위해 필요합니다.
NDP 및 SLAAC(IPv6)
RS(라우터 요청)(Type133, Code0)
라우터 광고(RA)(Type134, Code0)
NS(이웃 요청)(Type135, Code0)
NA(이웃 광고)(Type136, Code0)
리디렉션(유형137, 코드0)
IPv4는 ARP(주소 확인 프로토콜)를 사용하여 OSI 네트워크 모델의 계층 2와 3을 매핑한 반면, IPv6은 NDP(Neighbor Discovery Protocol) 형식의 다른 접근 방식을 사용합니다. NDP는 라우터 검색, 접두사 검색, 주소 확인 등을 포함한 다양한 기능을 제공합니다. NDP 외에도 SLAAC(StateLess Address AutoConfiguration)를 사용하면 DHCP(동적 호스트 구성 프로토콜)의 개념과 유사하게 네트워크에서 호스트를 동적으로 구성할 수 있습니다(DHCPv6은 보다 세부적인 제어를 위한 것임).
IP 데이터 전송 프로토콜이 올바르게 작동하려면 이러한 5가지 유형의 ICMP 메시지가 네트워크 내에서 차단되어서는 안 됩니다(외부 경계 무시).
ICMP 유형 번호 매기기
ICMP(인터넷 제어 메시지 프로토콜)에는 "유형" 필드로 식별되는 많은 메시지가 포함되어 있습니다.
| 유형 | 이름 | 사양 |
|---|---|---|
| 0 | 에코 답장 | |
| 1 | 할당되지 않음 | |
| 2 | 할당되지 않음 | |
| 3 | 목적지를 이용할 수 없음 | |
| 4 | 소스 퀸치(더 이상 사용되지 않음) | |
| 5 | 리디렉션 | |
| 6 | 대체 호스트 주소(더 이상 사용되지 않음) | |
| 7 | 할당되지 않음 | |
| 8 | 에코 | |
| 9 | 라우터 광고 | |
| 10 | 라우터 요청 | |
| 11 | 시간 초과 | |
| 12 | 매개변수 문제 | |
| 13 | 타임스탬프 | |
| 14 | 타임스탬프 응답 | |
| 15 | 정보 요청(더 이상 사용되지 않음) | |
| 16 | 정보 답변(더 이상 사용되지 않음) | |
| 17 | 주소 마스크 요청(더 이상 사용되지 않음) | |
| 18 | 주소 마스크 회신(더 이상 사용되지 않음) | |
| 19 | 예약됨(보안용) | 독주 |
| 20-29 | 예약됨(강건성 실험용) | ZSu |
| 30 | Traceroute(더 이상 사용되지 않음) | |
| 31 | 데이터그램 변환 오류(더 이상 사용되지 않음) | |
| 32 | 모바일 호스트 리디렉션(더 이상 사용되지 않음) | 데이비드_존슨 |
| 33 | IPv6 현재 위치(더 이상 사용되지 않음) | |
| 34 | IPv6 I-Am-Here(더 이상 사용되지 않음) | |
| 35 | 모바일 등록 요청(더 이상 사용되지 않음) | |
| 36 | 모바일 등록 답변(더 이상 사용되지 않음) | |
| 37 | 도메인 이름 요청(더 이상 사용되지 않음) | |
| 38 | 도메인 이름 회신(더 이상 사용되지 않음) | |
| 39 | 건너뛰기(더 이상 사용되지 않음) | |
| 40 | 포투리스 | |
| 41 | Seamoby와 같은 실험적인 이동성 프로토콜에서 활용되는 ICMP 메시지 | |
| 42 | 확장된 에코 요청 | |
| 43 | 확장된 에코 응답 | |
| 44-252 | 할당되지 않음 | |
| 253 | RFC3692 스타일 실험 1 | |
| 254 | RFC3692 스타일 실험 2 | |
| 255 | 예약된 |
속도 제한에 관한 몇 마디
이 문서에 설명된 것과 같은 ICMP 메시지는 매우 유용할 수 있지만 이러한 메시지를 모두 생성하려면 라우터의 CPU 시간이 걸리고 트래픽이 생성된다는 점을 기억하세요. 정상적인 상황에서 방화벽을 통해 초당 1000개의 핑을 얻을 수 있다고 정말로 예상하십니까? 이것이 정상적인 트래픽으로 간주됩니까? 아마도 그렇지 않을 것입니다. 이러한 유형의 ICMP 트래픽에 대해 적절하다고 판단되는 대로 네트워크 대역폭을 제한하십시오. 이 단계는 네트워크를 보호하는 데 도움이 될 수 있습니다.
읽고, 연구하고, 이해하세요
ICMP 패킷을 "차단할지 여부"라는 주제를 논의하면 항상 혼란, 분쟁 및 불일치가 발생한다는 점을 고려하여 이 주제를 스스로 계속 연구하는 것이 좋습니다. 나는 이 페이지에 많은 링크를 제공했습니다. 문제를 더 완벽하게 이해하려면 시간을 들여 읽어야 한다고 생각합니다. 그리고 귀하의 네트워크에 가장 적합한 것이 무엇인지에 대해 정보를 바탕으로 선택하십시오.
MikroTik: 작동시키려면 어디를 클릭해야 하나요?
모든 장점에도 불구하고 MikroTik 제품에는 한 가지 단점이 있습니다. 구성에 대한 정보가 흩어져 있고 항상 신뢰할 수 있는 것은 아닙니다. 모든 것이 논리적이고 구조적으로 수집되어 있는 신뢰할 수 있는 러시아어 소스를 추천합니다. 비디오 코스 " MikroTik 장비 설정" 이 과정에는 162개의 비디오 강의, 45개의 실험실 작업, 자가 테스트 질문 및 메모가 포함되어 있습니다. 모든 자료는 무기한으로 귀하와 함께 유지됩니다. 강좌 페이지에 요청을 남겨주시면 강좌의 시작 부분을 무료로 시청하실 수 있습니다. 이 과정의 저자는 인증된 MikroTik 트레이너입니다.
비밀 채널은 더하기 기호(익명성과 기밀성 보장)와 빼기 기호(데이터 유출 정리)와 함께 사용할 수 있는 정보 보안 방법 중 하나입니다. 실제로 해결하기 가장 어려운 정보 보안 문제 중 하나인 숨겨진 데이터 전송 탐지 또는 숨겨진 채널을 통한 데이터 전송 탐지라는 두 번째 구성 요소를 고려해 보겠습니다. 기사의 크기가 커지지 않도록 암호화 및 스테가노그래피와 같은 데이터 은폐 메커니즘을 의도적으로 무시하겠습니다.
알렉세이 루카츠키
시스코 보안 컨설턴트
숨겨진 데이터 전송이란 무엇입니까?
네트워크를 통한 숨겨진 데이터 전송이 이 방법의 유일한 적용은 아닙니다. "비밀 채널"이라는 용어는 1973년에 처음 등장했으며 전통적인 네트워크 연결이 없는 컴퓨팅 시스템에 사용되었습니다. 예를 들어, 처리 기간의 짝수 값은 1을 의미할 수 있고, 홀수 값은 0을 의미할 수 있습니다. 따라서 프로세스 기간을 조작하여 0과 1의 시퀀스를 형성할 수 있으며, 이를 사용하여 무엇이든 설명할 수 있습니다(소위 시간 채널이라고 함). 컴퓨팅 시스템의 숨겨진 프로세스의 또 다른 예는 프로세스가 특정 작업을 시작하고 특정 시간에 완료하는 경우입니다. 이는 하나의 단위로 해석될 수 있습니다. 지정된 시간 내에 작업이 완료되지 않으면 0입니다.
비밀 전송은 어떻게 구현될 수 있나요?
숨겨진 네트워크 데이터 전송에 대해 이야기하면 가장 널리 사용되고 구현하기 상대적으로 간단한 방법 중 하나는 캡슐화입니다. 이는 외부로 전송해야 하는 보호된 정보 또는 외부로 수신해야 하는 명령을 승인된 프로토콜에 포함시키는 것으로 구성됩니다.
이 경우 완전히 다른 캡슐화 옵션을 사용할 수 있습니다.
1987년에 은밀한 네트워크 전송이라는 아이디어가 제안되었고, 그 순간부터 기밀성 또는 데이터 유출을 보장하는 이 방법(펜스의 어느 쪽을 보느냐에 따라)에 대한 진지한 연구가 시작되었습니다. 특히 1989년에는 이더넷 프레임과 기타 여러 채널 프로토콜의 사용되지 않은 비트를 조작하는 것이 처음으로 제안되었습니다. 분명히 로컬 네트워크의 비밀 채널은 글로벌 네트워크에 데이터를 숨기는 것과는 달리 연구하기에 흥미롭지 않습니다. 숨겨진 TCP/IP 채널을 통한 데이터의 실제 전송 및 수신을 입증한 연구가 1996년에 발표되었을 때 획기적인(적어도 공개적인) 것을 고려할 수 있습니다. 또는 오히려 헤더의 개별 필드에 있습니다.
- HTTP 수준에서는 오랫동안 다른 애플리케이션 프로토콜을 기반으로 구축하기 위한 사실상의 표준이 되었습니다. 예를 들어 익명의 JAP 네트워크는 HTTP를 사용하여 데이터를 전송하고 제어하기 어려운 Tor 네트워크도 사용합니다. HTTP에서는 GET 및 POST 명령을 사용하여 데이터를 전송할 수 있으며, HTTP를 사용하여 비디오 및 오디오 스트리밍을 전송하는 경우 대량의 데이터를 전송하는 공격자의 능력은 거의 무제한이 됩니다.
- DNS 수준에서는 정보가 DNS 쿼리 및 이에 대한 응답 내에 숨겨져 있는 경우입니다. 사람들은 TCP 프로토콜을 DNS로 터널링하는 DeNiSe 도구가 등장한 2000년대 초반에 처음으로 이 방법에 대해 이야기하기 시작했습니다. 나중에 DNS를 통해 SSH를 캡슐화할 수 있는 가능성을 보여주는 Dan Kaminsky의 연구가 있었고 2005년 Defcon 컨퍼런스에서 발표되었습니다. 그리고 나서 이 주제가 인기를 얻기 시작했습니다. dns2tcp, DNScapy, DNScat, Heyoka, iodine, squeeza 등이 등장했습니다.
- ICMP 수준에서 데이터가 일반적으로 안전한 ICMP 프로토콜 내에 캡슐화되는 경우입니다. 1996년 Phrack 잡지에서 처음 언급된 Loki 프로그램은 이 원리에 따라 작동되었습니다. 그 뒤를 이어 더 발전된 Loki2가 나왔습니다. ICMP를 통해 암호화된 메시지와 통신할 수 있는 icm-pchat이라는 도구도 있습니다.
- TCP/UDP/IP 수준에서 개별 패킷 헤더 필드를 사용하여 누출을 숨기거나 외부에서 명령을 받는 경우. 사용되는 프로토콜에 따라 전송되는 데이터의 크기는 IP, UDP 및 TCP 프로토콜에서 각각 2바이트, 12바이트 및 38바이트로 다양합니다. TCP 헤더 수정을 사용하는 매우 흥미로운 도구는 Nushu입니다. 그 특징은 자체적으로 트래픽을 생성하지 않고 일부 애플리케이션이나 프로세스에 의해 노드에서 이미 전송된 트래픽만 수정한다는 것입니다. 즉, 수정된 트래픽이 있어야 할 곳으로 전송되고, 공격자는 단순히 네트워크를 통해 이를 가로채어 이렇게 유출된 데이터를 수집하는 것이다.
- 무선 네트워크에서 브로드캐스트를 통해 배포되는 전송 트래픽에 데이터가 마스킹되는 경우. 그건 그렇고, 이 경우 수동 모드에서 작동할 수 있는 수신 측을 감지하는 것은 쉽지 않습니다. 즉, 데이터를 수신하기 위해서만 가능합니다. HICCUPS 도구는 이 원칙을 바탕으로 구축되었습니다.
숨겨진 전송을 어떻게 감지할 수 있나요?
비밀 채널이 사용하는 다양한 방법과 해당 채널이 포함된 프로토콜을 살펴보면 비밀 전송을 탐지하는 방법이 왜 그토록 다양한지 이해할 수 있습니다. 주요한 것은 다음 매개변수(불완전한 목록) 확인으로 구성된 이상 제어입니다.
- 요청 및 응답 크기. 예를 들어, DNS 요청의 평균 길이는 40~60바이트를 넘지 않는 것으로 알려져 있습니다. 따라서 패킷 길이가 길어지고 DNS 쿼리 수가 증가하는 것은 비밀 채널이 작동 중임을 나타낼 수 있습니다. ICMP, SIP 등 다른 프로토콜에도 유사한 방식을 제안할 수 있습니다.
- 요청량. 일반적으로 특정 유형의 프로토콜에 대한 트래픽 볼륨은 고정된 값은 아니지만 몇 퍼센트 이내에서 거의 변경되지 않습니다. 따라서 서비스 프로토콜 트래픽이나 DNS 요청 수 또는 크기가 갑자기 증가하면 이상 현상이 발생하여 조사가 필요함을 나타낼 수 있습니다. 또한 이 경우 트래픽 프로필은 송신자 노드와 수신자 노드 모두에 대해 평가될 수 있습니다.
- 히트 수나 지역도 숨겨진 채널의 특징이 될 수 있습니다. 예를 들어 내부 DNS 서버가 있는 경우 외부 DNS 노드에 대한 지속적인 호출도 이상을 나타낼 수 있습니다.
- 다른 유형의 통계 분석도 비밀 채널을 탐지하는 데 유용합니다. 예를 들어, DNS 호스트 이름의 엔트로피 수준을 분석할 수 있습니다. 숨겨진 정보가 DNS 쿼리로 전송되는 경우 사용되는 문자 분포는 기존 문자 분포와 다릅니다.
네트워크 트래픽에서 이러한 이상 현상을 모니터링할 수 있는 도구는 NBAD(네트워크 기반 이상 탐지) 클래스 시스템입니다. 이 클래스 시스템에는 이미 다수의 내장 규칙이 포함되어 있거나 훈련 모드 후에 독립적으로 구성할 수 있습니다.
이상 분석 외에도 특정 프로토콜의 콘텐츠를 연구하여 비밀 채널을 탐지할 수도 있습니다. 이는 RFC의 애플리케이션 프로토콜 트래픽 편차를 모니터링할 수 있는 기존 차세대 클래스 솔루션과 침입 탐지 시스템을 모두 사용하여 수행할 수 있습니다. 예를 들어, 오픈 소스 솔루션 Snort에 대해 DNS 프로토콜에서 숨겨진 NSTX 채널을 탐지하기 위한 서명은 다음과 같습니다.
경고 udp $EXTERNAL_NET any - > $HOME_NET 53 (msg:"잠재적인 NSTX DNS 터널링"; 콘텐츠:"|01 00|"; 오프셋:2; 이내:4; 콘텐츠:"cT"; 오프셋:12; 깊이:3 ; 내용:"|00 10 00 01|"; 클래스 유형:잘못됨;
요약
보편성의 부족은 아마도 비밀 채널의 적극적인 사용과 그에 맞서 싸우는 데 주요 장애물일 것입니다.
네트워크 트래픽의 비밀 채널은 보편적이지 않고 고유한 제한과 범위를 갖는 매우 구체적인 방법입니다. 각 비밀 채널에는 대역폭, 잡음, 전송 모드(양방향 또는 단방향)와 같은 고유한 특성이 있으며 이를 사용할 때와 싸울 때 모두 고려해야 합니다. 그래도 L.N. 톨스토이는 이러한 채널을 통해 신속하게 전송할 수 없으며 일부 은밀한 전송 방법은 소음 수준이 매우 높아 외부 요인이 은밀한 전송의 성공에 큰 영향을 미칠 수 있는 글로벌 네트워크에서 효과적으로 사용되지 않습니다.
보편성의 부족은 아마도 비밀 채널의 적극적인 사용과 그에 맞서 싸우는 데 주요 장애물일 것입니다. 은밀한 데이터 전송에 대한 많은 제한으로 인해 특정 작업 및 특정 고객을 위해 개발된 표적 위협만 허용됩니다. 이처럼 보편성이 결여되어 있는 것은 이제 단일 제품 형태의 만병통치약도 없으며, 숨겨진 데이터 전송을 탐지하고 무력화하기 위해 다양한 도구와 기술을 사용해야 한다는 생각으로 이어집니다.
이 짧은 기사에서는 가능한 한 두 대의 컴퓨터, 몇 가지 재미있는 도구 및 운영 체제를 사용하여 무선 인터넷에 액세스하는 방법을 보여줍니다. 기술적인 측면을 아주 명확하게 설명하고 의견을 제시했습니다.
1. 소개.
방금 처음으로 노트북을 받았는데 그걸로 뭔가 엉뚱한 일을 해보고 싶었어요. (심지어 일도 하려고 했는데 너무 지루했어요.
:)). 워드라이빙은 처음에는 꽤 재미있는 활동이었지만, 네트워크가 보호된다는 사실을 알았을 때 조금 지루해졌습니다.
WEP는 저에게 너무 힘들고(인트라넷 트래픽이 없었기 때문에 네트워크는 죽은 것으로 간주될 수 있었습니다) 보호되지 않은 네트워크는 전혀 관심이 없습니다. 운 좋게도 대학 캠퍼스의 무선 메시는 좀 더 흥미로웠습니다.
네트워크는 무료 무선 인터넷을 제공하지만 액세스를 허용하기 전에 이름으로 MAC 주소를 등록해야 합니다. 등록되지 않은 사용자는 공급자 페이지(등록 페이지)로 리디렉션됩니다. 등록하려면 관리자와 2분간 대화를 나눠야 했지만, 저는 "아마도
그런 의사소통 없이 접속할 수 있는 방법이 있나요? 물론 그는 그랬다.
2. 첫 번째 침투 방법은 MAC 스푸핑입니다.
모든 것이 MAC 주소를 중심으로 돌아가기 때문에 가장 먼저 떠오른 것은
이미 등록된 MAC 주소를 알아내고 처리하는 것이었습니다.
스푸핑. 물론 말은 쉽지만, 한 번도 해본 적 없는 일이라는 점을 감안하더라도 거의 노력이 필요하지 않았다.
내가 한 첫 번째 일은 kismet("kismet -c orinoco,eth1,wifi")을 실행하고 메시의 냄새를 맡은 것이었습니다. Kismet은 다운로드한 모든 것을 저장합니다.
정보를 파일(제 경우에는 "/var/log/kismet/*.dump")로 저장하면 스니핑 결과를 그대로 볼 수 있습니다.
영수증. 그 결과, 모든 정보를 볼 수 있었고,
적절한 MAC 주소를 적어 두십시오.
네트워크 카드의 MAC 주소를 변경하는 데 사용되는 명령:
ifconfig eth1 다운
킬올 dhclient
ifconfig hw 에테르 00:11:22:33:44:55
ifconfig eth1 위로
dh클라이언트 eth1
모든 명령이 필요한 것은 아니지만 여러 MAC 주소를 차례로 변경하려고 할 때 매우 유용합니다.
그것은 나에게 유용했기 때문에... 변경하려고 시도한 MAC 주소가 바로 작동하지 않았습니다. 차단당했고 네트워크가 다운되어 다시 연결되지 않아 약간 짜증나는 결함이 발생했습니다.
귀하의 시스템에서. 아마도 이러한 문제는
버그가 있는 펌웨어로 인해 발생했거나 네트워크에 동일한 MAC 주소를 가진 네트워크 카드가 이미 있었기 때문일 수 있습니다.
모든 워크스테이션이 활성화된 것은 아니었고 키즈멧을 사용하여 결과가 나오는 대로 보는 것은 효과적이지 않았기 때문에 다른 방법을 시도했습니다.
네트워크에서 MAC 주소 필터링은 상당히 높은 수준에서 수행되었습니다. 언제든지 네트워크에 액세스할 수 있었습니다. 왜냐하면... 가입하려고 하면 등록을 요청하는 페이지로 이동했습니다.
액티브 호스트를 생각하다가 자연스럽게 nmap이 떠올랐습니다. 그래서 활성 스테이션의 IP 범위를 확인하기 시작했습니다.
marktwain:~# nmap -sP 10.0.0.1/22
2005-05-23 12:54 EEST에 nmap 3.81(http://www.insecure.org/nmap/) 시작
호스트 10.1.0.14가 작동 중인 것 같습니다.
MAC 주소: 00:0E:35:97:8C:A7(인텔)
호스트 10.1.0.95가 작동 중인 것 같습니다.
호스트 10.1.0.109가 작동 중인 것 같습니다.
MAC 주소: 00:0D:54:A0:81:39(3Com 유럽)
...한조각...
호스트 10.1.2.92가 작동 중인 것 같습니다.
MAC 주소: 00:02:2D:4D:1C:CE(Agere 시스템)
호스트 10.1.2.187이 작동 중인 것 같습니다.
MAC 주소: 00:02:2D:4D:1C:43(Agere 시스템)
Nmap 완료: 53.980초 안에 1024개의 IP 주소(20개 호스트) 스캔
다수의 MAC 주소. 대부분의
결과로 나온 주소 테이블은 (제가 가정한 대로) 지난 며칠 동안 네트워크를 방문한 컴퓨터의 MAC 주소입니다. 테이블에는 245개의 서로 다른 MAS가 있었습니다.
구애. 이것이 정상적인 행동인지는 모르겠습니다.
액세스 포인트가 있지만 남자들에게는 뭔가가 필요한 것 같아요
인터넷 유통의 변화. 어쨌든 이제 네트워크를 방문했지만 오래 전에 떠났을 가능성이 높은 컴퓨터의 MAC 주소가 충분해졌습니다. 몇 번의 스푸핑 시도 끝에 저는 이미 neworder.box.sk로 향하고 있었습니다...
3. 두 번째 시도 - ICMP 터널링.
내가 원하는 모든 것을 이뤘지만, 이 네트워크에는 아직 파고들 여지가 남아 있었다. 근데 뭐
이 네트워크가 없었다면 할 수 있었을 텐데
내 소유의 자동차는 한 대도 없을까요? 만약에
nmap이 열리지 않고 이러한 모든 MAC 주소를 표시하지 않습니까? 그래서 어쨌든 나는 접근권을 얻기 위해 다른 방법을 시도해보기로 결정했습니다.
이는 이전에 언급되지 않았지만 시스템을 우회합니다.
권한을 부여하는 인터넷 배포와 DHCP, 네트워크는 ICMP 메시지가 자유롭게 전달되도록 허용했습니다. 모든 인터넷 사이트의 활동을 확인하는 것은 완벽하게 작동했습니다. (잊지 않는 한, 왜 차단하지 않았는지 정말 이해할 수 없습니다.), ping
내 서버에서 실행중인 스니퍼에서도 감지되었습니다.
내 계획은 대학에 있는 노트북과 집에 있는 서버 사이에 터널을 만드는 것이었습니다. 그리고 그것을 통해 모든 연결을 전달하십시오.
인터넷에서 ICMP 터널링 애플리케이션을 찾았지만 원하는 대로 작동하는 애플리케이션이 하나도 없었습니다(즉, 내가 가장 좋아하는 브라우저나 다른 프로그램을 실행하면 터널과 함께 작동할 수 있도록 단순해지기를 원했습니다).
소화가 잘되는 것 같았습니다.
4. 약간의 코딩.
처음에는 아무것도 코딩할 계획이 없었습니다. 방금 ICMP 터널 애플리케이션을 사용해 보았습니다.
그러나 갑자기 그 중 하나의 소스 코드를 읽고 그것이 얼마나 놀랍도록 간단하고 이와 같은 작업을 수행하는 것이 얼마나 쉬운지 깨달았습니다. 프로그램 이름 – itunnel –
ICMP 터널링을 위한 일반적인 유틸리티입니다. 아이터널은 굉장합니다. 그러나 그것은 단지 터널일 뿐이다. 하나의 컴퓨터에서 실행하면 결국 두 대를 연결한 것처럼 보입니다.
네트워크 카드를 함께 사용하세요. 내가 하고 싶은 일로는 충분하지 않았습니다.
나는 사용자 프로세스가 커널과 직접 정보 패킷을 주고받을 수 있게 해주는 커널 모듈 TUN/TAP에 대해 이미 들어봤습니다.
프로그램은 가상 네트워크 인터페이스를 생성합니다.
이는 네트워크 인터페이스를 생성합니다.
정확히 동일하게 작동합니다
기준 가장 흥미로운 점은
사용자 프로그램은 반드시
인터페이스의 물리적 계층 역할을 합니다.
터널. 그들은 다음으로부터 정보 패킷을 읽어야 합니다.
장치 파일(예: "/dev/net/tun0")을 전송하고 응답 패킷을 작성합니다.
파일로 돌아갑니다.
좋은 자료를 못 찾았어요
TUN/TAP을 사용하지만 터널에 TUN/TAP을 사용하는 vtun이라는 프로그램이 있으므로
vtun 소스를 사용했습니다. 약간의 조사 끝에 tun*을 생성하고 읽고 쓰는 데 사용되는 작은 함수 라이브러리가 있다는 것이 밝혀졌습니다.
장치. 몇 가지 비트만 수정하면 프로그램을 직접 작성할 수 있는데 왜 내가 직접 프로그램을 작성해야 합니까?
실제로 작성한 코드는 다음과 같습니다.
#include "driver.h" /* vtun 라이브러리 선언 */
#포함하다
#포함하다
/* itunnel에서 약간 수정된 main()
*/
int run_icmp_tunnel(int id, int packetsize, char *desthost, int tun_fd);
/* 최대 단위 - 최대
캡슐화된 패키지 크기
*/
const int mtu = 1400;
int main(int argc, char **argv) (
char *dev;
int tun_fd = 0;
/* 터널 장치 생성 */
dev = (char *) malloc(16);
if (dev == NULL) (
printf("문제가 발생한 적이 없다면
16바이트 할당 중\"
"기억은 처음이다. Fatal.n");
1을 반환합니다.
}
개발자 = 0;
/*
좋은 라이브러리 기능
vtun에서 빈 문자열을 다음과 같이 허용합니다.*
*
인수를 사용하여 tunX 장치를 생성하고
*dev에 전달합니다. */
tun_fd = tun_open(dev);
만약 (tun_fd< 1) {
printf("장치를 생성할 수 없습니다. Fatal.n");
1을 반환합니다.
}
또 다른(
printf("터널링 장치가 생성되었습니다: %sn", dev);
}
/* 7530은 ICMP ID 필드이고,
터널의 패킷에 사용됨
*/
run_icmp_tunnel(7530, mtu, argv, tun_fd);
tun_close(tun_fd, dev);
}
여기 있습니다. 그리고 대부분은 댓글과 오류 확인입니다.
이미 언급했듯이 itunnel은 터널 건설에 이상적입니다. 그것은 주요 기능을 가지고 있습니다
입력, 출력 및 소켓용으로 열린 파일; 또한
명령줄에 대한 몇 가지 매개변수를 받았습니다(내 목적에 유용할 수 있음). 다음으로, 기본적으로 정보 패킷을 전송하는 약간 추상적인 함수를 호출했습니다. ICMP 헤더 없음
코드에 설명되어 있으며 다른 헤더로 쉽게 변경할 수 있습니다.
입력/출력/소켓은 다른 논리 회로에 따라 구성될 수 있습니다. 이 기능은 최소한의 조정만으로 작동합니다.
내가 만든 가장 큰 변화는 모든 명령줄 조작을 제거한 것입니다. 즉, 본질적으로 여러 코드 블록을 제거한 것입니다. 터널 로직의 가장 중요한 점은 입력과 출력이 둘 다이기 때문에 구분을 제거했다는 것입니다.
동일한 설명자(tunX 장치)에 정지 –
그것은 나에게 그렇게 행동하는 대신에 그것을 주었다
netcat을 실행하고 stdin을 ICMP 소켓으로 전달하고 ICMP 소켓을 stdout으로 전달합니다.
tunX 장치(예: 브라우저의 http 요청)로 나가는 신호를 ICMP로 보냅니다.
소켓 및 ICMP 소켓 출력(HTTP와 동일)
서버의 요청이 다시 전송되었습니다.
터널을 통해) tunX 장치로 (
브라우저로 다시 돌아갑니다). 마지막 문장이 매우 길고 복잡하므로 설명을 위해 작은 다이어그램을 제공합니다.
정보의 응답 패킷은 동일한 경로를 따르지만
다른 방법.
어느 순간 나는 충분히 미쳐서 실제로 새로운 코드 줄을 작성했습니다. 다음과 같습니다:
memcpy(&(target->sin_addr.s_addr), &(from.sin_addr.s_addr), 4);
그 기능은 모든 정보 패킷을 마지막 패킷이 도착한 장소로 보내기 시작하는 것입니다. 저 할 수 있어요
내 서버에서 실행하고 연결
어디서나 터널을 통해 패킷을 보냅니다.
수신자의 IP를 즉시 IP로 변경합니다.
내 노트북.
여기에서 결과를 확인할 수 있습니다.
5. 터널 설치.
집에서 터널을 테스트했는데 잘 작동했지만 집에는 방화벽이 없었습니다. 다음 날 대학에서 나는 그것을 실제 생활에서 테스트할 준비가 되었습니다. 우연히 카페 테이블에 앉아 있다가 스푸핑을 이용해 MAC 주소를 알아내고 터널을 구축했습니다.
제가 시도한 어리석은 일들과 제가 했던 작은 실험들을 모두 기억하기 어렵기 때문에 이 부분을 최대한 정리하려고 노력했습니다. 나는 실제로 그렇게 명확하게 모든 일을 한 것은 아닙니다.
모든 것이 나를 위해 작동하도록
3시간이 걸렸고 가능한 모든 것을 시도하면서 정보 패킷을 수신할 때 "패킷!"을 외치고 자체 패킷을 보낼 때 뭔가 성가신 소리를 내도록 코드를 수정했습니다. 등등.
서버에서 다음 명령을 실행했습니다.
tsee-diees:~# ./create_tun wifi.ttu.ee
생성된 터널 장치: tun0
중지됨 ./create_tun wifi.ttu.ee
tsee-diees:~# ifconfig tun0 mtu 1400 192.168.3.1 위로
tsee-diees:~# 경로 추가 192.168.3.2 tun0
tsee-diees:~# tethereal -i eth0 -f "icmp"
나는 이것이 즉시 작동할 것이라고 생각하고 이것을 내 노트북에서 실행했습니다.
마크트웨인:~# ./create_tun 194.204.48.52
생성된 터널 장치: tun0
중지됨 ./create_tun 194.204.48.52
marktwain:~# ifconfig tun0 mtu 1400 192.168.3.2 위로
marktwain:~# 경로 추가 192.168.3.1 tun0
marktwain:~# tethereal -i eth0 -f "icmp"
내가 해야 했던 일은 창조하는 일이었다.
두 개의 호스트가 있는 네트워크(서버는 192.168.3.1, 노트북은 192.168.3.2). 단순한 일반 LAN에서는 물리적 계층만 ICMP 터널이 됩니다. 아마도 당신처럼
기사의 나머지 텍스트에서 이해됨
이 방법은 실제로 작동하지 않았습니다. ping("ping 192.168.3.1")을 시작했지만 패킷이 여전히 통과하지 못했습니다.
운 좋게도 랩톱의 스니퍼가 나에게 작은 단서를 제공했습니다. ICMP 패킷은 반환 응답이었습니다. 물론 그렇지 않습니다.
떠나고 있었다. 따라서 터널을 종료하고 노트북에서 itunnel을 활성화한 다음 역방향 icmp 응답을 사용하고("icmp->type = 0;"을 "icmp->type = 8;"로 변경) 터널을 반환합니다.
시스템은 여전히 작동하지 않았지만 이번에는 패키지가
서버의 스니퍼에 나타났습니다.
무엇이 잘못되었을 수 있나요? 다음 패킷이 도착했을 때 “Packet!”을 외치도록 수정해 보았으나 감탄사가 나오지 않았습니다.
일어났다. “방화벽이 설치되어 있으면 인터넷에서 모든 ICMP 패킷을 차단해야 하는 이유는 무엇입니까?”라고 나는 궁금했습니다. 얼마 후 나는 이것이 사실이라는 것을 깨달았습니다(인터넷의 모든 ICMP 패킷이 차단되었습니다).
이미 더 좋습니다. 터널은 "패킷!"이라고 외칩니다. , 응답은 서버의 스니퍼에서 볼 수 있습니다. 실제로 각 요청에는 두 가지 응답이 있으며 그 중 하나만 랩톱의 스니퍼에서 볼 수 있습니다. 그리고 ping이 여전히 작동하지 않습니다.
두 패킷 중 하나가 중복되므로 커널에 icmp 포스트백에 응답하지 말라고 지시했습니다.
tsee-diees:~# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
그리고 핑이 통과하기 시작했습니다! 이 시점에서 저는 여전히 스푸핑된 MAC 주소를 사용하여 서버에 액세스하고 있었습니다. 등록되지 않은 사용자로부터 양방향으로 이동하는 패킷을 가져오는 것이 아이디어였으므로 MAC 주소 스푸핑을 중단했습니다. 동시에 터널은 계속 작동했는데 이는 다소 즐거운 놀라움이었습니다.
패킷의 흐름이 확립되었고, "인터넷"이 작동할 때가 왔습니다.
IP를 일부 변경하는 데 필요함
노트북으로 라우팅. 통과 경로
대학 무선 라우터를 서버의 터널 주소(이 경우 192.168.3.1)로 교체해야 했습니다. 터널 자체가 작동할 수 있도록 서버에 대한 경로가 여전히 필요합니다(ICMP 터널 패킷에도 따라야 할 경로가 필요함).
좋은 결과를 얻었습니다.
marktwain:~# Route add 194.204.48.52 gw 10.0.0.111 # 무선 라우터를 통해
marktwain:~# 경로 델 기본값
marktwain:~# Route add default gw 192.168.3.1 # 터널을 통한 다른 모든 것.
그리고 제가 좀 똑똑해서, 둘 사이에 불일치가 있을 수도 있다고 생각했어요.
서버와 주고받는 패킷의 수. 핑을 시작했어요
상황을 추적하기 위해 백그라운드에서:.
마크트웨인:~# ping 194.204.48.52 -i 0.2
PING 194.204.48.52 (194.204.48.52) 56(84) 바이트의 데이터.
물론 응답은 없었습니다. 이는 "터널 핑"이 아니었고 커널의 응답은 다음과 같았습니다.
껐다.
내 서버는 이미 훈련을 받았기 때문에
여러 컴퓨터 간에 인터넷 연결을 공유하려면 서버에서 해야 할 일은 두 가지 규칙을 추가하는 것뿐이었습니다.
tun0과 주고받는 패킷을 받아들이는 iptables의 FORWARD 체인. 현재 규칙("iptables -vL FORWARD")을 정기적으로 확인했을 때 연결이 갑자기 끊어졌습니다. 이 문제에 대해 다시 연결하고 조사한 결과,
그러나 곧 연결이 다시 끊어졌습니다. 정말 놀랐습니다. 연결이 왜 이렇게 불안정합니까?
생각 끝에 서버가 큰 ICMP 응답을 보낼 때마다 깨달았습니다.
(결국 핑헤더만 1400+였음) 거절당함
장비 자체. 터널은 물리적이었기 때문에
IP 수준에서 TCP는 자연스럽게 패킷을 다시 보내려고 시도했지만 크기는 여전히 동일했고 여전히 폐기되었습니다. 그래서 터널의 MTU를 300(in)으로 변경했습니다.
일반적으로 우연히 말하자면)
marktwain:~# ifconfig tun0 mtu 300
tsee-diees:~# ifconfig tun0 mtu 300
그리고 전체 시스템이 작동했습니다.
6. 결론.
이제 직접 해보세요.
숨겨진 채널정보를 은밀하게, 무단으로, 불법적으로 전송하는 데 사용되는 행위를 은폐하거나 공격을 수행하는 방법 중 하나입니다. 숨겨진 채널을 통해 정보가 유출될 수도 있고 반대로 정보가 조직에 유입될 수도 있습니다. 인터넷의 숨겨진 채널은 공격자가 비밀 문서를 보안 시설 입구를 통해 밀반입하기 위해 숨길 수 있는 서류 가방의 비밀 칸에 비유될 수 있습니다. 인터넷에서 공격자는 숨겨진 채널을 사용하여 탐지되지 않은 상태에서 비밀 자료를 전송할 수 있습니다. 이 경우 네트워크 보안 메커니즘은 보안 게이트웨이 역할을 합니다. 스파이가 보안으로부터 숨기기 위해 동일한 비밀 칸에 무기를 숨길 수 있는 것처럼 침투하다공격자는 시설과 함께 인터넷에서 숨겨진 채널을 사용하여 비밀리에 사이버 무기를 전송할 수 있습니다. 예를 들어 외부 서버에서 조직의 개인 네트워크에 있는 노드로 악성 코드를 다운로드할 수 있습니다.
인터넷의 비밀 채널 이해
인터넷의 비밀 채널은 친숙한 인터넷 프로토콜의 색다른 사용을 기반으로 할 수 있습니다. 별도의 채널(감염된 컴퓨터와 공격자의 명령 센터)의 엔드포인트는 이러한 비전통적인 기술을 인식하고 처리하여 공격하거나 동작을 숨길 수 있는 특수 소프트웨어를 사용해야 합니다. 이러한 소프트웨어는 사용자 자신이나 맬웨어 또는 RAT(원격 관리 도구)를 사용하는 공격자가 설치할 수 있습니다. 인터넷 비밀 채널은 암호화된 터널과 다릅니다. 이를 통한 정보는 암호화되지 않은 상태로 전송될 수 있지만(종종 발생함) 이러한 채널 자체는 외부인에게 숨겨져 있습니다. 이 경우 암호화 또는 암호화 키를 사용할 필요가 없지만, 때때로 비밀 채널은 여전히 데이터를 암호화하거나 난독화하는 다양한 방법을 사용합니다.
두 가지 예를 살펴보겠습니다. 첫 번째 기술은 IP(인터넷 프로토콜) 패킷 헤더의 ID(식별자) 필드에 정보를 한 번에 한 문자씩 은밀하게 전송하는 것입니다. 이 기술의 일반적인 구현에서는 문자의 ASCII 코드에 256을 곱하여 식별자 필드에 대체되는 16비트 값을 생성합니다. ICANN 약어를 전송하려면 다음 식별자 필드 값을 사용하여 5개의 IP 패킷을 전송해야 합니다.
| 비닐 봉투 | 10진수 ASCII 값 | IP 패킷 ID(x256) |
| 1 | 71 ("나") | 18176 |
| 2 | 67 ("C") | 17152 |
| 3 | 65 ("A") | 16640 |
| 4 | 78 ("N") | 19968 |
| 5 | 78 ("N") | 19968 |
수신 컴퓨터는 결과 값을 256으로 나누어 IP 패킷 ID 필드의 값을 해독합니다. 이러한 값의 전송은 의심을 불러 일으키지 않으며 IP 프로토콜은 중복 패킷 전송을 허용하므로 그러한 가능성은 감지되는 트래픽이 적습니다. 느린 속도는 전송 스텔스로 보상됩니다.
비밀 채널을 생성하는 두 번째 기술은 프로토콜 페이로드, 즉 선택한 프로토콜의 프레임워크 내에서 전송되는 기술 정보를 사용하는 것입니다. 이 경우 ECHO 요청 및 응답에 데이터가 추가됩니다. 이는 ICMP(Internet Control Message Protocol)에서 사용되는 서비스 메시지입니다. ECHO 메시지는 공통 서비스에서 사용됩니다. 핑. 네트워크 관리자는 종종 ping을 사용하여 원격 호스트에 연결할 수 있는지 확인하므로 ICMP ECHO 패킷 트래픽은 일반적으로 방화벽과 같은 네트워크 보안 도구를 통해 허용됩니다.
이러한 기술에 대해 자세히 알아보려면 비밀 채널 Q&A 및 ICMP를 통한 비밀 채널(PDF, 740KB) 문서를 확인하세요.
더 나아가. DNS 비밀 채널
DNS(Domain Name System) 프로토콜에는 비밀 채널을 편리하게 사용할 수 있게 해주는 여러 가지 특성이 있습니다. DNS 트래픽은 방화벽을 통해 양방향으로 허용됩니다. 비밀 채널을 생성하기 위해 DNS를 사용할 때의 위험성은 종종 간과되거나 과소평가됩니다. 이것이 바로 조직이나 인터넷 서비스 제공업체가 공격 징후가 있는지 DNS 트래픽을 항상 확인하지 않는 이유입니다. 때로는 권한 부여 또는 사용자 인증 기능이 수행되기 전에 이름을 확인하기 위해 DNS 트래픽이 더 넓은 인터넷으로 유출되어 DNS 비밀 채널을 사용하여 이러한 액세스 제어를 우회할 수 있습니다.
다음 게시물에서는 DNS 비밀 채널을 사용하여 데이터를 추출하고, 액세스 제어를 우회하거나 맬웨어를 다운로드하는 방법을 다룰 것입니다.