Solved: Re: losing access to website when changing to http rule

nygenxny123 · ‎05-04-2009

currently we have an external address

that is nat'd internally

the external address has a rule on the outside interface of our fw

permit any "xternal" address ip

incoming

the server is in our dmz...

however, the server is wide open in to the internet....SSH is allowed right now..which is bad.

The only protocol that is needed is http.

So i changed the rule to permit

any "external address" tcp http

however when i made the change..

I lost access to the web pages on the server..

Whats odd is i dont see a rule to permit

HTTP currently on the outside interface..but HTTP is accessible along with SSH.

Our core fw will have rules for the nat'd

internal address..could rules on this be the issue?

bmcginn · ‎05-05-2009

Hi there,

The IP any rule will allow any UDP or TCP connections. So if an access-list sees any UDP or TCP PDUs it will know it is IP.

Reason: As a PDU (Protocol Data Unit) is processed, the following basically occurs. The PDU is made up of various levels of encapsulation. The frame, or layer 2 PDU has a header and footer (which encapsulate a payload). The frame is processed by the asa by stripping the frame header and footer from the payload. The layer 2 payload is made up of the layer 3 PDU. The layer 3 PDU (or IP packet) is then processed. Within the header of the IP packet there is a protocol field which tells the device what format the layer 3 payload will be in. The protocol field can be any of the protocols listed in this page: http://www.iana.org/assignments/protocol-numbers/

As you can see, there are a lot of different protocols (possibly up to 255 if you go by the binary 2^8). TCP and UDP are only two out of that list.

When you do a permit ip any any, the ASA permits ALL of the protocols listed in that page. I am unsure as to the exact mechanics, but my guess would be that it doesn't even look at the protocol field in the IP header.

When you specify a tcp protocol in the access list, the asa will look at the layer 3 payload, which encompasses the TCP header. It ensures the protocol field in the IP header is set to 6 (or 00000110) and then it checks the port numbers in the TCP once the IP header is processed.

In short, if you specify tcp in an ACL, ONLY protocol 6 in an IP header will be allowed, if you specify ip in an ACL then ALL possible protocols in the protocol field will be accepted.

I hope that helps :)

If it does, can you please rate?

Thanks,

Brad

View solution in original post

bmcginn · ‎05-04-2009

Hi there,

Can you post the original (working but insecure) configuration and the new (not working but extremely secure :-)) configuration?

nygenxny123 · ‎05-05-2009

access-list outside_access_in extended permit ip any host xx.xx.xx.xxx

and after the change

access-list outside_access_in extended permit tcp any eq www host xx.xx.xx.xxx eq www

in asdm im just editing the config

to tcp http

i do notice in the url they are using they are using .net:8080

hmmmm

nygenxny123 · ‎05-05-2009

ok...so i changed it to this rule after noticing the .net:8080 url

access-list outside_access_in extended permit tcp any host xx.xx.xx.xx eq 8080

the url now works..but my guys are telling me it is still wide open..hmmmm

bmcginn · ‎05-05-2009

Hi again,

The previous line

access-list outside_access_in extended permit tcp any eq www host xx.xx.xx.xx eq www

didn't work because both source and destination ports were stipulated. The source port of one of the packets would probably be a random port and not port 80; so the permit statements in the ACL weren't matched and the packet was dropped by the implicit deny any any at the end of the ACL.

access-list outside_access_in extended permit tcp any host xx.xx.xx.xx eq 8080

allows any host to connect to the xx.xx.xx.xx host on TCP port 8080 only. It is a more secure than permit ip any host xx.xx.xx.xx.

This will at least block ssh and all other ports from the server. Without seeing the configuration or topology, the ACL line you added is a big step in the right direction in my opinion.

nygenxny123 · ‎05-05-2009

thx...

I just ran a basic nmap scan and it noticed that only 8080 was open.

My question is this..if http is a tcp

protocol..how was connections to 8080 allowed under the ip any rule?

bmcginn · ‎05-05-2009

Hi there,

The IP any rule will allow any UDP or TCP connections. So if an access-list sees any UDP or TCP PDUs it will know it is IP.

Reason: As a PDU (Protocol Data Unit) is processed, the following basically occurs. The PDU is made up of various levels of encapsulation. The frame, or layer 2 PDU has a header and footer (which encapsulate a payload). The frame is processed by the asa by stripping the frame header and footer from the payload. The layer 2 payload is made up of the layer 3 PDU. The layer 3 PDU (or IP packet) is then processed. Within the header of the IP packet there is a protocol field which tells the device what format the layer 3 payload will be in. The protocol field can be any of the protocols listed in this page: http://www.iana.org/assignments/protocol-numbers/

As you can see, there are a lot of different protocols (possibly up to 255 if you go by the binary 2^8). TCP and UDP are only two out of that list.

When you do a permit ip any any, the ASA permits ALL of the protocols listed in that page. I am unsure as to the exact mechanics, but my guess would be that it doesn't even look at the protocol field in the IP header.

When you specify a tcp protocol in the access list, the asa will look at the layer 3 payload, which encompasses the TCP header. It ensures the protocol field in the IP header is set to 6 (or 00000110) and then it checks the port numbers in the TCP once the IP header is processed.

In short, if you specify tcp in an ACL, ONLY protocol 6 in an IP header will be allowed, if you specify ip in an ACL then ALL possible protocols in the protocol field will be accepted.

I hope that helps :)

If it does, can you please rate?

Thanks,

Brad

nygenxny123 · ‎05-06-2009

thx!!!