3

a website aaa.com has a Static Public IP address x.x.x.x .

Client B resides in a network and it accesses the internet through a web proxy C. How the web requests are routed from B to the proxy is unknown. C blocks all connections to aaa.com.

if x.x.x.x:80 is reachable for a client B(say, using Telnet or nmap), then can the Client B access the website aaa.com (through HTTP) by using a HOST File entry aaa.com x.x.x.x

P.S This is Kind of a Trivia Question, but there is currently no way for me to test it to be sure or to see if there are any specific challenges here.

  • Hosts file entries are merely DNS resolution, so heh, no... – Fiasco Labs Dec 8 '15 at 16:30
  • Please read about DNS to have better understanding about how Internet works. Then read about different layers in OSI model, how popular protocol works. P.S. This really is a trivial question – Krishna Pandey Dec 8 '15 at 16:35
  • err you commentors may want to consider the line about telnet to the web server IP address being successful... – Rоry McCune Dec 9 '15 at 10:39
  • Interesting question. How about this then, if the proxy is resolved by hostname, not IP address, then send it to an external, controlled by you proxy on port 80? And if you have permissions to edit the host file, can you not just disable the proxy settings too? – user2867314 Dec 9 '15 at 12:04
  • Telnet is likely not proxy-aware; the browser is, thus the differing results. It's the tool that makes the difference, not the name resolution games. – gowenfawr Dec 10 '15 at 4:01
3

The answer is quite possibly, it depends on how the proxy is configured and the networking works.

The key to answering this question is the line about the IP address of aaa.com being accessible using telnet or nmap. As this is the case, we can assume that traffic to the site is not being blocked completely.

For example assuming the proxy is blocking based on hostnames it sees (e.g. aaa.com) and not based on other factors (e.g. the IP address) if it doesn't see a blocked address it may not block it.

If you give aaa.com a different address using hosts (which generally takes precedence in name resolution over other mechanisms), the request will go to the web server with that alternate name. Now the webserver may not respond as it will get a request for a host it doesn't recognise and may not respond well to that, or may redirect back to aaa.com which would cause the proxy blocking to kick in.

What we don't know from the question is whether the requests using telnet or nmap were bypassing the proxy and therefore that's why they could get to it, in that circumstance it might not work.

To provide an example, say we're trying to block www.google.com. If you put a line in /etc/hosts specifying one of www.google.com's addresses being www.flooble.com, and then make a request to www.flooble.com and intercept the request with a proxy, what you see is a request to www.flooble.com on the IP address mentioned, with no mention of www.google.com. So if the block is purely based on the hostname, it won't kick in.

enter image description here

Now we know from the question that connections to the web port on that IP address are successful, so it's possible that the connection would work.

EDIT - One other factor to consider, which would be important in this case is "where does the name resolution occur". In some cases with an explicitly configured proxy the name resolution occurs on the proxy, in which case the request wouldn't work. In other cases with a transparent proxy (i.e. the client browser isn't aware that it's using a proxy) the name resolution would occur prior to the proxy seeing the traffic, in which case it would seem from the question that the request would work.

1

tldr: nope.

The host file provides network translation, that is, you can have a local web server on 127.0.0.1 and add an entry so any request to google.com is routed to 127.0.0.1, this override happens before the request leaves your computer.

So, when your requests leave your computer, they may query a DNS service for the translation from nice-url.com to 198.198.198.198 or they will go directly to an IP, and the IP for aaa.com will not change because you changed it in your local host file.

  • 1
    In the question it says that a telnet connection to port 80 on the target web server is successful... – Rоry McCune Dec 9 '15 at 10:38
  • @RоryMcCune: yes but in that case he is using the IP address, which is not translated – Purefan Dec 9 '15 at 12:10
  • and if we assign a different host name to that IP address, how does the proxy know to block it? When it sees the request if all it see sees is the IP address, then given that we know traffic to the IP address gets there ok.... – Rоry McCune Dec 9 '15 at 12:12
  • if the target site has the ip 1.1.1.1 and a client can connect to it by using the IP directly then the proxy is not blocking it. If the host file maps websitea.com to 1.1.1.1 and the proxy allows connections to 1.1.1.1 then it will just allow it, the domain used does not matter. The proxy will only block IP addresses, it will not block "websitea.com" – Purefan Dec 9 '15 at 12:21
  • and thus it's possible that the connection will work depending on the configuration of the network/devices. that said in my experience commercial proxy products which block content tend to work based on host/domain names and not IP addresses, as the underlying IP address are subject to change and it would be a pain to maintain if it was IP addresses. – Rоry McCune Dec 9 '15 at 12:24
1

You can't for various reasons.

When a web-proxy is installed it is likely to be for a combination of reasons, both for caching traffic to optimize use of bandwidth and for security reasons.

You might be able to find a way of constructing a TCP connection that can pass HTTP traffic to a destination other than the proxy but it is very likely that the proxy works in conjunction with a stateful firewall that blocks HTTP traffic that isn't relayed through the proxy.


As PureFan wrote in their answer - the conversion of a hostname to an IP address (using DNS or local Hosts file etc) is simply a separate preliminary step that is carried out before the client attempts to make a TCP connection to the IP address of the HTTP server - you can't affect the way this second step uses proxies and firewalls by altering the way aaa.com is converted to an IP-address.


Without knowing anything about the proxy and firewall arrangements it isn't really possible to know what might work. For excample there might be a transparent proxy in use which might be harder to bypass than a proxy configured at the client.

  • isn't an IP address and a port number not enough to make a TCP connection? – JOW Dec 9 '15 at 10:15
  • In the question it says that a telnet to the IP address of the blocked web site is successful, do you think that may be a factor in whether this would or wouldn't work? – Rоry McCune Dec 9 '15 at 10:37
  • @Rory: Yes, ability to telnet to an IP-address is an indicator that TCP connections to other ports at that address may also be possible. It might be that a firewall blocks selectively but I agree this is less likely. – RedGrittyBrick Dec 9 '15 at 11:24
  • @JOW: Normally yes. However when a firewall is present it can be much more complicated. I doubt the OP has to deal with port knocking but that's an example where knowing an IP-address and port number is insufficient to successfully create a TCP connection. – RedGrittyBrick Dec 9 '15 at 11:32
  • @RedGrittyBrick also worth noting that the question specifies that it's telnet to port 80 that works ok, so we can conclude that at some level the web server port is accessible to the client. – Rоry McCune Dec 9 '15 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.