If i find port X open on an ip address, is it safe for me to assume that i will find a web server at domian:X where domain resolves to the ip

de flag

Lets say resolved to 36.45.6.x, and i port scanned that ip and ports 80,443,8080 came up and nmap tells me they all have http web servers running on them, is it safe for me to assume that if i visit a webserver will reply? like can an ip have port X open but in order for me to access it via hostname i have to go to domain:Y (where Y is a different port than X)

cn flag

is it safe for me to assume that if i visit a webserver will reply?

No, you can't assume anything.

While 80 and 443 are IANA reserved to be for HTTP and HTTPS, nothing forbids anyone to run something else on those ports.

Also the ports can be seen as open but acting as a decoy, from kernel level. Or there can be a process really attached to it, but for some reason it doesn't work properly and hence won't reply at all.

But even if you have a fully working webserver, you might not get replies or not get the expected reply.

If you get resolving to, the webserver at that IP address still needs to be especially configured to know about the name (or be configured in some wildcard way to accept any name). If it is not configured, it won't know what content to send back (there could be multiple websites hosted on the same IP address), and can either send content of one of the website it manages (like in Apache, first one declared in configuration files) or return an error, like HTTP 400 or 500 to tell the client that the name is wrong.

It can easily happen, because you can take any existing website, find its IP address, and then in ANY zone, add a record for ANY name pointing to that IP address (or similarly on Unix systems, tinker with /etc/hosts). Of course the webserver at that IP address will have no way to know what this new name is about, and hence will not reply as expected.

like can an ip have port X open but in order for me to access it via hostname i have to go to domain:Y (where Y is a different port than X)

That part is not clear. IP addresses do not have "ports". You might need to document yourself on the OSI 7 layers model of networking, or the Internet model. In short, at bottom you have IPv4 and IPv6, and there are no ports there, that concept just does not exist. On top of that, you have protocols like TCP and UDP, which do define ports. A TCP connection is a 4 items tuple: source IP, source port, destination IP, destination port.

Kind of on top of TCP, you have TLS. A TLS handshake, typically, starts with a "Server Name Indication" extension in the ClientHello message. This extension allows the client to specify the hostname of the host it is trying to reach at that IP level. Because through the DNS the client will have mapped the hostname (like extracted from the URL in case of HTTPS) to an IP address, but then as explained above that IP address can do mass virtual hosting of multiple names, so before even sending the first HTTP message, the TLS server needs to know for which hostname it is queried for (to be able to immediately return the correct certificate, as this happens early in the TLS handshake, and obviously before any HTTP exchange), and this is what the client does by using the SNI extension.

But what you describe can happen in some cases of proxying and/or domain cloacking.

pt flag

Ports 80 and 443 are reserved ports for web services and are not changed whether you are requesting via the domain name or IP address. 8080 is typically for proxy. The only port that changes is on the client (your) side because a random available high port number is chosen by your OS to complete the connection.

While you may get a reply on nmap, there are times when you may not be served the website that resides there when requesting by IP address because a rule states it must be requested by domain name. You may not get the website served even if requested by domain name if you don't meet certain criteria to be granted access such as only clients from a list of whitelisted IP addresses.


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.