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. Paul
Mon, 25 Sep 2006, by abrahams@acm.org:
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.
Please be more specific about your setup. Do you have a network-card with an alias IP address or something?
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.
Perhaps, but that doesn't make it the best setup. Having your LAN systems on the same segment and IP range as the "firewall" means that there's nothing between the Internet and the 'other' systems, except the router's rules for port-forwarding etc. If you want to have a better protection I'd look for a "real" router, that can be configured for multiple LAN IP ranges, or setup the Linux machine as such. . Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
On Tuesday 26 September 2006 5:01 pm, Theo v. Werkhoven wrote:
Mon, 25 Sep 2006, by abrahams@acm.org:
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.
Please be more specific about your setup. Do you have a network-card with an alias IP address or something?
My network card is assigned its IP address by the router using DHCP. Incoming traffic is processed using Network Address Translation. I have several Linux machines with this setup, each cabled to the router.
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.
I should have phrased this better. The network card is cabled to the router, which on its external side is cabled to a broadband modem.
Perhaps, but that doesn't make it the best setup. Having your LAN systems on the same segment and IP range as the "firewall" means that there's nothing between the Internet and the 'other' systems, except the router's rules for port-forwarding etc.
The router (a standard D-Link 4-porter) has an internal net address of 192.168.0.1 and assigns the computers on the LAN addresses of the form 192.168.0.x. Seen externally, it has an IP address assigned by Comcast, my broadband provider, also using DHCP, which Comcast requires. All the systems on the LAN are supposed to have the same firewall protection, using SuSE firewall (or in some cases the Windows firewall). So each machine has two levels of protection: the router, which itself provides pretty good protection, and the firewall on the individual machine. The main weakness of the router firewall is that it doesn't filter outgoing packets, only incoming ones.
If you want to have a better protection I'd look for a "real" router, that can be configured for multiple LAN IP ranges, or setup the Linux machine as such.
I'd settle for any degree of protection as long as I can share files with other machines on the LAN. Sharing could be either with NFS or with Samba. Thanks for your help. Paul
One other question that may help me get this set up. If I try to access a Samba share I get the message "Unable to find any workgroups in your local area". If I disable the firewall I don't get that message and can see the workgroups, so clearly the firewall is blocking access. What service should I turn on (in the Yast firewall section) to be able to see the workgroups? Paul
Paul Abrahams wrote:
One other question that may help me get this set up. If I try to access a Samba share I get the message "Unable to find any workgroups in your local area". If I disable the firewall I don't get that message and can see the workgroups, so clearly the firewall is blocking access. What service should I turn on (in the Yast firewall section) to be able to see the workgroups?
tcp 139, udp 137 and 138. If you use Yast to configure your firewall, check /etc/services to translate this to the service name, since this is what shows up in Yast. I find it easier to remember the port numbers. And by the way, since you only have one NIC, it should be set for Ext zone, so these would be allowed there. Internet vs LAN settings can only be set on your router, which is the only device to "see" both. -- Joe Morris Registered Linux user 231871
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.
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
On 26/09/06 21:59, Paul Abrahams wrote:
<snip>
Specifically, FW_DEVICE_INT, as the name suggests, specifies a device rather than a range of IP addresses.
Correct, and certainly if you are configuring a network with only one subnet in it, you don't need anything more than this.
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.
I see you bypassed where I said the internal zone device can be as protected as you want it to be: turn on the "protect from int" variable and see what happens.
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.
Well, I don't think there is a way to do this in the security/firewall section, but there sure is a way to do all of this in system/sysconfig editor. It's under network/firewall, I believe. This definitely points to what might be regarded as a deficiency in Yast: surely the entire firewall should be configurable from that security section.
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.
Read the blurb again: the only thing that is required is the network (either a single IP, or a net/mask). The protocol/port stuff is only necessary if you want to restrict an IP/IP range to a specific service, eg: 192.168.1.0/24,tcp,21 means that 192.168.1.* can only connect to the system via ssh, but 192.168.0.0/24 means 192.168.0.* can connect to any service (tcp or udp) that the system offers.
<snip> This is no substitute for proper security in those config files themselves, and should not be treated as such. <snip>
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.
I say again, this is no substitute for proper security in the config files -- what are you going to do if your firewalls are hacked? What are you going to do if an IP you thought to be trusted is spoofed?
<snip> 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?
Not at all, eg. you could allow anyone anywhere on the internet to connect to your IRC server by including this in your trusted-nets: 0/0,tcp,6667 (assuming, of course, that you forward port 6667 on your router). The big bad world is still in the external zone. However, apart from "/24" in place of "/255" (ahem :-) ) the following is correct:
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 thought I had solved the problem of Samba access within my LAN by setting FW_TRUSTED_NETS to 192.168.0.0/24. I don't know now why that seemed to be the case, but right now I have FW_TRUSTED_NETS set to that value and Samba access is being blocked (the other machine shows a request for username/password that can't be satisfied). Turning off the firewall makes Samba work again on the far end. The documentation does not make clear what services are provided to the FW_TRUSTED_NETS machines if you just list an IP address or range of IP addresses with none of the optional parameters -- do you get all services (like an unmodified external zone) or none of the services (like the internal zone)? I'd like to see an authoritative answer to that question. An ad hoc solution is to set FW_TRUSTED_NETS to: 192.168.0.0/24,tcp,139 192.168.0.0/24,udp,187 192.168.0.0/24,udp,138 which solves the Samba problem but not any other problem pertaining to local-net access. The effect I want is to enable all services for a specified range of IP addresses. Paul
On 28/09/06 18:20, Paul Abrahams wrote:
I thought I had solved the problem of Samba access within my LAN by setting FW_TRUSTED_NETS to 192.168.0.0/24. I don't know now why that seemed to be the case, but right now I have FW_TRUSTED_NETS set to that value and Samba access is being blocked (the other machine shows a request for username/password that can't be satisfied). Turning off the firewall makes Samba work again on the far end. If it is possible, please set FW_TRUSTED_NETS to just 192.168.0.0/24, restart the firewall, and then run:
iptables-save The results of this should tell us what is going on.This should work without having to specify a bunch of protocol/port options.
On Friday 29 September 2006 5:23 pm, Darryl Gregorash wrote:
If it is possible, please set FW_TRUSTED_NETS to just 192.168.0.0/24, restart the firewall, and then run:
iptables-save
The results of this should tell us what is going on.This should work without having to specify a bunch of protocol/port options.
Here you are: --begin----------- # Generated by iptables-save v1.3.3 on Fri Sep 29 19:29:11 2006 *mangle :PREROUTING ACCEPT [118789:21678230] :INPUT ACCEPT [106399:17747482] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [130874:24748273] :POSTROUTING ACCEPT [131024:24766431] COMMIT # Completed on Fri Sep 29 19:29:11 2006 # Generated by iptables-save v1.3.3 on Fri Sep 29 19:29:11 2006 *nat :PREROUTING ACCEPT [12576:3955486] :POSTROUTING ACCEPT [8974:583536] :OUTPUT ACCEPT [8974:583536] COMMIT # Completed on Fri Sep 29 19:29:11 2006 # Generated by iptables-save v1.3.3 on Fri Sep 29 19:29:11 2006 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] :forward_ext - [0:0] :input_ext - [0:0] :reject_func - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth0 -j input_ext -A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options -A INPUT -j DROP -A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options -A OUTPUT -o lo -j ACCEPT -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-OUT-ERROR " --log-tcp-options --log-ip-options -A input_ext -m pkttype --pkt-type broadcast -j DROP -A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT -A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 0 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 3 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 11 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 12 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 14 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 18 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 3/2 -j ACCEPT -A input_ext -p icmp -m state --state RELATED,ESTABLISHED -m icmp --icmp-type 5 -j ACCEPT -A input_ext -s 192.168.0.0/255.255.255.0 -m limit --limit 3/min -m state --state NEW -j LOG --log-prefix "SFW2-INext-ACC-TRUST " --log-tcp-options --log-ip-options -A input_ext -s 192.168.0.0/255.255.255.0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT -A input_ext -p udp -m limit --limit 3/min -m state --state NEW -m udp --dport 871 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p udp -m udp --dport 871 -j ACCEPT -A input_ext -p tcp -m limit --limit 3/min -m state --state NEW -m tcp --dport 872 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p tcp -m tcp --dport 872 -j ACCEPT -A input_ext -p udp -m limit --limit 3/min -m state --state NEW -m udp --dport 111 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p udp -m udp --dport 111 -j ACCEPT -A input_ext -p tcp -m limit --limit 3/min -m state --state NEW -m tcp --dport 111 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p tcp -m tcp --dport 111 -j ACCEPT -A input_ext -p udp -m limit --limit 3/min -m state --state NEW -m udp --dport 2049 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p udp -m udp --dport 2049 -j ACCEPT -A input_ext -p tcp -m limit --limit 3/min -m state --state NEW -m tcp --dport 2049 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p tcp -m tcp --dport 2049 -j ACCEPT -A input_ext -p udp -m limit --limit 3/min -m state --state NEW -m udp --dport 1231 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p udp -m udp --dport 1231 -j ACCEPT -A input_ext -p tcp -m limit --limit 3/min -m state --state NEW -m tcp --dport 1512 -j LOG --log-prefix "SFW2-INext-ACC-RPC " --log-tcp-options --log-ip-options -A input_ext -p tcp -m tcp --dport 1512 -j ACCEPT -A input_ext -p tcp -m tcp --dport 113 -m state --state NEW -j reject_func -A input_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options -A input_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options -A input_ext -p udp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options -A input_ext -m limit --limit 3/min -m state --state INVALID -j LOG --log-prefix "SFW2-INext-DROP-DEFLT-INV " --log-tcp-options --log-ip-options -A input_ext -j DROP -A reject_func -p tcp -j REJECT --reject-with tcp-reset -A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable -A reject_func -j REJECT --reject-with icmp-proto-unreachable COMMIT # Completed on Fri Sep 29 19:29:11 2006 ---end--------------------- Hope this helps. Did you want me to try a Samba access from some other machine? Paul
On 29/09/06 17:32, Paul Abrahams wrote:
On Friday 29 September 2006 5:23 pm, Darryl Gregorash wrote:
If it is possible, please set FW_TRUSTED_NETS to just 192.168.0.0/24, restart the firewall, and then run:
iptables-save
The results of this should tell us what is going on.This should work without having to specify a bunch of protocol/port options.
Here you are:
<snip> -A INPUT -i eth0 -j input_ext <snip> -A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -s 192.168.0.0/255.255.255.0 -m limit --limit 3/min -m state --state NEW -j LOG --log-prefix "SFW2-INext-ACC-TRUST " --log-tcp-options --log-ip-options -A input_ext -s 192.168.0.0/255.255.255.0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT Windows uses broadcasts extensively in its file sharing, so refusing all broadcasts is the reason why a Windows client cannot see the shares (as you mentioned in your next post). I believe if you set FW_ALLOW_FW_BROADCAST_EXT="137" in /etc/sysconfig/SuSEfirewall2, things should work again. Sorry I didn't catch this earlier, but I never even
OK, those are the first two rules in the input chains. After some icmp stuff comes: thought to ask you if you were denying broadcasts -- I just assumed that if you were using Samba, you must be allowing port 137 broadcasts. Please see the firewall config file for a discussion of how this variable works.
Hope this helps. Did you want me to try a Samba access from some other machine?
Paul
On Saturday 30 September 2006 5:21 am, Darryl Gregorash wrote:
On 29/09/06 17:32, Paul Abrahams wrote:
On Friday 29 September 2006 5:23 pm, Darryl Gregorash wrote:
If it is possible, please set FW_TRUSTED_NETS to just 192.168.0.0/24, restart the firewall, and then run:
iptables-save
The results of this should tell us what is going on.This should work without having to specify a bunch of protocol/port options.
Here you are:
<snip> -A INPUT -i eth0 -j input_ext <snip> -A input_ext -m pkttype --pkt-type broadcast -j DROP
OK, those are the first two rules in the input chains. After some icmp
stuff comes:
-A input_ext -s 192.168.0.0/255.255.255.0 -m limit --limit 3/min -m state --state NEW -j LOG --log-prefix "SFW2-INext-ACC-TRUST " --log-tcp-options --log-ip-options -A input_ext -s 192.168.0.0/255.255.255.0 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
Windows uses broadcasts extensively in its file sharing, so refusing all broadcasts is the reason why a Windows client cannot see the shares (as you mentioned in your next post). I believe if you set FW_ALLOW_FW_BROADCAST_EXT="137" in /etc/sysconfig/SuSEfirewall2, things should work again. Sorry I didn't catch this earlier, but I never even thought to ask you if you were denying broadcasts -- I just assumed that if you were using Samba, you must be allowing port 137 broadcasts. Please see the firewall config file for a discussion of how this variable works.
That has to qualify as a "gotcha". I fixed it just as you suggested and Samba now works on my Windows machines. An epistemological question: how might I have discovered that if you hadn't told me, other than plowing through all the FW parameters and just maybe realizing that this one needed to be changed -- and changed to 137? Even though the description of this variable in the config file mentions Samba, it doesn't indicate very clearly how essential it is. Too bad all this necessary stuff isn't in the Firewall section of Yast (granted that you can get at it through sysconfig if you know to look there). Thanks for all your help, Darryl. You certainly know a lot about this stuff. Paul
On 30/09/06 11:54, Paul Abrahams wrote:
<snip>
That has to qualify as a "gotcha". I fixed it just as you suggested and Samba now works on my Windows machines.
An epistemological question: how might I have discovered that if you hadn't told me, other than plowing through all the FW parameters and just maybe realizing that this one needed to be changed -- and changed to 137? Even though the description of this variable in the config file mentions Samba, it doesn't indicate very clearly how essential it is.
The only way to know what a firewall must permit is to know the services that need the network. That is often a great deal more detail than the average user should be expected to know in depth. The solution to this is, of course, a clearly written FAQ or Wiki, in a place that people can easily find it. Unfortunately, the Linux documentation world is as badly fragmented, and much of the information is woefully outdated -- the list FAQ mentions a SuSE FAQ at sourceforge, but the most recent amendment to that collection is March, 2005. The firewall document is dated 2002, so I suspect it is ipchains-based, whereas the 2.6 kernel uses iptables. I do not see this situation getting any better in my lifetime.
Too bad all this necessary stuff isn't in the Firewall section of Yast (granted that you can get at it through sysconfig if you know to look there).
I am not sure this is necessarily a good idea. How many services would need to be discussed, and in what detail? It could very quickly get out of hand. Perhaps it would be sufficient if port 137 broadcast is automatically turned on whenever the user chooses Samba-server as an allowed service (a note to this effect would have to be placed in the broadcast section, of course). PS, if I know so much about this, why did it take so long to resolve your problem? ;-)
On Saturday 30 September 2006 5:26 pm, Darryl Gregorash wrote:
On 30/09/06 11:54, Paul Abrahams wrote:
<snip> Too bad all this necessary stuff isn't in the Firewall section of Yast (granted that you can get at it through sysconfig if you know to look there).
I am not sure this is necessarily a good idea. How many services would need to be discussed, and in what detail? It could very quickly get out of hand. Perhaps it would be sufficient if port 137 broadcast is automatically turned on whenever the user chooses Samba-server as an allowed service (a note to this effect would have to be placed in the broadcast section, of course).
Certainly, turning on port 137 broadcast when the Samba server is enabled (just as NSF client/server are turned on when those are enabled in the Network Services section) would be doing many people a favor. More generally, a Special Settings section under the firewall configuration might well be tied into the firewall sysconfig settings. The firewall configurator could link to the very same text. Again, thanks for the key to the kingdom here. Paul
PS, if I know so much about this, why did it take so long to resolve your problem? ;-)
On Friday 29 September 2006 5:23 pm, Darryl Gregorash wrote:
On 28/09/06 18:20, Paul Abrahams wrote:
I thought I had solved the problem of Samba access within my LAN by setting FW_TRUSTED_NETS to 192.168.0.0/24. I don't know now why that seemed to be the case, but right now I have FW_TRUSTED_NETS set to that value and Samba access is being blocked (the other machine shows a request for username/password that can't be satisfied). Turning off the firewall makes Samba work again on the far end.
If it is possible, please set FW_TRUSTED_NETS to just 192.168.0.0/24, restart the firewall, and then run:
iptables-save
The results of this should tell us what is going on.This should work without having to specify a bunch of protocol/port options.
That's in an earlier post. I just discovered another strange thing. With the firewall on and with FW_TRUSTED_NETS set to 192.168.0.0/24, Windows machines get an access error if they try to look at the Samba shares. However, Linux machines can see those same shares. With firewall off, everyone sees the Samba shares. Paul
On Tuesday 26 September 2006 9:04 pm, Darryl Gregorash wrote:
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.
I thought I had solved the problem, but I had not. I did set FW_TRUSTED_NETS to 192.168.0.1/255 but still got the message: Unable to find any workgroups in your local network. This might be caused by an enabled firewall. Using Joe Morris's suggestion of enabling tcp 139, udp 137, and udp 138 (via the Advanced section of the Yast firewall section, Allowed Services, Advanced, I was able to get Samba going. But that wasn't quite what I wanted because it opened up Samba to the entire external universe. The documentation of the FW_TRUSTED_NETS setting is confusing: Which services should be accessible from trusted hosts/nets? Define trusted hosts/networks (doesnt matter if they are internal or external) and the TCP and/or UDP services they are allowed to use. Please note that a trusted host/net is *not* allowed to ping the firewall until you set it to allow also icmp! Choice: leave FW_TRUSTED_NETS empty or any number of computers and/or networks, seperated by a space. e.g. "172.20.1.1 172.20.0.0/16" Optional, enter a protocol after a comma, e.g. "1.1.1.1,icmp" Optional, enter a port after a protocol, e.g. "2.2.2.2,tcp,22" That seems to imply that I would need to specify the 3 Samba services that Joe cited plus any others I might want; a trusted host gets no extra services except those specifically given with something like this: 192.168.0.1/255,tcp,139,udp,137,udp,138 That didn't seem to work, however, possibly because I have the syntax wrong (the description of the parameter is vague about the correct way to specify several services). Any ideas? Paul
On Wed, 2006-09-27 at 18:23 -0400, Paul Abrahams wrote:
192.168.0.1/255,tcp,139,udp,137,udp,138
Is 192.168.0.1 an IP address for a single machine, or are you trying to define a network here? If it's a single machine, skip the / and just use 192.168.0.1. If it's a network, 255 is wrong. The number is the number of bits in the netmask, most common is 24, for a network where all the computers share the three first numbers If it is a single machine, the line should look like 192.168.0.1,tcp,139 192.168.0.1,udp,137 192.168.0.1,udp,138
On Wednesday 27 September 2006 7:17 pm, Anders Johansson wrote:
On Wed, 2006-09-27 at 18:23 -0400, Paul Abrahams wrote:
192.168.0.1/255,tcp,139,udp,137,udp,138
Is 192.168.0.1 an IP address for a single machine, or are you trying to define a network here? If it's a single machine, skip the / and just use 192.168.0.1. If it's a network, 255 is wrong. The number is the number of bits in the netmask, most common is 24, for a network where all the computers share the three first numbers
If it is a single machine, the line should look like
192.168.0.1,tcp,139 192.168.0.1,udp,137 192.168.0.1,udp,138
It's a network, and 192.168.0.0/24 as the value of FW_TRUSTED_NETS did the trick. That's better than the explicit tcp/udp specification since it effectively puts that subnet into the internal zone for all services -- just what I want. Paul
On Wednesday 27 September 2006 8:27 pm, I wrote:
It's a network, and 192.168.0.0/24 as the value of FW_TRUSTED_NETS did the trick. That's better than the explicit tcp/udp specification since it effectively puts that subnet into the internal zone for all services -- just what I want.
It would be very nice if Yast included the ability to set FW_TRUSTED-NETS in its firewall settings, especially since the existence of additional firewall settings in /etc/sysconfig is not obvious if you don't already know about it. The setting I'm using now seems to be exactly right for the very common configuration I described: several machines on a net, each with a single network card, and a router on that same net that connects to the rest of the world via a cable or DSL modem. And speaking of Yast: I have two machines running 10.0. On one of them, the /etc/sysconfig categories include Network/Firewall/personal-filewall, with FW_TRUSTED_NETS nowhere to be seen. I can still get at it via a search, though. On the other one those categories include Network/Firewall/SuSEfirewall2 and FW_TRUSTED_NETS is listed underneath it. Very odd, especially since the firewall seems to behave the same in both instances. Perhaps it has something to do with one installation being an upgrade and the other a new installation. Paul
On Wednesday 27 September 2006 8:27 pm, I wrote:
It's a network, and 192.168.0.0/24 as the value of FW_TRUSTED_NETS did the trick. That's better than the explicit tcp/udp specification since it effectively puts that subnet into the internal zone for all services -- just what I want.
It would be very nice if Yast included the ability to set FW_TRUSTED-NETS in its firewall settings, especially since the existence of additional firewall settings in /etc/sysconfig is not obvious if you don't already know about it. Yast, System, sysconfig editor, Network, firewall, SuSEfirewall2, and
On 27/09/06 18:44, Paul Abrahams wrote: peruse the list.. it's in there. All the settings from /etc/sysconfig/SuSEfirewall2 are in there. It should, however, be possible to set these in Security/Firewall (or Network/Firewall, depending on the Yast version).
On Wednesday 27 September 2006 9:35 pm, Darryl Gregorash wrote:
On 27/09/06 18:44, Paul Abrahams wrote:
It would be very nice if Yast included the ability to set FW_TRUSTED-NETS in its firewall settings, especially since the existence of additional firewall settings in /etc/sysconfig is not obvious if you don't already know about it.
Yast, System, sysconfig editor, Network, firewall, SuSEfirewall2, and peruse the list.. it's in there. All the settings from /etc/sysconfig/SuSEfirewall2 are in there.
It should, however, be possible to set these in Security/Firewall (or Network/Firewall, depending on the Yast version).
That's just what I meant. I should have been clearer. Paul
On 27/09/06 21:07, Paul Abrahams wrote:
On Wednesday 27 September 2006 9:35 pm, Darryl Gregorash wrote:
<snip>
It should, however, be possible to set these in Security/Firewall (or Network/Firewall, depending on the Yast version).
That's just what I meant. I should have been clearer. And now that I read again what I wrote above, I too should have been clearer.. that is what we *want*, but it isn't what we *get* :-)
On Thursday 28 September 2006 1:33 am, Darryl Gregorash wrote:
On 27/09/06 21:07, Paul Abrahams wrote:
On Wednesday 27 September 2006 9:35 pm, Darryl Gregorash wrote:
<snip>
It should, however, be possible to set these in Security/Firewall (or Network/Firewall, depending on the Yast version).
That's just what I meant. I should have been clearer.
And now that I read again what I wrote above, I too should have been clearer.. that is what we *want*, but it isn't what we *get* :-)
What would be the best way to ask Novell to fix this? There's a help file for Susefirewall, /usr/share/doc/packages/SuSEfirewall2/EXAMPLES, that lists a number of scenarios, but not the very common one I'm dealing with. Your suggestion shows that there is a simple way of handling it. If your approach has any disadvantages or weaknesses, I haven't found them. For those not following the thread earlier, the scenario is a home network with several machines, each with a single network card cabled to a router such as a D-Link, Linksys, or Netgear. The router in turn is connected to a DSL or cable modem that interfaces to a broadband ISP. Communication among the machines on the network should be entirely uninhibited but communication with machines outside the network should be fully protected by the firewall. The solution is to set the /etc/sysconfig parameter FW_TRUSTED_NETS to the value 192.168.0.0/24 or 192.168.1.0/24, depending on the router and assuming the router does not have a nonstandard configuration. Paul Paul
On 28/09/06 10:54, Paul Abrahams wrote:
On Thursday 28 September 2006 1:33 am, Darryl Gregorash wrote:
<snip> And now that I read again what I wrote above, I too should have been clearer.. that is what we *want*, but it isn't what we *get* :-)
What would be the best way to ask Novell to fix this?
Things have changed somewhat since opensuse.org came online -- there used to be an email address (??)@suse.com but I doubt if it is still active. I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
On Thu, Sep 28, 2006 at 11:21:00AM -0600, Darryl Gregorash wrote:
On 28/09/06 10:54, Paul Abrahams wrote:
On Thursday 28 September 2006 1:33 am, Darryl Gregorash wrote:
<snip> And now that I read again what I wrote above, I too should have been clearer.. that is what we *want*, but it isn't what we *get* :-)
What would be the best way to ask Novell to fix this?
Things have changed somewhat since opensuse.org came online -- there used to be an email address (??)@suse.com but I doubt if it is still active.
It hasn't been for quite some time.
I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
bugzilla.novell.com is open for your bugreports :) Ciao, Marcus
On 28/09/06 11:22, Marcus Meissner wrote:
On Thu, Sep 28, 2006 at 11:21:00AM -0600, Darryl Gregorash wrote:
<snip>
I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
bugzilla.novell.com is open for your bugreports :) So you think this is a bug, then, Marcus? :-)
On Thu, 28 Sep 2006, Darryl Gregorash wrote:
On 28/09/06 11:22, Marcus Meissner wrote:
On Thu, Sep 28, 2006 at 11:21:00AM -0600, Darryl Gregorash wrote:
<snip>
I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
bugzilla.novell.com is open for your bugreports :) So you think this is a bug, then, Marcus? :-)
I doubt it, but you can file an enhancement request there are well. I
believe that is what he meant.
--
Boyd Gerber
On 28/09/06 12:51, Boyd Lynn Gerber wrote:
On Thu, 28 Sep 2006, Darryl Gregorash wrote:
On 28/09/06 11:22, Marcus Meissner wrote:
On Thu, Sep 28, 2006 at 11:21:00AM -0600, Darryl Gregorash wrote:
<snip>
I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
bugzilla.novell.com is open for your bugreports :)
So you think this is a bug, then, Marcus? :-)
I doubt it, but you can file an enhancement request there are well. I believe that is what he meant. OK, but this issue crosses all SuSE versions since at least 9.3 -- bugzilla only accepts a single product for each bug, and for SuSELinux, only versions 10.x.
On a different train of thought, even if the bugzilla did accept reports for 9.3, would it be appropriate to use it, for example, to request that seamonkey be officially released for those versions? (Right now there is only an "unofficial" release in the suse/projects/ tree). Or that Yast in 9.3 be updated so it can use the new repositories, which contains all sorts of goodies for 9.3, but cannot be added as an installation source?
On 9/28/06, Darryl Gregorash wrote:
On a different train of thought, even if the bugzilla did accept reports for 9.3, would it be appropriate to use it, for example, to request that seamonkey be officially released for those versions? (Right now there is only an "unofficial" release in the suse/projects/ tree). Or that Yast in 9.3 be updated so it can use the new repositories, which contains all sorts of goodies for 9.3, but cannot be added as an installation source?
why not use smart or apt/synaptic? -- -- Svetoslav Milenov (Sunny) Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1 bit of competition.
On 28/09/06 16:23, Sunny wrote:
On 9/28/06, Darryl Gregorash wrote:
On a different train of thought, even if the bugzilla did accept reports for 9.3, would it be appropriate to use it, for example, to request that seamonkey be officially released for those versions? (Right now there is only an "unofficial" release in the suse/projects/ tree). Or that Yast in 9.3 be updated so it can use the new repositories, which contains all sorts of goodies for 9.3, but cannot be added as an installation source?
why not use smart or apt/synaptic?
Because neither of these are distributed with 9.3? Because it should be possible to do the entire system configuration, including adding/removing software packages, using only the default system configuration tool?
On Thu, September 28, 2006 4:05 pm, Darryl Gregorash wrote:
why not use smart or apt/synaptic?
Because neither of these are distributed with 9.3? Because it should be possible to do the entire system configuration, including adding/removing software packages, using only the default system configuration tool?
Well, AFAIK, that's kind of what Novell/SUSE was thinking when they released Zen with 10.1 a few months back. Zen is supposed to do updates to packages along with official security releases. -- Kai Ponte www.perfectreign.com || www.4thedadz.com remember - a turn signal is a statement, not a request
On 28/09/06 18:17, PerfectReign wrote:
On Thu, September 28, 2006 4:05 pm, Darryl Gregorash wrote:
why not use smart or apt/synaptic?
Because neither of these are distributed with 9.3? Because it should be possible to do the entire system configuration, including adding/removing software packages, using only the default system configuration tool?
Well, AFAIK, that's kind of what Novell/SUSE was thinking when they released Zen with 10.1 a few months back. Zen is supposed to do updates to packages along with official security releases.
I don't know much about Zen, since I'm using 9.3 -- but AFAIK, Zen is just a package maintenance tool, not a system administration tool like Yast is.
On Friday 29 September 2006 03:21, Darryl Gregorash wrote:
Things have changed somewhat since opensuse.org came online -- there used to be an email address (??)@suse.com but I doubt if it is still active. I poked around on the opensuse website a bit to find: http://en.opensuse.org/How_to_Participate and there is a wishlist reference in that.
There is a site dedicated to SuSEfirewall that may be of interest also. http://forge.novell.com/modules/xfmod/project/?susefirewall2 -- Regards, Graham Smith
On 27/09/06 18:27, Paul Abrahams wrote:
<snip> It's a network, and 192.168.0.0/24 as the value of FW_TRUSTED_NETS did the trick <snip>
Just out of idle curiosity, where did you get that /255 thingy from? My first post clearly stated /24, and I thought I had corrected your error in my second post (well, checking it, I see that I did).
On Wednesday 27 September 2006 8:52 pm, Darryl Gregorash wrote:
On 27/09/06 18:27, Paul Abrahams wrote:
<snip> It's a network, and 192.168.0.0/24 as the value of FW_TRUSTED_NETS did the trick <snip>
Just out of idle curiosity, where did you get that /255 thingy from? My first post clearly stated /24, and I thought I had corrected your error in my second post (well, checking it, I see that I did).
I mistakenly thought that 24 was the upper range of the last component of the IP address. I've seen the x.x.x.x/n notation but had forgotten about it. Paul
On 27/09/06 19:32, Paul Abrahams wrote:
...
192.168.0.0/24 ...
I mistakenly thought that 24 was the upper range of the last component of the IP address. I've seen the x.x.x.x/n notation but had forgotten about it. OK, probably an easy mistake to make if you don't use the notation regularly. As Anders has noted, the /24 defines the netmask to be the top 24 bits.. so /24 is the same as a netmask of 255.255.255.0. Some applications allow you to use them interchangeably, and that can get very confusing at times.
participants (10)
-
Anders Johansson -
Boyd Lynn Gerber -
Darryl Gregorash -
Graham Smith -
Joe Morris (NTM) -
Marcus Meissner -
Paul Abrahams -
PerfectReign -
Sunny -
Theo v. Werkhoven