La ricezione di connessioni IPv4 su AF_INET6 socket non è sicura?

8

La pagina man di FreeBSD per inet6 ha il seguente:

By default, FreeBSD does not route IPv4 traffic to AF_INET6 sockets. The default behavior intentionally violates RFC2553 for security reasons. Listen to two sockets if you want to accept both IPv4 and IPv6 traffic. IPv4 traffic may be routed with certain per-socket/per-node configuration, however, it is not recommended to do so. Consult ip6(4) for details.

OpenBSD ha anche una formulazione simile nel suo uomo pagina

For security reasons, OpenBSD does not route IPv4 traffic to an AF_INET6 socket, and does not support IPv4 mapped addresses, where IPv4 traffic is seen as if it comes from an IPv6 address like ::ffff:10.1.1.1. Where both IPv4 and IPv6 traffic need to be accepted, listen on two sockets.

Si tratta di sezione 3.7 di RFC2553 (obsoleto da RFC3493 ) relativo agli indirizzi IPv4 tradotti in ::FFFF:<IPv4-address> .

Quello che non capisco è quale tipo di problemi di sicurezza potrebbero essere esposti accettando le connessioni IPv4? Cosa rende un indirizzo IPv4 tradotto meno sicuro di qualsiasi altro indirizzo IPv6? E perché Linux consente un comportamento così "insicuro"?

    
posta imgx64 20.06.2015 - 16:28
fonte

1 risposta

5

La maggior parte di questi problemi di sicurezza si presentano quando un host accetta traffico IPv6 mappato IPv4 sulla rete , piuttosto che accettare il traffico IPv4 e presentarlo a un'applicazione su un socket IPv6 con un indirizzo mappato. Un'applicazione potrebbe non avere un buon modo per dire la differenza e rilevare un potenziale attacco in corso. Ovviamente nessun host dovrebbe mai accettare indirizzi mappati dalla rete, ma da quando i sistemi operativi si sono mai comportati perfettamente?

RFC 4942 § 2.2 spiega gli argomenti in modo approfondito:

Overloaded functionality is always a double-edged sword: it may yield some deployment benefits, but often also incurs the price that comes with ambiguity.

One example of such is IPv4-mapped IPv6 addresses (::ffff/96): a representation of an IPv4 address as an IPv6 address inside an operating system as defined in [RFC3493]. Since the original specification, the use of IPv4-mapped addresses has been extended to a transition mechanism, Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they are potentially used in the addresses of packets on the wire.

Therefore, it becomes difficult to unambiguously discern whether an IPv4 mapped address is really an IPv4 address represented in the IPv6 address format (basic API behavior) or an IPv6 address received from the wire (which may be subject to address forgery, etc.). (SIIT behavior). The security issues that arise from the ambiguous behavior when IPv4-mapped addresses are used on the wire include:

  • If an attacker transmits an IPv6 packet with ::ffff:127.0.0.1 in the IPv6 source address field, he might be able to bypass a node's access controls by deceiving applications into believing that the packet is from the node itself (specifically, the IPv4 loopback address, 127.0.0.1). The same attack might be performed using the node's IPv4 interface address instead.

  • If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field corresponding to IPv4 addresses inside a site's security perimeter (e.g., ::ffff:10.1.1.1), he might be able to bypass IPv4 packet filtering rules and traverse a site's firewall.

  • If an attacker transmits an IPv6 packet with IPv4-mapped addresses in the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, he might be able to use a node as a proxy for certain types of attacks. For example, this might be used to construct broadcast multiplication and proxy TCP port scan attacks.

In addition, special cases like these, while giving deployment benefits in some areas, require a considerable amount of code complexity (e.g., in the implementations of bind() system calls and reverse DNS lookups) that is probably undesirable but can be managed in this case.

In practice, although the packet translation mechanisms of SIIT are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], NAT-PT uses a mechanism different from IPv4-mapped IPv6 addresses for communicating embedded IPv4 addresses in IPv6 addresses. Also, SIIT is not recommended for use as a standalone transition mechanism. Given the issues that have been identified, it seems appropriate that mapped addresses should not be used on the wire. However, changing application behavior by deprecating the use of mapped addresses in the operating system interface would have significant impact on application porting methods as described in [RFC4038], and it is expected that IPv4-mapped IPv6 addresses will continue to be used within the API to aid application portability.

Using the basic API behavior has some security implications in that it adds additional complexity to address-based access controls. The main issue that arises is that an IPv6 (AF_INET6) socket will accept IPv4 packets even if the node has no IPv4 (AF_INET) sockets open. This has to be taken into account by application developers and may allow a malicious IPv4 peer to access a service even if there are no open IPv4 sockets. This violates the security principle of "least surprise".

    
risposta data 20.06.2015 - 21:18
fonte

Leggi altre domande sui tag