Close Port Cisco PIX 506E

Answered Question
Jun 9th, 2010

                         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?

I have this problem too.
0 votes
Correct Answer by Federico Coto F... about 6 years 5 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 5 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 5 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 5 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 5 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 5 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 5 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 5 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

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

                          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

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

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

                         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

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

                    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

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

                         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

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

Federico.

Jon Marshall Wed, 06/09/2010 - 10:30

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

                       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

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

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

                                    Thanks, this is really good information.

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

                       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