I want to make a really secure environment for a Linux computer. Essentially I will direct connect to the hardware with keyboard and screen only, there is no need to have any SSH etc. so all servers will be stopped, UFW will block all inbound ports.
Re outbound ports, there is one client service for arguments sake 'foo-serviced' that will need to connect to some other servers on my LAN, its a client that gets a system allocated outbound port. If possible I would like to block all outgoing traffic too, except for that foo-serviced connection. Is there a way to manage system allocated ports so I can allow that port, or is there a way to allow specific clients access?
After further research I realised that I can block all outbound and then use the port of the destination server to allow the outbound access.
Related
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 know that ipchicken.com will tell you your router's ip address and the port it is using for your connection. But can this information be obtained "locally"? (Without relying on a website).
What I want it for is establishing a connection between two random hosts...without a "dedicated server" in the middle. My problem is to reach through the NAT. I think the best bet is a kind of TCP hole punching, where both hosts connect somewhere and then just tell each other (it can be by phone or chat or similar) the current ip address and the port number their routers are using. It should trick the routers into forwarding the packets to the hosts, albeit coming from a different source than they originally connected to.
Is it possible to find the port number your router is using to patch you through in a more local manner than ipchicken.com?
Are there any ideas on other possible approaches to this problem?
EDIT: Setting port forwarding on the router is not an option in this case, as many people (including me) do not have admin powers over their routers and I do not want to impose such a task on the "users" of my application
The router would use a different source port for every outgoing connection, so checking based on an outgoing connection will not work for your use case.
For an incoming connection, i.e., if you want to reach a specific machine behind a NAT device (like a home router), you'll have to explicitly open up some ports on the router and set up forwarding rules. The router would then listen for incoming connections on that port and forward it to a machine:port based on the configured rule.
How you do this would depend on the specific router make/model. Search the web or logon to the admin interface and look around, it should be easy to find. However make sure you understand the security implications of opening up a port on your router!
UPDATE based on edited question:
Without port-forwarding and if both devices are behind NAT, your only solution is to have an intermediary server! If only one of them is behind NAT, you can have that machine initiate the connection.
You could use a Stun server as the external globally reachable server.
I've been investigating networking for use in a two-player game I'm writing, and I'm still not clear on when a device must have a port forwarded in order to communicate with the outside world.
From what I've seen in other games, port forwarding is always required in order to host a server, but is not required on the client. In addition, there are other situations, such as skype (which, to my understanding is ultimately client to client), where neither end must forward a port.
So my question is, in over-the-Internet communication, when is and isn't port forwarding necessary, and what steps can i take as a developer to make it so my users don't have to worry about it? Thanks in advance!
Port forwarding is needed when a machine on the Internet needs to initiate a connection to a machine that's behind a firewall or NAT router. If the connection is initiated by the machine behind the firewall, the firewall/router automatically recognizes the reply traffic and sends it to the machine that opened the connection.
But if a packet arrives on the external interface, and it's not a part of such a connection, the router needs to know what to do with it. By default, it will reject it. But if forwarding is configured for the port, that tells it what internal machine to send it to.
Put another way: you need port forwarding if you want to run a server behind the NAT firewall/router, you don't need it if you're just running a client.
There is reason why Skype don't (not always) need manual setting of port forwarding:
When you install Skype, a port above 1024 is chosen at random as the
port for incoming connections. You can configure Skype to use a
different port for incoming connections if you wish, but if you do,
you must open the alternative port manually.
If the port chosen for incoming connections becomes unavailable, by
default ports 80 and 443 will be used as alternatives. If another
application (such as Apache HTTP server or IIS) uses these ports, you
can either configure the application to use other ports, or you can
configure Skype to not use these ports.
Port forwarding is must if you host a server.
You can use same technique as Skype...
I am not sure if there is any other option...
Port forwarding (occurs) when a NAT, firewall or some other device blocks communication on all or some ports.
To answer your question as an example, most commercial routers use NAT to allow multiple people to use the same IP(As view from the outside world) provided by ISPs. Most ISP's use NAT to allow multiple customers to use the same IP(As viewed from the outside world). To get this to work, the NAT changes the internal IP and the port number of a communication to THE(there is only one for the entire sub network) external IP and a new port number. By doing this, the router/isp/ect can tell which internal IP and port each external communication goes to.
Anytime one of the computers communicating over the internet are behind a NAT, port forwarding is required. I'm sure there are way more situations than this, and the solution to each can be quite complicated. But this covers the vast majority.
I did a test of NFS service over Cisco ASA 5505 firewall.
With normal interface default ACL, which is "permit ip any any" on inside interface (Level 100), "deny ip any any" on outside interface (level 0). NFS server is connected to outside interface. Everything works great. By look at the the packets go through, I can see inside PC call NFS server's 111 port, negotiate a port using portmap. Finished this TCP connection. Then NFS server (outside PC) use the negotiated port to connect to inside PC and transfers data. Cisco ASA firewall keep TCP states very well and "remembered" the negotiated port, thus let outside PC using this port to talk to inside PC even the outside ACL is "deny ip any any". The firewall is fully stateful, every thing is great so far.
However, as long as I connected the NFS server (outside PC) to Cisco ASA firewall using VPN. Everything changed. By look at the packets, NFS can still go through firewall and negotiate a port by portmap. While after this TCP session is over. Firewall FORGET the negotiated port and block the outside PC using negotiated port to talk back to inside PC.
With or without VPN is the only change. There is just one ACL, on inside interface, permit ip any any. The NFS server is set to can be access from any subnet. There is no NAT and no service-policies setup on this firewall.
Can anyone please explain why Cisco Firewall rules is not "stateful" anymore over VPN? Is it designed to be? What is the best way to let NFS working over VPN without open a range of dynamical ports on outside interface?
One of the strong sides on NFSv4.0 is firewall friendly. No port map required. You need only single TCP port 2049 to be opened. All operations which have have a state on the server require client to send a heard bit, which is typically ~ 90 seconds. We you is in your firewalled setup and quite happy with it.
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.