Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Akira_Yagi
Participant
Jump to solution

How to disable Gaia access from the Internet

Hello,

I have a typical policy that allows access to Gaia (https) from some internal machines, followed by a stealth rule that blocks all the other accesses (any-[sms, clusterxl and nodes]-drop).

Despite this, if I try to open a browser from an external machine, pointing to one of the public IPs (https://publicIP) of the cluster, I'm asked to accept the certificate.

I can't load the user/password page, but I need to avoid to even to show that something is listening.

The customer told me that in the past someone executed a command to block this access, but I was expecting that the policy was enough.

What is this command? I don't want to disable the Gaia Portal, just from the Internet.

Or there is a configuration in the Global Policy that I missed?

1 Solution

Accepted Solutions
HeikoAnkenbrand
Champion Champion
Champion

Add an static NAT rule and NAT it to null IP:-)

src: internet

dst: portal ip

port: portal port

NAT src: internet

NAT dst: static NAT to null IP for example 127.0.0.99

NAT port: portal port

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips

View solution in original post

17 Replies
PhoneBoy
Admin
Admin
Akira_Yagi
Participant

Thank you for the answer but I'm not sure this SK is related to my problem.

What happens is that if I try to load the cluster public IP from, for example, my smartphone by using 4G data connection (just to say that I'm completely outside), I'm asked to accept the certificate for the https://[public_ip].

If I go on, I can't load anything since I have a "any-[nodes/cluster]-drop" stealth rule.

But I need to avoid that Gaia WebUI responds at all from outside, I just want that if someone put my cluster's public IP in their browser, they have an error page.

Is not about seeing unwanted logs, people can actually understand that something is behind that IP..

PhoneBoy
Admin
Admin

It is exactly related to the problem.

To explain in a little more detail, there is something called multiportal that "multiplexes" access to the various web portals (Gaia, Mobile Access Blade, API, UserCheck, etc).

This allows discrete portals running different webservers to use the same IP/port combination with the difference being what URI is accessed.

A kernel-level process actually does the redirection, which means it's "always listening" on ports 80/443.

The only way to know what URI is accessed is to terminate the TCP connection.

Based on the configuration/security policy and the URI accessed, the connection will either be allowed/dropped.

The SK tells you how to disable this.

The downside is you can't leverage Multiportal anymore and you must set each individual web portal to use a different IP/port combination.

Kristof_Vermael
Contributor

It looks like the SK is only for the HTTP redirection, not the HTTPS issue :

In order to stop the Security Gateway from responding to all TCP connections on port 80 (e.g., for PCI audits), edit the relevant 'implied_rules' file (refer to sk92281 for locations) and install policy

 

I have tried this solution :

-> set the gaia portal to 4434

-> set allowed hosts in Gaia

-> //#define ENABLE_PORTAL_HTTP_REDIRECT in implied rules

 

HTTP is now indeed not redirecting to HTTPS, and my connction to 4434 is working for my allowed hosts, but HTTPS is still poping up the certificate and so the gateway is still exposed on the internet.

 

 

HeikoAnkenbrand
Champion Champion
Champion

Add an static NAT rule and NAT it to null IP:-)

src: internet

dst: portal ip

port: portal port

NAT src: internet

NAT dst: static NAT to null IP for example 127.0.0.99

NAT port: portal port

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
JozkoMrkvicka
Authority
Authority

We have disabled WebUI and the problem is solved 🙂 What is the point to have WebUI in these days? Just one-time access for First Time Wizard...

Kind regards,
Jozko Mrkvicka
S_E_
Advisor

hi,

old thread, I know.

However, did you just disabled the start of httpd2 or is there a better solution?

Regards

0 Kudos
JozkoMrkvicka
Authority
Authority

clish command "set web daemon-enable off".

If you are using management, disabling webUI on management will cause API stopped working.

Kind regards,
Jozko Mrkvicka
Kristof_Vermael
Contributor

Hello Heiko,

 

I was in the assumption NAT rules do not work for implied rules, but i have tested your solution and it seems to be working just fine !

 

Thank you for this, this is a bit dirty solution to solve but I can live with this 🙂

 

0 Kudos
peter_schumache
Collaborator

Additional question to this:

How do you specify the source object "Internet" in R77.x, in R80.x

0 Kudos
Kristof_Vermael
Contributor

In the access policy, I'm negating a group objects containing all internal en VPN subnets.

In the NAT policy, i'm using a NO NAT rule this group as source and as destination. All Internet nat rules are below this rule, all internet natting are above this rule.

Kristof_Vermael
Contributor
0 Kudos
Danny
Champion Champion
Champion

Properly defining GAiA's hosts access is very important. Therefore I added a check to our ccc script that will show in bold red letters when host access is set to Any.

Martijn
Advisor
Advisor

Hi all,

The NAT configuration is the solution, but not a very nice one.

We have a customer with the same issue. He created certificates for the Gaia portal, but when someone access the appliances from the internet over HTTPS, the certificate is shown including information from the internal network (Root CA name etc.) This is not what the customer wants.

Does anyone know if a better solution has become available?

Regards,

Martijn

0 Kudos
Martijn
Advisor
Advisor

Hi,

From support I got an better solution that does not involve creating strange NAT configuration. Just edit the implied_rules.def file in $FWDIR/lib

From:

 

// The following is for portals: http and https (80 and 443)

#if defined (ENABLE_PORTAL_HTTP_REDIRECT)

#define enable_portal_http(gw, ip_list, portals_allow_ext_ifc) \

    ((dport = 80) or (dport = 443)),                                \

    ((portals_allow_ext_ifc = 0, ifaddr in internal_interface_list \

    ) or (portals_allow_ext_ifc = 1)),                               \

    <dst> in ip_list, inbound, tcp,        \

  start_rule_code(MAKE_RULENUM(0,0x38)),              \

    set r_entry CHANGE_TYPE(r_entry,CONN_NOENC),                  \

    set r_mhandler &tcpt_dummy_handler,                                          \

    IMPLIED_RECORD_CONN(MAKE_RULENUM(0,0x38)), \

    IMPLIED_LOG, accept;

#else

#define enable_portal_http(gw, ip_list, portals_allow_ext_ifc)

#endif

 

TO:

 

// The following is for portals: http and https (80 and 443)

#if defined (ENABLE_PORTAL_HTTP_REDIRECT)

#define enable_portal_http(gw, ip_list, portals_allow_ext_ifc) \

 /*   ((dport = 80) or (dport = 443)),                                \

    ((portals_allow_ext_ifc = 0, ifaddr in internal_interface_list \

    ) or (portals_allow_ext_ifc = 1)),                               \

    <dst> in ip_list, inbound, tcp,        \

  start_rule_code(MAKE_RULENUM(0,0x38)),              \

    set r_entry CHANGE_TYPE(r_entry,CONN_NOENC),                  \

    set r_mhandler &tcpt_dummy_handler,                                          \

    IMPLIED_RECORD_CONN(MAKE_RULENUM(0,0x38)), \

    IMPLIED_LOG, accept; */

#else

#define enable_portal_http(gw, ip_list, portals_allow_ext_ifc)

#endif

After this, you need to create explicit rule to allow the required traffic, but the certificate is not shown anymore.

In my lab and at the customers gateway, this was to solution.

Hope it helps.

Regards,

Martijn

Mike_Jensen
Advisor

How do I access the above to make the needed change?  A file using vi editor?  I believe I am having the exact same problem with the ICA certificate showing on the public internet via https.

0 Kudos
Danny
Champion Champion
Champion

Yes, in expert mode run: $FWDIR/lib/implied_rules.def

I suggest to read this article as well.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events