OK, I think we agree. I believe the command below enables websense filtering for any traffic outbound on port 8080. The addition of the proxy-block command adds an additional check which is performed on the websense server (not locally on the ASA) above normal URL filtering to also check if traffic (in this case on port 8080) is using an external proxy and if so denies the connection. Any non proxies traffic on port 8080 is subject the same URL filtering checks that other traffic is when using websense.
Thanks for the input. On Mon, Sep 10, 2012 at 5:05 PM, Kingsley Charles < [email protected]> wrote: > You got me wrong. > > The following prevents any inside hosts connecting to a proxy server > listening on port 8080. > > > filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block > > > With regards > Kings > CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security) > > > On Mon, Sep 10, 2012 at 12:24 PM, Ben Shaw <[email protected]> wrote: > >> I may be confused but are you suggesting configuring proxy-block prevents >> proxy servers inside the ASA from accessing the internet on behalf of its >> proxy clients that are also inside of the ASA? >> >> From my reading, research and understanding, the proxy block function is >> designed to prevent use of an outside proxy by clients on the inside not to >> prevent an internal proxy server that is also on the inside interface from >> reaching the internet in behalf of its clients. >> >> It wouldn't make much sense to me to prevent internal proxies from >> accessing the internet from inside the ASA while not have the ability to >> block internal users from connecting to external proxy servers with the >> intent to avoid the filtering of their web sessions. >> >> >> >> >> On Mon, Sep 10, 2012 at 4:42 PM, Kingsley Charles < >> [email protected]> wrote: >> >>> URL filtering is always performed outbound from higher to lower security >>> interface. ASA doesn't perform vice-versa. >>> >>> In small offices, LAN users connect to the internet using proxy server. >>> They will have a PC connected to the internet and all the other machines >>> inside the office will connect through this PC. This PC is the proxy server. >>> >>> Now, the task is to block that kind of http traffic going on port 8080. >>> >>> >>> >>> With regards >>> Kings >>> CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security) >>> >>> On Mon, Sep 10, 2012 at 10:22 AM, Ben Shaw <[email protected]> wrote: >>> >>>> Thanks for your responses. >>>> >>>> I suppose the first this to state is that without an ACL dropping >>>> TCP8080 (which the ASA doesn't have) there is a need to do something with >>>> filtering to prevent these connections which is what the question is asking >>>> as with only the command below and no ACL, connections on 8080 will be >>>> allowed and not filtered by websense. >>>> >>>> >>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow >>>> >>>> As no ACL is applied to block port 8080, the following command is >>>> needed to satisfy the requirement to block proxied outbound connections on >>>> port 8080 >>>> >>>> >>>> filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block >>>> >>>> This raises the question for me then as to what the proxy-block option >>>> actually does. My thoughts is that it does one of the following >>>> >>>> - Adds additional intelligence to the inspection of the filtered >>>> traffic to be able to tell if traffic matched by the rule is using a proxy >>>> and if so blocks the connection and if not filters it with websense as with >>>> normal web traffic >>>> - Deems that any traffic matching the IP/port combo is proxied traffic >>>> and blocks locally without referring to websense >>>> >>>> I did some tests but again as I don't have a websense sever it is >>>> difficult to be sure if things are being blocked because of there being no >>>> websense server to do proper filtering or because traffic configured >>>> configured to proxy-block is automatically denied locally on the ASA >>>> >>>> Here are my results: >>>> >>>> 1. Applying basic filtering >>>> >>>> >>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 >>>> >>>> Results >>>> - Connection failed >>>> - "requests dropped" counter in the "show url-server statistics" output >>>> incremented >>>> - 3 way handshake seen on outside interface between client and server >>>> >>>> >>>> 2. Applying filtering with proxy-block option >>>> >>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block >>>> >>>> Results >>>> - Connection failed >>>> - "requests dropped" counter in the "show url-server statistics" output >>>> incremented >>>> - 3 way handshake seen on outside interface between client and server >>>> >>>> >>>> 3. Applying filtering with proxy-block option on port 8080 >>>> >>>> >>>> filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block >>>> >>>> Results >>>> - Connection failed >>>> - "requests dropped" counter in the "show url-server statistics" output >>>> incremented >>>> - 3 way handshake seen on outside interface between client and server >>>> on port 8080 >>>> >>>> >>>> 4. Applying filtering with proxy-block and allow option >>>> >>>> >>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow proxy-block >>>> >>>> Results >>>> - Connection completed and server accessible >>>> - "requests dropped" counter in the "show url-server statistics" output >>>> incremented >>>> - 3 way handshake seen on outside interface along with other TCP >>>> packets on port 8080 >>>> >>>> From these results I still can't be certain what is happening as >>>> interestingly the dropped requests counter incremented with all four tests >>>> even though test four connected by virtue of the "allow" option being used. >>>> >>>> My feeling is that because in test 2 and 3 I still see a TCP handshake >>>> complete between the client and server that the proxy-block option does not >>>> automatically just drop these connections locally on the ASA but instead >>>> requests additional inspection for the traffic to the websense server to >>>> check for use of a proxy. I think this is what is happening because if the >>>> packet was just denied locally via the proxy drop option then I wouldn't be >>>> seeing the TCP connection on the outside interface. >>>> >>>> That being said, as no websense connection is available it is hard to >>>> say with absolute certainty as I may seen difference results if this >>>> filtering server was available. I constantly see the ASA sending TCP SYNs >>>> to the configured websense server but as it does not exist and no >>>> connection is made I cannot check if the ASA would send a websense request >>>> for one or any of the tests above. >>>> >>>> So going back to the question, if indeed the proxy block option does >>>> add additional proxy checking capabilities on the traffic as opposed to >>>> just denying the the traffic automatically, it would seem that the >>>> solutions configuration of the following two commands is correct: >>>> >>>> >>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow >>>> filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block >>>> >>>> The first command will perform filtering on normal web traffic allowing >>>> it to pass if the websense server is down. This first command I believe >>>> will also allow proxies to be used on port 80 via websense as proxy block >>>> is not configured. The second command will add websense filtering on port >>>> 8080 also. However if proxy traffic is detected by websense on port 8080 it >>>> will be blocked. As the filtering on port 8080 is stricter, never wanting >>>> to proxied traffic through on this port, the allow option is not configured >>>> ensuring that if websense is down and the proxy detection is not available >>>> then all traffic on port 8080 will be blocked anway. This seems to be >>>> consistent with what the question is asking. >>>> >>>> Any feedback or corrections to what I am thinking would be appreciated. >>>> >>>> Thanks >>>> Ben >>>> >>>> >>>> >>>> On Mon, Sep 10, 2012 at 5:55 AM, GuardGrid <[email protected]> wrote: >>>> >>>>> I think based on the question it specifically calls out proxy on port >>>>> 8080. >>>>> The filter url http is only going to redirect port 80 traffic to the >>>>> websense for inspection. >>>>> If we do not indicate to the ASA that http traffic could be going on >>>>> 8080 it would not know to take the appropriate action. >>>>> >>>>> So in this case I assume if normal http traffic flows on 8080 the ASA >>>>> would redirect to websense but if it was forwarded by a proxy, probably >>>>> looking for X-Forwarded-For" or something then do not allow. That is my >>>>> guess. >>>>> >>>>> -Srikant >>>>> >>>>> On Sun, Sep 9, 2012 at 10:34 AM, Ben Shaw <[email protected]>wrote: >>>>> >>>>>> Hi All >>>>>> >>>>>> I am doing a lab which asks to complete the following: >>>>>> >>>>>> - Configure ASA1 for HTTP URL filtering for all users on the inside >>>>>> using a WebSense server located at 10.0.0.100. >>>>>> - In the case that the filtering server is down all HTTP requests >>>>>> should be allowed. >>>>>> - Ensure that users accessing websites via external proxies on port >>>>>> 8080 are blocked by this policy. >>>>>> >>>>>> My answer was >>>>>> >>>>>> url-server (outside) vendor websense host 10.0.0.100 >>>>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow proxy-block >>>>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow proxy-block >>>>>> >>>>>> It seems I don't understand the usage of the proxy block command as >>>>>> the solution gave the answer as >>>>>> >>>>>> url-server (outside) vendor websense host 10.0.0.100 >>>>>> filter url http 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 allow >>>>>> filter url 8080 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 proxy-block >>>>>> >>>>>> I was under the impression that using the proxy block option as I did >>>>>> would allow normal HTTP connections for the traffic from any source >>>>>> networks to any destination be checked against the external filtering >>>>>> server but block this same traffic if it is using a proxy. It seems from >>>>>> the solution however that the proxy block option is used by itself to >>>>>> identify a source and destination network and a port (8080 in this case) >>>>>> to >>>>>> apply a blanket deny on all matching traffic. >>>>>> >>>>>> It would seem easier t me to just allow HTTP traffic in an ACL and >>>>>> deny all other traffic (inc 8080) in this case though I understand this >>>>>> is >>>>>> not how the question is wanting it to be done. >>>>>> >>>>>> Considering I can't really test this too easily as I don't have a >>>>>> websense server can anyone confirm, deny or clarify my observations? >>>>>> >>>>>> Thanks >>>>>> Ben >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> For more information regarding industry leading CCIE Lab training, >>>>>> please visit www.ipexpert.com >>>>>> >>>>>> Are you a CCNP or CCIE and looking for a job? Check out >>>>>> www.PlatinumPlacement.com >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>>> Are you a CCNP or CCIE and looking for a job? Check out >>>> www.PlatinumPlacement.com >>>> >>> >>> >> >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
