|
Home > Archive > alt.certification.cisco > October 2003 > Cisco PIX 501
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Jim Blake 2003-10-24, 3:25 pm |
| I have a PIX 501 on my desk, wired so the outside port is connected to
a switch port on my ADSL router, getting its IP address via DHCP from
the router. On the inside of the PIX, I have a PC, running XP,
configured to get its address via DHCP from the PIX.
I used Startup Wizard to get the thing working, and then fired up
Windows Media Player on the PC, and sure 'nuf, I could get media
player and HTTP traffic streaming through the PIX, (I guess?) on
account of the Implcit inbound rule.
I decided to create a "stop everything" rule, then create rules above
it to permit http, ftp, etc. I put up the deny rule and the PDM GUI
showed the rule as OK, having pressed the "Apply To PIX" button. CLI
showed a line:
"access-list outside_access_in deny ip any any"
and this was applied further down with:
"access-group outside_access_in in interface outside"
which I believe means apply the access list "outside_access_in" to
incoming traffic from the outside interface.
That looked OK, but traffic still flows. I assume that this is because
a stateful f/w will allow the traffic because everything so far is
initiated inside. Sooooo....
First quetion: Is the assumption above right, or if it is wrong, why
does my deny/deny rule not stop http and media player streams dead in
their tracks?
Second question: How do I stop access to things like media player,
initiated inside(clearly not with the commands I'm using!!)
In case its to do with translation, here's the detail.
I'm using address xlation, with the f/w running 10.1.1.1 255.255.255.0
as its internal interface address (PC gets DHCP address 10.1.1.2
usually) and using 192.168.7.4 (DHCP allocated) in the outside, and
overloading that address with PAT, so the translation rule looks like:
----------------------------------------------------------------
Orginal | Translated |
-----------------------------------------------------------------
Interface | Address | Interface | Address |
----------------------------------------------------------------
inside | inside:any/0.0.0.0 | outside | Interface PAT |
Thanks for any light you can shed on this one, guys!
Cheers
JB
| |
| reshman 2003-10-24, 4:25 pm |
| Here is what I think I know about Pix:
1. ACL's will not block connections that have a state. Once the connection
attempt makes it into the PIX, it will be allowed. In your case, you are
trying to block traffic from the outside to the inside. Since the Media
Player traffic, etc. is source from the inside interface, it will be allowed
on the return path (from the outside interface) because there is a
connection (show conn).
2. If you want to stop these kinds of connections, you need to block them
inbound on the inside interface so that the connection request never creates
a state entry. I am not sure what ports Media Player, etc. use, but you
would need to block those.
Hope that helps.
-Mike
"Jim Blake" <j__blake@hotmail.com> wrote in message
news:48f6aebe.0310241026.33951946@posting.google.com...
> I have a PIX 501 on my desk, wired so the outside port is connected to
> a switch port on my ADSL router, getting its IP address via DHCP from
> the router. On the inside of the PIX, I have a PC, running XP,
> configured to get its address via DHCP from the PIX.
>
> I used Startup Wizard to get the thing working, and then fired up
> Windows Media Player on the PC, and sure 'nuf, I could get media
> player and HTTP traffic streaming through the PIX, (I guess?) on
> account of the Implcit inbound rule.
>
> I decided to create a "stop everything" rule, then create rules above
> it to permit http, ftp, etc. I put up the deny rule and the PDM GUI
> showed the rule as OK, having pressed the "Apply To PIX" button. CLI
> showed a line:
>
> "access-list outside_access_in deny ip any any"
>
> and this was applied further down with:
>
> "access-group outside_access_in in interface outside"
>
> which I believe means apply the access list "outside_access_in" to
> incoming traffic from the outside interface.
>
> That looked OK, but traffic still flows. I assume that this is because
> a stateful f/w will allow the traffic because everything so far is
> initiated inside. Sooooo....
>
> First quetion: Is the assumption above right, or if it is wrong, why
> does my deny/deny rule not stop http and media player streams dead in
> their tracks?
>
> Second question: How do I stop access to things like media player,
> initiated inside(clearly not with the commands I'm using!!)
>
> In case its to do with translation, here's the detail.
> I'm using address xlation, with the f/w running 10.1.1.1 255.255.255.0
> as its internal interface address (PC gets DHCP address 10.1.1.2
> usually) and using 192.168.7.4 (DHCP allocated) in the outside, and
> overloading that address with PAT, so the translation rule looks like:
> ----------------------------------------------------------------
> Orginal | Translated |
> -----------------------------------------------------------------
> Interface | Address | Interface | Address |
> ----------------------------------------------------------------
> inside | inside:any/0.0.0.0 | outside | Interface PAT |
>
>
> Thanks for any light you can shed on this one, guys!
>
> Cheers
> JB
| |
| edmonds_robert 2003-10-24, 9:27 pm |
| A couple of things to add. First, by default, the PIX (once configured with IP address, NAT rules, etc.) will allow all outbound connections and deny all inbound connections. Therefore, your deny any any rule did absolutely nothing that wasn't already being done. Second, RESHMAN is correct about the access-list to stop Media Player, which I believe runs on port 1755. Your outbound access-list would look like
access-list acl_inside deny tcp any any eq 1755
access-list acl_inside deny udp any any eq 1755
access-group acl_inside in interface inside
Your inbound rules, in conjunction with your static NAT statements, will be to allow access to servers and services that reside behind your firewall. | |
| Jim Blake 2003-10-26, 3:25 pm |
| Guys,
Thanks for the help. It's working now and I owe you both a
cyber-beer...Its *soooooo* obvious when it works, which is did after
reading your posts and actually *using* the grey cells!
JB
|
|
|
|
|