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 internal zone can be as protected as you want it to be; just set FW_PROTECT_FROM_INT to "yes", restart the firewall, and run iptables-save to see exactly what has happened with the input_int filter. If you do this, then only those services explicitly stated in
On 25/09/06 17:53, Paul Abrahams wrote: the FW_SERVICES_INT_* or FW_TRUSTED_NETS variables will be allowed. Note also that, no matter what you do with the firewall configuration (internal OR external zones), there is still only one output rule for traffic originating on "this" machine, and that is to accept everything (masquerading isn't relevant to this discussion, because only your router is doing this task). The SuSEfirewall basically gives you no more control over outbound traffic than your router. If you need more control than you currently have, you should look into obtaining a newer router, one that has a stateful firewall. 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.) 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, 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). 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. 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 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.