SDB:CUPS and SANE Firewall settings

SANE 是「让扫描仪访问变得简单！(Scanner Access Now Easy)」的缩写。它提供了对扫描仪硬件 (例如，平板扫描仪）的标准访问，SANE 网络值守程序 (daemon) 允许远程客户端访问连接在本地主机上的扫描仪。关于如何设定 SANE 的基本信息请参阅 [[SDB:配置扫描仪]，SANE 网络值守程序相关请见 http://www.sane-project.org/man/saned.8.html

本文章中的防火墙表示 SuSEfirewall2，其使用 iptables -- 一个用于 Linux 内核网络数据包过滤的管理工具。其它的防火墙软件可能在工作中表现得完全迥异。

关于防火墙的常规知识

请参考 SuSEfirewall2 软件包的文档，位于 /usr/share/doc/packages/SuSEfirewall2/ 文件夹以及其配置文件 /etc/sysconfig/SuSEfirewall2 中的注释，和有关 SuSEfirewall2 的在线文档。

另外还可以参考「openSUSE 安全指南」手册中的「伪装和防火墙」章节，其安装在 opensuse-manual_<locale> 软件包中，例如 opensuse-manual_en 软件包中的 /usr/share/doc/manual/opensuse-manual_en/manual/index.html。

后者也有在线版本，例如，针对 openSUSE 12.3 的版本可在 http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/ 找到。

关于防火墙的基本知识

防火墙用于保护您的主机不受来自网络的那些您并不想要的访问所害。

要通过网络访问您的主机，必须在您的主机上至少运行一个服务器进程。每种服务器进程都可以通过一个特殊的网络端口访问。例如网页服务器进程 (例如 Apache 网页服务器) 可通过 HTTP 端口 80 访问，CUPS 打印服务器进程可通过 IPP 端口 631 访问。

如果您的主机上没有运行服务器进程，您的主机就不可通过网络访问，因而您就不需要一个防火墙。不管怎样啦出于安全考虑您不应该关闭防火墙，因为当意外启动了某种服务器进程时，它将保护您的计算机不受来自网络的那些您并不想要的访问所害。

相反，如果您的主机上运行了一个或更多的服务器进程，并且您在防火墙中打开了它们相关的短偶，您就移除了对您主机上的这些服务器的保护，因为您只需要防火墙去保护运行中的服务器不受来自网络的并不想要的流量干扰。另一方面对于那些应该能够被网络访问的服务器进程，您必须在防火墙中打开对应的端口。这意味着需要被网络访问的服务器进程不应该受防火墙保护。可通过网络访问的服务器进程必须自行提供足够的安全性。这就是您为什么要应用针对可通过网络访问的服务器进程的安全更新，以及全部与这些服务器进程有关的安全更新，的原因。

若您的主机只连接到了一个受信任的内部网络，有一个专用的防火墙机器来保护整个内部网络，您可能可以关闭您的主机上的防火墙。

例如假设您有一个运行着您的网站的网页服务器。另外也运行着 CUPS 服务器进程因为也连接着一个打印机，有时您会直接在服务器上打印一些东西。

当然啦，任何用户都可以从互联网的任意位置浏览您的主页以及您的网站提供的任何东西。

但另一方面，您服务器上的任何其它东西都不应该被来自互联网的任何用户访问。尤其是，随机用户不应该能够浪费您的纸张和在您的打印机上打印，对吧。

因此您运行了一个防火墙，允许到 HTTP 端口 80 的任何网络流量通过 (例如，端口 80 在防火墙上是开着的) 来允许任意用户访问网页服务器。

但另一方面，防火墙阻止对任何其它端口的任何网络访问 (例如，全部其它端口在防火墙上都是关着的)，因此尤其是 CUPS 服务器不会被网络访问，因此您的打印机将能避免为来自网络的您并不想要的生人所用。

对于这种简单的「要么有要么没有」的配置 (允许对网页服务器的任何网络访问，而禁止对 CUPS 服务器的任何访问），简单地打开和关闭防火墙中的端口就足够了。

现在假设您又有了一台服务器，运行着网页服务器和 CUPS 服务器，但现在本地连接的打印机应该能够被一个受信任的内部网络的用户所访问。

受信任的网络意味着您信任全部可以访问此网络的用户。可以将计算机联网的用户 (例如，笔记本上可使用 "root" 账户的人) 都可以发送和接受任何网络流量。这样的用户可以在网络中进行窃听，也可以伪造网络中的任何服务器 (除了那些额外的妥善设置过的网络交互机硬件，其限制了用户的网络访问)。

简单地打开和关闭防火墙中的端口不再够用了，因为如果在防火墙中打开了 CUPS 的 IPP 端口而不加进一步限制的话，来自互联网的任何用户也就又可以使用您的打印机打印来浪费您的纸张了。

在防火墙中应用进一步限制的关键点在于辨别网络流量是否来自于您的受信任的内部网络。

因此您的受信任的内部网络流量必须与其它非信任的网络流量区别开。区别不同类型网络流量的最好方法使用不同的网络。最简单和最安全的维护分离的网络的解决方案是使用分离的网络硬件。

因此用于您的受信任网络的网络硬件必须与用于其它的网络硬件分离开。在本例中，通常在您的服务器上配置两个网卡接口，一块供您的受信任的内部网络连接，另一块用于互联网连接。因此您的网络配置中有两个网络接口，名为，例如 "eth0" 和 "eth1"。

Finally assume you have again a server machine with a network interface for the Internet connection and a second network interface for your trusted internal network. On the server machine a web-server and a CUPS server are running and the locally connected printer should be accessible only by the trusted users of your internal network.

In this case you would first and foremost assign the network interface for the Internet connection to the external (EXT) zone of the firewall and the network interface for the internal network to the internal (INT) zone of the firewall.

By default the firewall prevents any network access via the network interface which belongs to the external zone but it lets any network traffic pass via the network interface which belongs to the internal zone.

Note that access direction matters. The firewall prevents access of your host from the Internet but not the other way round. Therefore you can still access servers in the Internet from your host. In particular you can access all those web servers which run out there in the Internet with your browser program. For example you can access the web server which runs on www.opensuse.org to get the openSUSE home page from it even when the firewall prevents access of your host from the Internet. Have in mind that this way all what you request from the Internet gets delivered to your system. The firewall does not protect you when you visit a malicious web server with your browser program which will get its malicious web pages, see in particular the Wikipedia article http://en.wikipedia.org/wiki/Drive-by_download about "Drive-by download". Furthermore you can submit any data to all those servers which are accessible out there in the Internet. The firewall does not protect you when you submit private or confidential data to a wrong server, see in particular the Wikipedia article http://en.wikipedia.org/wiki/Phishing about "Phishing". If you cannot trust the network you must not type in your authentication credentials into arbitrary web interfaces which are "just accessible" for you. If you cannot trust the network you must not submit private or confidential data to arbitrary servers which are "just accessible" for you. If you cannot trust a network you must not release private or confidential data into the network - except you had set up in advance sufficient encryption and authentication to ensure that only your intended recipient can decode your data regardless that others in the network could have also received your encrypted data.

As a result you can still browse the Internet without restrictions but no server process on your server machine is accessible from the Internet while all your server processes are accessible from your internal network.

As a second step you open HTTP port 80 for the external zone in the firewall to allow arbitrary users to access your web server from any location in the Internet.

In the end the web server is accessible for anybody from anywhere (i.e. from the Internet and from the internal network) but the CUPS server is only accessible for users in the trusted internal network.

As another example assume you have a laptop which you use while traveling but also in trusted networks in the office and at home.

When the laptop has a single network interface card, trusted and non-trusted network traffic will mix up. Therefore you assign the network interface to the external firewall zone to protect the laptop against unwanted access via any network. Usually it does not make sense to have any server process running on the laptop because when the laptop is moved from one network to another network, the server process becomes suddenly unavailable in the one network but available in the other network which results an unpredictable behaviour for the users which use your server. But when no server process is running on the laptop, it is not accessible via network so that no firewall is needed. Nevertheless to be on the safe side you should not switch off the firewall because it will protect the laptop against unwanted access when whatever kind of server process was started by accident.

Assume you must run whatever server process on the laptop. Now you need to get trusted and non-trusted network traffic separated. You could use a wireless network interface card for all kind of untrusted network connections while traveling and an additional network interface card with a traditional wired network cable connection which you use only in the office and at home. You would assign the network interface for the wireless card (e.g. "wlan0") to the external firewall zone and the network interface for the office and at home (e.g. "eth0") to the internal firewall zone. This way it would be actually fool-proof to keep the laptop protected against unwanted access via network: As long as the connection to a trusted network exists (there is no firewall protection for the wired network) you cannot move the laptop into a non-trusted network environment. Before you can do this you must unplug the traditional wired network cable which instantly makes the laptop no longer accessible because the firewall protects the wireless network.

In this article a trusted network means that you trust all users who can access this network so that you can open particular ports for particular server processes in the firewall for this network.

From the firewall point of view there is no such thing as "partially trusted" for a particular network because one cannot "partially open" a port in the firewall. Either the port is open for a particular network or not. Accordingly either you trust all users to access a server process in a particular network or not.

Do not confuse what "trusted network" means here with a more general meaning of trust. You may have different networks where you let the users of each network access more or less sensitive server processes. For example a trusted internal network with access to an internal print server where also confidential documents are printed on an internal printer device and a separated network for guests with access to a separated print server plus a separated printer device where guests can print their documents. In each of the two networks you trust all the users to access the same kind of server process but both networks do not have the same level of trust from a general point of view. The simplest and most secure solution to maintain security is also used here: Separated hardware. Separated networks with separated print sever machines plus separated printer devices. Why separated printer devices? You may Google for "network printer security risk".

When Network Security is Likely to be Doomed

The basic idea to increase likelihood that your network security is doomed is to mix up trusted and non-trusted network traffic in one same network environment.

Save money and use the same network hardware for trusted and non-trusted network traffic and as a consequence pay with an increased likelihood that your network security is doomed and with an increased effort to maintain your network security.

Use one same "router-box" device for both your trusted internal network and the connection to the Internet. In such a case the router-box device is the crucial point (in particular the crucial point of possible failure) regarding network security. Usually such router-box devices provide their own built-in firewall (which may work totally different than the SuSEfirewall2). Carefully read the documentation for your particular router-box how to set up its built-in firewall and which kind of protection it can provide. Perhaps it supports even separation of your internal network from the Internet via private IP addresses like 192.168.xxx.xxx together with network address translation (NAT), also known as network masquerading. If your router-box supports private IP addresses together with NAT (and if there is no security flaw in the router-box), your hosts are in a trusted internal network where the router-box is a dedicated firewall machine which protects your whole internal network so that you may even switch off the firewall on your hosts (provided you trust your router-box).

Another way to increase likelihood that your network security is doomed is to use wireless communication for your trusted internal network traffic. In this case arbitrary users within a certain proximity out of your building have physical access to the electromagnetic waves which belong to the network traffic of your trusted network. Those users do have a particular kind of physical access to your internal network. Therefore your network security totally depends on the trustworthiness of the security protocol which is used for network traffic encryption like the insufficient and deprecated WEP (Wired Equivalent Privacy) and its successors like WPA (Wi-Fi Protected Access) and finally WPA2 also known as RSN (Robust Secure Network). As of this writing (January 2010), only WPA2/RSN is considered secure, provided there is no WPS (Wi-Fi Protected Setup) functionality enabled which is insecure (Google for "wpa2 wps crack"). But WPA2 may not work with some older wireless network cards. Meanwhile (September 2012) WPA2 might be no longer secure because it seems possible to figure out its NT hash. Additionally there are other non-standard successors of WEP which could be insecure. Carefully read the documentation for your wireless network devices how to set up network traffic encryption for each of them and keep yourself continuously up to date regarding security issues or do not use wireless communication for your trusted internal network traffic.

Of course the best way to increase likelihood that your network security is doomed is to do all your network traffic via one same wireless router-box device. In this case carefully read the documentation for your particular wireless router-box how to set up its built-in firewall and its network traffic encryption protocol.

On the other hand this kind of network environment is common nowadays in particular for home networks and small office networks where unfortunately often unexperienced users must maintain their network security.

Assume you have a wireless router-box device which provides the Internet access for a workstation at home to which a printer is connected. Additionally you have a laptop and it should be possible to use the printer from the laptop. The workstation and the laptop have only a wireless network interface card to access the router-box.

Plain opening of a port for the external zone in the firewall destroys your network security because it removes any firewall protection for the service which is accessed via this port. When the CUPS print server process is the only server process which runs on the workstation, opening its IPP port 631 removes effectively any firewall protection from the workstation.

Instead inspect your network configuration to find out if different network interfaces are used for the Internet connection and for your internal network. For example there might be a network interface like "dsl0", "ppp0" or "ippp0" for the Internet connection and another network interface like "eth0" or "wlan0" for the internal network. In this case assign the network interface for the Internet connection to the external (EXT) zone of the firewall and the network interface for the internal network to the internal (INT) zone of the firewall.

In particular regarding "Small home network" see the SuSEfirewall2 configuration examples /usr/share/doc/packages/SuSEfirewall2/EXAMPLES or /usr/share/doc/packages/SuSEfirewall2/EXAMPLES.html

If one same network interface like "eth0" or "wlan0" is used for the Internet connection and for the internal network, assign the network interface to the external (EXT) zone and specify the IP address of the trusted internal network via FW_TRUSTED_NETS in the firewall configuration.

Regarding FW_TRUSTED_NETS see the SuSEfirewall2 configuration example "Laptop in private network but with additional public IP adresses" which applies also for any host (regardless if it is a laptop, a workstation or a server) when the same network interface is used for trusted and non-trusted network traffic.

Note that FW_TRUSTED_NETS does not allow incomming UDP broadcast packages. To accept also UDP broadcast packages specify the matching UDP port(s) where UDP broadcast packages should be accepted via FW_ALLOW_FW_BROADCAST_EXT in the firewall configuration.

But a FW_TRUSTED_NETS setup can be only a best effort attempt to get some kind of network security because IP addresses could be spoofed and in case of FW_ALLOW_FW_BROADCAST_EXT also malicious UDP broadcast package on the specified port(s) would be accepted from any possibly malicious server in the Internet.

In this case you should change your network hardware so that your trusted internal network traffic becomes well separated from the non-trusted network traffic.

What is Specific Regarding Firewall Setup for Printing

The CUPS server process (the cupsd) is accessible via TCP via the IPP port 631 to accept print jobs. By default it is only accessible via the internal interface of the local host (lo) to accept print jobs so that printing is only possible directly from the local host where it runs but not from any remote host via network. If the cupsd runs in its default mode, you do not need a firewall to protect your printer against unwanted access. Nevertheless to be on the safe side you should not switch off the firewall because it will protect your printer against unwanted access via network when the cupsd is not running in its default mode.

First and foremost have the following section in the SuSEfirewall2 documentation in mind: /usr/share/doc/packages/SuSEfirewall2/README reads

Some words about security:
...
Run only those services you actually need.
Think twice before opening them to the Internet.
...
Do not expose services that are designed
for use in a LAN to the Internet (like CUPS).

It is crucial to limit access to CUPS to trusted users.

Printing documents lets the user access and contol the printer hardware because in the end the printer processes data which is basically a program which controls the printer machine.

Usual network printer devices (printers with a built-in network interface, see SDB:Printing via TCP/IP network) are no longer only "dumb" printing units. Nowadays network printers are also real computers with full network capabilities. When it looks like a printer, acts like a printer, sounds like a printer, it could be a computer! A user who controls a network printer controls a printing unit plus a computer with network access. Therefore it is crucial to limit access to network printer devices to trusted users (Google for "network printer security risk" - see above).

Furthermore any user who is allowed to submit print jobs could do some kind of denial of service attack: Either by submitting huge nonsense print jobs which waste toner/ink and paper or by submitting a specific tiny PostScript print job which lets PostScript processing software (like Ghostscript) or the printer's built-in PostScript interpreter hang up in an endless loop. The latter may result in loss of print jobs on PostScript printers when subsequent jobs of other users were already sent into the printer's memory while the tiny job is blocking the printer's actual printing unit in an endless loop. If the blocking job can only be aborted by a printer reset, the other jobs in its memory are usually lost.

To protect your printer against unwanted access:

Do not open the CUPS IPP port 631 for the external zone in the firewall.

On the other hand the firewall lets by default any network traffic pass via network interfaces which belong to the internal zone. Therefore when the network interface for the internal network is assigned to the internal firewall zone, client hosts in the internal network can access the CUPS server process and submit print jobs. Independent of the firewall setup the CUPS server must additionally be configured to accept print jobs from those client hosts (which is not the default, see above).

To make your CUPS server accessible:

Assign the network interface which belongs to the internal network to the internal zone of the firewall.

Additionally by default the CUPS server process is accessible via UDP via IPP port 631 to accept any incomming information about remote print queues from any remote host. A CUPS print server can publish information about its queues in the network by sending UDP broadcasts and/or regular UDP (unicast) packets. Accordingly the CUPS server processes which run on the client hosts accept by default incomming information about remote print queues.

In this way, the queues of the server are available on the clients without any CUPS-specific configuration on the client hosts. Users on the clients can browse the queues on various servers. Therefore the whole stuff is called "CUPS Browsing". See the section "Intrinsic design of CUPS <= 1.5 for printing in the network" at SDB:CUPS_in_a_Nutshell and note the section "CUPS 1.6 has major incompatible changes" therein.

The crucial point regarding network security is that client hosts must not accept remote print queue information from untrusted (i.e. external) CUPS servers.

Otherwise possibly confidential print jobs could be sent to untrusted CUPS servers. See the "print job phishing" thread on the cups.general Newsgroup: http://www.cups.org/newsgroups.php?gcups.general+T+Q%22print+job+phishing%22 which reads in particular:

When printing in the network is done via
usual CUPS Browsing, on the other workstations
in the network all announced queues with
the same name build automatically a so called
"implicite class" so that a print job which
is sent to the destination with this name
is printed on an arbitrary printer in this class.
...
A malicious user ... can set up queues ... with
the same name as queues on the official CUPS server
and announce his queues in the network.
...
on the other workstations their users cannot
notice that duplicated queues exist so that the
malicious user could do "print job phishing".

If you wonder why this behaviour is the default, have in mind that CUPS is designed for use in an internal network where the usability and convenience benefits (no CUPS-specific configuration on the client hosts) outweigh the security risk in an external network where furthermore by default the firewall provides protection. See the above "print job phishing" thread which reads in particular:

To summarize:
1. Once a malicious user gains access to a network,
there are numerous ways to compromise that network.
2. CUPS browsing attacks are easy to detect.
3. Disabling key features of CUPS browsing does not
offer any added security while making printing
much less usable.
4. Adding a signing key for browse packets would
make CUPS browsing more secure but would require
active configuration of every system on the network
to be effective.
5. Using alternate protocols and/or manual
configuration of shared printers can offer improved
security at the expense of usability/convenience.

By default the firewall prevents any access via network interfaces which belong to the external zone and by default all network interfaces belong to the external zone. Therefore by default the firewall rejects or drops any remote print queue information from any host so that client hosts are protected against "print job phishing".

In general if you cannot trust the network you must not submit your private or confidential print jobs to arbitrary printers (i.e. to arbitrary print queues) which are "just accessible" for you.

To protect your host against "print job phishing":

Do not open the CUPS IPP port 631 for the external zone in the firewall.

On the other hand the firewall lets by default any network traffic pass via network interfaces which belong to the internal zone. Therefore when the network interface for the internal network is assigned to the internal firewall zone on the client hosts, remote print queues which are published by internal CUPS print servers will be available on the client hosts.

To make published remote print queues available:

Assign the network interface which belongs to the internal network to the internal zone of the firewall.

As example for an exceptional case assume you have a laptop which you use while traveling but also in trusted networks in the office and at home where you like to use published remote print queues.

When the laptop has only a single network interface, trusted and non-trusted network traffic is mixed up so that the network interface must be assigned to the external firewall zone to protect the laptop against unwanted access via any network.

In this case you cannot open the CUPS IPP port 631 for the external zone in the firewall because this removes the firewall protection from the laptop in any network.

You simply cannot use arbitrary information about remote print queues from arbitrary hosts when trusted and non-trusted network traffic is mixed up.

In particular you cannot use FW_ALLOW_FW_BROADCAST_EXT="631" in this case because this would open the CUPS IPP port 631 for UDP broadcasts for the external zone so that remote print queue information from untrusted (i.e. external) CUPS servers would be accepted.

Instead you must specify on the laptop the trusted CUPS servers (usually one server for the office and another one for at home) and poll the list of available print queues from the trusted CUPS servers via a so called "BrowsePoll" setting in the CUPS configuration of the laptop, see SDB:CUPS_in_a_Nutshell the section "Configuration of the clients", "Special cases".

Assume printing from the laptop happens only in the office where no locally connected printer is used but only one single CUPS server of the company. Then it is no longer needed to run a CUPS server process on the laptop. Instead a so called "client-only" configuration could be set up, see SDB:CUPS_in_a_Nutshell the section "Configuration of the clients", "Client-only configuration". A possible drawback is that application programs may be delayed for some time (until a timeout happens) when they try to access the CUPS server of the company in another network where it is actually not available (e.g. while traveling). Usually it is a host name resolution (DNS) timeout which causes the delay so that it may help to have a hardcoded entry for the CUPS server of the company in the /etc/hosts file.

Neither for "BrowsePoll" nor for a "client-only" configuration you need to open the CUPS IPP port 631 in the firewall.

What is Specific Regarding Firewall Setup for Using Scanners

For using scanners via network the SANE network daemon (the saned) is the server process which must run so that remote clients can access scanners which are connected (usually via USB) to the local host.

When you have a network printer scanner copier all-in-one device with a built-in network interface so that the device is directy accessible via network, it is usually used in a different way by "stand-alone scanning to e-mail" where no SANE software (in particular no saned) is involved (see the section "Scanning via Network" in SDB:Configuring Scanners).

The saned is used by the clients via two kind of network connections. In addition to a control connection (via port 6566) saned also uses a separated data connection (for the actual scanning data). The port of the data connection is selected by the operating system and could no be specified so that all ports above 1024 must have been accessible (i.e. open in the firewall) for connections from the clients. The newest saned version provides support to specify a range of ports for the data connection in the saned configuration file /etc/sane.d/saned.conf via an entry like "data_portrange = 30000 - 30100" so that only those ports would have to be open in the firewall. But the latter does not provide real better security because in the end the saned must be accessible for using scanners via network.

See what the saned man page reads:

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.

Additionally remember this section in the SuSEfirewall2 documentation: /usr/share/doc/packages/SuSEfirewall2/README reads

Some words about security:
Run only those services you actually need.
Think twice before opening them to the Internet.
Do not expose services that are designed
for use in a LAN to the Internet.

To protect your host against unwanted access:

Do not open the sane-port 6566 or any other port regarding using scanners for the external zone in the firewall.

On the other hand the firewall lets by default any network traffic pass via network interfaces which belong to the internal zone. Therefore when the network interface for the internal network is assigned to the internal firewall zone, client hosts in the internal network can access the SANE server process to access scanners which are connected to the server machine. Independent of the firewall setup the SANE server must additionally be configured to permit access from those client hosts (by default it does not permit access).

To make your SANE server accessible:

Assign the network interface which belongs to the internal network to the internal zone of the firewall.

Alternatively as a best effort setup when one same network interface is used for the Internet connection and for the internal network, assign the network interface to the external zone and specify the trusted internal network via FW_TRUSTED_NETS in the firewall configuration.

Example for FW_TRUSTED_NETS:

Assuming your trusted subnet is 192.168.0.0/24 the entry reads:

FW_TRUSTED_NETS="192.168.0.0/24,tcp,6566"

Saned needs additional ports besides 6566 for the actual data transfer (see above). It is recommend to use the same ports as ftp 30000 - 30100 for this (see Bug 551282#c39). Therefore the port range setting in /etc/sane.d/saned.conf should read:

data_portrange = 30000 - 30100

Instead of opening these ports in the firewall (cf. above "DO NOT ...") additional entries like the following are required (assuming your trusted subnet is 192.168.0.0/24) in the firewall configuration:

FW_TRUSTED_NETS="... 192.168.0.0/24,tcp,30000:30100"
FW_SERVICES_ACCEPT_RELATED_EXT="192.168.0.0/24,tcp,,30000:30100"

Furthermore the kernel module nf_conntrack_sane must be loaded (see this mail http://lists.opensuse.org/archive/opensuse/2011-05/msg00000.html) via the following additional entry for FW_LOAD_MODULES in the firewall configuration:

FW_LOAD_MODULES="... nf_conntrack_sane"

A side note when the subnet is 192.168.0.0/24: Often "router-box" devices that support separation of an internal network from the Internet use by default 192.168.0.0/24 for the internal network to that the above examples match in this case. But 192.168.0.0/24 could cause conflicts. For example when a virtual private network (VPN) should be used between two such internal networks that both have the same "router-box" default 192.168.0.0/24, see http://openvpn.net/index.php/open-source/documentation/howto.html#numbering

Summary

By default the SuSEfirewall2 prevents any network access via network interfaces which belong to the external zone but it lets any network traffic pass via network interfaces which belong to the internal zone.

Both CUPS and SANE provide network services that are designed for use in a LAN and not intended to be exposed to the Internet or other non-trusted networks.

To use printers and scanners in a trusted internal network and have firewall protection against unwanted access from the Internet, set up the SuSEfirewall2 as follows:

Do not open the CUPS IPP port 631 or the sane-port 6566 or any other port for the external zone.

If different network interfaces are used for the Internet connection and for the internal network, assign the network interface for the Internet connection to the external zone and the network interface for the internal network to the internal zone.

Alternatively as a best effort setup when one same network interface is used for the Internet connection and for the internal network, assign the network interface to the external zone and specify the trusted internal network via FW_TRUSTED_NETS (and FW_ALLOW_FW_BROADCAST_EXT in case of UDP broadcasts) in the firewall configuration.

Bottom Line

To use printers and scanners in a trusted internal network and be protected by the SuSEfirewall2 against unwanted access from the Internet, do first and foremost this one single fundamental setup to gain security plus convenience in your network:

Only assign the network interface which belongs to the internal network to the internal zone of the firewall.

SDB:CUPS and SANE Firewall settings

目录

场景

关于防火墙的常规知识

关于防火墙的基本知识

When Network Security is Likely to be Doomed

What is Specific Regarding Firewall Setup for Printing

What is Specific Regarding Firewall Setup for Using Scanners

Summary

Bottom Line

更多信息