No authentication for port 18231 Policy Server Login (old)

[Jason_Dance]

Hello fellow community members!

Our security vulnerability scan has flagged that there is no authentication algorithm / ciphers for connections to port 18231 on our gateways (which according to the awesome diagram from Heiko Ankenbrand is "Policy Server Login (old)"). 

As we're using E80.xx Endpoint protect against a separate Policy server, I'm guessing we don't use this port any more (perhaps it was for the older R75 VPN client??).

Does anyone know of a way to secure this port, either by blocking it, or by making it offer secure SSL ciphers??

Regards,

Jason

[PhoneBoy]

Vulnerability scan shows port 18231 open under LISTEN mode when using TLS1.0 and TLS1.1 

[HeikoAnkenbrand]

Yes, with a SYN scan you see the port as open. 

If you check the TLS certificates, you see an TLS handshake.

Afterwards the Check Point communication follow.

Regards

Heiko

[Jason_Dance]

Thanks Dameon Welch-Abernathy‌.

Do you know if the E80.xx client will have any issues with setting this to TLS1.2?

[PhoneBoy]

Possible some older VPN clients might.

[Jason_Dance]

Interesting.  I applied the first two options in SK132712 to my R77.30 gateways, and the nmap scan has not shown any improvement.

PORT      STATE SERVICE         VERSION

18231/tcp open  ssl/fw1-pslogon Check Point FireWall-1 Policy Server logon

| ssl-enum-ciphers:

|   TLSv1.0:

|     ciphers:

|       TLS_DH_anon_WITH_3DES_EDE_CBC_SHA - F

|       TLS_DH_anon_WITH_AES_128_CBC_SHA - F

|       TLS_DH_anon_WITH_AES_256_CBC_SHA - F

|     compressors:

|       NULL

|     cipher preference: client

|_  least strength: F

[Antonis_Hassiot]

Any update here? We also performed the actions mentioned here: 

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

for port 18231, but the port still shows as listening. 

The following line was already commented out as follows:

 /*#define ENABLE_FW1_PSLOGON_NG*/

[MaxGutberletRM]

Just tried the same on 80.40 but without any apparent success either. Despite /*#define ENABLE_FWD_TOPO*/ and /*#define ENABLE_FW1_PSLOGON_NG*/ - validated on the MGR and on the two cluster members - the FW still listens on 18231 and fails basic PCI scan using Qualys.
 

[_Val_]

Did you reboot or ran cpstop;cpstart after the modifying the files?

[Antonis_Hassiot]

We found that the port was disabled only after unticking Policy Server box and leaving it unticked. We didn't actually need Policy Server enabled. Otherwise the port would show as listening in netstat.  

[_Val_]

Strangely enough, that too is mentioned in the sk132712 you referenced above yourself. 

Anyway, I am glad you have found the solution.

[_Val_]

Also, read by the SK, you need to run additional modifications through SmartConsole

[MaxGutberletRM]

Already did that obviously - multiple times.

But we found the issue: we had a old EXPLICIT policy rule active that allowed 18231 to connect to the FW. So the implicit rules were disabled but an explicit rule still existed.

In addition to that, the statemet in the SK "You can disable the daemon completely by editing the implied_rules.def, and removing/commenting the relevant lines:" is incorrect - all you remove is the _access_ to the daemon but the daemon is still started which you can easily ceck by running the netsat on the GW which still shows the daemon listening. 

But at least the PCI scan now is ok with the FW