I need to add that the printing on this same all-in-one works, from both the server and remotely from the laptop.  The only thing broken is networked scanning.

did you reboot after the updsate?

Yes.  Yast advises you to update after a kernel update, and I always do that.

Shouldn't it be assigned to the kernel people
when a kernel update broke it?

Just to make sure, if you install and boot the old kernel, does it work again?

How do you do that?  I'll need to know how to acquire the old kernel, and also need to know which computer to put it on, the server or the client, or both.  That kernel is not the one on the original install disk, it's been upgraded several times since GM.

Also, the power supply/charger on my laptop (the client) went bad, so it will be a few days before I have a new one and can try out a test.

http://download.opensuse.org/update/11.1/rpm/i586/?P=kernel-%2A.i586.rpm has all the update kernels so far, just pick the one that was installed previously. You said it broke with a kernel update (applied to which machine?), I just wanted to make sure that it's really the kernel update and not something else that was updated at the same time.

I finally got the use of my notebook back, so I was able to test this.

1. I downgraded the kernel on the notebook.  Result: failure
2. With notebook at downgraded version, I downgraded the server.  Same result
3. I re-upgraded the notebook and tested.  Same result

As all four states are tested between these two machines with complete failure to detect or use the scanner, we can probably assume that the problem is not the kernel.  Rather, either some other package is responsible or some part of the update hosed-up a configuration file somewhere deep in the bowels of either (or both) machine.

As a side note, I have an old Thinkpad A20 I've been using for testing.  It now has the newly-released 11.2 (i586 KDE) and is connected to the same net.  It also doesn't see the scanner, yet the printer works (HP OfficeJet 6310 All-In-One).

Thanks for testing. As this is clearly not a kernel update problem, reassigning back

See
http://en.opensuse.org/SDB:Configuring_Scanners_from_SUSE_LINUX_9.2
"Trouble-Shooting (Debugging)"
how to provide debug-messages.

Sorry for taking so long, unavoidable circumstances.  There is no test procedure for the network connection in that web page, so I had to make up my own using clues from the page and links from it.

Here is what I did:

In the web page, under network scanning/saned, I found a reference, in a warning, to read "man saned"

Doing that, under "RESTRICTIONS" I found the line:
"In  addition to the control connection (port 6566) saned also uses a data connection.  The port of this socket is selected by the operating system and can't be specified by the user currently.  This may be a problem if the connection must go through a firewall (packet filter).  If you must use a packet filter, make sure that all ports > 1024 are open on the server for connections from the client."

That reference to network ports gave me what I needed to experiment.  This is what I did next:

1. Opened tcp ports 1024-7999 on the server.  (For some reason, I had 8000:8001 programmed into the manual tcp port list, even though I have http and https server options enabled.)

Tried to scan, instead of "searching for scanner" dialog box hanging for a long time, it came up immediately with a "scanner not found" message.

I then re-installed the scanner driver on the server.

Tried scanning again and the behavior of xsane reverted to its previous state: hanging on the searching box before finally getting the not found error message.  I went back to the server and found that the tcp port setting changed to 1024:6565 6567:8001.  I reset ports to 1024:7999 8000:8001 and set the allowed clients to 192.168.0.0/8 (from 127.0.0.0/8).

Tried another preview scan.  The xsane dialog actually came up.  I clicked the acquire preview button and the scanner scanned, then hung.

I tried some more port settings, then just shut the firewall down.  Ran full scanning tests, and found all network scanning completely restored (remember, FIREWALL OFF).

It appears the server firewall is not being set up properly to allow networked scanning.  In addition, it was actually altered during or by the update in such a way as to break network scanning capability.  That man page says there are ports, for data use, that cannot be set by the user, and I can find no reference to what they are.

I hope this helps.

So in the end it was a running firewall which
made network scanning impossible.

This is no bug regarding scanning.

This is documented in the YaST scanner setup help text
and therein you can also disable firewall protection
for the 'INT' zone (but only if you use the SuSEfirewall):
------------------------------------------------------------------
Scanning via Network
...
Server Settings
If you have locally connected scanners and want
to make them accessible via the network,
set up the saned network scanning daemon
so that your host becomes a server.
In 'Permitted Clients', enter which client hosts
are permitted to access saned on your server.
Enter a comma-separated list of client hosts
(hostnames or IP addresses) or subnets
(CIDR notation, such as 192.168.1.0/24).
If no client hosts are permitted, saned is not activated.
If saned is activated, xinetd is also activated
and set up for saned.
Clients contact saned via the sane-port (TCP port 6566)
but scanning data is transferred via an additional random port.
The default 'Firewall Settings' during system installation
protect your host from external access.
This is not a problem when using scanners in an internal network
(when the network interface belongs to the internal network zone)
unless you have firewall protection enabled for the internal zone.
Allowing access from an external network does not make sense
because scanning documents requires physical scanner access.
Therefore access from the external zone can only be denied
if it was accidentally allowed by insecure firewall settings.
...
Client Settings
If you want to access scanners connected to other hosts (servers)
in the network, set up the net metadriver to access them via
the daemon running on the servers.
saned and firewall on the servers must permit the access.
In 'Servers Used', enter which servers should be used.
Enter a comma-separated list of servers (server names
or IP addresses).
If no servers are entered, net is not activated.
------------------------------------------------------------------

