Help us enhance your Sophos Community experience. Share your thoughts in our Sophos Community survey.

Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 2 answers
  • Subscribers 43 subscribers
  • Views 29426 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How do I close UDP Port 500?

Bill Roland

I am failing a PCI scan because UDP Port 500 is showing as open|filtered on Nmap scans.  I see that this is the ISAKMP service.  However I do not have any IPsec connections defined, I have Cisco VPN disabled, and I even went so far as to create a Deny/Drop firewall rule for everything incoming hitting port 500, put it at the top, and that still doesn't work.

How do I find out what service on the XG has this port open and then close it?



This thread was automatically locked due to age.
Parents
  • 0

    One thing to attempt is to stop the related daemon on the XG which is enabled by default.

    From the advanced shell option on the XG run the following:

    # service strongswan:stop -ds nosync

     

  • 0 in reply to FHF

    Well that changed the status to "closed" on the port scan, so its definitely strongswan that is listening.  Support tried to tell me it was RED but that was counter to all the published KB's.  

    Is there a way I can create an ACL or something to filter it?  I am assuming it is going to start up everytime I reboot the appliance?  I have another XG on which I have never activated IPSec or Cisco VPN and it correctly shows as "filtered" rather than "closed."   

  • +1 in reply to Bill Roland

    Alright so replying to my own thread, I think I have figured out a workaround.  I remembered this being a problem in the past with RED and somebody suggesting the workaround of creating a business rule and essentially publishing the port to a null IP address.  So I did that for UDP 500, and voila, it's now coming back as "filtered" since XG is now forwarding this traffic to essentially a black hole.  We'll see if its confirmed by the next PCI scan that will occur in the next 24 hours but my own port scan now show it as filtered, as it should be.

    I maintain this should not be necessary.  I have another XG where this behavior doesn't happen, I guess because I never activated IPSec on it and so whatever internal ACL that gets created to allow IKE traffic on UDP 500 for strongswan to listen for never happened.  Seems like a bug to me.

Reply
  • +1 in reply to Bill Roland

    Alright so replying to my own thread, I think I have figured out a workaround.  I remembered this being a problem in the past with RED and somebody suggesting the workaround of creating a business rule and essentially publishing the port to a null IP address.  So I did that for UDP 500, and voila, it's now coming back as "filtered" since XG is now forwarding this traffic to essentially a black hole.  We'll see if its confirmed by the next PCI scan that will occur in the next 24 hours but my own port scan now show it as filtered, as it should be.

    I maintain this should not be necessary.  I have another XG where this behavior doesn't happen, I guess because I never activated IPSec on it and so whatever internal ACL that gets created to allow IKE traffic on UDP 500 for strongswan to listen for never happened.  Seems like a bug to me.

Children
No Data
Unfiltered HTML