Close Port Cisco PIX 506E

Answered Question
Jun 9th, 2010
User Badges:

                         If I add a Deny ACL after all my permit ACL's will a deny any source to port 500  close the port on my PIX 506? I need to keep that port from showing up in a scan to comply with security standards? Also this should not cause a problem with any other traffic right?

Correct Answer by Federico Coto F... about 6 years 11 months ago

On the ASA you can prevent the ASA from responding to UDP 500 by creating an ACL and applying it to the outside with the keyword ''control

-plane''

This will allow the ACL to check packets intended to the ASA as well as packets going through.


However, not possible on PIXes.


Federico.

Correct Answer by Jon Marshall about 6 years 11 months ago

iketurner931 wrote:


                       Jon,


                              I was told this is a huge security issue. Is this true? What problems will having that port open cause? Also does the ASA platform have this same issue?


Not sure about the ASA because i never tested it. It's not really a huge security issue. Just because the pix will respond on udp port 500 doesn't mean you can then form an IPSEC tunnel ie. you need a lot more information than that to successfully bring up an IPSEC tunnel. That is why you should always select a good preshared key, never e-mail the key etc..


Edit - even though it is not necessarily a huge security issue it would be good if you could indeed stop the pix from responding on that port.


Jon

Correct Answer by Federico Coto F... about 6 years 11 months ago

If you're positive that all VPN traffic is being permitted by the ACL, then you can safely remove the sysopt.


Federico.

Correct Answer by Federico Coto F... about 6 years 11 months ago

If you remove the ''sysopt connection permit-ipsec'' then all VPN traffic is going to be checked by the outside ACL.


By default, when the VPN terminates on the PIX, all traffic encapsulated through the tunnel is permitted (without an ACL) because of the sysopt command above.

If you remove it, you will need to permit on the outside ACL all the VPN traffic explicity.


Federico.

Correct Answer by Kureli Sankar about 6 years 11 months ago

Like Federico says

Access-list applied on the interface is only for THROUGH the box traffic.


That does not affect "TO" the box traffic like vpn termination, telnet/ssh/asdm TO the box.


You can add this command - sysopt connection permit-ipsec


http://www.cisco.com/en/US/docs/security/pix/pix63/command/reference/s.html#wp1026942


connection permit-ipsec

Implicitly permit any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections.


-KS

Correct Answer by Federico Coto F... about 6 years 11 months ago

Yes, but assuming that ACL is applied to the outside interface (interface where the VPN tunnel terminates)....

You're denying from any source to any destination traffic UDP on destination port 500 (ISAKMP)


The IPsec VPN tunnel terminated on the PIX uses UDP port 500 (ISAKMP) to establish the tunnel.

So, the PIX should be able to listen on UDP port 500 on its outside interface.


I have no PIX here to prove it, but what I'm saying is that the ACL applies only to traffic through the PIX and not to the PIX.

This means that all traffic intended to the PIX itself is not going to be checked by the ACL (only traffic passing through).


If you have an scenario where the IPsec VPN passes through the PIX (then you will need to open UDP 500)


Federico.

Correct Answer by Panos Kampanakis about 6 years 11 months ago

That will block traffic destined to xxx on port 500.

Make sure your ACL lines above that line don't allow it because then the deny line will not be hit.


I hope it helps.


PK

Correct Answer by Federico Coto F... about 6 years 11 months ago

Hi,


Whatever you specify under an ACL on the PIX is just going to affect traffic passing through the PIX (not to the PIX itself).

So, for VPN traffic terminating on the PIX, the ACLs won't hurt.


Federico.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (8 ratings)
Loading.
Correct Answer
Federico Coto F... Wed, 06/09/2010 - 06:25
User Badges:
  • Green, 3000 points or more

Hi,


Whatever you specify under an ACL on the PIX is just going to affect traffic passing through the PIX (not to the PIX itself).

So, for VPN traffic terminating on the PIX, the ACLs won't hurt.


Federico.

Charlie Mayes Wed, 06/09/2010 - 06:38
User Badges:

                          What about this?


                                                  access-list close_port deny udp any X.X.X.X eq 500

Correct Answer
Panos Kampanakis Wed, 06/09/2010 - 06:45
User Badges:
  • Cisco Employee,

That will block traffic destined to xxx on port 500.

Make sure your ACL lines above that line don't allow it because then the deny line will not be hit.


I hope it helps.


PK

Correct Answer
Federico Coto F... Wed, 06/09/2010 - 06:46
User Badges:
  • Green, 3000 points or more

Yes, but assuming that ACL is applied to the outside interface (interface where the VPN tunnel terminates)....

You're denying from any source to any destination traffic UDP on destination port 500 (ISAKMP)


The IPsec VPN tunnel terminated on the PIX uses UDP port 500 (ISAKMP) to establish the tunnel.

So, the PIX should be able to listen on UDP port 500 on its outside interface.


