Channels
  • Peter

    Peter

    2 weeks ago
    Hey there 👋 Is there any way to canonicalise IPv4-Mapped IPv6 addresses in osquery? Such that I can filter and query using the IPv4 address of
    10.0.2.136
    for a connection where the
    remote_address
    is recorded as
    ::ffff:0a00:0288
    ?
  • s

    seph

    2 weeks ago
    That latter address looks like an ipv6 address. I don’t think osquery has any ipv6->ipv4 translation function. Is there a consistent mapping?
  • Peter

    Peter

    2 weeks ago
    Aye. From what I understand these are IPv4 mapped IPv6 addresses. They're a known standard for dual stack, where the first 80-bits are 0, 16-bits are 1 (0xFFFF), followed by the IPv4 address as a dotted quad or hex encoded integer (inet_aton style).
    The traffic itself uses IPv4, but the address is recorded as IPv6 in this format.
  • s

    seph

    2 weeks ago
    Several things….
    First, net10 is an internal address, so that may not ever translate to the remote_address — standard NAT issue.
    Osquery does have an inet_aton function, but it’s to go from dotted quad to int.
    select inet_aton("1.0.1.5") as ipInt ipInt = 16777477
    . It don’t see a reverse form.
    I imagine it’s possible to string split off the
    0a00:0288
    and then convert it. But it would be some kinda grotty work.
    And generally speaking. PRs welcome
  • Peter

    Peter

    2 weeks ago
    Thanks for the replies. In terms of this being an RFC1918 address: I'm aware, these events are related to network connections from a control-plane which intentionally are not internet routable, nor is there any address translation going on 🙂 In terms of
    inet_aton
    , this only supports a single address family, whereas the replacements
    inet_ntop
    and
    inet_pton
    (reverse) support multiple address families - currently, IPv4 and IPv6. I'll have a look into what may be required in order to canonicalise this data at query time, as logs for network connections shipped off-box would otherwise require upstream processing to ensure that the same "encoding" is used for IPv4 connections. Otherwise, if I bucket the data, I'll have one bucket for
    ::ffff:0a00:0288
    and another for
    10.0.2.136
    despite them being the same address.