I'm having trouble really assessing whether or not I'm exposing our internal servers in a very unsecure and obvious way.
I have 2 domains, one internal and one external (dmz) on the firewall. I need information from the internal, and we don't want to start a migration thing, or open up ports directly to the internal server. I'm unable to connect from DMZ to internal, but the other way works fine.
I created a web api service on the dmz, which has a static TcpListener, and accepts only one connection.
I then created a simple console application on the internal server, connecting to this web api TcpListener. It holds on to the connection, and I'm able to send commands via rest-api calls to the dmz server, and send back Json data from the internal server, thus obtaining the bilateral connection I needed.
What I'm wondering is, whether this will pose a serious threat to our security? I don't know enough about network security to be able to say, but the TcpListener only has that one connection, and it's only open long enough for me to occupy this connection.
Can anyone give me a clue as to how (in)secure this solution is?
The server is in DMZ, so anyone can connect to your TcpListener. A port scan will reveal this listening socket. You need to apply authentication (client certificate / IP whitelist / basic / digest / ...).
Related
I'm having a windows application that will be deployed on multiple pcs in different networks. This applications need to launch some actions upon receiving appropriate request from external service.
For this, I got HttpListener that waits for requests and performs required actions.
The issue is with NAT and security. When windows application starts it needs to tell external service that it's alive and how it can be reached (being behind NAT it's not as trivial, some kind of tunneling is needed?). When external service needs something to be executed on windows application, it sends it a request and application should proceed with actions and send response to the server.
What is the best way to expose my Windows Application behind NAT to external service (tunneling?) and how to make it secure (HTTPS?)? Or, maybe, there is a better solution for this kind of remote calls (RPC?)?
Sending http requests to clients behind NAT means, that you have to manually create a route in your NAT router for each client that forwards a port on the external IP to a fixed internal IP.
To make it secure, you have two options:
Use TLS (https) = each client needs a cert and accept https
Leave the requests insecure but keep them in a "secure environment". This could be done with an VPN connection between your server and the NAT network (while defining the local network as secure).
Such a setup works fine if you want to run a server application (one host) and are willing to invest some time. It will typically shorten your life if you want to do that with a large amount of client applications in a company network.
There are technologies available to send messages to clients without having to configure anything on routers. For .Net we have SignalR which combines multiple approaches and uses "the best possible": https://dotnet.microsoft.com/apps/aspnet/signalr
When I send data using socket in C# on LAN, everything works fine, but how do I send my data over the internet. How to send while the sever I create uses the ip from my compute (private ip)
Can someone suggest on how can I achieve this, basically I should be able to send data anywhere over the internet, not just on LAN.
These days most computers have a router with a firewall between them. Routers, via secreuity design, stop direct access to the computers behind them and their local network.
Yes you will either have to
configure the router to map through a specific port to one of your computers.
Or, the more common way to do this is using a central hub, ie a Web service as an intermediary. This way no firewall are needed as both computers are only connecting one way (out). You could use a wcf service or Web api or many technologies to achieve this and usually you'd use a database to store you game state which makes it persistent
Please actually read my post before placing it on hold!!
Let me start by saying I've been searching for a solution all afternoon and so far I have seen plenty of examples for WCF but none that would do what I need.
I have developed an application in c# that will be installed on customer servers and accesses a sql server on the customer's local network. The application also has the ability to control network relays on the customer's local network and records the status of these in sql. I am trying to figure out a way to have the customer's server establish a connection to our datacenter and be able to issue commands back to the customer's server (retrieve datasets from sql, control the network relays, etc). I have found plenty of ways to have a client call classes on a server but have so far been unsuccessful in finding the reverse. One consideration was writing a web service as part of the application on the customer's server but need a way to establish this connection for customers with dynamic IP addresses and without having to publish through firewalls, etc.
Have you considered using
VPN - Virtual private network
or
Configuring a Port Forwarding redirect on the ADSL modem, and using a solution like www.noip.com ?
If I understand correctly you want to get information from the customer's database, which is behind a firewall and has no known static ip, in addition there might be several hundred customers so a dedicated VPN to the customer is not viable.
First of all: you should not contact the customer database directly. Databases are not designed for this scenario and would probably be left open to attack if exposed directly to the internet.
So you need a service on top of the database. There are two main options you can use for this service:
Polling service
The service is actually a client calling some web service on your network and asking for instructions.
Benefits: easy to implement and deploy.
Downsides: With polling there is always the cost-benefit of scalability/bandwidth use vs. speed of service. There are also some considerations in selecting the time to poll to prevent all the client polling at the same time.
The service is a tcp-server
This can be a usual web service (or RESTfull service) or some other service. The only difference is that it needs to advertise itself. For that you need to have a known directory server. When the service starts it then connects to the directory service and tells it the port it can be contacted on (the directory knows the ip from the connection). It will then need to periodically contact the directory to let it know it is still alive and so any change in IP is detected.
A client on your network would now query the directory to find the address of the client and connect directly to it to issue commands.
Benefit: Scalable and bandwidth efficient.
Downside: More difficult to implement. Requires firewall traversal solutions (UPNP or firewall exceptions).
I am developing a LAN-based database application. It involves a central "server" app to house the database, along with many "client" applications that access it.
The "server" will be a simple C#-based HTTP server that responds to GET and POST requests. However, since it is designed to be able to run from any laptop on the network, I am wondering how to establish the connection between clients and the server without knowing the IP address.
I suppose I could ping every IP address from 192.168.0.0 to 192.168.0.255, and then test those that responded to see if any are my server. But I would only do that if there is no better way. Any suggestions?
Many of these types of discovery services run by putting out some kind of beacon on either the subnet broadcast address (for 192.168.0.0/24 it would be 192.168.0.255) or by putting out a beacon on a multicast address.
Multicast is particularly interesting because in a properly configured network, it allows hosts to find the service even across subnets. Routers and switches won't generally forward broadcast packets across subnet boundaries, but multicast packets will.
The beacon would have information in it such as the port the service is running on, what type of service it is, whatever is needed to start using the service.
To head you in the right direction, what you should do is have the database server running on a specified port. Then send out a broadcast to that port from the client (the system needing to connect to the database). When the database server receives this, it will be able to respond to the sender, allowing a handshake to occur.
Of course, you will need to validate the database server's authenticity (to make it secure, unless you aren't worried about that). This can be as simple as having the client display 4 numbers which then need to be typed into the database, so that the database can send the 4 numbers back to the client proving it is the right computer (how the iTunes remote works), or you can use certificates (but that is too complex a topic for me to cover correctly).
After that the two computers will know each others IPs, and you're set!
What do I use for two way communication over the internet without the necessity to open ports on the client side?
Users won't agree to open ports and do port forwarding on the client side although everything is possible on the server side.
But,I need to accomplish two way communication..
How do I go about achieving this?
It doesn't matter whether its WCF or remoting or webservices...
I just need a quick and fast way to just get the concept to work out and distribute the application.
ofcourse,it's going to be through the internet.
Please help..
Thanks
Edit : Please note that i need to connect multiple clients and maintain a session for each client.
WCF supports duplex HTTP bindings.
As long as the initiating client can access the service, a callback contract can be defined to call the client. It simply keeps the HTTP connection once the client has initiated it.
It depends what you want to do. Duplex WCF can work, but through NAT and Proxies it becomes somewhat "iffy" because it depends on the client opening a WCF endpoint and maintaining the connection.
I wrote a beginners guide to WCF callbacks a while ago - it's simple enough to do, but you'll need to test it a lot, from various client setups.
Connect via TCP (raw sockets, or higher implementation) to a your central server.
Your server should have an application that listens to a specific, well known, TCP port.
Each client connects to your server, using the specific port, and "logs in".
Write an application protocol above the TCP (authentication, session management, etc.), and there you have it, since a TCP connection, once established, works for both directions.