I have no PIX here to prove it, but what I'm saying is that the ACL applies only to traffic through the PIX and not to the PIX.

This means that all traffic intended to the PIX itself is not going to be checked by the ACL (only traffic passing through).


If you have an scenario where the IPsec VPN passes through the PIX (then you will need to open UDP 500)


Federico.

Charlie Mayes Wed, 06/09/2010 - 07:09
User Badges:

                         What if I already have a site to site VPN tunnel up to a remote site? Will adding that ACl to close udp port 500 cause issues with that tunnel?

Correct Answer
Kureli Sankar Wed, 06/09/2010 - 06:54
User Badges:
  • Cisco Employee,

Like Federico says

Access-list applied on the interface is only for THROUGH the box traffic.


That does not affect "TO" the box traffic like vpn termination, telnet/ssh/asdm TO the box.


You can add this command - sysopt connection permit-ipsec


http://www.cisco.com/en/US/docs/security/pix/pix63/command/reference/s.html#wp1026942


connection permit-ipsec

Implicitly permit any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections.


-KS

Charlie Mayes Wed, 06/09/2010 - 07:17
User Badges:

                    If I remove this command from my firewall how will it effect my site to site VPN?   sysopt connection permit-ipsec

Correct Answer
Federico Coto F... Wed, 06/09/2010 - 07:57
User Badges:
  • Green, 3000 points or more

If you remove the ''sysopt connection permit-ipsec'' then all VPN traffic is going to be checked by the outside ACL.


By default, when the VPN terminates on the PIX, all traffic encapsulated through the tunnel is permitted (without an ACL) because of the sysopt command above.

If you remove it, you will need to permit on the outside ACL all the VPN traffic explicity.


Federico.

Charlie Mayes Wed, 06/09/2010 - 08:20
User Badges:

                         I already have an acces -list permitting the source and destination traffic on this firewall for the VPN tinnel traffic so it should be ok to remove the sysopt connection permit-ipsec command.

Correct Answer
Federico Coto F... Wed, 06/09/2010 - 08:22
User Badges:
  • Green, 3000 points or more

If you're positive that all VPN traffic is being permitted by the ACL, then you can safely remove the sysopt.


Federico.

Charlie Mayes Wed, 06/09/2010 - 08:25
User Badges:

                       Sounds Good. Thanks Federico.

Jon Marshall Wed, 06/09/2010 - 10:30
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Just to clarify because i'm a bit confused myself


Whether you turn on sysopt connection permit-ipsec or remove it will have no effect on whether or not UDP port 500 is allowed to the outside interface of the pix. And even if you add a line in your outside acl denying udp port 500 to the outside interface from memory this will have no affect either.


The pix behaves quite differently than an IOS router. As far as i know you cannot actually stop a pix from responding to UDP port 500 with or without an acl.


Jon

Charlie Mayes Wed, 06/09/2010 - 10:35
User Badges:

                       Jon,


                              I was told this is a huge security issue. Is this true? What problems will having that port open cause? Also does the ASA platform have this same issue?

Correct Answer
Jon Marshall Wed, 06/09/2010 - 10:39
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

iketurner931 wrote:


                       Jon,


                              I was told this is a huge security issue. Is this true? What problems will having that port open cause? Also does the ASA platform have this same issue?


Not sure about the ASA because i never tested it. It's not really a huge security issue. Just because the pix will respond on udp port 500 doesn't mean you can then form an IPSEC tunnel ie. you need a lot more information than that to successfully bring up an IPSEC tunnel. That is why you should always select a good preshared key, never e-mail the key etc..


Edit - even though it is not necessarily a huge security issue it would be good if you could indeed stop the pix from responding on that port.


Jon

Correct Answer
Federico Coto F... Wed, 06/09/2010 - 10:42
User Badges:
  • Green, 3000 points or more

On the ASA you can prevent the ASA from responding to UDP 500 by creating an ACL and applying it to the outside with the keyword ''control

-plane''

This will allow the ACL to check packets intended to the ASA as well as packets going through.


However, not possible on PIXes.


Federico.

Charlie Mayes Wed, 06/09/2010 - 10:48
User Badges:

                                    Thanks, this is really good information.

Charlie Mayes Wed, 06/09/2010 - 10:47
User Badges:

                       That is what I thought. Below is what they said but, we are not running a concentrator behind the firewall that will be answering any requests at all. It is just performing regular firewall functions.


                    /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}


                        In Aggressive Mode IKE, the response from the VPN concentrator includes an authentication hash based on a pre-shared key (PSK). This hash is not encrypted, so if it is captured in transit, a dictionary or brute force attack against the hash can potentially allow for the recovery of the PSK, and the exposure potentially sensitive information from VPN sessions. In rare cases where the PSK is the sole means for authentication to the VPN, attackers can use it to authenticate against the VPN and intrude the network

Actions

This Discussion