unfortunately my browser didn't like that page. HTTP is blocked from outside. Limited clients can access it from inside. SMTP no fixup was recomended because of exchange behavior, yes. Thanks you for the input.
Printable View
unfortunately my browser didn't like that page. HTTP is blocked from outside. Limited clients can access it from inside. SMTP no fixup was recomended because of exchange behavior, yes. Thanks you for the input.
Not an expert in this area but the link does work if you remove the spaces (represented by %20) and the <br%20/>
I tried to post the fixed link here but AO destroyed it by inserting the spaces and html formating
Cheers,
-D
Not an expert in this area but the link does work if you remove the spaces (represented by %20) and the <br%20/>
I tried to post the fixed link here but AO destroyed it by inserting the spaces and html formating
Cheers,
-D
Yep , that does work. Cheers. Great article.
Yep , that does work. Cheers. Great article.
Why do you use fixup ftp and http if these ports aren't open?
Setup your ruleset like this:
Allow rule (conduit permit tcp x.x.x.x eq smtp host y.y.y.y)
deny everything else (conduit deny ip any any)
Why do you use fixup ftp and http if these ports aren't open?
Setup your ruleset like this:
Allow rule (conduit permit tcp x.x.x.x eq smtp host y.y.y.y)
deny everything else (conduit deny ip any any)
That's a damn good question, I guess it's there as a safety margine but it's not used so I'll take them out. I had considered the conduit command to deny everything. The initial startup command for the pix interface has it set to deny everything but an extra step would be beneficial to ensure unwanted packets are definitely denied. But I am thinking, if I go messing with the conduits I might as well conform to modern convention and switch to ACL controls. Of course just adding that deny line wouldn't hurt, so I did.
To update everyone, I had a very generous AO member (thanks T.S.) scan me last night and with the running config posted here there are no open ports reported back. Although I did turn off the FTP server that was running in IIS on the mail server.
//edit I think I spoke too soon on the fixup commands. They are enabled by default and if there are no vulnerabilities accociated with their use, would it make sense that if a packet did get through, you would want it to run through the fixup security engine for inspection? They are enabled by default and I know some recomend their removal if not used but I question the benefit of fixup exploits versus and active insepection of packets comming in that are orignated from inside, such as web browsing. Am i oversimplifying? The command is global affecting both inside and outside interfaces but I AM NOT a Cisco expert.
That's a damn good question, I guess it's there as a safety margine but it's not used so I'll take them out. I had considered the conduit command to deny everything. The initial startup command for the pix interface has it set to deny everything but an extra step would be beneficial to ensure unwanted packets are definitely denied. But I am thinking, if I go messing with the conduits I might as well conform to modern convention and switch to ACL controls. Of course just adding that deny line wouldn't hurt, so I did.
To update everyone, I had a very generous AO member (thanks T.S.) scan me last night and with the running config posted here there are no open ports reported back. Although I did turn off the FTP server that was running in IIS on the mail server.
//edit I think I spoke too soon on the fixup commands. They are enabled by default and if there are no vulnerabilities accociated with their use, would it make sense that if a packet did get through, you would want it to run through the fixup security engine for inspection? They are enabled by default and I know some recomend their removal if not used but I question the benefit of fixup exploits versus and active insepection of packets comming in that are orignated from inside, such as web browsing. Am i oversimplifying? The command is global affecting both inside and outside interfaces but I AM NOT a Cisco expert.
just finish my last observation, if http is open from inside to outside, you should take a look at "strict" parameters. That would avoid "embeded" ftp on http strings. Maybe this the origin from those ftp connections