Secure the boot loader program (e.g. GRUB)

[Rahul_Patil]

Can we make changes in grub.conf file of R80.40 management with below parameter. Its is hardening point and we need to close 

Secure the boot loader program (GRUB) with
configure /etc/grub/grub.conf with below mentioned parameters.
 Password
 timeout=03
 immutable
 audit=1

[_Val_]

First question, why?

[Rahul_Patil]

We are working in bank. This is hardening points as per bank policy for linux customize OS. I want to know can we make change as per point or not. If cant make changes so required details justification. I have raise ticket with TAC the any help on new requirement.

[_Val_]

GAIA is already hardened and is compliant with several industry regulations, so I would appreciate an actual solid reason here, not just because someone asked you to do that. 

Please explain what exactly you are trying to harden. Please provide a technical explanation for each of the parameter. Why in GRUB? Why those elements only and not others? Mind, GAIA is linux based, but not exactly Linux.

[genisis__]

Surely the point here is this is an appliance not just an open standard OS, therefore the correct process would be to raise a TAC case and provide them with the PEN tester information (if that is what has actually triggered this).

At this point Checkpoint could provided a statement or further action, if its a statement then this should be recorded in the audit report as an exception to the policy based on the vendors feedback.

[_Val_]

@genisis__ I am not sure if your comment is intended to me or to the topic-starter. I do agree that the proper channel is TAC, but since the question, with a very sparse information, is asked in the community, I personally am very curious about the actual justification to this request. 

That said, I do not believe any PEN test results would require changes in GRAB in the first place. I suspect there is a big chunk of information missing, hence my request to know more. 

[genisis__]

sorry Val, yes it was intended for the topic-starter.

[Tobias_Moritz]

I think the main point here is, that there are often some requirements to reduce the attack surface of a gateway. Based on what the topic-starter wrote, obviously even to reduce the attack surface when access to local console is already acquired (by physical access or breaking into LOM).
Something like: Access to local console should not allow to bypass access control mechanism e.g. by using GRUB shell to boot into single user mode (boots directly to root shell without authentication).

When you have a blackbox-like gateway from a vendor, you can only verify the verbal requirements against the actual behavior of the box or ask the vendor. If it does not comply and you cannot change it, you have to ask the vendor.

Because Check Point has some more whitebox-like approach with its gateways, which means you know that it is based on RHEL 7 these days and you even get a root shell without some special TAC script, you can check the implementation of some features yourself and even fix / change it. To ask vendor before doing so, is often a good idea when you want a supported setup.

I think this is was the topic-starter wanted to do here. But let's see, what he says.