On Tuesday 26 September 2006 9:04 pm, Darryl Gregorash wrote:
On 25/09/06 17:53, Paul Abrahams wrote:
I want to configure the SuSE firewall so that communication within my LAN is uninhibited but communication outside the LAN is fully protected. Looking at the firewall configuration in Yast, I see that the external zone is protected but the internal zone is not. However, I don't see how to specify that the internal zone consists of hosts with addresses 192.168.0.x. This would seem to be a pretty common requirement.
It appears that the firewall configurator can specify that an interface is external or internal, but I have only one interface (network card). It connects to the LAN and to the router; the router in turn talks to the world. It's a very common setup.
The net of the internal zone is determined by the configuration of whatever device is specified in FW_DEVICE_INT, ie. the firewall script determines this information for you. (In fact, you will note that the net/mask of any network device is determined by the firewall script.)
Specifically, FW_DEVICE_INT, as the name suggests, specifies a device rather than a range of IP addresses.
However, based on your other posts (2 others thus far), I suspect you will be best served by defining your devices to be in the external zone,
Yes. I realized early on that since the internal zone is in general unprotected, I couldn't get protection from the outside world by using it. In fact, it seems that with only one interface (network card), turning off the firewall is pretty much equivalent to declaring that interface to be internal.
and defining your LAN net/mask in the FW_TRUSTED_NETS variable, ie. FW_TRUSTED_NETS="192.168.0.0/24" (you will have to change this if you ever change the net on the router).
That is the critical hint. There's no way to do this setting through Yast as far as I can tell, though there ought to be. I hadn't realized until you pointed it out that there are a number of firewall-related settings in /etc/sysconfig and many of these are not manipulable through Yast.
At this point, you should check to see that your Samba networking is functioning properly (it should be, and if it is not, verify that the router is not blocking the traffic before making any further changes on any workstation). If you have any NFS or CUPS functionality within the LAN, it should also be tested. Again, if the services are properly configured but do not work, check the router first.
After diddling FW_TRUSTED_NETS, Samba became available just as you said it should. A simple way to see what the router is blocking is to turn off the firewall; anything that's still inaccessible is inaccessible because of the router. The FW_TRUSTED_NETS variable also accepts a list of services, which I didn't provide. Samba worked anyway.
Note that anything defined in TRUSTED_NETS will have access controlled only by the config files of the services you are running. This is no substitute for proper security in those config files themselves, and should not be treated as such. If, for example, you do not want anyone outside your network to be able to access a CUPS server, then not only should you block these at the router, but you should also configure cupsd to reject any connections originating outside your network.
If the outside connections are not listed in FW_TRUSTED_NETS, I'd think that the outsiders would be blocked from cupsd on that account.
If you are running any services that should be accessible from anywhere on the internet, these may now be allowed using either the FW_SERVICES_EXT_* or FW_SERVICES_ACCEPT_EXT variables (use the latter one for services for which you also wish to restrict access by IP or net/mask). Of course, the router must also be configured to forward the appropriate ports to the appropriate system. Note that any services opened using the SERVICES_EXT_* variables will be allowed for any source IP, anywhere on the internet. Again, what you do here is not a substitute for proper configuration of the services themselves.
It appears to me that including an IP address in the FW_TRUSTED-NETS range effectively moves it from the external zone to the internal zone. Is that correct? If so, then the answer to my original question is pretty simple: assign the network card to the external zone and set FW_TRUSTED_NETS to 192.168.0.1/255. Then machines on the LAN have full access to each other and machines outside the net have none, other than what is explicitly allowed. I'm surprised that the question I asked about allowing full access within a LAN and restricted access outside it hasn't come up more often, since that situation describes the typical home/small office configuration with several machines hooked into a basic (D-Link, Linksys, Netgear) router that is in turn connected to a broadband ISP via either a cable modem or a DSL modem. I did find a couple of other people asking that question on linuxquestions.org, but no clear answers there. Thanks for an excellent and most informative post. Paul