I have a domain let's call it (testserver.com) that points to my PC IP (192.XXX.X.X), I need to setup a rule/proxy/something that will make all connections from testserver.com goes to 192.XXX.X.X:8080, sorry if this is a stupid or impossible question
First, #Daniel might have a good suggestion there, it would ofc be easier to work with names.
So, I have just gone to the Windows Firewall with Advanced settings, here are the steps I think are to do for incoming traffic.
First: Add an Inbound-connection-rule:
inbound connection rule
Second: Choose the Option "Port"
rule that controls a connection for an TCP or UDP port
Third: Choose your protocol type, TCP or UDP and select the second option below, write 8080
define protocol and port
Fourth: Now choose if only secured connection(s) should be allowed or also not-secured
choose option for network security
Fifth: Now select if domain, public connection or private connection
network type
Sixth: Now add name and description of the rule
name and desc
Seventh: Go to properties of your (new) rule
Eighth: Now you can check the different tabs and also change the protocol from UDP or TCP to any other. The tab "Scope" will let you define IP-adress(es) for this connection that are either public or private, for this connection. In case you're interested, you can also define Authorized computers for this connection, but the connection must be secured then.
the IP scope section
You can set rules for incoming or outgoing traffic in the Windows Firewall. I cannot tell you the exact steps currently, as I am not home. Tho I found this post helpful:
https://serverfault.com/questions/496335/open-windows-firewall-to-all-connections-from-specific-ip-address
If you still need help, I would watch later. But actually the Windows Firewall should be quite easy to manage.
Related
In MDN's proxy example, I have seen that they use 127.0.0.1:65535 as an invalid url
(link to the source):
const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
if (blockedHosts.indexOf(host) != -1) {
browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
return deny;
}
return allow;
}
Is there anything special about port 65535? Is it safe to assume that no process will ever listen to that port?
In the documentation of Proxy Auto-Configuration (PAC) files, I did not see a straightforward way to block requests otherwise. For instance, there is DIRECT, PROXY, SOCKS but no REJECT or DENY. I assume that PROXY 127.0.0.1:65535 is the official way to deny requests.
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
No, it's not safe.
It's just the very last port on the local machine. I'm perfectly able to open it without any special privileges and send data to it.
They are simply using it as a valid address but a port that's unlikely to be used. Not the best solution, but probably good enough for example code.
There's no special stipulation and 65535 a valid port for a proxy. If you just happen to run a valid proxy there the example will fail to block.
Normally "9" is used as the default port for "discard service". 65535 is nothing special but the biggest possible port number. I assume they use it because they believe no one will listen to the port.
However, this approach is not safe because 1) anyone can write a server socket listening to port 65535; and 2) the port number might be randomly allocated to a client as ephemeral port.
In addition to the other answers, the Discard Protocol (port 9) is the closest equivalent to /dev/null. To quote from the Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
Also blocking requests via the proxy API is not the typical usage. Instead the webRequest API is better suited for blocking requests. There are discussions to change the example.
I assume that explains why there is no explicit support for denying requests in the PAC de facto standard, and why the workarounds of redirecting traffic to unused ports or domains are used.
I have a dedicated windows 2012 server with 12 dedicated IPs.
I want to be able to make connections simultaneously from two different ips that I choose.
This will be used for two different browser applications.
I have tried the following:
ForceBindIP %IP_ADDRESS% %APP_EXE%
But the IP doesn't change, the browser always displays the lowest IP from my added range.
I have also experimented with a script that removes all the ips, and then just adds one.
netsh interface ipv4 delete address "Ethernet" 104.251.111.110
netsh interface ipv4 delete address "Ethernet" 104.251.111.111
netsh interface ipv4 delete address "Ethernet" 104.251.111.112
netsh interface ipv4 delete address "Ethernet" 104.251.111.114
....
netsh interface ipv4 add address "Ethernet" 104.251.111.115 255.255.255.0
This changes the address BUT I end up having only one IP for both applications.
If the applications you intend to use doesn't support binding to interfaces/ip (true, it's uncommon), you can use SOCKS or Proxy software (which is a lot more common, especially browsers).
For instance you could install WinGate or Squid http://www.squid-cache.org (which is the one I know most).
Squid-Cache have the ability to bind to different outgoing addresses based on rules (http://www.squid-cache.org/Doc/config/tcp_outgoing_address/ ).
Basically what you need to do is:
install Squid
add ACL for loopback IP mapping, such as:
acl IP110 src 127.0.0.1/32
acl IP111 src 127.0.0.2/32
[...]
tcp_outgoing_address 104.251.111.110 IP110
tcp_outgoing_address 104.251.111.111 IP111
[...]
And the default, which is just formally needed:
tcp_outgoing_address 104.251.111.110
Each application will then need to be configured with a Proxy (or SOCKS, if you go that way), which is a configuration option most commonly available. On the proxy configuration set the corresponding local IP:
for outgoing connection using IP .111, use proxy on 127.0.0.2
for outgoing connection using IP .110, use proxy on 127.0.0.1
.. and so on.
Make sure Squid (or WinGate) bind to localhost 127.0.0.1/24, so you shouldn't have big security concerns, but if this is exposed on internet you may want to proceed to security assessment anyway.
This way if you decide to offload some application remotely, to other server, you can still manage to use the same outgoing IP(s), you just need to change squid configuration to allow external connection, which could be a big plus for scaling.
It looks like you're searching for a fix involving little rework of the browser applications. Assuming that you're using IIS to serve the applications, you should:
Using File Explorer or command line, soft-link the application configuration in another root folder for each instance of the browser application.
Using IIS, recreate the application as a site for each of the above browser application folders.
Using IIS, bind each instance of the browser application to the IP address you wish to serve it with.
Caveat: It's tempting to use the same app pool for all instances, but evaluate your hardware before! Remember that (depending on the application requirements) you create a single point of failure when using a single app pool. Create separate app pools with identical parameters to reduce this risk.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.
Most proxy servers perform the job of forwarding data to an appropriate "real" server. However, I am in the process of designing a distributed system in which when the "proxy" receives a TCP/IP socket connection, the remote system actually connects with a real server which the proxy nominates. All subsequent data flows from remote to the real server.
So is it possible to "forward" the socket connection request so that the remote system connects with the real server?
(I am assuming for the moment that nothing further can be done with the remote system. Ie the proxy can't respond to the connection by sending the IP address of the actual server and the remote connections with that. )
This will be under vanilla Windows (not Server), so can't use cunning stuff like TCPCP.
I assume your "remote system" is the one that initiates connection attempts, i.e. client of the proxy.
If I get this right: when the "remote system" wants to connect somewhere, you want the "proxy server" to decide where the connection will really go ("real server"). When the decision is made, you don't want to involve the proxy server any further - the data of the connection should not pass the proxy, but go directly between the "remote system" and the "real server".
Problem is, if you want the connection to be truly direct, the "remote system" must know the IP address of of the "real server", and vice versa.
(I am assuming for the moment that nothing further can be done with
the remote system. Ie the proxy can't respond to the connection by
sending the IP address of the actual server and the remote connections
with that. )
Like I said, not possible. Why is it a problem to have the "proxy" send back the actual IP address?
Is it security - you want to make sure the connection really goes where the proxy wanted? If that's the case, you don't have an option - you have to compromise. Either the proxy forwards all the data, and it knows where the data is going, or let the client connect itself, but you don't have control where it connects.
Most networking problems can be solved as long as you have complete control over the entire network. Here, for instance, you could involve routers on the path between the "remote system" and the "real client", to make sure the connection is direct and that it goes where the proxy wanted. But this is complex, and probably not an option in practice (since you may not have control over those routers).
A compromise may be to have several "relay servers" distributed around the network that will forward the connections instead of having the actual proxy server forward them. When a proxy makes a decision, it finds the best (closest) relay server, tells it about the connection, then orders the client to connect to the relay server, which makes sure the connection goes where the proxy intended it to go.
There might be a way of doing this but you need to use a Windows driver to achieve it. I've not tried this when the connection comes from an IP other than localhost, but it might work.
Take a look at NetFilter SDK. There's a trial version which is fully functional up to 100000 TCP and UDP connections. The other possibility is to write a Windows driver yourself, but this is non-trivial.
http://www.netfiltersdk.com
Basically it works as follows:
1) You create a class which inherits from NF_EventHandler. In there you can provide your own implementation of methods like tcpConnectRequest to allow you to redirect TCP connections somewhere else.
2) You initialize the library with a call to nf_init. This provides the link between the driver and your proxy, as you provide an instance of your NF_EventHandler implementation to it.
There are also some example programs for you to see the redirection happening. For example, to redirect a connection on port 80 from process id 214 to 127.0.0.0:8081, you can run:
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
For your proxy, this would be used as follows:
1) Connect from your client application to the proxy.
2) The connection request is intercepted by NetFilterSDK (tcpConnectRequest) and the connection endpoint is modified to connect to the server the proxy chooses. This is the crucial bit because your connection is coming from outside and this is the part that may not work.
Sounds like routing problem, one layer lower than TCP/IP;
You're actually looking for ARP like proxy:
I'd say you need to manage ARP packets, chekcing the ARP requests:
CLIENT -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP
Then normal socket connection via TCP/IP from client to server.
I'm trying to see the results of an incoming ping on a target windows machine. This is needed to verify that the ping, which is running in a background thread, is being sent from the originator.
I have tried netstat to no avail. Are there any other approaches I could try?
Thanks.
Ping is an ICMP packet and doesn't create a TCP connection (hence you won't see it in netstat). On Linux, I'd add a rule to the firewall.
The most simple solution for your case might be to open a connection and close it. That will add it to the output of netstat with WAIT_CLOSE.
As Aaron Digulla already noted, ping is ICMP. This also means the originator even less trustable then with TCP; there's no SYN/ACK handshake. You just get an IP packet on your host, and you have to trust the header fields. Anyone can spoof those header fields, with almost no restrictions (It might be a bit challenging to get an IP claiming to come from 127.0.0.1 past a router)
Therefore, ICMP is not suitabel for verification tasks. You need a challenge/response protocol. TCP works reasoanbly well as long as you can trust the network but not necessarily all hosts on it (a reasonable assumption for the Internet. Not strong enough for financial transactions, which is why they use SSL)