It seems the bug here is that somehow (I have no idea how)
the firewall was activated after whatever software update.
If you may find out what caused this, you may file a new
bug report regarding the comonent which seems to have
activated the firewall after whatever software update.

I don't know where to start.  Here is what I think I understand:

The firewall is SUPPOSED to be active.  That protects my computer from internet predators.

"External Zone" is anything outside the computer.

"Internal Zone" is anything inside the computer.

I have no clue what "Demilitarized Zone" is.  It doesn't seem to be used for anything.

Saned is only supposed to allow scanning on the local network (usually 192.168.0.x).  I don't know how to defeat that (not that I really need to).

I noted that tcp 6566, activated and tested it.  It only allowed partial functionality, and did not permit complete scans.

This is not cleared up.  Those directions do not fix network scanning.  As I mentioned before, the only I can get network scanning to work properly is to shut down/turn off/deactivate the entire firewall.  CLEARLY, there is a port that saned is using/expecting that it is not opening in the external zone of the firewall, since the internal zone is wide open.

If this belongs, somehow, to security/firewall, please reassign it there.  I am relying on you guys knowing which component is at fault.

To summarize: network scanning is not fixed.  Being required to scan with the firewall disabled/off forces an unacceptable breach of security and will open my server to hackers.

Joseph Short,
FYI, you could set the bug severity (e.g. "major")
but you should not set the bug priority to "high"
(I assume this is even somewhere documented).

In any case it does not belong to the component "Printing"
but may fit hopefully better to "Security".

