좋은 오래된 IPV4 기반 iptables 방화벽 스크립트를 변환하고 CLASS A / B / C / D / E 예약 주소 공간을 IPV6에있는 주소 공간으로 대체하고 싶습니다. 내 목표는 이러한 주소에서 시작된 패킷을 거부하는 것입니다. 이러한 패킷은 공용 네트워크에 도달 할 수 없으므로 스푸핑되어야합니다.
지금까지 이것을 찾았습니다. 더 이상 예약 된 공간이 있습니까? IPV6 웹 서버에 대한 데이터가없는 곳이 있습니까?
루프백 :: 1
글로벌 유니 캐스트 (현재) 2000 :: / 3
고유 한 로컬 유니 캐스트 FC00 :: / 7
링크 로컬 유니 캐스트 FE80 :: / 10
멀티 캐스트 FF00 :: / 8
답변:
::/8 -예약 됨-더 이상 사용되지 않는 IPv4 호환 ::/960200::/7 -예약0400::/6 -예약0800::/5 -예약1000::/4 -예약2001:db8::/32 -문서2002::/24 -6to4 0.0.0.0/82002:0a00::/24 -6to4 10.0.0.0/82002:7f00::/24 -6to4 127.0.0.0/82002:a9fe::/32 -6to4 169.254.0.0/162002:ac10::/28 -6to4 172.16.0.0/122002:c000::/40 -6to4 192.0.0.0/242002:c0a8::/32 -6to4 192.168.0.0/162002:c612::/31 -6to4 198.18.0.0/152002:c633:6400::/40 -6to4 198.51.100.0/242002:cb00:7100::/40 -6to4 203.0.113.0/242002:e000::/20 -6to4 224.0.0.0/42002:f000::/20 -6to4 240.0.0.0/44000::/3 -예약6000::/3 -예약8000::/3 -예약a000::/3 -예약c000::/3 -예약e000::/4 -예약f000::/5 -예약f800::/6 -예약fc00::/7 -고유 지역fe00::/9 -예약fe80::/10 -로컬 링크fec0::/10-사이트 로컬 (더 이상 사용되지 않음, RFC3879 )ff00::/8 -멀티 캐스트참조 RFC 5156 및 IANA의 예약 목록을 참조하십시오.
실제로 수행중인 작업을 모르면 임의의 IPv6 주소를 차단 하지 마십시오 . 그만해, 이건 나쁜 습관이야 이렇게하면 예상치 못한 방식으로 연결이 끊어 질 수 있습니다. 얼마 후, 당신은 당신의 IPv6가 올바르게 동작하지 않는 것을 보게 될 것이고, 당신은 "IPv6가 작동하지 않는다"고 비난하기 시작할 것입니다.
ISP가 무엇이든, 에지 라우터는 이미 어떤 패킷을 보낼 수 있는지, 어떤 패킷을 받아 들일지를 알고 있으며 (스푸핑 된 주소에 대한 우려는 전혀 근거가 없습니다), 운영 체제는 나머지와 함께해야 할 일도 알고 있습니다. 15 년 전 방화벽 규칙을 작성하는 것에 대해 읽은 내용은 오늘 더 이상 적용되지 않습니다.
요즘에는 차단하려는 범위의 주소에서 패킷을 수신 할 때마다 어떤 종류의 공격보다 잘못 차단하는 합법적 인 패킷 일 가능성이 훨씬 높습니다. 인터넷의 중추를 관리하는 사람들은 당신보다 훨씬 더 많은 경험을 가지고 있으며, 이미 숙제를 제대로했습니다.
또한 예약 된 블록 목록과 각 블록에서 예상되는 내용은 암석에 설정되어 있지 않습니다. 그들은 시간이 지남에 따라 변합니다. 현재의 기대치가 더 이상 내일과 같지 않으면 방화벽이 잘못되어 연결이 끊어집니다.
방화벽은 네트워크 내부 의 내용을 보호하고 모니터링 해야합니다. 외부는 항상 변화하는 정글입니다.
2000::/3여유 공간이 부족 하기 전에 모두
당신은 기본적으로 가지고 있습니다. fec0 :: / 10에 사이트 로컬 주소에 대한 RFC도 있었지만 더 이상 사용되지 않습니다 . IPv6의 아이디어는 NAT가 더 이상 필요하지 않기 때문에 내부 네트워크에서 전체적으로 라우팅 가능한 주소도 사용할 수 있다는 것입니다. 방화벽은 적절하게 차단하도록 구성하기 만하면됩니다.
그런데 IPv4 랜드 클래스에서도 더 이상 참조되지 않습니다. CIDR 이 대신 사용됩니다.