Could anyone please explain if by default (firewall application) all users can access DMZ? Or only inside users? Also, if the users will be added to the access control list?
The most common form of a DMZ is a kind of "proxy" network between your intranet (LAN) where all your clients are connected to and the WAN. Imagine you have a network with some web servers, PCs like laptops or workstations, and some other servers or services with databases or similar. In front of your LAN, there´s a firewall creating the gateway to the WAN.
If everything is inside the same network you'll have security issues since, if one machine gets compromised, basically everything will be possible.
As long as you're communicating in the same subnet, let´s say a class C network of 192.168.0.0 (IP-Range from 192.168.0.1 - 192.168.0.254) the traffic will not be routed to your gateway which is usually your firewall. Meaning that every request you do from 192.168.0.2 to 192.168.0.3 will not be monitored and/or restricted by your firewall. This is an issue.
Web servers for instance have to be accessible from the outside. If an attacker gets access to the server he could mess with anything in your network.
Now you introduce a DMZ, basically a proxy network between your LAN and the WAN (at least in most cases). Since it's an own subnet the traffic will be routed through your gateway (firewall) so your rules apply. Also, to get into the intranet the data has to pass two firewalls (or twice the same firewall). You can now create firewall rules that will allow or disallow the communication from servers or clients and vice versa in the DMZ to your actual LAN. This way you can define that every communication into your LAN is denied by default and then you start adding rules to allow communication, for instance, if some service has to connect to a database in your LAN or similar.
Many networks only filter inbound traffic that way but in my opinion, you should also deny all outbound traffic until approved by a firewall rule.
Also, depending on the situation, often the clients are in the DMZ as well-meaning only critical infrastructure is in your actual intranet. In this case, commonly only administrative users will have "full" access to the intranet itself. Generally, it's a good idea to put the clients in a separate, restricted network since you'll often get to points where the clients are the biggest vulnerability for your network (Like users who like to open word documents clearly being some kind of fraud and similar)
Related
I am making a game in Libgdx where a user(client) will be a host of the server himself
and only one other client can connect to him and play with him(likewise there might be multiple independent servers and pair of clients playing with each other like miniclip games)
but how will the other client locate host-client (or servers) IP?
I am using kryonet
Some guy suggested me to do NAT punching and stuff but I am totally confused.
Please help
(I am complete beginner to networking)
If you want your clients to discover servers just in LAN, you can do broadcasting on the servers and sniffing on the clients. As they are in the same LAN, there should be no need for NAT.
Otherwise, you have to set up managers(servers for managing) on the Internet. Servers have to register themselves to a manager, clients ask a manager for servers information. As managers know both servers and clients public IP addresses, NAT should be easy once you think your managers as STUN servers.
The most simple manager can be just a simple wraper over database/Redis with a server name/server ip/server metadata table. Details about how to implement it relies on your skill stack. To enable STUN, there are open source STUN server and client you can just pick up, e.g. coturn. No matter you put the STUN server into your manager or not, both your managers and STUN servers have to be published on the Internet (sure include AWS) where they have their own public IP.
Or you can let the managers to relay messages for servers and clients. But this way may be too complicated compares to previous. I would not recommend.
I have a router os installed on a virtual server, with 3 interfaces:
lan-192.168.1.1/24
wan-192.168.2.1/24
wifi-192.168.3.1/24
I have a PPOE client to connect over WAN to ISP and get static public IP
x.x.x.x
I have a windows server with DNS, HTTP services on LAN interface, and 1 wireless access point on WIFI interface.
I have created rules for block incoming connection from internet, except 80,53,...
I have created dst-nat from my public IP x.x.x.x to local server IP.
Another dst-nat from LAN to server LAN IP address.
Also SRC NAT to masqurade, LAN and WIFI connections to server.
Another SRC-NAT masqurade for access internet.
Also mikrotik DNS service used to get records and catch from my local server DNS service.
All things work good, until, I want create hotspot service on WIFI interface.
dynamic firewall filters and NATs destroy all things work.
Scenario is access WIFI users to internet by authentication and access local server locally and free.
Also internet access for lan users free.
Also public web access to my server from internet.
Thanks in advance!
NOTE: Skip to TLDR if you just want the direct answer.
This configuration has been made far more complicated than necessary. I'm going to write this up from memory because I don't have an unused router handy at the moment, but this should work.
I'm going to make some assumptions here:
You do not want anyone from the WAN or PPPoE to be able to reach your LAN.
You don't want anyone from the WIFI to be able to reach your LAN except for HTTP or DNS.
You FULLY intend to circle back once everthing is working and ENABLE HTTPS on your server. THIS IS IMPORTANT!!!
First, set up everything to work without restriction. No rules except for a single masquerade entry. You want to masquerade all traffic NOT destined for 192.168.0.0/16. This rules is all you will need. the DST-NAT rules are unnecessary unless you want to provide service to traffic on the PPPoE interface.
Next, add the following firewall rules under the FORWARD chain:
ACCEPT all Established and all Related traffic (no other restrictions).
ACCEPT FROM 192.168.3.0/24 TO TCP 80,53,443 destined for your Windows Server IP address.
ACCEPT FROM 192.168.3.0/24 TO ICMP destined your Windows Server IP address.
ACCEPT FROM 192.168.1.0/24 TO !192.168.0.0/16. This allows Internet access for the LAN.
ACCEPT FROM 192.168.3.0/24 TO !192.168.0.0/16. This allows Internet access for the WIFI.
DROP everything else.
Make sure everything still works. These basic rules will give you at least some protection on your LAN from random people connecting to your WIFI. This way, if you ever disable your Hotspot to allow unrestricted access through your Wifi, you're LAN is still protected.
* TLDR *
Now you can set up your hotspot. The most important part is on your Walled Garden IP list tab, under IP -> Hotspot. You must add entries here allowing access to whatever servers you want to function before someone logs on, specifically your server's HTTP, DNS, etc services. The Hotspot will translate these into automatically-created firewall rules for you.
Finally, I would remiss if I didn't tell you that this is not a complete firewall setup, and there's all sorts of stuff that can go wrong here if things are not implemented properly. My email is in my profile here if you are interested in paid assistance.
I have an application that relies on IP addresses for communication (Domain names simply does not work. :(... )
Its function is to connect to its peer on the other machine and send data over after establishing trust. During the "trust establishing" phase they both exchange their IPs for future communication. They both are behind the two different firewalls and are NATted. One is in our NATted office network and other is in the cloud NATted behind their firewall. The applications knows their respective private IPs and exchange that (the 10.x.xxx.xxx range), when they try to connect back to each other (using the private IPs with range 10.x.xxx.xxx) for transferring data they fail. The connection is TCP and the port range is pretty varied.
I am curious if there is anyway I can hard code (for this one time) a rule (at may be firewall level or some place outside my application) that says if there is a connection being initiated for IP address 10.x.xxx.xxx then redirect it to 205.x.xxx.xxx?
Private IP address ranges like 10.x.y.z are, by their very nature, private.
You can't do any meaningful resolution unless each node in between the endpoints has rules in place to translate these.
Translation is tricky, all the main tools you would use cater for static translation (port forwarding, e.g. where a particular port is forwarded to a particular IP). This is one avenue, but it is a hacky one (it requires you to open lots of ports, procedurally update your router and probably have some sort of broker server to maintain mappings).
Alternatively, you could run the isolated networks over a VPN, which would give your endpoints mutual private IPs which you can use to connect to eachother. It would simply be a case of binding to this new address and communicating across the VPN. This would also potentially encrypt your communication over the internet.
Other possibilities are to use NAT/TCP punchthrough techniques which can allow traversal, but these are really a patch to a broken network topology (Read up on IPv6 to see how this can be alleviated).
Alternatively, you could route all the connections over a proxy, but this will complicate matters compared to a VPN.
To answer the question about hardcoding a rule, port forwarding is the solution here. It will obviously depend on your router configuration for the peer accepting the connection, but this client should have the port target port forwarded to the machine. This will obviously not scale very well and is really shifting to a server/client architecture for one connection!
Depending on your hardware, you may be able to forward a range of ports (if a single port cannot be established) and limit the port forwarding to certain incoming connections (the external IPs).
Information on port forwarding can be found at http://portforward.com/
This sounds a lot like what you'd want out of a VPN. Is there anyway that you could set one up? Basically the Site-To-Site VPN between you and the cloud would say 'oh hey, here is an ip located on the remote network, go ahead and connect through the link'. Would this kind of solution work in your case?
Something along these lines: http://i.msdn.microsoft.com/dynimg/IC589512.jpg
In short: How to reliably discover a server running somewhere on a (presumably multi-segmented) local area network with zero client configuration
My client application has to locate the server application without knowing the server IP address. It has to work on a local LAN that may be split into segments with hubs or other switching devices.
I already have a working solution, but it is a bit cumbersome to get it working on multi-segment networks. It works as follows:
When the client starts up, it sends UDP broadcasts on its own network segment. If the server is running on the same segment, it works without any issues - the server responds with the appropriate messages.
If the server and client are running on networks separated by a hub / switch that won't forward UDP (the most likely case), then I have a server instance running on each segment, and they forward client requests to each other via TCP - but I need to configure this for the server instances (simple, but still a pain for tech support.) This is the main problem that I need to address. There are sites where we have hundreds of clients running on 5 or 6 separate segments.
The problems I'm facing:
1. Although my application installer enables the appropriate ports on the firewall, sometimes I come across situations where this doesn't seem to happen correctly.
2. Having to run multiple server instances (and therefore configure and maintain them) on hub/switched networks that won't forward UDP
Finally I need a solution that will work without maintenance on a minimal Windows network (XP / 2000 / Vista) that probably doesn't have Active Directory or other lookup services configured.
I don't want to tag on any runtime stuff for this - should be able to do it with plain VC++ or Delphi.
What approaches do commercial apps usually take? I know that SQL Server uses a combination of broadcast and NetBEUI calls (I may be wrong about this).
Thanks in advance.
You have a few terminology issues:
Where you say "network segment" you appear to mean "IP subnet". Devices on the same network segment can see the same IP broadcasts.
Where you say "hub/switch" you appear mean "IP router".
Where you say "won't forward UDP", the problem is actually "won't forward IP broadcasts".
Once we get past that, you have a few options:
Your servers could register themselves under a well-known name in DNS, if you have a DNS server that allows dynamic DNS updates. You should probably use a SRV record as specified in RFC2782. The clients then do a DNS lookup to find the server(s).
You could statically assign your server(s) well-known names in the organisation's DNS, perhaps with a SRV record as with the previous option.
Your servers could join an IP multicast group, if your routers support IP multicast. The clients then send their initial discovery request as a UDP packet to the (pre-ordained) multicast address.
If you have domain server, I would go with small service on it. You can connect with other services to it and use it as distribution point.
Why domain server? It is relatively easy to find it's name (DsGetDcName).
Other choices would include DHCP server, DNS server or something of that kind that needs to be filled by maintenance staff anyhow.
I was wondering that how application like skype ( a popular chat client ) works in local network with one router, How it can listen on particular port?
for example:=
In one network A and B are two machines running skype , gateway of both is G1,
now how A and B will have same IP on internet that is of G1, but how can they ensure that they are listening on different ports? How can they ask to router G1 for unique port.
I want to make a simple text chat server on linux. How can I have connections between two different computers in two different networks?
Solution to your problem is to have a forwarding server somewhere in the net.
Different programs use different means to connect to each other. But every chat server, including Skype, has a server, which forwards data or information about subnet IP/port availability.
There are two types of clients: "listening" clients and "passive" ones. Listening clients have direct access to Internet via router port forwarding, and "passive" ones have to use additional tricks to get their hands on external data, line external servers or additional ports to listen.
The point is, not clients connect to each other, but they connect to a server, which then connects back to them to verify they are available, and, if at least one of them is not firewalled, direct another on to connect to the first one, excludint itself from further communication. And if both are firewalled, then is has to forward their messages through itself.
Host Discovery
Manual discovery, client A knowns who client B is
Discovery through broadcast UDP which is used by lot of games for LAN play. A client sends out a packet to the broadcast address for their subnet. The peers can choose to pick up this broadcast and respond. The downside is that this is limited to the current subnet. The more general INADDR_BROADCAST (255.255.255.255) works for all subnets on the local-link, but it cannot be routed, so won't work over internet (this is what DHCP auto-configuration uses).
Discovery through a central (Rendezvous) server. Each individual client knows the address of the server, and the latter informs them about each other. This technique is used by IRC, Voip, IMs and by most 'peer-to-peer' networks.
Communication
After the initial discovery is done you want to be able to talk to eachother. On the internet this can get tricky. Most people nowadays have their own router and sit behind a NAT, so direct connections are impossible.
Using a Rendezvous server, you can possibly talk to each other using the server itself. client A tells the server what to say, and it in turn tells client B, since both clients have an outbound connection to the server.
It is possible for the clients to talk to each other without the server proxying. This requires either DMZ, port forwarding or UPnP. DMZ will basically forward all incoming connections on all the ports to a given local IP. Port forwarding only forwards certain ports to local IPs. UPnP is a bit more advanced, the client requests that the router temporarily forwards a port to it, and you tell the other client via the rendezvous server where to connect.
Chatting app implementation
The easiest solution to your problem is most likely to use a central server, which is known by all the clients, that proxies host discovery and possibly the communication between the clients. If you want the clients to communicate directly, you can just proxy host discovery, and then let either DMz, manual port forwarding or UPnP do the rest.
Another solution would be to just have direct communication through NAT traversal techniques discussed above, and do manual host discovery.
Yet another solution would be to use a public webserver and 'abuse' its ability to insert content to chat with each other.
You need a central UDP Rendezvous Server.
After the initial connection from the client to the server the UDP clients can be redirected to talk to eachother directly even if firewalled.
The trick is to open an UDP connection from the inside.
Check out Real-Time Media Flow Protocol and how they use it.
Check out UDP Hole Punching
alt text http://labs.adobe.com/technologies/stratus/images/p2pvideo_250x215.jpg
Traditional NAT servers replace the source address and port with the address and a random port number of the external interface of the NAT server. This works well for simple protocols such as HTTP and SMTP, but it can create problems for more complex protocols that require multiple response ports on the external interface of the NAT server. NAT servers also aren’t aware of information stored in the data portion of the application layer header without the help of NAT editors and similar software fixes.
Windows XP’s answer to these problems is NAT Traversal, which can automatically allow the UPnP-enabled NAT client application to communicate with a UPnP NAT device. NAT Traversal provides methods to allow the UPnP client to learn the public IP address of the NAT server and to negotiate dynamically assigned port mappings for UPnP NAT client applications.
NAT Traversal features can be built into any hardware device or software application. Applications that commonly cause troubles for NAT devices but work well when UPnP-enabled include the following:
Multiplayer Internet games
Audio and video communications
Terminal Services clients and servers
Peer-to-peer file sharing applications
When these applications are UPnP-enabled, access through the Windows XP ICS allows them to work seamlessly.
Unless A and B are actually "listening" to the responses to outgoing requests, your router will need to be cofigured to forward the relevant port numbers to the relevant hosts. This isn't something that you can request in the code, it's something you need to configure on the router itself.