Now I have the issue back :-(

I cannot fix how saned works.
It uses a random port for data transfer.
That is how it is designed by the SANE project.

I also cannot fix how our firewall works
because its defaults are perfectly reasonable:
By default it protects access from the "EXT" zone
and allows access only for the "INT" zone.

Finally I will never even open random ports
in the "EXT" zone via the YaST scanner setup
only to make scanning via network "just work"
for the price of a totally insecure firewall setup
which would be in the end the same as having
no firewall running at all.

In the end I cannot do anything here.

Joseph Short,
perhaps what you actually need is explanation what
"External Zone" and "Internal Zone" means regarding firewall
and a description how to set up your firewall accordingly?
Is this what you ask for?

***This answer is in two postings -- first is detailed, second is summary***

Johannes, I am not trying to make you unhappy.  I am trying to use network scanning without shutting off the server firewall.

Here is what I have:

Before the update, network scanning worked with an active firewall.  Now, unless I disable the firewall and open my server to hackers, I can not use network scanning.  That means no one else can, either.  I have traced the problem to saned and the firewall.  One or both of these two components is/are responsible for the complete loss of this capability.  Any action taken here should be either to track down and fix the problem, or announce that network scanning is no longer supported or supportable.

While it would be nice to know what those zones are and what they are for, we are really only talking about the External Zone.  That is the one through which scanning goes to operate.  I believe I have my firewall set up correctly (it's not that difficult).  Everything else works properly and the same as it did before.  Only network scanning is broken.

Saned is supposed to set TCP 6566 in the external zone.  In fact, not only is saned not setting it, saned setup actually deletes it when I put it there manually.

I will be more than happy to run any test you want and provide any test result you desire to troubleshoot the problem.  It doesn't look like you have access to a system you can test this yourself on.

If you can't fix a broken saned, could you at least allow me to download and use the version that's NOT broken, the one that worked before the update?  It's a real pain to scan with the server and then transfer the files.

SUMMARY OF PREVIOUS POST:

1. Before the update, network scanning worked.
2. After the update, network scanning is broken.
3. Network scanning works only when firewall is shut down.
4. Saned setup is supposed to set TCP 6566.  It does not set it.
5. Even when you set TCP 6566 manually, saned setup deletes it.
6. I will run any test you ask and deliver any test result you want.
7. If the current version of saned cannot be repaired so that it actually does what is designed to do, can we (or at least I) go back to the previous version that is not broken?

There is no bug in saned.
There is no "previous version that is not broken".
It worked and works all the time this way.

You just cannot do scanning via network in an
untrusted network environment.
With "cannot" I mean that of course you "can"
but then without any security because - see "man saned":
  saned is not intended to be exposed
  to ... non-trusted networks

Even if with a huge amount of effort, the saned authors
at the SANE project might enhance saned to run secure
even in an untrusted network environment
(this would in particular require SSL/TLS encrypted
communication to avoid that others could eavesdrop
on the scanning data to sniff secret image data),
it would not make much sense because scanning documents
requires physical scanner access but it does not make
much sense to permits physical hardware access
in an untrusted network environment.


There is also no bug in our firewall.


Scanning via network works well for me and for others
provided the firewall is correctly set up.

When before the update, network scanning worked
but no longer after the update, the only reason
is here from what I can see from the above comments
that after the update your firewall runs
but it did not run before the update.

Because you wrote things like
---------------------------------------------------------------
"External Zone" is anything outside the computer.
"Internal Zone" is anything inside the computer.
...
Saned is supposed to set TCP 6566 in the external zone.
---------------------------------------------------------------
which do not make any sense at all,
my assumption is that all what you actually need
is an understanding how the firewall works.
Therefore I wrote comment #17.

Again:
There is no bug in the software so that I cannot
fix anything in the software here so that for the
software the bug is still invalid.

Please do not misunderstand me.
For a normal user it is perfectly o.k. not to understand
particular complicated stuff like a firewall.
In this case there should be at least sufficient
documentation how to set up the firewall.
I don't know our firewall documentation (because I never
read it because firewall setup works for my needs).

Therefore again my question:
Do you need documentation how to set up the firewall
so that scanning via network works in a trusted
internal network?

Johannes,

My network scanning used to work.

My firewall has ALWAYS been active.  I check it periodically to make sure it is up and working.  I know it worked before and after.  I NEVER leave a computer exposed like that.

After the update, network scanning is broken and no longer works.  That looks like a bug.

My network on this side of my router (192.168.0.x) is trusted.

I have to set this in the saned setup as 192.168.0.0/24, that's what that setting is for.

That tells saned that any client it can see with an ip of 192.168.0.(anything) can be trusted for scanning.

There is no other setup for network scanning.


Please send me documentation for setting up openSUSE 11.1 firewall.  That's an 11.1 version of openSUSE.  I've never had to do more setting up of a firewall than the normal allowing http for a web server; they just haven't (until now) required that much maintenance.

What I really DON"T understand is why you think I did something bad to the firewall to break network scanning, when I did NOTHING more than allow a software update.  This is massively frustrating.


**By the way:

1. If scanning can not be done securely through the network, how is it that PRINTING is accomplished safely?  On the same HP all-in-one device?  And:

2. If scanning is supposed to be done completely without a firewall, why would saned's own documentation specify that TCP 6566 be set in that firewall?  If there's no firewall running, no port would be blocked and nobody would bother with setting TCP 6566.  (Remember, this is just explicitly unblocking a port, it doesn't have anything to do with port routing.)

I suspect the other port(s) used by saned are ones that are not normally blocked by a standard firewall.  ***Maybe you could send me the range of those other ports that saned chooses randomly.  I can test this and see if opening that range enables scanning.

The setup for saned like 192.168.0.0/24
in /etc/sane.d/saned.conf is totally
separated from the firewall setup.

When you have 192.168.0.0/24 in /etc/sane.d/saned.conf
the saned accepts all 192.168.0.x network traffic
but the running firewall can still block it
on a lower level (i.e. directly in the kernel)
so that no network traffic arrives at the saned.

Therefore also the firewall setup must be made accordingly
so that the kernel sends network traffic to the saned.

No application (e.g. the saned) must change any firewall rule
in the kernel because for applications the firewall rules
are sacrosanct. Only the admin sets the firewall rules.

When your 192.168.0.x network is trusted,
set in the YaST firewall setup the particular
network interface (something like eth0 or eth1)
which belongs to the 192.168.0.x network
to be in the internal ("INT") zone of the firewall.

To do this run the YaST firewall setup
and select "Interfaces",
then select the network interface which belongs
to the 192.168.0.x network,
click the [Change...] button so that a
"Zone for Network Interface" popup appears,
therein select "Internal Zone" and click [OK]
which closes the "Zone for Network Interface" popup,
then click [Next] and [Finish].

When the network interface for the 192.168.0.x network
is set to be in the internal zone of the firewall,
the firewall permits access via this interface
which means it allows access for the 192.168.0.x network.

The result is that the firewall does no longer block
the network traffic for the 192.168.0.x network
so that in the end scanning via the 192.168.0.x network
would again work.

Please report if scanning via the 192.168.0.x network
again works after you set its network interface
to be in the internal zone of the firewall.

Johannes,

I spent the entire day on this.  I got it to work, but I need for you to read the entire post.  It contains some very important information.

You were right that the network scanning will only work if the Internal Zone is active on the network interface.  Please remember that most people only have one interface, and only one Zone can connect to that one interface.  This is important because the Internal Zone is set up by default with every service, port and protocol enabled and wide open.  The Internal Zone is essentially a fire-gaping-hole rather than a firewall.

The way to correct this is to uncheck that little box at the bottom of the "Allowed Services" page labeled "Protect Firewall from Internal Zone."  This clears all that greyed-out stuff and lets you put in all the stuff you want to allow while blocking all the rest.  Otherwise, you have no firewall.  Remember, most people, like me, have only one network interface to work with -- we cannot connect outside services to a separate interface.

The other part is VERY IMPORTANT!  When working with an environment where network scanning takes place on the same interface/zone as, for example, web browsing, you must manually open port TCP 6566 and open the Dynamic ports 49152:65535 on TCP, UDP, and RPC.  If you don't, scanning will not work.  I found the Dynamic ports reference at:
http://www.iana.org/assignments/port-numbers

The random ports that saned uses are in there.

(Prior to my problems, I didn't have to set any ports, nor did I have to use Internal Zone.  Something changed between the firewall, saned and Yast2 and broke my network scanning.  It is now restored.)

Another very important point is this:  Sometimes when something gets changed (usually through Yast2), no change becomes active until the computer is rebooted.  For example, during my testing, I changed the firewall back to External from Internal.  Network scanning still worked -- until I rebooted the server.  It took another hour or so of testing before I realized that the change from Internal to External did not register until the reboot.  I'd be surprised if no one else noticed this, but maybe most people just note it and don't say anything.

I have some recommendations here:

1. Either have the network scanning setup in Yast2 make the necessary changes to the firewall, or at least inform the user that those firewall changes need to be made -- what they are and how to do it.  I realize that this incurs a slight security risk, but remember, most people have only one interface, and saned is designed to accept only requests from the trusted, and specified, subnet (usually 192.168.x.x).

2. Include an option for opening the Dynamic Ports (49152:65535) with an explanation as to why you might need to do that and with the usual security warnings.

3. If this problem won't or can't be fixed, at least provide documentation accessible from a "help" button to help a user patch it together and make it work.  I'll be happy to write something to help out (most of it is right here).

4. Recommend (with a pop-up box) a reboot after changes in network operations and services to make sure those changes become active.  This will save a lot of hair-pulling and gnashing of teeth by people who haven't yet discovered this "feature."

Thank you

(In reply to comment #18)
> Before the update, network scanning worked with an active firewall.  Now,
> unless I disable the firewall and open my server to hackers, I can not use
> network scanning.

I had the same issues with FTP after an update (10.2->11.1) - after some config changes in /etc/sysconfig/SuSEfirewall2 (see below) it works again. Details on http://www.suse.com/relnotes/i386/openSUSE/11.0/RELEASE-NOTES.en.html#10

> If you can't fix a broken saned, could you at least allow me to download and
> use the version that's NOT broken, the one that worked before the update?

If I'm right, the change is in the firewall...

(In reply to comment #23)
> browsing, you must manually open port TCP 6566 and open the Dynamic ports
> 49152:65535 on TCP, UDP, and RPC.  If you don't, scanning will not work.

These ports can hopefully be tracked as "related" ports so that they don't have to be open always and for everybody. For example, my FTP daemon needs FW_SERVICES_ACCEPT_RELATED_EXT="0/0,tcp,,20000:21000"
FW_LOAD_MODULES="ip_conntrack_ftp"

I just see that there is also a nf_conntrack_sane module - try adding it to FW_LOAD_MODULES and put the dynamic ports to FW_SERVICES_ACCEPT_RELATED_EXT.

If you don't get the firewall config running as described above, asking on the opensuse-security mailinglist might be a good idea ;-)

Ludwig,
see comment #23 and comment #24 above.

Could you recommend a reasonable firewall config
so that scanning via network is possible
even when the firewall is active for the INT zone?

The int zone is meant to be trusted. If you disable the option to protect it the int zone would be just the same as ext. saned just used a braindead protocol that doesn't work properly with firewalling. There is no special conntrack module as for ftp (which has security issues too). I don't think the yast2 scanner module needs to offer more complex firewall settings. The existing ones are sufficient.

If your interface is connected to different networks at the same time, you desperately want the ext zone but still want to trust some IP addresses you can specifically configure that (FW_TRUSTED_NETS, FW_SERVICES_ACCEPT_EXT).
If you're carrying around a laptop that connects to different networks which you trust differently you may want to try fwzs (http://lizards.opensuse.org/2009/08/28/firewall-zone-switcher-updated/).

(In reply to comment #26)
> There is no special conntrack module as for ftp

Hmmm, Ludwig, what's this then? ;-)

# lsmod |grep sane
nf_conntrack_sane       7892  0
nf_conntrack          102912  6 nf_conntrack_sane,nf_conntrack_ipv6,[...]

(I never tested if it works, but it exists.)

Joseph, does scanning work if you setup your firewall as I described in comment #24?

I didn't know about that one (and overlooked it in your comment).
I'm not sure it's that useful though. You'd have to use something
like FW_SERVICES_ACCEPT_RELATED_EXT="0/0,tcp" to make it work in a
generic way. ie accept all related packets from everywhere.
Preconfiguring saned to use a specific port range might be better.
And now that I the above config snippet, I remember that we did just
that for the ftp servers. pure-ftpd and vsftpd use 30000-30100 by
default. The same method could be used for saned, provided that it
indeed works like passive ftp on both client and server side. See
for example /etc/sysconfig/SuSEfirewall2.d/services/vsftpd and
/etc/vsftpd.conf from vsftpd

Let's see if reasonable firewall settings are possible
to allowe scanning via network even with active firewall.

Regarding a specific port range for saned, see "man saned":
-----------------------------------------------------------------
The saned.conf configuration file contains both options
for the daemon and the access list.

data_portrange = min_port - max_port

Specify the port range to use for the data connection.
Pick a port range between 1024 and 65535; don't pick a
too large port range, as it may have performance issues.
Use this option if your saned server is sitting behind
a firewall. If that firewall is a Linux machine, we strongly
recommend using the Netfilter nf_conntrack_sane module instead.
-----------------------------------------------------------------

I do not understand the "instead" therein.
It looks as if usage of nf_conntrack_sane would mean
that one cannot use data_portrange in /etc/sane.d/saned.conf
additionally?

By the way:
I do not understand how a (presumably small) port range
could make it more secure.
I would think that the smaller the port range,
the easier it is for an eavesdropper to sniff packages
and the easier for an attacker to attack a system
because he knows the ports of interest in advance?

Regardless of the port range for the data connection:
The saned listens on the well-known port "sane-port" (6566)
and according to "man saned"
------------------------------------------------------------------
First and foremost: saned is not intended to be exposed
to the internet or other non-trusted networks.
Make sure that access is limited by ... a firewall setup. 
------------------------------------------------------------------
so that first and foremost our firewall setup must
protect port 6566 against access from the Internet
any any other non-trusted networks.

Ludwig,
wouldn't only the one following manual setting by the user
  FW_TRUSTED_NETS="192.168.1.0"
be already sufficient and a reasonable firewall setting
to make scanning via network possible even with active firewall
(provided that the 192.168.1.0 network is trusted by the user)?

If yes,
I could implement in yast2-scanner that the user can enter
his trusted networks and then yast2-scanner would append those
values to FW_TRUSTED_NETS in /etc/sysconfig/SuSEfirewall2.

(In reply to comment #32)
> Let's see if reasonable firewall settings are possible
> to allowe scanning via network even with active firewall.
> 
> Regarding a specific port range for saned, see "man saned":
> -----------------------------------------------------------------
> The saned.conf configuration file contains both options
> for the daemon and the access list.
> 
> data_portrange = min_port - max_port
> 
> Specify the port range to use for the data connection.
> Pick a port range between 1024 and 65535; don't pick a
> too large port range, as it may have performance issues.
> Use this option if your saned server is sitting behind
> a firewall. If that firewall is a Linux machine, we strongly
> recommend using the Netfilter nf_conntrack_sane module instead.
> -----------------------------------------------------------------
> 
> I do not understand the "instead" therein.
> It looks as if usage of nf_conntrack_sane would mean
> that one cannot use data_portrange in /etc/sane.d/saned.conf
> additionally?

You can. But then using the module doesn't make much sense.

> I do not understand how a (presumably small) port range
> could make it more secure.

Opening ports never make anything more secure :-) Restricting the
ports to a range that is not used automatically prevents accidental
access to local services.

> I would think that the smaller the port range,
> the easier it is for an eavesdropper to sniff packages
> and the easier for an attacker to attack a system
> because he knows the ports of interest in advance?

Doesn't matter.

> Regardless of the port range for the data connection:
> The saned listens on the well-known port "sane-port" (6566)
> and according to "man saned"
> ------------------------------------------------------------------
> First and foremost: saned is not intended to be exposed
> to the internet or other non-trusted networks.
> Make sure that access is limited by ... a firewall setup. 
> ------------------------------------------------------------------
> so that first and foremost our firewall setup must
> protect port 6566 against access from the Internet
> any any other non-trusted networks.
> 
> Ludwig,
> wouldn't only the one following manual setting by the user
>   FW_TRUSTED_NETS="192.168.1.0"
> be already sufficient and a reasonable firewall setting
> to make scanning via network possible even with active firewall
> (provided that the 192.168.1.0 network is trusted by the user)?

It would be FW_TRUSTED_NETS="192.168.1.0/24"

> If yes,
> I could implement in yast2-scanner that the user can enter
> his trusted networks and then yast2-scanner would append those
> values to FW_TRUSTED_NETS in /etc/sysconfig/SuSEfirewall2.

The yast2-scanner module would be the only one doing such things so
I'd not recommend that. IMO the service file with port range
specification is the simplest way. The UI could still warn if the
user choses that option.

I assume you mean something like
having in /etc/sane.d/saned.conf
-------------------------------------------------------------------
data_portrange = 10000 - 10100
-------------------------------------------------------------------
together with a
/etc/sysconfig/SuSEfirewall2.d/services/sane
which contains accordingly 
-------------------------------------------------------------------
TCP="sane-port 10000:10100"
-------------------------------------------------------------------

But this alone is not sufficiently secure because
this alone just opens ports 6566 and 10000 - 10100
for any access from any host or network.

Therefore additionally I need a firewall setup to protect
access to those posts from any non-trusted hosts and networks
i.e. I need a firewall setup to allow access to those posts
only from explicitely stated trusted hosts and/or networks.

How can I do the latter?



By the way:

Meanwhile I think the whole basic firewall setup based upon ports
is mostly useless.

I think the basic firewall setup might be better based
"first and foremost" upon trusted hosts and networks.

Reasoning:

For the INT zone it does not make sense because an active firewall
for "INT" makes it effectively "EXT" (see comment #26).

Opening ports in the EXT zone does also make not much sense
because allow any access from any host or network to particular
ports does not provide any protection for this ports.

As far as I see the only reason for a firewall setup based upon ports
is when certain services are listening but access should be allowed
only to some of them (e.g. allow access to the HTTP server
but do not allow access to whatever other running server).
But when no access is allowed to a service, why is its server
process listening at all on the outer network (e.g. why is
the server not only listening on the loopback interface)?

In contrast when I could specify via basic firewall setup
which hosts and networks are trusted (all others are then
untrusted), the question which ports/services are allowed
to be accessed from the trusted hosts and networks
is of secondary importance (by default all ports/services
are allowed to be accessed from trusted hosts and networks).

(In reply to comment #34)
> I assume you mean something like
> having in /etc/sane.d/saned.conf
> -------------------------------------------------------------------
> data_portrange = 10000 - 10100
> -------------------------------------------------------------------
> together with a
> /etc/sysconfig/SuSEfirewall2.d/services/sane
> which contains accordingly 
> -------------------------------------------------------------------
> TCP="sane-port 10000:10100"
> -------------------------------------------------------------------
> 
> But this alone is not sufficiently secure because
> this alone just opens ports 6566 and 10000 - 10100
> for any access from any host or network.

... in that zone

> Therefore additionally I need a firewall setup to protect
> access to those posts from any non-trusted hosts and networks
> i.e. I need a firewall setup to allow access to those posts
> only from explicitely stated trusted hosts and/or networks.
> 
> How can I do the latter?

Manually. Comment #26.
 
> Meanwhile I think the whole basic firewall setup based upon ports
> is mostly useless.
> 
> I think the basic firewall setup might be better based
> "first and foremost" upon trusted hosts and networks.

Depends on the network setup. If you trust IP addresses you have to
trust your router to not forward forged addresses. That's not the
case e.g. if you have a laptop that connects to different wlans and
has FW_TRUSTED_NETS=something. Anyone in the wlan could configure
itself with an address of that range.

> Opening ports in the EXT zone does also make not much sense
> because allow any access from any host or network to particular
> ports does not provide any protection for this ports.

Yes. Open port means open port. That's what people get by clicking
on "open port" :-)

> As far as I see the only reason for a firewall setup based upon ports
> is when certain services are listening but access should be allowed
> only to some of them (e.g. allow access to the HTTP server
> but do not allow access to whatever other running server).
> But when no access is allowed to a service, why is its server
> process listening at all on the outer network (e.g. why is
> the server not only listening on the loopback interface)?

Who knows why people configure their system one way or another.
In any case SuSEfirewall2 primarily works based on interfaces and
zones rather than trusting IP address ranges. So if you want a
configuration that makes sense use separate zones.

Thanks a lot!

"if you want a configuration that makes sense use separate zones"
is exactly what I also think (see comment #22).

Trusted networks should have well separated network interfaces
so that those network interfaces can be assigned to the INT zone
to have the trusted network well separated from the rest.

Anything else is a problematic mix-up of trusted and
non-trusted stuff in one same network environment.

I will enhance the help text in yast2-scanner accordingly
so that users hopefully better understand what they may set up
in which particular kind of their network environments.

I will not implement support for sophisticated firewall setup
in problematic network environments in yast2-scanner.
Such kind of firewall setup must be done via yast2-firewall
which is THE tool for a more sophisticated firewall setup.

(In reply to comment #33)
> (In reply to comment #32)
> > data_portrange = min_port - max_port
...
> > a firewall. If that firewall is a Linux machine, we strongly
> > recommend using the Netfilter nf_conntrack_sane module instead.
> > -----------------------------------------------------------------
> > 
> > I do not understand the "instead" therein.
> > It looks as if usage of nf_conntrack_sane would mean
> > that one cannot use data_portrange in /etc/sane.d/saned.conf
> > additionally?
> 
> You can. But then using the module doesn't make much sense.

I'd even say it makes much sense and you _should_ use data_portrange.
My understanding (based on firewalling FTP) is:
a) you open (only) the sane port in the firewall
b) you add the data_portrange ports to *_ACCEPT_RELATED_*:
   FW_SERVICES_ACCEPT_RELATED_EXT="0/0,tcp,,20000:21000"
   These ports will not be open in general. They will only be opened by the
   nf_conntrack_sane module to a specific client while accessing the scanner.

(Ludwig, please correct me if I'm wrong.)

I guess "man saned" is based on the config / method SuSEfirewall had in openSUSE 10.x and older: just open the sane port (part "a)") and let the nf_conntrack_* module open whatever related ports it wants (part "b)" was not needed in openSUSE <= 10.3).

Since 11.0 you have to specify / allow the related ports in the firewall explicitely. (If you don't specify data_portrange in saned, you would have to add something like 1024:65000 to *_ACCEPT_RELATED_* which would potentially open all highports for RELATED connections.)

That said: AFAIK /etc/sysconfig/SuSEfirewall2.d/services/* files don't support the *_ACCEPT_RELATED_* part - but that would be a separate feature request ;-)

BTW: I don't recommend using the 10000:10100 range - 10024 is used by amavis on many systems, and 10025 by postfix taking the mail back from amavis.

FYI:
"man saned" is not related to SuSEfirewall and/or openSUSE
because "man saned" shows the current upstream man page
from the SANE project sane-backends sources "as is".
By the way:
http://www.sane-project.org/man/saned.8.html
seems to be outdated because the content there
is what I remember from older sane-backends versions,
in particular the "RESTRICTIONS" part therein.

(In reply to comment #37)
> (In reply to comment #33)
> > (In reply to comment #32)
> > > data_portrange = min_port - max_port
> ...
> > > a firewall. If that firewall is a Linux machine, we strongly
> > > recommend using the Netfilter nf_conntrack_sane module instead.
> > > -----------------------------------------------------------------
> > > 
> > > I do not understand the "instead" therein.
> > > It looks as if usage of nf_conntrack_sane would mean
> > > that one cannot use data_portrange in /etc/sane.d/saned.conf
> > > additionally?
> > 
> > You can. But then using the module doesn't make much sense.
> 
> I'd even say it makes much sense and you _should_ use data_portrange.
> My understanding (based on firewalling FTP) is:
> a) you open (only) the sane port in the firewall
> b) you add the data_portrange ports to *_ACCEPT_RELATED_*:
>    FW_SERVICES_ACCEPT_RELATED_EXT="0/0,tcp,,20000:21000"
>    These ports will not be open in general. They will only be opened by the
>    nf_conntrack_sane module to a specific client while accessing the scanner.

Hmm, that could work indeed.
 
> That said: AFAIK /etc/sysconfig/SuSEfirewall2.d/services/* files don't support
> the *_ACCEPT_RELATED_* part - but that would be a separate feature request ;-)

Oh it already does :-)

> BTW: I don't recommend using the 10000:10100 range - 10024 is used by amavis on
> many systems, and 10025 by postfix taking the mail back from amavis.

That's weird. Amavis shouldn't be using that port either I guess. For ftp services we use 30000:30100 so that could be used for sane too.

FYI regarding "By the way" in comment #38:
I filed an upstream bug report regarding
"man/saned.8.html on the website looks outdated"
https://alioth.debian.org/tracker/index.php?func=detail&aid=312165&group_id=30186&atid=410366

Ludwig,
could you describe or point to documentation how
/etc/sysconfig/SuSEfirewall2.d/services/* files
do support *_ACCEPT_RELATED_* because
/etc/sysconfig/SuSEfirewall2.d/services/TEMPLATE
reads
"Only the variables TCP, UDP, RPC, IP and BROADCAST are allowed"
and the only possible values for each of those variables is a
"space separated list of allowed ... ports".

(In reply to comment #41)
> Ludwig,
> could you describe or point to documentation how
> /etc/sysconfig/SuSEfirewall2.d/services/* files
> do support *_ACCEPT_RELATED_* because
> /etc/sysconfig/SuSEfirewall2.d/services/TEMPLATE
> reads
> "Only the variables TCP, UDP, RPC, IP and BROADCAST are allowed"
> and the only possible values for each of those variables is a
> "space separated list of allowed ... ports".

Gotcha! :-) You are not on 11.2 and you didn't install the updates for 11.1. Meanwhile that paragraph looks like this:

# Only the variables TCP, UDP, RPC, IP, BROADCAST, RELATED and
# MODULES are allowed. More may be supported in the future.

I am just on the product and OS what this bug report is about ;-)
but you are right, I do not install updates unless I really
really need a particular one.

Fixed in YaST SVN revision 60192.

New version 2.19.0 with this RPM changelog entry:
--------------------------------------------------------------------
- Replaced overcomplicated but nevertheless mostly useless code
  for using the YaST SuSEFirewall module by simple generic code
  in a ShowFirewallPopup function in the same way as it works
  for yast2-printer (compare Novell/Suse Bugzilla bnc#549065)
  and enhanced the help text "Regarding Firewall",
  (see Novell/Suse Bugzilla bnc#551282).
--------------------------------------------------------------------

The enhanced the help text "Regarding Firewall" is:
--------------------------------------------------------------------
Regarding Firewall

Clients contact the saned via the sane-port (TCP port 6566)
but scanning data is transferred via an additional random port.
Therefore is is not sufficient for scanning via network
to open only port 6566 in the firewall.

You can specify a port range for the data connection
in the saned config file /etc/sane.d/saned.conf
via an entry like 'data_portrange = 30000 - 30100'
and then open port 6566 and the port range 30000:30100
in the firewall.

The default firewall settings protect your host from external access.
Allowing access from the external network (i.e. for the external zone)
does not make sense because scanning documents requires
physical scanner access by trusted users.

On the other hand the default firewall settings allow
any access from an internal (i.e. trusted) network
unless you have firewall protection enabled for the internal zone.
But an active firewall for the internal zone (i.e. for the
trusted network zone) does usually also not make much sense
because this makes the internal zone effectively the same
as the external zone.

The simplest and most secure way to do scanning via network
is when the trusted network has a well separated network interface
to have the trusted network well separated from the rest.
Then those network interface can be assigned to the internal zone
via the YaST Firewall setup module and scanning via network
will work without any further firewall setup.

Anything else may result a problematic mix-up of trusted and
non-trusted network traffic in one same network environment.
For example when both the internal network and the connection
to the Internet happens via one same 'router-box' device.
In such a case the 'router-box' device is the crucial point
(in particular the crucial point of possible failure)
regarding network security.

In any case a plain opening of a port for the external zone
is dangerous because it allows access from any foreign host
to those port but does not provide any protection for
the service which is accessed via this port (e.g. the saned).
Instead of plain opening of ports for arbitrary access
one should additionally specify in the firewall setup
from which hosts and networks the access is allowed.
The YaST Firewall setup module can also be used
for such kind of more sophisticated firewall setup.
--------------------------------------------------------------------

Submitted to YaST:Head as submitreqest 27529 and accepted it.

Submitted to openSUSE:Factory as submitreqest 27530:
$ osc request list openSUSE:Factory yast2-scanner
 27530  State:new     Creator:jsmeix       When:2009-12-23T15:58:18
        submit:       YaST:Head/yast2-scanner -> openSUSE:Factory
        Comment: 'version upgrade to 2.19.0'

In YaST SVN revision 60474:

Reduced the too long help text 'regarding firewall'
(see comment #44) but added a link to
'SDB:CUPS and SANE Firewall settings' at
http://en.opensuse.org/SDB:CUPS_and_SANE_Firewall_settings

Submitted as yast2-scanner version upgrade to 2.19.1
to YaST:Head (request 30279) and openSUSE:Factory (request 30280).