Please help me identify IPV6 packet

Hello, I've recently set up a laptop with Vista Home Premium Edition, Look'n'Stop firewall (2.06p3), and phant0m's rule set.

Shortly after installing the phant0m rules, I began getting a few IPV6 hits in the log. I was able to track down most of them and set up appropriate rules, however there is one recurring packet that I have no clue about. (Please see attached image.) This packet attempts to send 9 times while the computer is connecting to my local network before quitting, and the contents appear to be exactly the same each time.

Blocking it doesn't appear to create any problems, but I would like to identify what it is and why it wants to send before creating a rule to block (or allow) and ignore it.

 

Hi jnshk

It's the IPv6 Hop-by-Hop Option (HOPOPT)...

RFC 2460.

You may create a raw rule to allow these IPV6 paquets.

 

Thank you for the response!

I am relatively familiar with how to create a standard rule, but the raw rules are currently above my head. Is there some guide on how to properly create a raw rule, or could you walk me through the process?



Also, slightly off-topic: When creating standard rules, is there a way to create a single rule that matches a list of non-consecutive ports? I know that you can make a rule match a consecutive range of ports (i.e. - 80-443), or you can make it match two ports (i.e. - 80 and 443), but can you make it match a list of ports (i.e. - 21, 80, 443, 8080)?

Thanks in advance for any help you can give.

 

Hi jnshk,

You cannot create a single rule which is contained more than two non-consecutive ports but you can create a single rule which is contained a list of non-consecutive ports and consecutive range of ports。

 

Well, I looked at the RFC 2460 information as well as phant0m's description of what each value in a raw rule represents, but I still don't seem to understand the concept properly.

I tried creating a raw rule with the following properties:
- Allowed
- Logged
- Field: 0
- Direction: Outgoing
- Field Offeset Type: IP
- Inbound: 18
- Outbound: 18
- IP Type: IPV6
- Field Criteria: EQUAL_VALUE1
- Value1: 0
- Field Size: 1 byte
- Value Display Mode: Decimal
- Operator with the next field: AND
(next field left at default settings)

You're probably already chuckling at my naivety... Obviously, I don't quite understand the structure of a packet or a raw rule yet.

As best as I can tell, the above rule did little more than open a gaping hole in my firewall, because it appears to have allowed and matched a handful of UDP connections that normally would have been silently allowed or denied by other rules.

I looked at some of the various raw rules in phant0m's set, and they all seem to start with field 0 being set as ETH, inbound offset of 12, outbound offset of 12, and field value set as equal to 2048. I'm guessing this is significant, but I don't understand why just yet?

Could someone construct a generic rule to safely allow just these "hop-by-hop" packets, and perhaps explain what each field in the rule actually does?

 

Hi jnshk,

Yes, the first field to be mentioned is usually the Ethernet Type. And if you don't indicate it, some other packets could be wrongly detected (as you observed).
2048/0x800 is IP, and for the rule we are working on, it should be IPV6, so 0x86DD.
This IPV6 indication is different from the checkbox you have in the rule edition dialog box. Here it refers directly to the packet, and in the rule edition dialog box it indicates if the current field should apply for IP, IPV6 or both (and this is important only when we are working on rules compatible with both protocols, and for TCP/UDP/ICMP field type information, which is not the case here).

To create a raw rule, the best way is to start with a standard rule, and after you edit it as a raw rule to modify/add fields you can't edit with the standard edition.

Here is the rule I created that way:
http://looknstop.soft4ever.com/Rules/En/IPV6-Protocol 0.rie

First I created a standard rule and I've specified it was IPV6 and Protocol 47 (just to put something I will retrieve easily).
Then I edited the rule, I've checked the first field was verifying 0x86DD, and in the second field I've retrived the value 47, and I changed it to 0, and saved the rule.

Note: there is currently a limitation about the IPV6 address format in the raw rule edition plugin. The maximum data size for a field is 6 and 16 is required size for IPV6 address. So, unfortunately, it is not possible to specify ff02::16 as the destination address (and also it doesn't work if you specify it first with the standard edition and edit the rule later with the raw rule edition plugin).

Regards,

Frederic

 

Frederic, thank you for the response!

I still don't completely understand how the raw rules work, but I've at least got a baseline idea and you've given me some methods that I can use to play around with rules and learn a bit more on my own.

Are there any plans to expand raw rule support to allow for data sizes larger than 6 bytes in the near future?

 

Yes, this will be supported, but I don't know when precisely. The good thing is the problem is only on the plugin side, so it doesn't require a new version of the main Look 'n' Stop application.

Frederic