Port 444 SSL Extender

[Tony_Graham]

All,

I just updated from R80.40 to R81 so I did a follow up external port scan (GRC shields Up) to see if everything looked as

expected. It picked up on port 444 stating it is 'closed'. All other ports are 'stealth'.

I remember in the past this happening and I was able to disable a service and get it back to 'stealth'.

The current 'closed' port has to do with SSL Extender VPN. We do not use VPN in any capacity and therefore

it is not used. If I check the gateway settings the only blades I have active are Firewall and Anti-SPAM & Email Security.

Any ideas on what clicky box I need to find to get back to full stealth?

Thanks!

[the_rock]

Thats a bit odd, if you dont even have the blade enabled. Hm...let me look into that for you.

Andy

[Tony_Graham]

I thought I would let everyone know this issue is back. 444 is in reject mode. However, editing implied_rules.def is not stopping it now either. I also have port 80 and 443 that have appeared as open. No idea why. Has to have happened during and update. I have a ticket into TAC.

[G_W_Albrecht]

Port 443 would have been used by SSL VPN and Visitor Mode as well as by IA blades Browser Auth  and TS Agent - but port 444 is not used by CP at all...

[HeikoAnkenbrand]

Hi @Tony_Graham 

Check which process is running on the port:
netstat -tulpn | grep ":444"

Now the process and the process ID should be output at the last position.
Depending on the process, you decide what needs to be disabled.

Furthermore, this should not be a problem if there is a stealth rule on the firewall that prevents access to port 444.

[Tony_Graham]

netstat -tulpn | grep ":444"

returns nothing of value.

There is a stealth rule in place so I assume if it something in Global that is overriding it.

[the_rock]

Guys are definitely right, port 444 would not even be used by the firewall. 

[Tony_Graham]

As it is a Sandblast appliance there is no other product installed on it.

[K_montalvo]

Hello Tony,

You sure you are scanning the correct IP Address? Port 444 could just be an snpp protocol or something else. As other comments on this post you can verify in the FW CLI for netstat or do a pgrep 444 or ps aux | grep 444 and confirm if is running any PID, if you can to kill process use kill and (PID)

Thanks,

[Tony_Graham]

GRC does an autodetect to determine the originating IP for the scan which is my external gateway.

I have confirmed this. There are no running PIDs on that port that I can find.

[Chris_Atkinson]

Have you performed visitor mode customizations historically like those referenced in sk111974?

[Tony_Graham]

You may have jogged a spider web out of my mind. In the past when this port popped up it had something to do with an external CP control connection in Global Properties. I don't recall which one needed to be unticked to stealth 444 but one of them does. I think it's an error that 444 isn't used. It might not be used but something exposes it and there is a clicky bit to turn it back off.

[the_rock]

What @Chris_Atkinson said makes sense. That came to my mind as well...check implied_rules.def on mgmt server, as well as under gateway object -> vpn clients -> remote access -> support visitor mode...what port is listed there?

Andy

[Tony_Graham]

Well that's the trick. I cannot check gateway object --> vpn clients because there is not a menu for that.

R81. Inside implied_rules.def on mgmt server I see a line under

#define multiportal_real_ports_block_in

(dport in multiportal_real_ports) or (dport = 8880) or (dport =444) or (dport = 8802), IMPLIED_LOG, reject;

So something does monkey with 444. I think I'll contact TAC about it so they know the port is getting set as enabled but closed for some reason.

**UPDATE** The stealth rule does not block the 444 port.

[Wolfgang]

Have a look Remote Access with Visitor Mode set to use TCP port 444 no longer works after upgrading to R77.30 

something was changed from default…

[Tony_Graham]

Yes. I have been through that SK. I do not wish to enable remote access.

I could change (dport in multiportal_real_ports) or (dport = 8880) or (dport =444) or (dport = 8802), IMPLIED_LOG, reject; 

to 'drop' from 'reject' but not sure what consequences/side-effects that would have for the other ports 8880 or 8802.

[HeikoAnkenbrand]

Do you  defined a static NAT rule for port 444?

[Tony_Graham]

No I have never used 444 for anything.

[G_W_Albrecht]

What about just removing the or (dport =444) ? You could test that...

[Tony_Graham]

I could but until I speak with TAC as to why it may have been there in the first place, I am opting to set it as drop for now.

It looks to me like it was a part of 77.30 (sk111974), but why it seems to be following me during upgrades I don't know. It's odd nobody else has seen this though.

[Tony_Graham]

Also note I have gone through the Smart Console Policy editor and viewed the Implied Rules.

There are no references to 444, 8802 or 8880 in the implied rules. Not sure why they are in implied_rules.def.

I also have no service objects for those ports in my policy editor so maybe it is cruft from an upgrade that can be removed. Beyond my pay grade at this point. Have to wait and see what TAC says.

[the_rock · Accepted solution]

I would hate to advise anyone to change that file (implied_rules.def), BUT...one thing you could try is make a copy and modify that line with port 444, verify, apply policy and re-run the test again.

[Tony_Graham]

"I would hate to advise anyone to change that file (implied_rules.def), BUT..", you just did LOL.

I was confident enough to give it a whirl as I was leaning that way myself.

By the way it worked. 444 is now stealthed again. I changed the line from 'reject' to 'drop'.

I don't know why I remember having to do this awhile back for the same reason. According to sk92281 this file

gets overwritten during upgrades so if I had made the change in the past it would have gotten zapped during my move to R81 last Friday. Still don't know why these entries in implied_rules.def are appearing to begin with.

[the_rock]

Well, I did NOT advise you to change it...I said you COULD...lol. After all, its your firewall. I can only suggest things mate : - )

[Tony_Graham]

LOL. Sure, I'm just kidding with you.

[the_rock]

Well, its good right? If it worked, no harm, you have original file anyway ; - )

[Tony_Graham]

Yes on both accounts. The biggest fear I always have is locking myself out of the device. I recall having to hook up with a serial connection once....<shudder>.

[the_rock]

Good job! Well, as far as losing access, thats why you always carry console cable...better safe than sorry ; )

[HeikoAnkenbrand · Accepted solution]

Yes, that works.

But I would not change anything in Check Point's inspect code without confirming that with the TAC.

PS:
You should be aware that this will be overwritten with Check Point's default inspect code during the next upgrade.

[HeikoAnkenbrand]

I would also wait for the statement of the TAC.