Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Jason_Dance
Collaborator

No authentication for port 18231 Policy Server Login (old)

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

12 Replies
PhoneBoy
Admin
Admin

HeikoAnkenbrand
Champion Champion
Champion

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

➜ CCSM Elite, CCME, CCTE
Jason_Dance
Collaborator

Thanks Dameon Welch-Abernathy‌.

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

0 Kudos
PhoneBoy
Admin
Admin

Possible some older VPN clients might.

0 Kudos
Jason_Dance
Collaborator

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

0 Kudos
Antonis_Hassiot
Contributor

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
Explorer

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.
 

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Antonis_Hassiot
Contributor

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.  

0 Kudos
_Val_
Admin
Admin

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

Screenshot 2021-08-23 at 10.09.12.png

Anyway, I am glad you have found the solution.

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
MaxGutberletRM
Explorer

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 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events