Recently as part of our PA-3200 deployment been going through the joys of implementing NIST SP 800-70 configuration controls which in this case means the DoD STIG's (specifically Firewall and IDS STIG, v8 r17) and running into a problem which I noticed during my demo but didn't think much about it until now is a distinct lack of vulnerability rule documentation where is gets way down in the weeds. A great example is ipv6-opts which block "IPv6 options" but which options? all of them? etc. Anyways part of the config requirements is certain check box items must be met and the "NG" feature is irrelevant in this case .. not many but a couple so I'm hoping somebody can point me where to implement as opposed to "not supported". Specific questions are (and some of this will be "how do I meet this compliance language"):
PREFACE: Yes I have reviewed all the "IPv6" vulns and they simply aren't very verbose (or even named well), for example "ipv6" is really 6-to-4. IPv6-frag might do what I need but I have no idea because "Fragment Header for IPv6" doesn't mean anything specific.
1) Drop Undefined IPv6 Header Extensions/Protocol Values (May be an intrinsic FW feature.) - Undefined IPv6 header extensions means that the Next Header type is not registered with Internet Assigned Numbers Authority (IANA). The header extension is the same as the protocol value, and should be dropped. Drop all undefined extension headers/protocol values.
2) Drop at least one fragment of any inbound fragmented packet for which the complete data set for filtering to include protocol/port values cannot be determined.(May be an intrinsic FW feature) - A FW must be able to properly enforce its filtering policy upon fragmented packets. This requires that the FW be able to find the complete set of header data including extension headers and the upper layer protocol/port values. It also requires that the packet not be susceptible to fragment overlap attacks. Fragment overlaps are a more serious problem in IPv6 than in IPv4 because the presence of extension headers can push the upper layer protocol/port information outward (toward packet boundaries) making it much harder to protect. How a FW achieves these requirements is not important as long as both aspects are met. The wording “drop at least one fragment” used in the actions below is a statement of the bare minimum action to secure a packet, and is chosen to allow FW venders flexibility in achieving it.
3) Drop all inbound IPv6 packets containing more than one Fragmentation Header within an IP header chain. (May be an intrinsic FW feature) - Nested fragmentation is an unnecessary and unwanted IPv6 condition that is not forbidden by the specifications. It occurs when an IP header chain contains more than one Fragmentation Header implying that a fragment has been fragmented. In the specification, the phrase “IP header chain” rather than “packet” is used, because a tunneled packet has more than one IP header chain and each chain can have a Fragment Header (this case is not nested fragmentation). Nested fragmentation is a new phenomenon with IPv6. It is not possible in IPv4, because the fragmentation fields are part of the main header and are modified in the event of a secondary fragmentation event. Nested fragmentation in IPv6 should be dropped by FWs since internal nodes that process the fragmentation may or may not be equipped to handle this unexpected case. These nodes may crash or behave in some unpredictable manner.
4) Validate IPv6 router advertisement suppression is enabled on all external-facing interfaces.
5) Firewall drops all inbound and/or outbound IPv6 packets containing a hop-by-hop option of option type 0xC2. [This go back to my ipv6-opts issue, I don't want to drop all options, just 0xC2]
PS: Yes I know I can kill all of this with default deny/deny all/any at the end but looking for specific rules for compliance reasons.
Its really detailed question, and I will help you upto possible extent.
1) Yes, Firewall should drop all the packets with unknown header.
2) Firewall captures all the fragments, merge them to verify its authenticity. If its authentic then it forwards fragments. If firewall find any fragment invalid then it drops them.
3) Not sure, need more time for research
4) Not sure, need more time for research
5) Can be blocked by zone protection, let me know if you need help.
I am still doing research, will get back with more information.
Good deal on #1 and #2 .. I'm going to assume they are " intrinsic" implementations and don't need any further configuration on my part. #5 was more a comment, I know how to do that one :smileyhappy: . A quick question on #1 and #2 though, if I had a rule saying "allow any any all all" would it still kill them given it's intrinsic, i.e. even if I wanted bad packets I couldn't get them?
Thanks on research #3 and #4.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!