Hopopt security question

[Timothy Rice]

G'day all,

Yesterday while mucking around with my firewall I added some logging rules
to iptables to show which protocols are hitting my machine. I was only
expecting tcp, udp and icmp, so was rather surprised when the logs showed
bombardment by something called hopopt, which I'd never heard of before.

Now that I've investigated, it appears that most of the time hopopt is
harmless and indeed seems to be necessary for ssh. For the moment, I've
set hopopt as permitted but rate-limited.

I was just wondering what would be considered best practice for dealing
with hopopt in iptables? Could hopopt ever be used as a vector for malware,
intrusion, or other compromise? Does it hurt to rate-limit it? What's the
worst that could go wrong if I just give it blanket acceptance and don't
log it?


Cheers,


Tim Rice
--
PhD Candidate
A: Room 210, Richard Berry (Maths & Stats), Melbourne University
E: t.r...@ms.unimelb.edu.au
W: http://www.ms.unimelb.edu.au/~trice
G: https://github.com/cryptarch

[hannah commodore]

On 28 Jul 2014, at 10:41, Timothy Rice <t.r...@ms.unimelb.edu.au> wrote:

> G'day all,
>
> Yesterday while mucking around with my firewall I added some logging rules
> to iptables to show which protocols are hitting my machine. I was only
> expecting tcp, udp and icmp, so was rather surprised when the logs showed
> bombardment by something called hopopt, which I'd never heard of before.
>
> Now that I've investigated, it appears that most of the time hopopt is
> harmless and indeed seems to be necessary for ssh. For the moment, I've
> set hopopt as permitted but rate-limited.

I see hopopt is registered in /etc/protocols as proto ID 0, and is described
as "IPv6 Hop-by-Hop Option".

I highly doubt that it's legitimate traffic of this type, and that something
is not decoding the protocol field properly, so it defaults to 0?
Certainly I've never seen hopopt in use on any network I administer

> I was just wondering what would be considered best practice for dealing
> with hopopt in iptables? Could hopopt ever be used as a vector for malware,
> intrusion, or other compromise? Does it hurt to rate-limit it? What's the
> worst that could go wrong if I just give it blanket acceptance and don't
> log it?

I'd suggest using tcpdump or dumpcat from Wireshark to save a sampling of
the data, and see what it's actually being used for. It is curious to say
the least

Hannah

[Timothy Rice]

G'day Hannah,

Thanks for your input.

> I see hopopt is registered in /etc/protocols as proto ID 0, and is described
> as "IPv6 Hop-by-Hop Option".

Yeah; although I don't know what IPv6 Hop-by-Hop Option means :-)

> I highly doubt that it's legitimate traffic of this type, and that something
> is not decoding the protocol field properly, so it defaults to 0?
> Certainly I've never seen hopopt in use on any network I administer

The idea about something or other defaulting to 0 seems reasonable. The
(pseudo-)hopopt traffic I've seen has been of two distinct sorts.

When I first investigated it at home, most of the bombardment was coming
from my housemate's PS3. When I used tcpdump I saw some stuff in there about
an EA gameserver. When I googled the exact text it came up with a match for
the Battlefield franchise. So even though I don't know what games my housemate
owns, I guess yesterday he was playing Battlefield 4 :D

Secondly, the hopopt traffic seems to be carrying some DNS stuff. I've added the
same logging into my desktop here at uni and am get similar results to at home.
When I run,

$ sudo journalctl -r -b -k | head -5

I get,

-- Logs begin at Sun 2013-10-20 12:01:41 EST, end at Mon 2014-07-28 14:28:46 EST. --
Jul 28 14:28:45 pc2517 kernel: Iptables: Hopopt/MDNS IN=eno1 OUT= MAC=01:00:5e:00:00:fb:18:03:73:2f:05:86:08:00 SRC=128.250.24.134 DST=224.0.0.251 LEN=73 TOS=0x00 PREC=0x00 TTL=255 ID=48704 DF PROTO=UDP SPT=5353 DPT=5353 LEN=53
Jul 28 14:28:45 pc2517 kernel: Iptables: Hopopt/MDNS IN=eno1 OUT= MAC=ff:ff:ff:ff:ff:ff:34:15:9e:39:f7:a0:08:00 SRC=128.250.30.231 DST=255.255.255.255 LEN=131 TOS=0x00 PREC=0x00 TTL=64 ID=9846 PROTO=UDP SPT=17500 DPT=17500 LEN=111
Jul 28 14:28:45 pc2517 kernel: Iptables: Hopopt/MDNS IN=eno1 OUT= MAC=ff:ff:ff:ff:ff:ff:40:6c:8f:18:bd:d6:08:00 SRC=128.250.30.37 DST=255.255.255.255 LEN=132 TOS=0x00 PREC=0x00 TTL=64 ID=9351 PROTO=UDP SPT=17500 DPT=17500 LEN=112
Jul 28 14:28:45 pc2517 kernel: Iptables: Hopopt/MDNS IN=eno1 OUT= MAC=ff:ff:ff:ff:ff:ff:34:15:9e:07:f5:22:08:00 SRC=128.250.30.136 DST=255.255.255.255 LEN=171 TOS=0x00 PREC=0x00 TTL=64 ID=20330 PROTO=UDP SPT=17500 DPT=17500 LEN=151

