cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2354
Views
0
Helpful
17
Replies

Close Port Cisco PIX 506E

Charlie Mayes
Level 1
Level 1

                         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?

8 Accepted Solutions

Accepted Solutions

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.

View solution in original post

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

View solution in original post

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.

View solution in original post

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

View solution in original post

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.

View solution in original post

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

Federico.

View solution in original post

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

View solution in original post

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.

View solution in original post

17 Replies 17

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.

                          What about this?

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

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

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.

                         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?

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

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

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.

                         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.

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

Federico.

                       Sounds Good. Thanks Federico.

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

                       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?

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: