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

should i be worried about a key install to an unknown ip from the firewall?

So we had 2 vpn key installs that were successful from the same firewall to different ips (one from mongolia and one from china), should i be worried about that? because all i see in the logs are just the key installs so just 2 logs and no other logs, no exchange of information to those ips,etc. Do i have to investigate something else?

 

key1.PNG

That is how the log looks like, the other key install is also the same but with a different destination ip.

 

Thanks and Regards.

0 Kudos
Reply
3 Replies
PhoneBoy
Admin
Admin

You’ll notice it also says “No Proposal Chosen.”
Which means no key was actually installed.

This could be a configuration error on the remote end but I suppose it could also be a reconnaissance attempt by a remote party (portscan or similar).
Something to keep an eye on for sure.

0 Kudos
Reply
kb1
Collaborator

thank you

0 Kudos
Reply
Timothy_Hall
Champion
Champion

This has been brought up before at CheckMates, basically all UDP 500 traffic is allowed by the firewall and sent to the process vpnd on the gateway which is where all IKE negotiations occur.  You'll see random Internet IPs trying to start IKE negotiations with a "Key Install" log but they won't get anywhere since they are not a defined peer. 

IKEv1 Phase 1 does things in kind of a messed up order of operations by design which is not Check Point's fault.  IKEv1 Phase 1 performs the following three tasks in this order:

  • Agree on algorithms to form an SA
  • Compute a secret key with Diffie-Hellman
  • Authenticate the negotiating peers

The fact that lots of negotiation and a computationally expensive Diffie-Hellman calculation is performed before the peers even authenticate each other should raise alarm bells.  Because the peer has not been authenticated yet, it always possible they are hostile and trying to crash us with malformed or otherwise corrupt negotiations.  For that reason all IKE is handled in the vpnd process instead of the INSPECT/Firewall Worker which traditionally runs in the kernel.  If the vpnd process happens to crash, its parent process fwd simply respawns it immediately, no harm no foul.  However if IKE negotiations took place inside the kernel, a crash caused by the peer in there would cause the whole system to crash.  With the advent of USFW, it will be interesting to see if functions like this that are done for stability reasons in separate processes will end up getting integrated into the INSPECT/fwk/Firewall Worker when USFW is enabled.

IKEv2 resolves this design issue by authenticating the peers first before allowing any other operations.

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
Reply