this is my first post so...
I'm quite new to networking, I just started transferring data over TCP and everything is working fine. I am hosting a small chat server (Made in Autoit v3) on my own network, but what bothers me is that all the clients could simply track the ip on which the server is hosted...
As I don't want to be 'hacked' I would like to know if there is a way to hide the ip on which the server is hosted. Maybe routing it through another network if that is possible.. As I said I have pretty much 0 experience with networking, I can port forward and setup a simple server but that is pretty much it :)
Thanks everyone!
When you are opening up any service to the world, you should secure via IPsec or TLS/SSL like services, further more you should open only those ports on the IP which is required by that service.
example: a.b.c.d:8080 for HTTP so instead have it on HTTPS(port 443) that means a.b.c.d:443. HTTPS requires TLS/SSL certificate and you can get them from here.
For your service TLS/SSL should suffice the needs because it works over transport layer.
Related
I'm wondering how L2TP works internally to provide transparent IP connectivity.
I understand that L2TP tunnels IP packets via UDP port 1721. However I don't see how this provides transparent access. For example let's say I have a VPN connection and my browser connects to google.com. It would normally make a TCP connection to google's IP address over port 80. However something has to intercept this request and route it through L2TP's mechanism.
In the Security Now podcast they did a 4 part series VPNs is great detail. The best part is that there are transcripts online so you don't have to listen to the whole thing if you know what to search for. here's a link to the main page http://www.grc.com/vpn/vpn.htm
A broad question.
We have a client application that currently talks to a web service to exchange data between two clients. The first client stores data on the service and other clients poll the service to collect it at some later time.
We are looking to change this infrastructure a little in that clients will Connect() to the service supplying the IP and Port that they will 'speak' on. When client A wishes to send data to client B it will look up client B's IP and port on the service and then send the data directly to that IP and port.
In the situation where several clients exist behind a common firewall (and NAT), my gut instinct is that I would need to configure port forwarding for each client so that inbound messages at the public IP (ie public side of firewall) can be routed to the appropriate client. As our application is designed to shield 'techy' details we'd like to avoid this it all possible. One caveat is that we are quite happy for the client to have to open a port on the firewall, but to avoid the extra step of setting up port forwarding.
Hope this makes sense, and please feel free to ask for any clarification.
-- Edit --
We are aware of UPnP but it is a non-starter for us due to the fact that it is either not available on some routers and the fact that some corporate environments don't allow it.
Thanks,
Simon
Most home routers provide a UPnP interface to allow applications to set up port forwarding without requiring the user to do anything. Depending on the router model, they may need to enable it on the router, usually a checkbox in some buried config screen.
The project I am working on is a client/server architecture. In a LAN environment, I want the client's to be able to automatically determine the server's address. I want to avoid having to manually configure each client with the ip address of the server. What is the best way to do this? Some alternatives I have thought about doing are:
The server could listen for
broadcast packets from the clients.
The message from the client would be
a request for the IP address of the
server. The server would respond with its address.
The machine running my project's server could also have a
bind server running. The LAN's router could
be configured to use it as one of its
DNS servers.
I think I saw that
there is a bind library. Does that
mean I can build the bind service
into my server so that bind doesn't
have to be installed on the server?
Any other ideas? What have you done in the past? What are the pros/cons of these approaches and others that might be suggested?
Thanks for your help!
I like number one, that seems shortest and simplest to me. Might get tricky if the "LAN" actually involves switches that you can't broadcast through. Multicasting should help, then.
You can also use DNS, as in Zeroconf. See Bonjour for information about an implementation.
You can use WCF 4.0's new Discovery feature. Two things are possible:
The server can announce to the network that he has gone up or down, and clients can connect to it or look elsewhere, respectively.
The client broadcast an inquiry for a service and all matching services on the network will reply. The client can then pick the service he wishes to use.
You can use either or both, and it's all handled by WCF, so there's little work to actually use it. You can even set up WCF proxies if you have a restrictive network topology (such as NAT or other routing issues). The proxies can cross/convert protocols and even have custom load-balancing or other routing logic.
http://msdn.microsoft.com/en-us/library/dd456782.aspx
I'm using Java to create a client/server application that communicates using TCP. The network that the client is running on has an outbound firewall that prevents the client from connecting to the server. Is there any way/workaround to create a TCP connection through this firewall?
I have tried to use common ports that are open such as port 80, 443, and 113, however the firewall appears to drop the connection once it is made (possibly by detecting non-protocol packets).
An alternative would be to have the client software run as a Java applet hosted from an external website, however I'm not sure if the outbound firewall would still be able to block this connection.
Any help would be greatly appreciated.
Assuming that the users have internet access, and you can't telnet through port 80/443, it probably mean that the users connect through an HTTP Proxy configured in the browser.
You could try to research on various tunneling methods via an HTTP Proxy... Though, that will be a very unstable hack.
I recommend contacting the system administrator, explaining your needs, and see what he/she suggests.
You can try to communicate using http or https. By tunneling your protocol over these, it might be possible that the firewall lets your traffic through.
We meet a testing scenario which needs to tamper with source IP address of a Http request to simulate clients coming from different countries. Do you know any tool help on this?
Last but not least, our web site is built with ASP.NET.
Thanks.
In a test environment it usually isn't difficult. First read this SO question about virtual network interfaces.
If the server and client are on the same machine, all you have to do is figure out how to get your client software to bind to your virtual interface.
wget for instance has the --bind-address option to specify which local address to bind to. Web browsers are a bit more difficult to do this with; you may need to just run it in a VM.
If your server and client are on the same LAN, you just need to configure your router with some static routes to your client machine. In this case you probably don't need a virtual network interface, just set a static IP for your client machine; as long as the gateway is set up correctly it should be able to send packets to the server, and as long as the route is set up correctly the replies should find their way back to the client.
If the client and server are separated by an internet, it's rather more difficult. One option is to set up a network tunnel endpoint on the server and tunnel it to the client machine, which "knows" that it has the virtual network interface.
As noted in answers to the ServerFault question "Are IP addresses trivial to forge", you cannot easily forge source addresses in a protocol that required two way communication (e.g. TCP). Note that this "two way communication" is required at the packet level. You cannot just say "no problem, I want to send requests and ignore HTTP responses." To establish a TCP session, you need to receive data. Your best bet is to use a proxy server.
I am unsure if the IP standard allows for this, but if you are working in a Lab environment, where you don't need internet connectivity during the test, I can see it working under following circumstances:
Basically, I would set the server's network interface to use netmask 0.0.0.0 and flush the rest of the routing table.
Then you could configure a client machine to take on any IP address as long as you use netmask 0.0.0.0. And two-way communication should be possible.
Server[1.2.3.4/0] <---> Client[x.x.x.x/0]
But please bear with me. I haven't tested this, so I could be wrong :-)
If you have access to your infrastructure, you can add an interface off the router and then place a static route on the router to that network.
Server-----Router----Internet
/
Test_PC----/
Alternatively you can look into PBR (Policy Based Routing) and on the routers you can flag source packets and change the source on the fly, so your server will think they are coming from where you'd like them to come from.
Server-------------Router_with_PBR-------------Internet----- PC
SCR:4.2.2.2 Change SCR:6.6.6.6 to 4.2.2.2 6.6.6.6
But you have to ask yourself why do you want to see when packets come from different countries. Some countries have massive proxy servers that filter access ( "Great Firewall of China"), so the above tests will not prove much.
Your best bet then is using proxy servers or if your looking for a long term solution then setup a server (virtual is great for this) and use RDP for testing. I'm sure you can rent a virtual server somewhere for a month or two.
That's not possible. Because when you forge the ip address, the response is never going to come back, which is required for http.
The best way is to use proxies. See also this question on serverfault.
If you change your source IP address, that means no traffic from your web server will be able to reach back to the client.
You might be able to use some kind of proxy and/or address translation filter to do the remapping while still allowing two-way communication.