Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Ben_Hartmann
Explorer

let ip option field "security" pass the gateway and do filtering on that field

Hi Community,

I am struggling with a unusual customer request. They are using the IP option "Security [130]" (RFC1108) in self-written software to tag special tcp-packets in the header. Now they want these packets to pass through the r80.20-gateway and implement filtering based on this IP option field.

Based on sk62082 (How to allow TCP/UDP packets with IP options through Check Point Security Gateway) it should be possible to let packets with these options passing the gateway.

Before implementing sk62082:
@;6765544;[SIM-206293920];handle_packet_do: stripping IP options failed, conn: <172.30.0.2,1024,10.125.231.130,10000,6>;

Changes based on sk62082 in $FWDIR/lib/table.def:

2019-04-23 08_19_37-admin@gw-2582f3_~.png

After implementing sk62082 (changed table.def & policy install):
@;6768953;[fw4_0];fw_log_drop_ex: Packet proto=6 172.30.0.2:1024 -> 10.125.231.130:10000 dropped by fw_ipopt_restore Reason: fw_ipopt_restore failed;

So even the simple forwarding of this security-field is failing on r80.20 (contrary to the sk). Any idea why the ipopt_restore is failing?

The packet looks like this:2019-04-23 11_56_51-Kali-Linux - Konsole – VMware ESXi.png

And wireshark (on sending client) is successfully detection the IP option "Security":

2019-04-23 11_57_40-Kali-Linux - Konsole – VMware ESXi.png

For the 2nd part (the filtering) I am thinking about three possible options:

- 1.: special protocol type (maybe INSPECT code)
- 2.: custom application (based on sk103051)
- 3.: IPS signature

Has anyone of you worked with IP options on CheckPoint before? And is it even possible to filter based on a IP option field?

Based on the notes at the end of sk62082 (

"SecurePlatform OS / Gaia OS kernel does not strip IP options. Therefore, the packet arrives to Check Point kernel with IP options, and is dropped."

) I would think that the IP options are not stripped and therefor should be available for detection/filtering. But the following still shows a chain called "ipopt_strip":
2019-04-23 12_08_58-ipopt_strip - Google-Suche.png

Any help is kindly appreciated!

 

Kind regards,
Ben Hartmann
Security Consultant
Axians IT Security
Germany

0 Kudos
2 Replies
PhoneBoy
Admin
Admin

When you say “implement filtering” what do you mean specifically?
Permit/deny packets based on the presence of this IP Option in the packet?
Note that by default we drop packets with IP Options set.
We can allow packets with specific IP Options set to be inspected as per the normal policy.

The fact we can’t restore IP Options to the packet suggests a bug that will need to be further investigation by the TAC.
0 Kudos
Ben_Hartmann
Explorer

Yes, I want to permit/deny based on the presence of this IP Option.

Regarding the restore of IP Option: I will open a ticket with TAC.

 

Kind regards,
Ben

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events