The mention of MDNS in the log is because I googled "224.0.0.251". Apparently
this address is used for multicast DNS (something else I don't know much about).

Another reason to suspect it's related to DNS is because when I started blanket
rejecting all "hopopt" packets, I was no longer able to ssh into the machine.

In case it's relevant, I'm running Archlinux on all boxes and the iptables rule
I'm using to log hopopt is,

-A INPUT ! -i lo -p hopopt -j LOG --log-prefix "Iptables: Hopopt/MDNS "

> I'd suggest using tcpdump or dumpcat from Wireshark to save a sampling of
> the data, and see what it's actually being used for. It is curious to say
> the least

These sound like good ideas. I haven't had occasion to use wireshark much
before so I'll need to read up on how to do this properly. Also, if I'm
going to be wiresharking all the packets, I'm probably better off doing that
on my own home network, so I might set this aside until tonight ;-)


Thanks again.


Cheers,


Tim

[hannah commodore]

On 28 Jul 2014, at 15:07, Timothy Rice <t.r...@ms.unimelb.edu.au> wrote:

> -A INPUT ! -i lo -p hopopt -j LOG --log-prefix "Iptables: Hopopt/MDNS "

You could also add --log-ip-options to the firewall rule to see more verbose
messages about the protocol headers. Might be useful

[Jafaruddin Lie]

Hop-By-Hop option is part of IPv6 extension header.

Basically this section of the extension header specifies all the options that need to be looked at by all devices in the routing path (some other option, for example, Destination Options are not looked at by the intermediary devices). Where are these IPv6 packets coming from? Your internal network or  external network? 

--
You received this message because you are subscribed to the Google Groups "mlug-au" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mlug-au+u...@googlegroups.com.
To post to this group, send email to mlu...@googlegroups.com.
Visit this group at http://groups.google.com/group/mlug-au.
For more options, visit https://groups.google.com/d/optout.

--
Registered Linux user no. 384430

[Timothy Rice]

G'day Jafaruddin,

> Hop-By-Hop option is part of IPv6 extension header.
> Basically this section of the extension header specifies all the options
> that need to be looked at by all devices in the routing path (some other
> option, for example, Destination Options are not looked at by the
> intermediary devices). Where are these IPv6 packets coming from? Your
> internal network or external network?

Thanks for the explanation.

Something else that may or may not be relevant is that I've got ipv6 disabled
on the kernel commandline.

The packets are mainly coming from the local network -- either getting
broadcast from the PS3 running Battlefield or when I use ssh. However, I've
noticed a few coming from externally. At first I thought this was because I
have an open ssh port that gets attacked a lot. However, it just occurred to
me that it might be because I have the tor service enabled. I guess the tor
service needs to regularly keep in touch with the tor network even when it's
not in active use?

[Jafaruddin Lie]

Hi Tim

Those packets were generated by other devices on your network that uses IPv6.

Without looking further, my guess it is probably MDNS.

For your SSH connection, your server might be configured to listen on :: (check your /etc/ssh/sshd_config and remove Listen :: line) and make sure AddressFamily is set to inet and not default.

This is, of course, assuming you are running openSSH :)

I hope that helps.

*Now maybe I can go back lurking on the list :P

[Timothy Rice]

> You could also add --log-ip-options to the firewall rule to see more verbose
> messages about the protocol headers. Might be useful

Thanks -- although it didn't seem to change anything :-)

I've found that I can consistently get hopopt entries to appear in the
kernel/iptables log by taking the wifi down then bringing it back up again.
I manage the wifi manually using wpa_supplicant and dhclient. Everything
is restricted to IPv4.

I wasn't able to get tcpdump or tshark to filter on protocol (maybe I used
the wrong commands?) so chose "dst 224.0.0.251" since the iptables log shows
a lot of "hopopt" directed there. Thus, the tcpdump and tshark commands
might not have captured everything, and they might have some false positives.

The commands to generate the attached files were:

$ sudo tcpdump -vvv -XX -i wlp4s7 dst 224.0.0.251 -w tcpdump.cap
$ tshark -i wlp4s7 dst 224.0.0.251 -w tshark.cap
$ sudo journalctl -r -b -k | grep Iptables | head > hopopt.log
$ sudo nmap -sS localhost > nmap.log

If anyone shares my inexperience with tcpdump and tshark, you can convert the
above cap files back into human-readable form with:

$ tcpdump -vvv -XX -r tcpdump.cap
$ tshark -r tshark.cap

192.168.1.2 is the workstation ("hex").
192.168.1.4 is the printer (HP Envy).

[Timothy Rice]

G'day Jafaruddin,

> Those packets were generated by other devices on your network that uses
> IPv6.
> Without looking further, my guess it is probably MDNS.

This sounds consistent with what I've seen so far.

> For your SSH connection, your server might be configured to listen on ::
> (check your /etc/ssh/sshd_config and remove Listen :: line) and make sure
> AddressFamily is set to inet and not default.

Thanks. The Listen and AddressFamily lines were both commented. I've
uncommented AddressFamily and set it to inet.

> *Now maybe I can go back lurking on the list :P

Thanks for the tips :-)

[hannah commodore]

Sorry for the top post.

It's most definitely MDNS traffic (aka ZeroConf, Bonjour, Rendezvous, whatever)
The pcap files don't actually show it as the hopopt protocol. It's just standard

Ethernet multicast->IPv4 multicast->UDP port 5353

Maybe perhaps the iptables rule is matching "hoptopt" traffic incorrectly,
and it's actually a red herring.

You can use a tool like mdns-scan to query the MDNS resolvers:
http://0pointer.de/lennart/projects/mdns-scan/README.txt

hannah

> <hopopt.log><nmap.log><tcpdump.cap><tshark.cap>

[Timothy Rice]

> You can use a tool like mdns-scan to query the MDNS resolvers:
> http://0pointer.de/lennart/projects/mdns-scan/README.txt

Cool, I will take a look.

Thanks for your help :-)


~ Tim