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

Port 444 SSL Extender

Jump to solution

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!

 

2 Solutions

Accepted Solutions
the_rock
Champion
Champion

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.

View solution in original post

HeikoAnkenbrand
Champion
Champion

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.

View solution in original post

29 Replies
the_rock
Champion
Champion

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

Andy

G_W_Albrecht
Legend
Legend

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...

CCSE CCTE SMB Specialist
HeikoAnkenbrand
Champion
Champion

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
Collaborator

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.

 

0 Kudos
the_rock
Champion
Champion

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

Tony_Graham
Collaborator

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

0 Kudos
K_montalvo
Advisor

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
Collaborator

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.

0 Kudos
Chris_Atkinson
Employee
Employee

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

 

 

Tony_Graham
Collaborator

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.

0 Kudos
the_rock
Champion
Champion

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
Collaborator

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.

0 Kudos
Wolfgang
Leader
Leader
Tony_Graham
Collaborator

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.

0 Kudos
HeikoAnkenbrand
Champion
Champion

Do you  defined a static NAT rule for port 444?

Tony_Graham
Collaborator

No I have never used 444 for anything.

0 Kudos
G_W_Albrecht
Legend
Legend

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

CCSE CCTE SMB Specialist
0 Kudos
Tony_Graham
Collaborator

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.

0 Kudos
Tony_Graham
Collaborator

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.

0 Kudos
the_rock
Champion
Champion

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.

View solution in original post

Tony_Graham
Collaborator

"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.

 

0 Kudos
the_rock
Champion
Champion

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
Collaborator

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

0 Kudos
the_rock
Champion
Champion

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

Tony_Graham
Collaborator

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>.

0 Kudos
the_rock
Champion
Champion

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

HeikoAnkenbrand
Champion
Champion

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.

View solution in original post

HeikoAnkenbrand
Champion
Champion

I would also wait for the statement of the TAC.

0 Kudos
Tony_Graham
Collaborator

Oh I'm definitely going to talk to them about it.