shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
2007년 11월, 1970년대 프랑스의 트랜스팩 데이터 네트워크 창시자 중 한 명이었던 레미 데프레는 프랑스에서 두 번째로 큰 ISP인 프리에 자신이 발명한 6rd 메커니즘을 사용하여 IPv6를 신속하게 배포할 것을 제안했다. 당시 프리에는 IPv6 서비스를 제공할 단기 계획이 없었지만, 프리의 CTO인 라니 아사프는 즉시 이 솔루션을 구현하기로 결정했다. 5주 후, 적절한 마케팅 승인 및 운영 검증을 거쳐 프리 고객에게 IPv6가 제공된다는 보도 자료가 발표되었다.
6rd 메커니즘과 프리의 배포를 설명하는 첫 번째 초안은 2008년 2월 9일 국제 인터넷 표준화 기구에 제출되었다. 개선 후 2010년 1월 24일에 정보 제공용 RFC 5569로 게시되었다.
2010년 3월, 국제 인터넷 표준화 기구의 워킹 그룹은 6rd에 대한 최신 초안이 추가 수정 후 표준 트랙 RFC가 되어야 한다고 승인했다. 2010년 8월, 표준 트랙 RFC 5969가 게시되었다.
2010년 10월, 컴캐스트는 홈 게이트웨이 장치용 6rd 소프트웨어를 오픈 소스로 무료로 제공했다.
6to4와의 비교.
6to4는 기본 IPv6와 IPv4 간의 트래픽을 중계 서버를 사용하여 중계한다. 이 중계 서버는 중계 서비스를 제공할 준비가 된 네트워크에 공통 IPv4 및 IPv6 프리픽스를 광고하지만, 모든 기본 IPv6 호스트가 이러한 중계기로 향하는 작동 경로를 가지고 있다는 보장은 없다. 이 때문에 6to4 호스트는 모든 기본 IPv6 호스트에서 도달할 수 있다는 보장이 없다. 중계기가 사용 가능하더라도 종종 트래픽 증가에 따라 좋은 서비스 품질을 유지할 의무가 없는 제3자에 의해 운영된다. 6rd는 각 ISP가 6to4에 대해 표준화된 특별한 프리픽스 대신 자체 IPv6 프리픽스 중 하나를 사용하도록 하여 이 모델을 변경한다. 따라서 공급자는 자사의 6rd 호스트가 IPv6 네트워크에 도달할 수 있는 모든 기본 IPv6 호스트에서 도달할 수 있도록 보장한다. 중계기는 ISP의 완전한 통제하에 있으므로 고객에 대한 서비스 품질에 대한 전적인 책임을 유지한다.
6rd 중계기는 동일한 관리 엔터티의 통제하에 있는 제한된 호스트 집합에 의해서만 사용될 수 있으므로 6to4에서 가능한 트래픽 익명화 공격의 범위도 줄어든다.
주소 공간 소모.
전체 IPv4 주소 공간을 매핑하기 위해 32비트의 IPv6 주소 공간을 사용하는 가장 간단한 6rd 배포는 모든 ISP 라우터에서 기본적으로 IPv6가 지원되는 경우보다 더 많은 주소 공간을 소모한다. 이는 IPv4 주소 공간의 중복 부분을 생략하고, 경우에 따라 여러 6rd 도메인을 배포함으로써 완화될 수 있다.
대륙별 인터넷 레지스트리(RIR)에 의한 IPv6 공간의 기본 할당은 32비트 프리픽스이다. 6rd를 사용하여 IPv4 주소를 매핑하는 데 32비트가 걸리므로, 이는 ISP가 전체 IPv4 주소를 사용하려면 고객에게 64비트 IPv6 프리픽스만 할당할 수 있음을 의미한다. 그러나 6rd는 IPv4 주소의 중복 부분을 버릴 수 있도록 허용한다. 예를 들어, ISP가 고객에게 발행하는 IPv4 주소들이 모두 처음 18비트를 공유하는 경우, 6rd 프리픽스는 나머지 14비트만 포함하면 된다. 이러한 유연성 없이 프리는 원래 고객에게 64비트 IPv6 프리픽스를 할당했지만, RIPE NCC로부터 더 큰 IPv6 공간 할당(26비트 프리픽스)을 받은 후 더 짧은 프리픽스를 할당할 수 있었다.
세계 IPv6의 날(World IPv6 Day)은 2011년에 인터넷 협회와 여러 대형 인터넷 콘텐츠 서비스가 주최하고 조직한 기술 테스트 및 홍보 행사로, 공개 IPv6 배포를 테스트하고 홍보하는 데 목적이 있었다. 2011년 테스트 날의 성공에 이어, 인터넷 협회는 2012년 6월 6일에 세계 IPv6 런칭의 날(World IPv6 Launch Day)을 개최했다. 이 행사는 단순히 테스트 날이 아니라, 참가자들의 제품과 서비스에 IPv6를 영구적으로 활성화하는 것을 목표로 했다.
세계 IPv6의 날.
세계 IPv6의 날은 2011년 1월 12일에 페이스북, 구글, 야후!, 아카마이 테크놀로지스, 라임라이트 네트워크 등 5개 주요 기업과 함께 발표되었다. 이 행사는 2011년 6월 8일 UTC 00:00에 시작하여 같은 날 23:59에 종료되었다. 이 행사의 주요 동기는 다양한 합성 테스트에서 나타난 IPv6 고장의 실제 영향을 평가하는 것이었다. 이를 위해 세계 IPv6의 날 동안 주요 웹 기업 및 기타 산업 플레이어들은 24시간 동안 자사의 주요 웹사이트에서 IPv6를 활성화했다. 추가 목표는 인터넷 서비스 제공업체, 하드웨어 제조업체, 운영 체제 공급업체 및 웹 기업과 같은 산업 전반의 조직들이 IPv6를 위한 서비스를 준비하도록 동기를 부여하여, IPv4 주소 공간이 고갈됨에 따라 IPv4에서 성공적인 전환을 보장하는 것이었다.
이 테스트는 주로 웹사이트가 AAAA 레코드를 발행하여 IPv6를 지원하는 호스트가 IPv6를 사용하여 연결할 수 있도록 하는 것으로 구성되었다. 인터넷 서비스 제공자(ISP)들은 참여를 권장받았지만, 그날 어떤 활동적인 것을 배포할 것으로 예상되지 않았고, 단지 지원 문제를 처리할 준비를 강화하는 것이었다. 이 개념은 2010년 구글 IPv6 컨퍼런스에서 광범위하게 논의되었다.
가장 큰 검색 엔진, 소셜 네트워킹 웹사이트, 인터넷 백본 및 콘텐츠 전송 네트워크를 포함한 많은 회사와 조직이 이 실험에 참여했다.
초기 세계 IPv6의 날에는 400개 이상의 참가자가 있었으며, 여기에는 인터넷에서 가장 많이 접속되는 일부 목적지, 콘텐츠 전송 네트워크뿐만 아니라 다음과 같은 다양한 인터넷 서비스 및 인프라 제공업체도 포함되었다. 컴캐스트, 구글, 야후!, 페이스북, 얀덱스 유튜브, 아카마이 테크놀로지스, 라임라이트 네트워크, 마이크로소프트, 보니지, AOL, 맵퀘스트, T-온라인, 시스코 시스템즈, 주니퍼 네트웍스, 화웨이, NTP 풀, 미국 상무부, 마스터카드, 영국방송공사, 텔멕스.
주요 통신사들은 모든 인터넷 트래픽 중 IPv6 트래픽의 비율이 기본 및 터널링 스택을 합쳐 0.024%에서 0.041%로 증가했다고 측정했다.
소비자 접속 네트워크의 대부분의 IPv6 트래픽은 구글 사이트로 향했다. 콘텐츠 사이트가 성공을 위해 IPv6를 채택해야 할 필요성을 보여주듯이, 가장 큰 증가는 실제로 6to4 전환 기술에서 나타났다.
초기 결과에 따르면, 그 날은 계획대로 진행되었고 참가자들에게 심각한 문제는 없었다.
시스코 시스템즈와 구글은 테스트 동안 심각한 문제가 없었다고 보고했다. 페이스북은 결과를 고무적이라고 평가했으며, 그 결과 개발자 사이트에 IPv6를 활성화한 상태로 유지하기로 결정했다. 그러나 IPv6가 일관되게 적용되기 전에 더 많은 작업이 필요하다는 것이 일반적인 의견이었다.
참가자들은 데이터에 대한 상세한 분석을 계속 수행할 것이라고 말했다. 많은 참가자들이 듀얼 스택을 계속 유지하는 것이 가치 있다고 여겼다.
세계 IPv6 런칭.
초기 세계 IPv6의 날의 성공에 이어, 2012년 6월 6일 세계 IPv6 런칭으로 행사가 반복되었으며, 이번에는 모든 참여 사이트에 IPv6를 영구적으로 활성화하는 것을 목표로 했다. 이 행사는 "이번에는 진짜다"라고 홍보되었다.
세계 IPv6 런칭 참가자에는 2011년 테스트 날의 참가자들과 더 많은 기업이 포함되었으며, 위키미디어 재단도 위키백과를 포함한 자사 사이트에 IPv6를 영구적으로 활성화했다.
시스코의 알랭 피오코에 따르면, 현재 전 세계 월드 와이드 웹 IPv4 페이지뷰의 약 30%를 차지하는 콘텐츠는 세계 IPv6 런칭의 날 이후 IPv6를 통해 접근 가능하게 되었다고 한다. AMS-IX의 IPv6 트래픽은 런칭 날 50% 증가하여 2 Gbit/s에서 3 Gbit/s로 늘었다. 암스테르담 인터넷 익스체인지의 IPv6 트래픽은 이더 타입 분포에 따라 0.4%로 측정되었으며, IPv4는 일별 및 주별 그래프 모두에서 평균 99.6%로 측정되었다.
IPv6 전환 메커니즘(IPv6 transition mechanism)은 1983년부터 사용된 인터넷 프로토콜 버전 4(IPv4) 인프라에서 후속 주소 지정 및 라우팅 시스템인 인터넷 프로토콜 버전 6(IPv6)으로 인터넷 전환을 용이하게 하는 기술이다. IPv4 및 IPv6 네트워크는 직접적으로 상호 운용되지 않으므로, 전환 기술은 두 네트워크 유형의 호스트가 다른 모든 호스트와 통신할 수 있도록 설계되었다.
기술적 기준을 충족하기 위해 IPv6는 현재의 IPv4로부터 간단한 전환 계획을 가져야 한다. 국제 인터넷 표준화 기구(IETF)는 인터넷 드래프트와 Request for Comments 프로세스를 통해 워킹 그룹과 논의를 진행하여 이러한 전환 기술을 개발하고 있다. 일부 기본 IPv6 전환 메커니즘은 RFC 4213에 정의되어 있다.
스테이트리스 IP/ICMP 변환.
스테이트리스 IP/ICMP 변환 (SIIT)은 IPv6와 IPv4의 패킷 헤더 형식 간을 변환한다. SIIT 방식은 IPv4 변환 주소라고 불리는 IPv6 주소 클래스를 정의한다. 이들은 접두사 을 가지며 로 작성될 수 있으며, 여기서 IPv4 형식 주소 는 IPv6 지원 노드를 나타낸다. 이 접두사는 전송 프로토콜 헤더 체크섬 변경을 피하기 위해 0 값의 체크섬을 생성하도록 선택되었다.
이 알고리즘은 영구적으로 할당된 IPv4 주소가 없는 IPv6 호스트가 IPv4 전용 호스트와 통신할 수 있도록 하는 솔루션에 사용될 수 있다. 주소 할당 및 라우팅 세부 사항은 사양에서 다루지 않는다. SIIT는 스테이트리스 네트워크 주소 변환의 특수한 경우로 볼 수 있다.
이 사양은 NGTRANS IETF 워킹 그룹의 산물이며, 2000년 2월 썬 마이크로시스템즈의 E. Nordmark에 의해 처음 작성되었다. 2011년에 개정되었고, 2016년에 현재 개정판이 발표되었다.
터널 브로커.
터널 브로커는 IPv4 인터넷 전송 링크에서 IPv6 트래픽을 캡슐화하여 IPv6 연결을 제공하며, 일반적으로 6in4를 사용한다. 이는 IPv4 인터넷 내에 IPv6 터널을 설정한다. 터널은 터널 설정 프로토콜(TSP) 또는 AYIYA를 통해 관리될 수 있다.
6rd.
6rd는 레미 데프레스가 개발했다. 이는 ISP의 IPv4 인프라를 통해 IPv6 서비스를 신속하게 배포하는 것을 용이하게 하는 메커니즘이다. IPv4와 IPv6 주소 간의 스테이트리스 주소 매핑을 사용하며, IPv4 패킷과 동일하게 고객 노드 간에 최적화된 경로를 따르는 자동 터널을 통해 IPv6 패킷을 전송한다.
2007년에 네이티브 주소를 사용하는 IPv6 서비스의 초기 대규모 배포에 사용되었다 (RFC 5569). 프로토콜의 표준-트랙 사양은 RFC 5969에 있다.
전송 릴레이 변환.
전송 릴레이 변환 (TRT) 방식은 두 호스트 사이의 중간 장치 역할을 한다. 변환기의 기능은 IPv6 주소를 IPv4 주소로 변환하고 그 반대로도 변환하는 것이다. TRT는 IP 주소 매핑과 사용자 지정 IP 주소를 통해 이 변환을 수행한다.
예를 들어, IPv6 주소()에서 IPv4 주소()로 패킷이 전송될 경우, 주소는 로 읽힌다. 패킷은 먼저 IPv6/TCP 프로토콜을 통해 변환기로 라우팅된 다음, 변환기에서 IPv4/TCP 프로토콜을 통해 IPv4 호스트로 라우팅된다.
TRT는 DNS ALG로 알려진 AAAA 레코드와 A 레코드 간의 DNS 변환과 유사한 작업을 사용한다.
NAT64.
NAT64는 IPv6 호스트가 IPv4 서버와 통신할 수 있도록 하는 메커니즘이다. NAT64 서버는 최소한 하나의 IPv4 주소와 32비트의 IPv6 네트워크 세그먼트(예: )의 종단점이다. IPv6 클라이언트는 이러한 비트를 사용하여 통신하려는 IPv4 주소를 내장하고, 결과 주소로 패킷을 보낸다. 그러면 NAT64 서버는 IPv6 주소와 IPv4 주소 사이에 NAT 매핑을 생성하여 통신할 수 있도록 한다.
DNS64는 도메인의 AAAA 레코드를 요청받았을 때, A 레코드만 찾으면 A 레코드로부터 AAAA 레코드를 합성하는 DNS 서버를 설명한다. 합성된 IPv6 주소의 첫 번째 부분은 IPv6/IPv4 변환기를 가리키고, 두 번째 부분은 A 레코드의 IPv4 주소를 내장한다. 해당 변환기는 일반적으로 NAT64 서버이다. DNS64의 표준-트랙 사양은 RFC 6147에 있다.
이 전환 메커니즘에는 두 가지 주목할 만한 문제가 있다.
$ nslookup ipv6test.google.com 2606:4700:4700::64
권한 없는 응답:
ipv6test.google.com canonical name = ipv6test.l.google.com.
이름: ipv6test.l.google.com
주소: 64:ff9b::8efa:c3e4
ISATAP.
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)은 IPv4 네트워크 위에 듀얼 스택 노드 간에 IPv6 패킷을 전송하기 위한 IPv6 전환 메커니즘이다.
6over4(IPv4 멀티캐스트를 사용하는 이전 유사 프로토콜)와 달리, ISATAP은 IPv4를 가상 비방송 다중 접근 네트워크(NBMA) 데이터 링크 계층으로 사용하므로 기본 IPv4 네트워크 인프라가 멀티캐스트를 지원할 필요가 없다.
464XLAT.
464XLAT은 IPv6 전용 네트워크의 클라이언트가 IPv4 전용 인터넷 서비스에 접근할 수 있도록 한다.
클라이언트는 SIIT 변환기를 사용하여 IPv4에서 IPv6로 패킷을 변환한다. 이 패킷은 NAT64 변환기로 전송되어 IPv6에서 IPv4로 다시 변환된 후 IPv4 전용 서버로 전달된다. 클라이언트 변환기는 클라이언트 자체 또는 중간 장치에 구현될 수 있으며 CLAT(Customer-side transLATor)으로 알려져 있다. NAT64 변환기 또는 PLAT(Provider-side transLATor)는 서버와 클라이언트(CLAT를 통해) 모두에 도달할 수 있어야 한다. NAT64의 사용은 UDP, TCP 및 ICMP를 사용하는 클라이언트-서버 모델로 연결을 제한한다.
Dual-Stack Lite (DS-Lite).
듀얼 스택 라이트 기술은 인터넷 접속을 위해 고객 댁내 장치(CPE)에 IPv4 주소를 할당하는 것을 포함하지 않는다. CPE는 근거리 통신망의 네트워킹 요구 사항에 따라 LAN 클라이언트를 위해 사설 IPv4 주소를 분배한다. CPE는 IPv6 패킷 내에 IPv4 패킷을 캡슐화한다. CPE는 전역 IPv6 연결을 사용하여 패킷을 전역 IPv4 주소를 가진 ISP의 캐리어급 NAT(CGN)에 전달한다. 원래 IPv4 패킷은 복구되고 IPv4 패킷에 대해 NAT가 수행되어 공용 IPv4 인터넷으로 라우팅된다. CGN은 CPE 공용 IPv6 주소, 사설 IPv4 주소 및 TCP 또는 UDP 포트 번호를 세션으로 기록하여 트래픽 흐름을 고유하게 식별한다.
경량 4over6은 NAT 기능을 ISP 측에서 CPE로 이동시켜 캐리어급 NAT를 구현할 필요성을 없애면서 DS-Lite를 확장한다. 이는 각 CPE에 공유 IPv4 주소에 대한 포트 범위를 할당함으로써 달성된다. NAT 기능을 CPE로 이동하면 ISP는 각 가입자에 대해 추적되는 상태의 양을 줄일 수 있어 변환 인프라의 확장성을 향상시킨다.
V4-via-v6 라우팅.
V4-via-v6 라우팅은 IPv4 주소가 최종 호스트에만 할당되고 중간 라우터에는 IPv6 주소만 할당되는 기술이다. IPv4 경로는 평소와 같이 전파되며, 패킷 변환이나 캡슐화는 사용되지 않지만 IPv6 넥스트 홉을 사용한다. V4-via-v6는 코어 네트워크에 IPv6 주소만 할당하면 되므로 필요한 관리량을 줄이지만, 여전히 코어 네트워크가 IPv4 패킷을 전달할 수 있어야 한다.
V4-via-v6는 경계 경로 프로토콜(BGP) 및 바벨 라우팅 프로토콜에 정의되어 있다. 이는 버드 인터넷 라우팅 데몬 및 babeld에 구현되었다.
MAP.
주소 및 포트 매핑(MAP)은 시스코 시스템즈의 IPv6 전환 제안으로, A+P 포트 주소 변환과 ISP 공급자의 내부 IPv6 네트워크를 통한 IPv4 패킷 터널링을 결합한다. MAP-T 및 MAP-E는 2015년 7월 표준 트랙에 진입했으며, 스카이 이탈리아는 2021년 일찍이 인터넷 서비스에 MAP-T를 배포했다.
초안 제안.
다음 메커니즘은 여전히 논의 중이거나 IETF에서 폐기되었다.
IPv4 잔여 배포 (4rd)는 IPv6 네트워크를 통해 IPv4 서비스의 잔여 배포를 용이하게 하기 위한 실험적 메커니즘이다. 6rd와 마찬가지로 IPv6와 IPv4 간의 스테이트리스 주소 매핑을 사용한다. 이는 전송 계층 포트를 기반으로 하는 IPv4 주소 지정을 지원한다. 이는 A+P 모델의 스테이트리스 변형이다.
지원 중단된 메커니즘.
이러한 메커니즘은 IETF에 의해 지원이 중단되었다.
NAT-PT.
네트워크 주소 변환/프로토콜 변환(NAT-PT)은 RFC 2766에 정의되어 있지만, 수많은 문제로 인해 RFC 4966에 의해 구식화되고 역사적 상태로 폐기되었다. 이는 일반적으로 DNS 애플리케이션 계층 게이트웨이(DNS-ALG) 구현과 함께 사용된다.
NAPT-PT.
NAT-PT와 거의 동일하지만 RFC 2766에 설명된 네트워크 주소 포트 변환 + 프로토콜 변환은 주소뿐만 아니라 포트 변환도 추가한다. 이는 주로 메커니즘의 한쪽에서 두 호스트가 메커니즘의 다른 쪽에서 동일하게 노출된 포트를 사용하는 것을 방지하기 위한 것으로, 애플리케이션 불안정 및 보안 결함을 유발할 수 있다. 이 메커니즘은 RFC 4966에 의해 지원이 중단되었다.
B.A.T.M.A.N.(Better Approach to Mobile Ad-hoc Networking)은 독일 "프라이풍크" 커뮤니티에서 개발 중인 멀티홉 모바일 애드혹 네트워크용 라우팅 프로토콜이며, OLSR이 대규모 메시 배포의 성능 요구 사항을 충족하지 못했기 때문에 이를 대체하기 위해 고안되었다.
B.A.T.M.A.N.의 핵심은 네트워크를 통한 최적의 경로에 대한 지식의 분산이다. 즉, 단일 노드가 모든 데이터를 가지고 있지 않다. 이 기술은 네트워크 변경에 대한 정보를 네트워크의 모든 노드에 전파할 필요성을 없애준다. 각 노드는 데이터를 수신한 "방향"에 대한 정보만 저장하고 그에 따라 데이터를 전송한다. 데이터는 노드에서 노드로 전달되며, 패킷은 개별적이고 동적으로 생성된 경로를 얻는다. 집단 지성 네트워크가 생성된다.
2007년 초, B.A.T.M.A.N. 개발자들은 네트워크 계층 대신 데이터 링크 계층(OSI 모델의 2계층)에서 라우팅하는 아이디어를 실험하기 시작했다. 3계층 라우팅 데몬과 구별하기 위해 "adv"(고급) 접미사가 선택되었다. UDP/IP를 통해 교환된 정보를 기반으로 라우팅 테이블을 조작하는 대신, 가상 네트워크 인터페이스를 제공하고 이더넷 패킷을 자체적으로 투명하게 전송한다. batman-adv 커널 모듈은 2.6.38부터 공식 리눅스 커널의 일부가 되었다.
B.A.T.M.A.N.은 고전적인 라우팅 프로토콜의 요소들을 가지고 있다: 다른 B.A.T.M.A.N. 노드를 감지하고 노드들 사이의 최적 경로를 찾는다. 또한 새로운 노드를 추적하고 그 존재를 이웃에게 알린다.
정적 네트워크에서는 네트워크 관리자 또는 기술자가 어떤 컴퓨터가 어떤 경로 또는 케이블을 통해 연결되는지 결정한다. 라디오 네트워크는 끊임없이 변화하며, 낮은 참여 임계값이 "프라이풍크" 네트워크 기반의 중요한 부분이기 때문에 이 작업은 최대한 자동화되어야 한다.
정기적으로 모든 노드는 브로드캐스트를 전송하여 자신의 존재를 모든 이웃에게 알린다. 이웃들은 이 메시지를 다시 자신의 이웃에게 전달하고, 이런 식으로 네트워크의 모든 노드에 정보가 전달된다. 특정 노드로 가는 최적의 경로를 찾기 위해 B.A.T.M.A.N.은 수신된 발신자 메시지를 세고, 메시지가 어떤 이웃을 통해 들어왔는지 기록한다.
거리 벡터 프로토콜처럼 B.A.T.M.A.N.은 전체 경로를 결정하려 하지 않고, 발신자 메시지를 사용하여 올바른 방향으로의 첫 번째 패킷 전송 단계만 결정한다. 데이터는 그 방향의 다음 이웃에게 전달되고, 다음 이웃도 같은 메커니즘을 사용한다. 이 과정은 데이터가 목적지에 도달할 때까지 반복된다.
라디오 네트워크 외에도 B.A.T.M.A.N.은 이더넷과 같은 일반적인 유선 케이블 연결에서도 사용할 수 있다.
이 과제는 가능한 한 쉽고, 작고, 빠른 네트워크 프로토콜을 만드는 것이었다. 개발을 여러 단계로 나누고 반복적인 프로세스를 통해 복잡한 기능을 구현하는 것이 합리적이라고 보였다.
첫 번째 단계에서는 라우팅 알고리즘이 구현되었고, 실제 적용 가능성과 당면 과제에 대한 적합성이 테스트되었다. 발신자 메시지(존재 여부 정보)를 송수신하기 위해 UDP 포트 1966이 선택되었다.
버전 1 알고리즘은 중요한 가정을 했다: 노드가 다른 노드로부터 존재 데이터를 수신하자마자, 데이터도 다시 보낼 수 있다고 가정했다. 그러나 무선 네트워크에서는 단방향 통신만 가능한 경우, 즉 비대칭 링크가 존재할 수 있다. 이를 허용하고 발생하는 문제를 해결하기 위한 메커니즘이 프로토콜에 통합되었다. 이 메커니즘을 통해 노드는 이웃 노드가 양방향 통신을 제공하는지 여부를 결정할 수 있다. 양방향 노드만 네트워크의 일부로 간주되며, 단방향 노드는 더 이상 완전히 포함되지 않는다.
이 버전의 가장 큰 혁신은 B.A.T.M.A.N.이 여러 네트워크 장치를 지원한다는 점이다. B.A.T.M.A.N.이 실행되는 컴퓨터나 라우터는 높은 건물과 같은 중앙 위치에 배치될 수 있으며, 여러 유선 또는 무선 네트워크 인터페이스가 연결될 수 있다. 이렇게 배치될 경우 B.A.T.M.A.N.은 재전송 지연 없이 여러 방향으로 네트워크 데이터를 릴레이할 수 있다.
네트워크를 통한 최적 경로를 결정하는 동안 특정 비정상적인 현상과 특별한 상황이 발생할 수 있었다. 이러한 문제들은 원형 라우팅(데이터가 목적지에 도달하는 것을 방해할 수 있음)을 방지하기 위해 해결되고 대처되었다.
노드는 인터넷 접속을 제공한다는 정보를 네트워크에 알릴 수 있다. 다른 노드들은 이 정보를 사용하여 자신에게 가까운 인터넷 연결이 있는지, 그리고 얼마나 많은 대역폭을 사용할 수 있는지 평가한다. 그들은 특정 게이트웨이를 사용하거나 B.A.T.M.A.N.이 연결 속도와 같은 기준에 따라 사용할 게이트웨이를 결정하도록 허용할 수 있다.
B.A.T.M.A.N. 자체를 실행하지 않는 장치를 알리는 기능도 이 버전에 포함되었다. 일반적으로 이 방법은 홈 네트워크를 메시 네트워크에 연결하는 데 사용된다. 지붕의 안테나 설치는 B.A.T.M.A.N.을 통해 무선 네트워크에 연결하고, 건물의 나머지 부분은 단순히 알려져 접근 가능하게 된다.
이 버전의 B.A.T.M.A.N.은 실제 환경에서 높은 수준의 안정성을 보이지만 수렴 시간이 다소 느리다는 것이 입증되었다. 이는 이론적 분석에 의해 확인된다.
BMX6.
BatMan-eXperimental (BMX)는 독립적인 브로드캐스트 데이터그램으로 OGM(원천 메시지)을 여러 번 전송하여 실제 지수를 근사화하는 것을 목표로 한다. 이는 악셀 노이만이 개발한 BATMAN의 독립적인 분기였다. 보안 신뢰 멀티 토폴로지 라우팅(SEMTOR)을 통합한 확장 버전은 BMX7이라고 불린다.
버전 4는 비정상적인 링크 상황에서 전송 품질을 더 잘 감지하는 알고리즘을 구현한다. 발신자 메시지는 이 데이터를 통합하도록 업데이트되어 다른 노드들이 비대칭 연결의 품질을 더 잘 감지할 수 있도록 한다.
2017년 B.A.T.M.A.N.은 HBO 시리즈 실리콘 밸리 (시트콤)(시즌 4 에피소드 2)의 화이트보드에 쓰여 있었는데, 주인공 리처드 헨드릭스가 자신의 "새로운 인터넷" 개념의 구성 요소로 B.A.T.M.A.N.을 포함하는 것으로 보인다(텍스트는 화이트보드 오른쪽 상단에 표시되어 있다).
캡티브 포털(Captive portal)은 와이파이 또는 유선 네트워크에 새로 연결된 사용자에게 네트워크 리소스에 대한 더 넓은 접근 권한이 부여되기 전에 표시되는, 웹 브라우저로 접근하는 웹 페이지이다. 캡티브 포털은 일반적으로 인증, 전자지급결제대행서비스, 소프트웨어 사용권 동의/이용 목적 제한 방침 수락 또는 설문 조사 완료를 요구할 수 있는 랜딩 또는 로그인 페이지를 제공하는 데 사용된다. 캡티브 포털은 케이블 및 상업적으로 제공되는 와이파이와 홈 핫스팟을 포함한 광범위한 모바일 및 보행자 광대역 서비스에 사용된다. 캡티브 포털은 또한 아파트, 호텔 객실 및 비즈니스 센터와 같은 기업 또는 주거용 유선 네트워크에 대한 접근을 제공하는 데 사용될 수 있다.
캡티브 포털은 클라이언트에게 제공되며 게이트웨이 또는 웹 페이지를 호스팅하는 웹 서버에 저장된다. 게이트웨이의 기능 집합에 따라 웹사이트 또는 TCP 포트를 허용 목록에 추가하여 사용자가 캡티브 포털과 상호 작용할 필요 없이 사용할 수 있다. 연결된 클라이언트의 MAC 주소는 지정된 장치에 대한 로그인 프로세스를 우회하는 데 사용될 수도 있다.
WISPr은 이 웹 브라우저 기반 인증 방법을 Universal Access Method(UAM)라고 부른다.
캡티브 포털은 주로 사용자가 접근 조건(허용된 포트, 책임 등)을 알리는 환영 메시지를 보는 개방형 무선 네트워크에서 사용된다. 관리자는 자체 사용자가 자신의 행동에 책임을 지고 법적 책임을 피하도록 이를 수행하는 경향이 있다. 이 책임 위임이 법적으로 유효한지는 논란의 여지가 있다. 일부 네트워크는 네트워크에서 불법 활동이 발생할 경우 관리자가 당국에 정보를 제공할 수 있도록 사용자의 휴대폰 번호 또는 신원 정보를 입력하도록 요구할 수도 있다.
종종 캡티브 포털은 마케팅 및 상업적 통신 목적으로 사용된다. 사용자가 웹 브라우저에서 웹 기반 등록 양식을 작성하여 개인 데이터를 교환할 때까지 개방형 와이파이를 통한 인터넷 접근은 금지된다. 웹 기반 양식은 웹 브라우저에서 자동으로 열리거나, 사용자가 웹 브라우저를 열고 어떤 웹 페이지를 방문하려고 할 때 나타난다. 즉, 사용자는 인터넷 접근 권한이 부여되고 캡티브 포털을 "완료"할 때까지 인터넷에 자유롭게 접근할 수 없는 "포로" 상태이다. 이를 통해 이 서비스 제공자는 와이파이 접근 지점에 연결하는 사용자에게 광고를 표시하거나 보낼 수 있다. 이러한 유형의 서비스는 페이스북과 같은 사회 연결망 계정으로 로그인하도록 요청할 수 있으므로 때때로 "소셜 와이파이"라고도 알려져 있다. 지난 몇 년 동안 이러한 소셜 와이파이 캡티브 포털은 와이파이 데이터 수집을 중심으로 마케팅을 제공하는 다양한 회사와 함께 흔해졌다.
사용자는 캡티브 포털에서 많은 유형의 콘텐츠를 찾을 수 있으며, 콘텐츠를 보거나 특정 행동을 수행하는 대가(종종 상업적 연락을 가능하게 하기 위해 개인 데이터를 제공)로 인터넷 접근을 허용하는 경우가 많다. 따라서 캡티브 포털의 마케팅 사용은 리드 생성(비즈니스 연락처 또는 잠재 고객)을 위한 도구이다.
캡티브 포털을 구현하는 다양한 방법이 있다.
HTTP 리디렉션.
일반적인 방법은 모든 월드 와이드 웹 트래픽을 웹 서버로 보내는 것으로, 웹 서버는 캡티브 포털로 HTTP 302 리디렉션을 반환한다. 최신 인터넷 지원 장치가 네트워크에 처음 연결되면, 공급업체에서 미리 정의한 감지 URL로 HTTP 요청을 보내고 HTTP 상태 코드 200 OK 또는 204 No Content를 기대한다. 장치가 HTTP 2xx 상태 코드를 받으면 무제한 인터넷 접근 권한이 있다고 가정한다. 장치가 대신 캡티브 포털로 302 리디렉션 상태 코드를 받으면 캡티브 포털 프롬프트가 표시된다. 는 511 Network Authentication Required 상태 코드를 지정한다.
ICMP 리디렉션.
클라이언트 트래픽은 레이어 3 수준에서 ICMP 리디렉션을 사용하여 리디렉션될 수도 있다.
DNS를 통한 리디렉션.
클라이언트가 이름으로 원격 호스트의 리소스를 요청할 때, 해당 호스트 이름을 확인하기 위해 DNS가 쿼리된다. 캡티브 포털에서 방화벽은 네트워크의 DHCP가 제공하는 DNS 서버만 인증되지 않은 클라이언트가 사용할 수 있도록 보장한다(또는, 대안적으로 인증되지 않은 클라이언트의 모든 DNS 요청을 해당 DNS 서버로 전달한다). 이 DNS 서버는 모든 DNS 조회 결과로 캡티브 포털 페이지의 IP 주소를 반환한다.
DNS를 통한 리디렉션을 수행하기 위해 캡티브 포털은 DNS 하이재킹을 사용하여 중간자 공격과 유사한 작업을 수행한다. DNS 오염의 영향을 제한하기 위해 일반적으로 TTL 0이 사용된다.
캡티브 포털 API.
은 네트워크가 DHCP(IPv4 및 DHCPv6 모두) 옵션 및 IPv6 NDP 라우터 광고를 사용하여 캡티브 포털 API 엔드포인트의 존재를 클라이언트에게 알리는 표준화된 방법을 소개한다. RFC 8910은 2023년 7월에 Systemd-networkd v254에 구현되었다. 네트워크매니저 토론에서도 캡티브 포털 상호 작용에 사용될 가능성을 탐구했다.
캡티브 포털 탐지 URL은 일반적으로 캡티브 포털 뒤에 있지 않을 때 최소한의 표준화된 응답을 반환한다. 장치가 예상 응답을 받으면 직접 인터넷 접근 권한이 있다고 결론 내린다. 응답이 다르면 장치는 캡티브 포털 뒤에 있다고 가정하고 캡티브 포털 로그인 프로세스를 트리거한다.
캡티브 포털은 불완전한 방화벽 규칙 집합을 가지고 있는 것으로 알려져 있는데예를 들어 아웃바운드 포트가 열려 있어서클라이언트가 포털을 우회할 수 있다.
DNS 터널링.
일부 배포에서는 규칙 집합이 클라이언트의 DNS 요청을 인터넷으로 라우팅하거나, 제공된 DNS 서버가 클라이언트의 임의 DNS 요청을 처리한다. 이를 통해 클라이언트는 DNS 패킷 내에서 임의의 트래픽을 터널링하여 캡티브 포털을 우회하고 개방된 인터넷에 접근할 수 있다.
자동 제출.
일부 캡티브 포털은 적절하게 장착된 사용자 에이전트가 캡티브 포털을 감지하고 자동으로 인증할 수 있도록 구성될 수 있다. 애플의 Captive Portal Assistant와 같은 사용자 에이전트 및 보조 응용 프로그램은 올바른 자격 증명에 접근할 수 있는 한 서비스 운영자의 의지와 상관없이 캡티브 포털 콘텐츠 표시를 투명하게 우회할 수 있으며, 또는 잘못되거나 오래된 자격 증명으로 인증을 시도하여 의도하지 않은 결과(예: 우발적인 계정 잠금)를 초래할 수 있다.
MAC 스푸핑.
MAC 주소를 사용하여 연결된 장치를 추적하는 캡티브 포털은 이전에 인증된 장치의 MAC 주소를 재사용하여 우회될 수 있다. 유효한 자격 증명을 사용하여 캡티브 포털에 장치가 인증되면 게이트웨이는 해당 장치의 MAC 주소를 허용 목록에 추가한다. MAC 주소는 쉽게 스푸핑될 수 있으므로 다른 장치가 인증된 장치인 척하여 캡티브 포털을 우회할 수 있다. 다른 연결 컴퓨터의 IP 주소와 MAC 주소가 인증된 것으로 확인되면 모든 머신이 인증된 대상의 MAC 주소와 인터넷 프로토콜(IP) 주소를 스푸핑하고 게이트웨이를 통해 경로를 허용받을 수 있다. 이러한 이유로 일부 캡티브 포털 솔루션은 강탈 위험을 제한하기 위해 확장된 인증 메커니즘을 만들었다.
웹 브라우저 필요.
캡티브 포털은 종종 웹 브라우저 사용을 요구한다. 이메일 클라이언트나 인터넷에 의존하는 다른 응용 프로그램을 먼저 사용하는 사용자는 연결이 설명 없이 작동하지 않는 것을 발견할 수 있으며, 유효성을 검사하려면 웹 브라우저를 열어야 한다. 이는 운영체제에 웹 브라우저가 설치되어 있지 않은 사용자에게는 문제가 될 수 있다. 그러나 DNS에 의존하지 않는 이메일 및 기타 기능을 사용하는 것이 때로는 가능하다(예: 응용 프로그램이 호스트 이름 대신 연결 IP 주소를 지정하는 경우). 유사한 문제는 클라이언트가 AJAX를 사용하거나 웹 브라우저에 이미 페이지가 로드된 상태로 네트워크에 가입할 때 발생할 수 있으며, 이러한 페이지가 원본 서버에 HTTP 요청을 시도할 때 미정의 동작 (예: 손상된 메시지 나타남)을 유발한다.
마찬가지로, HTTPS 연결은 리디렉션될 수 없으므로(적어도 보안 경고를 트리거하지 않고는), 캡티브 포털에 의해 승인되기 전에 보안 웹사이트에만 접근하려는 웹 브라우저는 그러한 시도가 설명 없이 실패하는 것을 볼 것이다(일반적인 증상은 의도한 웹사이트가 다운되거나 접근할 수 없는 것처럼 보이는 것이다).
와이파이와 TCP/IP 스택은 있지만 HTTPS를 지원하는 웹 브라우저가 없는 플랫폼은 많은 캡티브 포털을 사용할 수 없다. 이러한 플랫폼에는 닌텐도 Wi-Fi 커넥션을 사용하는 게임을 실행하는 닌텐도 DS가 포함된다. 브라우저가 아닌 인증은 이 목적을 위한 XML 기반 인증 프로토콜인 WISPr을 사용하거나 MAC 기반 인증 또는 다른 프로토콜 기반 인증을 사용하여 가능하다.
또한 플랫폼 공급업체는 캡티브 포털 핫스팟 운영자와 서비스 계약을 맺어 핫스팟의 동화 속 정원을 통해 플랫폼 공급업체의 서버에 무료 또는 할인된 접근을 허용할 수 있다. 예를 들어, 2005년 닌텐도와 웨이포트는 특정 맥도날드 레스토랑에서 닌텐도 DS 사용자에게 무료 와이파이 접근을 제공하기 위해 협력했다. 또한, VoIP 및 SIP 포트는 게이트웨이를 우회하여 전화기가 전화를 걸고 받을 수 있도록 허용될 수 있다.
해커의 양심(The Conscience of a Hacker) 또는 해커 선언문(Hacker Manifesto)은 1986년 3월 18일, 더 멘토르라는 가명을 사용하며 리전 오브 둠이라는 2세대 해커 그룹에 속했던 컴퓨터 보안 해커인 로이드 블랭큰십이 작성한 짧은 에세이다.
이 글은 저자의 체포 이후 작성되었으며, 프랙이라는 지하 해커 이진에 처음으로 게재되었다. 이 글은 많은 웹사이트에서 찾아볼 수 있으며, 티셔츠와 영화에도 등장한다.
해커 문화의 초석으로 여겨지는 이 선언문은 다른 사람들을 착취하거나 해를 끼치려는 이기적인 욕구를 초월하는 해킹의 목적이 있으며, 기술은 우리의 시야를 넓히고 세상을 자유롭게 유지하는 데 사용되어야 한다고 주장한다.
이 글을 쓰게 된 동기를 묻자 블랭큰십은 이렇게 말했다. 나는 해킹 금단 현상을 겪고 있었고, 크레이그/나이트 라이트닝은 다가오는 프랙 호에 실을 무언가가 필요했다. 나는 달은 무자비한 밤의 여왕을 읽고 있었고 혁명이라는 생각에 매우 매료되었다. 더 중요한 공개 행사에서 체포와 기사의 작성 동기에 대해 묻자 블랭큰십은 이렇게 말했다. 나는 그냥 있어서는 안 될 컴퓨터에 있었다. 그리고 나와 같은 상황에 처한 전국의 친구들에게 큰 공감을 느꼈다. 영화 위험한 게임 이후의 시기였기 때문에 당시 해커에 대한 대중의 인식은 '야, 우리는 핵전쟁을 시작할 거야, 아니면 틱택토를 하든가, 둘 중 하나야' 정도였다. 그래서 나는 우리가 무엇을 하고 왜 하고 있는지에 대한 본질을 내가 정말로 느꼈던 대로 쓰려고 노력하기로 결정했다.
이 글은 1995년 영화 해커스에서 여러 번 인용되는데, 영화에서는 역사적으로 정확한 프랙이 아니라 해커 잡지 2600에서 읽히는 것으로 나온다.
더 멘토르는 H2K2에서 해커 선언문을 낭독하고 추가적인 통찰력을 제공했다. 이 글은 또한 게임 쿨파 인나타의 아이템이기도 하다.
해커 선언문 포스터는 2010년 영화 소셜 네트워크에서 마크 저커버그의 하버드 방에 등장한다.
해커 선언문은 에드워드 스노든의 자서전 영구 기록에 언급되어 있다.
앰플리튜드 프라블럼의 2019년 앨범 《크라임 오브 큐리오시티》는 더 멘토르 본인, YTCracker, 인버스 페이즈 및 TRIAD의 리눅스 커널 관리자 킹 피셔가 참여했으며 해커 선언문에 헌정되었다. 각 곡의 제목은 에세이의 구절이다.
레드 팀(Red team)은 적을 시뮬레이션하고, 조직의 지시에 따라 물리적 또는 디지털 침입을 시도한 다음, 조직이 방어력을 개선할 수 있도록 보고하는 그룹이다. 레드 팀은 조직을 위해 일하거나 조직에 고용된다. 그들의 작업은 합법적이지만, 레드 팀 활동이 진행되고 있다는 사실을 모르거나 레드 팀에 속을 수 있는 일부 직원들을 놀라게 할 수 있다. 레드 팀에 대한 일부 정의는 더 광범위하며, 조직 내에서 고정관념에서 벗어나 덜 그럴듯하다고 간주되는 대체 시나리오를 검토하도록 지시받은 모든 그룹을 포함한다. 이러한 지시는 잘못된 가정과 집단사고에 대한 중요한 방어가 될 수 있다. 레드 팀이라는 용어는 1960년대 미국에서 유래했다.
기술적 레드 팀은 네트워크와 컴퓨터를 디지털 방식으로 침해하는 데 중점을 둔다. 조직의 네트워크와 컴퓨터를 공격으로부터 방어하는 책임을 맡은 블루 팀이라는 사이버 보안 직원 그룹도 있을 수 있다. 기술적 레드 팀에서는 공격 벡터를 사용하여 접근 권한을 얻은 다음, 더 많은 장치를 잠재적으로 침해할 수 있는지 탐색하기 위해 정찰이 수행된다. 크리덴셜 헌팅은 컴퓨터에서 암호 및 세션 쿠키와 같은 크리덴셜을 찾는 것을 포함하며, 일단 이러한 크리덴셜이 발견되면 추가 컴퓨터를 침해하는 데 사용될 수 있다. 제3자의 침입 중에 레드 팀은 조직 방어를 돕기 위해 블루 팀과 협력할 수 있다. 교전규칙 및 표준 운영 절차는 레드 팀이 훈련 중에 손상을 일으키지 않도록 보장하기 위해 자주 활용된다.
물리적 레드 팀은 제한 구역에 진입하기 위해 팀을 파견하는 데 중점을 둔다. 이는 울타리, 카메라, 경보, 자물쇠, 직원 행동과 같은 물리적 보안을 테스트하고 최적화하기 위해 수행된다. 기술적 레드 팀과 마찬가지로 교전규칙은 레드 팀이 훈련 중에 과도한 손상을 일으키지 않도록 보장하는 데 사용된다. 물리적 레드 팀은 종종 정보가 수집되고 보안 약점이 식별되는 정찰 단계를 포함하며, 그 정보는 건물에 물리적으로 진입하기 위한 작전(일반적으로 야간에)을 수행하는 데 사용된다. 보안 장치는 도구와 기술을 사용하여 식별되고 무력화될 것이다. 물리적 레드 팀원들은 서버실에 접근하여 휴대용 하드 드라이브를 가져오거나, 임원 사무실에 접근하여 기밀 문서를 가져오는 것과 같은 특정 목표를 부여받을 것이다.
레드 팀은 사이버 보안, 공항의 보안, 법집행, 군대, 정보기관을 포함한 여러 분야에서 사용된다. 미국 정부에서 레드 팀은 미국 육군, 미국 해병대, 미국 국방부, 연방항공국, 미국 교통안전청에서 사용된다.
레드 팀과 블루 팀의 개념은 1960년대 초에 등장했다. 레드 팀의 초기 사례 중 하나는 냉전 기간 동안 미군을 위한 시뮬레이션을 수행한 싱크탱크인 랜드 연구소와 관련이 있었다. "레드 팀"과 빨간색은 소련을 나타내는 데 사용되었고, "블루 팀"과 파란색은 미국을 나타내는 데 사용되었다. 또 다른 초기 사례는 미국의 국방부 장관인 로버트 맥나마라가 어떤 정부 계약자가 실험용 항공기 계약을 수주해야 하는지 탐색하기 위해 레드 팀과 블루 팀을 구성한 것과 관련이 있었다. 또 다른 초기 사례는 군비 통제 조약 협상과 그 효과를 평가하는 것을 모델링한 것이었다.
레드 팀은 때때로 "반대적 사고" 및 집단사고(그룹이 반대 증거에도 불구하고 가정을 만들고 유지하려는 경향)와 연관된다. 레드 팀이라고 불리지는 않았지만, 집단사고에 맞서 싸우기 위해 그룹을 구성한 가장 초기 사례 중 하나라고 주장할 수 있는 그룹은 1973년 욤키푸르 전쟁 중 이스라엘의 의사결정 실패 이후 형성된 이스라엘 이프차 미스트라바이다. 임박한 공격에 대한 충분한 증거에도 불구하고 이스라엘에 대한 공격은 거의 이스라엘을 기습했고, 거의 이스라엘의 패배로 이어질 뻔했다. 이프차 미스트라바는 전쟁 후 형성되었으며, 외교 정책 및 정보 보고서에 대해 항상 반대적이고, 예상치 못하며, 비정통적인 분석을 제시하여 앞으로 간과되는 일이 줄어들도록 하는 임무를 부여받았다.
2000년대 초에는 테이블탑 훈련에 레드 팀이 사용된 사례가 있다. 테이블탑 훈련은 종종 응급 구조대에 의해 사용되며, 테이블탑 보드 게임을 하는 것과 유사하게 최악의 시나리오에 대해 연기하고 계획하는 것을 포함한다. 9·11 테러에 대한 대응으로, 테러 방지를 염두에 두고 중앙정보국은 새로운 레드 셀을 만들었고, 레드 팀은 테러리즘과 같은 비대칭전에 대한 대응을 모델링하는 데 사용되었다. 이라크 전쟁의 실패에 대한 대응으로 레드 팀 활동은 미국 육군에서 더욱 보편화되었다.
시간이 지남에 따라 레드 팀 활동은 기업, 정부 기관, 비영리 조직을 포함한 다른 산업 및 조직으로 확장되었다. 이 접근 방식은 사이버 보안 세계에서 점점 더 인기를 얻고 있으며, 레드 팀은 조직의 디지털 인프라에 대한 실제 공격을 시뮬레이션하고 사이버 보안 조치의 효과를 테스트하는 데 사용되고 있으며, LLM과 같은 생성형 AI 기술 분석으로 발전하고 있다.
기술적 레드 팀은 조직의 컴퓨터 시스템을 디지털 방식으로 침투하려고 시도하여 조직의 디지털 보안을 테스트하는 것을 포함한다.
블루 팀은 침입에 대한 방어를 담당하는 그룹이다.
사이버 보안에서 모의 침투 테스트는 윤리적 해커("펜 테스터")가 컴퓨터 시스템에 침입하려고 시도하는 것을 포함하며, 놀라움의 요소는 없다. 조직은 모의 침투 테스트를 인지하고 방어할 준비가 되어 있다.
레드 팀은 한 걸음 더 나아가 물리적 침투, 사회공학, 그리고 놀라움의 요소를 추가한다. 블루 팀은 레드 팀에 대한 사전 경고를 받지 않으며, 이를 실제 침입으로 취급한다. 영구적인 내부 레드 팀의 역할 중 하나는 조직의 보안 문화를 개선하는 것이다.
퍼플 팀은 두 팀의 임시적인 조합이며 테스트 중에 신속한 정보 대응을 제공할 수 있다. 퍼플 팀의 한 가지 장점은 레드 팀이 특정 공격을 반복적으로 실행할 수 있고, 블루 팀은 이를 사용하여 탐지 소프트웨어를 설정하고, 보정하고, 탐지율을 꾸준히 높일 수 있다는 것이다. 퍼플 팀은 "위협 헌팅" 세션에 참여할 수 있으며, 레드 팀과 블루 팀 모두 실제 침입자를 찾는다. 퍼플 팀에 다른 직원들을 참여시키는 것도 유익하며, 예를 들어 로깅 및 소프트웨어 경고를 도울 수 있는 소프트웨어 엔지니어와 가장 재정적으로 손실이 큰 시나리오를 식별하는 데 도움을 줄 수 있는 관리자가 있다. 퍼플 팀의 한 가지 위험은 안일함과 집단사고의 발전이며, 이는 다른 기술 세트를 가진 사람들을 고용하거나 외부 공급업체를 고용함으로써 극복할 수 있다.
화이트 팀은 레드 팀과 블루 팀 간의 작업을 감독하고 관리하는 그룹이다. 예를 들어, 이는 레드 팀의 교전규칙을 결정하는 회사의 관리자일 수 있다.
레드 팀 또는 적의 초기 진입 지점을 교두보라고 한다. 성숙한 블루 팀은 종종 교두보를 찾아 공격자를 제거하는 데 능숙하다. 레드 팀의 역할은 블루 팀의 기술을 향상시키는 것이다.
침투 시, 블루 팀의 레이더망을 벗어나 명확한 목표를 요구하는 은밀한 "수술적" 접근 방식과 무차별 대입 공격에 가까운 시끄러운 "카펫 폭격" 접근 방식이 있다. 카펫 폭격은 종종 레드 팀에게 더 유용한 접근 방식인데, 예상치 못한 취약점을 발견할 수 있기 때문이다.
다양한 사이버 보안 위협이 존재한다. 위협은 네트워크의 도메인 컨트롤러를 해킹하는 것과 같은 전통적인 것부터 암호화폐 채굴을 설정하거나 직원에게 개인 식별 정보 (PII)에 대한 너무 많은 접근 권한을 제공하여 회사에 일반 데이터 보호 규칙 (GDPR) 벌금을 초래하는 것과 같은 덜 정통적인 것까지 다양할 수 있다. 이러한 위협 중 어떤 것도 레드 팀이 되어 문제의 심각성을 탐색할 수 있다. 테이블탑 게임을 하는 것처럼 침입을 연기하고 계획하는 테이블탑 훈련은 너무 비용이 많이 들거나, 너무 복잡하거나, 실제 실행하기에 불법적인 침입을 시뮬레이션하는 데 사용될 수 있다. 전통적인 목표 외에도 레드 팀과 블루 팀에 대한 침입을 시도하는 것이 유용할 수 있다.
네트워크에 대한 접근 권한이 확보되면 정찰을 수행할 수 있다. 수집된 데이터는 시각적으로 노드, 관계 및 속성을 그리는 소프트웨어인 그래프 데이터베이스에 저장될 수 있다. 일반적인 노드는 컴퓨터, 사용자 또는 권한 그룹일 수 있다. 레드 팀은 일반적으로 자신의 조직에 대한 매우 좋은 그래프 데이터베이스를 가지고 있는데, 이는 블루 팀과 협력하여 네트워크의 상세한 지도와 사용자 및 관리자의 상세한 목록을 만드는 등 홈 필드 이점을 활용할 수 있기 때문이다. 사이퍼와 같은 질의 언어를 사용하여 그래프 데이터베이스를 만들고 수정할 수 있다. 아마존 웹 서비스 (AWS)와 같은 타사 도구의 관리자를 포함한 모든 유형의 관리자 계정은 그래프 데이터베이스에 배치하는 데 중요하다. 데이터는 때때로 도구에서 내보낸 다음 그래프 데이터베이스에 삽입될 수 있다.
레드 팀이 컴퓨터, 웹사이트 또는 시스템을 침해하면 강력한 기술은 크리덴셜 헌팅이다. 이는 일반 텍스트 비밀번호, 암호문, 해시 또는 액세스 토큰의 형태일 수 있다. 레드 팀은 컴퓨터에 접근하고, 다른 컴퓨터에 접근하는 데 사용될 수 있는 크리덴셜을 찾은 다음, 많은 컴퓨터에 접근하는 것을 목표로 이를 반복한다. 크리덴셜은 파일, Git과 같은 소스 코드 저장소, 주기억장치, 추적 및 로깅 소프트웨어를 포함한 여러 위치에서 훔칠 수 있다. 패스 더 쿠키 및 패스 더 해시와 같은 기술을 사용하여 비밀번호를 입력하지 않고도 웹사이트 및 기계에 접근할 수 있다. 광학 문자 인식 (OCR), 기본 암호 악용, 크리덴셜 프롬프트 스푸핑, 피싱과 같은 기술도 사용할 수 있다.
레드 팀은 컴퓨터 프로그래밍 및 명령줄 인터페이스 (CLI) 스크립트를 활용하여 일부 작업을 자동화할 수 있다. 예를 들어, CLI 스크립트는 마이크로소프트 윈도우 기기에서 컴포넌트 오브젝트 모델 (COM)을 활용하여 마이크로소프트 오피스 애플리케이션의 작업을 자동화할 수 있다. 유용한 작업에는 이메일 전송, 문서 검색, 암호화 또는 데이터 검색이 포함될 수 있다. 레드 팀은 인터넷 익스플로러의 COM, 구글 크롬의 원격 디버깅 기능 또는 테스트 프레임워크인 셀레늄을 사용하여 브라우저를 제어할 수 있다.
실제 침입 중에는 레드 팀을 재편성하여 블루 팀과 협력하여 방어를 도울 수 있다. 특히, 침입자들이 다음에 무엇을 시도할 가능성이 있는지에 대한 분석을 제공할 수 있다. 침입 중에 레드 팀과 블루 팀 모두 침입자보다 조직의 네트워크와 시스템에 더 익숙하기 때문에 홈 필드 이점을 갖는다.
조직의 레드 팀은 실제 공격자에게 매력적인 목표가 될 수 있다. 레드 팀 구성원의 컴퓨터에는 조직에 대한 민감한 정보가 포함될 수 있다. 이에 대응하여 레드 팀 구성원의 컴퓨터는 종종 보안이 강화된다. 컴퓨터를 보호하는 기술에는 운영 체제의 방화벽 구성, 시큐어 셸 (SSH) 및 블루투스 접근 제한, 로깅 및 경고 개선, 파일 안전 삭제, 하드 드라이브 암호화 등이 있다.
한 가지 전술은 "능동 방어"에 참여하는 것으로, 이는 침입자의 위치를 추적하는 데 도움이 되는 미끼 및 허니팟을 설정하는 것을 포함한다. 이러한 허니팟은 그렇지 않으면 감지되지 않았을 수 있는 네트워크 침입에 대해 블루 팀에게 경고하는 데 도움이 될 수 있다. 운영 체제에 따라 허니팟 파일을 설정하는 데 다양한 소프트웨어를 사용할 수 있다. macOS 도구에는 OpenBMS가, Linux 도구에는 auditd 플러그인이, Windows 도구에는 시스템 액세스 제어 목록 (SACL)이 포함된다. 알림에는 팝업, 이메일, 로그 파일 작성 등이 포함될 수 있다. 중요한 로그 파일을 다른 컴퓨터의 로깅 소프트웨어로 신속하게 전송하는 중앙 집중식 모니터링은 유용한 네트워크 방어 기술이다.
레드 팀 관리.
교전규칙 사용은 접근 금지 시스템을 명확히 하고, 보안 사고를 방지하며, 직원 프라이버시가 존중되도록 보장하는 데 도움이 될 수 있다. 표준 운영 절차 (SOP) 사용은 적절한 사람들이 통보되고 계획에 참여하도록 보장하고, 레드 팀 프로세스를 개선하여 성숙하고 반복 가능하게 만들 수 있다. 레드 팀 활동은 일반적으로 규칙적인 리듬을 갖는다.
특정 지표 또는 핵심 성과 지표 (KPI)를 추적하는 것은 레드 팀이 원하는 결과물을 달성하고 있는지 확인하는 데 도움이 될 수 있다. 레드 팀 KPI의 예로는 연간 특정 횟수의 모의 침투 테스트를 수행하거나 특정 기간 내에 특정 수의 펜 테스터로 팀을 확장하는 것이 포함된다. 침해된 기계, 침해 가능한 기계 및 침투와 관련된 기타 지표의 수를 추적하는 것도 유용할 수 있다. 이러한 통계는 일별로 그래프로 표시하고 보안 관제 센터 (SOC)에 표시되는 대시보드에 배치하여 블루 팀에게 침해를 감지하고 차단하도록 동기를 부여할 수 있다.
최악의 위반자를 식별하기 위해 침해는 소프트웨어에서 발견된 위치, 회사 사무실 위치, 직책 또는 부서별로 그래프로 표시되고 그룹화될 수 있다. 몬테카를로 시뮬레이션은 어떤 침입 시나리오가 가장 가능성이 높고, 가장 큰 피해를 주거나, 둘 다인지 식별하는 데 사용될 수 있다. 능력 성숙도 모델 유형인 테스트 성숙도 모델은 레드 팀이 얼마나 성숙했는지, 그리고 성장하기 위한 다음 단계가 무엇인지 평가하는 데 사용될 수 있다. 지능형 지속 공격 (APT)을 포함한 전술, 기술 및 절차 (TTP) 목록인 MITRE ATT&amp;CK Navigator는 레드 팀이 얼마나 많은 TTP를 악용하고 있는지 확인하고, 미래에 활용할 TTP에 대한 추가 아이디어를 제공하는 데 참고할 수 있다.
물리적 침입.
물리적 레드 팀 활동 또는 물리적 모의 침투 테스트는 시설의 물리적 보안, 직원 및 보안 장비의 보안 관행을 테스트하는 것을 포함한다. 보안 장비의 예로는 보안 카메라, 자물쇠, 울타리 등이 있다. 물리적 레드 팀 활동에서는 컴퓨터 네트워크가 일반적으로 목표가 아니다. 일반적으로 여러 보안 계층을 갖는 사이버 보안과 달리 물리적 보안은 한두 계층만 존재할 수 있다.