Suppose computer A sends an HTTP request to a server B, and B wants C to answer it. Is it possible for C to send a response back to A without B intervention and without specific actions from A (as with a 3xx redirection)? Suppose C may not have a public IP address.
That's what a reverse proxy would do. Depending what platform you are on, there are a lot of options.
One way that works on many platforms is e.g. node-http-proxy that you could start on server B. In the most simple case, this one-liner would do:
require('http-proxy').createServer(81, 'serverb').listen(80);
It listens on port 80 and redirects to port 81 on serverb.
See https://github.com/nodejitsu/node-http-proxy for more options.
Of course, there are lots of well-established proxies with a lot more bells and whistles (although node-http-proxy can do https tunneling etc. as well), but configuring those can be more challenging that running this one-liner. It all depends on your use case.
Edit: Reading your comment, this can be done using direct routing. Your question is about HTTP (layer 7), and as direct routing works on a lower layer, higher-level protocols like HTTP work as well. Quote from http://horms.net/projects/has/html/node9.html:
Direct Routing: Packets from clients are forwarded directly to the
back-end server. The IP packet is not modified, so the back-end
servers must be configured to accept traffic for the virtual server's
IP address. This can be done using a dummy interface, or packet
filtering to redirect traffic addressed to the virtual server's IP
address to a local port. The back-end server may send replies directly
back to the client. That is if a host based layer 4 switch is used, it
may not be in the return path.
Related
I would like to know how internal communication links between private internal servers and a reverse proxy look.
When from my client (browser) I make a request to, say https://facebook.com, I hit Facebook's reverse proxy. I have two questions, when that reverse proxy gets a request and needs to forward it to the server that should handle it, does that sever it is forwarding the request to have a domain name or is it just an IP address ((user.facebook.com or useroffacebook.com v.s. 34.23.66.25 (DO NOT GO TO THAT ADDRESS I JUST MADE IT UP!!!)))? Also, does that connection use HTTP or HTTPS?
Like Kshitij Joshi already mentioned, it could be both.
A more detailed perspective for implementation:
reverse proxy should use IP addresses for routing so they are still working even if the DNS fails or is unavailable to the proxy for some reason.
internal traffic should also be encrypted (HTTPS). using plain text, even in internal networks, must be considered dangerous and is not recommended.
from my mindset you can replace the 'should' with a 'must'.
Now i am getting super confused with how ports actually work ,
This is my understanding of ports. I know that port 80 is for HTTP protocol and port 443 is for HTTPS protocol, so whenever I access http://website.com [(name or ip)], it is converted to http://website.com:80 [(name or ip)], and when I access https://website.com [(name or ip)], it gets converted to https://website.com:443 [(name or ip)].
So, if i am accessing a website on another port, i.e, i have my local setup of either springboot or angular app, and they are HTTP endpoints,
and I access http://localhost:someportNumber (example: http://localhost:5000), how does that get translated to port, as I have explicitly specified port 5000, but HTTP works on port 80.
Can you please help me with my understanding of how ports works.
Till now I was clear on how ports work, but now when I think of it like this today, it challenges my understanding of ports.
I came across this conflict of understanding when I was learning about the services on Google Kubernetes Engine. In there I created a service of type nodeport, which had configs like
port: 443
targetPort: 443
nodePort: 31000
and when I accessed external ip address of one of the nodes https://[external-ip]:31000, it worked.
So I began to challenge my understanding and I can't wrap this around my head that how is it working.
PS:- It is not about the concept of NodePort/ClusterIP/LoadBalancer. But in general about how these ports work with protocol port http or https, with a port of application.
You can specify any port (such as 5000 in your example). The URI simply begins with http to indicate what protocol is used - it does not mandate the use of port 80. The address is then used to contact the host on the specified port (which will be port 80 unless a different port was specified). Upon successful connection, the client then expects the server to speak HTTP.
On the server side, there is just a program that is listening on a port, waiting for incoming connections.
In the old days, one wouldn't call a person at a company directly. Instead one would call the main company switchboard and ask for the person at some extension.
Operator: How can I help you?
You: Extension 123
Operator: Connecting you now
Think of a "port" like an extension at a company. The hostname/IP address is the phone number of the company, the port is the extension at that company.
Going back to the analogy, once you are connected to the phone extension, you have a conversation. Both parties have an expectation of the conversation to be had. For example, if I call the extension corresponding to sales, I can place an order while if I call the extension corresponding to recruitment, I can submit my resume. This relationship between the purpose of the call and the extension is by convention and is not implicit in the extension itself.
When you form a connection over the internet to some machine at port 80, the assumption is that we will be exchanging HTTP traffic. However if I form a connection to some machine at port 5000, then there is nothing to prevent THAT connection from also sending and receiving HTTP traffic. For example, if sales at my company can be contacted on extension 80 and you can place an order there may also be an additional extension (5000) which you can call to place other types of orders that aren't available at the 80 extension.
See also:
http://www.steves-internet-guide.com/tcpip-ports-sockets/
My question is about networking. I'm just looking for a simple answer, yet I couldn't find one after 1 hour research. I know there are techniques such as Wi-Fi Hotspot, man-in-the-middle-attack, local network, echo switch, etc. But I couldn't find an answer to my specific question.
Let's say, client A wants to communicate with server B, and server B says client A must authenticate himself via HTTP basic authentication first. My question is, what happens if client A sends the authentication credentials via HTTP layer (insecure), who can read the HTTP headers that the client A sends to server B over the internet? Would it be easy to do that? Like placing a breakpoint between two arbitrary routers, which help to transfer the packets across the internet, in order to read those headers? How does it work in general?
Thank you!
PS.: I am not trying to learn and do it. I just want to know, how dangerous it would be, if the HTTP basic auth is made via the insecure HTTP layer.
Who can read the HTTP headers that the client A sends to server B over
the internet?
Your Network Provider (e.g Wi-fi hotspot Provider).
Your Domain Name System server (DNS, as 192.168.1.1).
Your Internet Service Provider (ISP).
Your Virtual Private Network if using one (VPN server).
Yourself Or a Virus.
and here comes the HTTPS (HTTP + SSL Encryption)
SSL is about communicating in a language that you and the server only understand.
How dangerous it would be if the HTTP basic auth is made via the insecure HTTP layer?
Well, from above, You can totally get that a simple virus or even a public Wi-fi Hotspot Device can capture and see all of your data if the communication was done in a plain HTTP Socket.
A Simple packet may contain all of your Device information including its basic contents as your passwords, credit cards information, The HTML form for the signup/login that you've just completed with all its data, VoIP Calls and messages being sent to the server + upcoming/received ones.
that's why we need SSL encryption and the server should have a valid SSL certificate too.
By the way, your device may have sent thousands of packets while you read this now!
Capturing the packets that your device sends or even the packets that other devices on your network send can be done through any packet capturing tool or software as Wireshark.
I would like to know how "realistic" is to consider implementing an intercepting proxy(with cache support) for the purpose of web filtering. I would like to support also IPv6, authentication of clients and caching.
Reading to the list of disadvantages from squid wiki http://wiki.squid-cache.org/SquidFaq/InterceptionProxy that implements an intercepting proxy, it mentions some things to consider as disadvantages when using it(that I want to clarify):
Requires IPv4 with NAT - proxy intercepting does not support IPv6, why ?
it causes path-MTU (PMTUD) to possibly fail - why ?
Proxy authentication does not work - client thinks it's talking directly to the originating server, in there a way to do authentication in this case ?
Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since it will not know how to deal with it - This seems quite plausible as the way redirecting of traffic to proxy is done in this case is by a firewall changing the destination address of a packet from the originating server to the proxy's own address(Destination NAT). How would in this case, if i want to intercept other protocols besides http know where the connection was intended to go so I can relay it to that destination ?
Traffic may be intercepted in many ways. It does not necessarily need to use NAT (which is not supported in IPv6). A transparent interception will surely not use NAT for example (transparent in the sense that the Proxy will not generate requests with his own address but with the client address, spoofing the IP address).
PMTUD is used to detect the largest MTU size available in the path between the client and server and vise versa, it is useful for avoiding fragmentation of Ip packets on the path between the client and server. When you use a Proxy in the middle, even if the MTU is detected, it not necessarily the same as the one from the client to the proxy and from the proxy to the server. But this is not always relevant, it depends on what traffic is being served and how the proxy is behaving.
If the proxy is authenticating in the client behalf, it needs to be aware of the authentication method, and it will probably need some cookies that exist in the client. Think of it this way... If a proxy can authenticate an access to a restricted resource on your behalf, it means anyone can do it on your behalf, and the purpose of a good authentication is to protect you from such possibilities.
I guess this was a very old post from the Squid guys, but the technology exists to redirect anything you want to a specific server. One simple way to do it is by placing your server as a Default Gateway for the network, then all packets pass through it and you could redirect the packets you like to your application (or another server). And you are not limited to HTTP, BUT you are limited to the way the application protocol works.
I have web application that runs on Tomcat (and gets HTTP requests) and some other backend standalone application that gets only TCP. For some reasons, I can use outside only port 8080. So, I need to get all TCP requests (from outside) to port 8080 and forward HTTP ones to web application on Tomcat and all TCP pure requests (that are not HTTP) - to standalone application. Internal forwarding could be done to any port, e.g. 8181 on Tomcat and 8282 on standalone application. Is it possible to setup such configuration? How it could be done?
Thanks in advance.
TCP and HTTP are protocols in different networking stack layer. If you want to use some application to filter HTTP requests, your application should deal with Application-Layer information, not Network-Layer(like TCP/UDP).
I don't see how this can be possible generally. You could look packet-by-packet, but the middle of an http body can be arbitary so you can't just look at the data of each packet
If any particular client will send you either http or general TCP but not both, can you do this by source-IP address? Do you know the addresses of either the servers that will send you http requests or the ones that will send you TCP requests?
If you don't know the source IPs, you could heuristically look at the first packet from some previously unknown IP and see if it looks like http, then tag that address as containing http traffic.
What is the content/format ot the TCP communication? Is there any pattern you can detect in that?
Y
Perhaps you could do something like this using iptables + L7 filter. Of course this will only work if you run Linux on your box. Also I don't know how recently l7 filter project has been updated.
Java servlet technology is not limited to Http. The servlet interface lets you read in the incoming input stream via ServletRequest.getInputStream(). So you can create an implementation of Servlet interface and map it in web.xml and you are all set to receive any TCP traffic.
Once you have the read the input stream to sniff the content you will want to forward HTTP requests to an HttpServlet. To do this you will need to make sure that the input stream you pass on is positioned at the very beginning of the input.
EDIT: On reading your question once again, I noticed that you don't plan to expose the Tomcat directly on external port as I originally thought. If you are willing to make the tomcat listen on the external port, you can try the approach described above