SDB:CUPS and SANE Firewall settings

Jump to: navigation, search

This article is rather old and was written with only traditional IPv4 networking in mind.

With nowadays IPv6 networking certain things are rather different so what was true for traditional IPv4 networking could be no longer true for nowadays IPv6 networking.


Situation

You like to use printers and scanners in your network and you like to have firewall protection against unwanted access.

Using printers and scanners via network is likely to happen in particular in home networks and small office networks. Therefore this article provides at first basic information regarding firewall and network security.

CUPS and SANE are systems for using and managing printers and scanners respectively.

CUPS is the acronym for Common Unix Printing System. For basic information how to set up CUPS see SDB:CUPS in a Nutshell and YaST_Printer and regarding CUPS server security see http://www.cups.org/documentation.php/security.html

SANE is the acronym for Scanner Access Now Easy. It provides standardized access to scanner hardware (e.g. a flatbed scanner) and a SANE network daemon that allows remote clients to access scanners which are connected to the local host. For basic information how to set up SANE see SDB:Configuring Scanners and regarding the SANE network daemon see http://www.sane-project.org/man/saned.8.html

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

For openSUSE Leap 42.3 (and prior versions) SuSEfirewall2 was the default firewall iptables-based front-end with rules generated according to the /etc/sysconfig/SuSEfirewall2 configuration file.

For openSUSE Leap 15.0 onwards, firewalld is the default firewall front-end (which still uses the Linux kernel's netfilter framework), and can be configured using the 'firewall-cmd' CLI interface or the graphical 'firewalld-config' utility.

In this article "the firewall" usually means the SuSEfirewall2 or firewalld. Third party firewalls (e.g. a firewall in an Internet "router-box" device) may work quite differently.

Security: Make Things Not Just Work

The intended purpose of security measures is to make things not "just work" which means security causes some kind of annoyance for the user when things do not "just work" out of the box. If everything would "just work" by default, it would be totally insecure.

Things should only work for authorized users. To distinguish authorized users from others, a person who works with a computer must somehow authenticate to be an authorized user which usually happens via a password dialog. Alternatively physical location can be used to distinguish authorized users from others. For example a person who works directly locally at the computer can be automatically logged in as authorized user while in contrast a person who works from remote via network needs to authenticate via password dialog. Additionally the location in the network (i.e. the network environment) can be used to distinguish legitimate access via network from unwanted access. Basically the firewall allows access via network or rejects it by partitioning the network environment into so called "zones" that are used to distinguish legitimate access in one zone from unwanted access in another zone.

In this context security means that in particular access from remote via network must not "just work" by default. Any kind of desired access from remote via network must be explicitly allowed by an authorized user.

General Information About openSUSE Firewalls

For openSUSE Leap 42.3 (and prior), refer to the documentation of the SuSEfirewall2 package in the /usr/share/doc/packages/SuSEfirewall2/ directory and the comments in its configuration file /etc/sysconfig/SuSEfirewall2 and the online documentation about SuSEfirewall2.

For openSUSE Leap 15.0 onwards, the current documentation can be found online in the Security Guide on https://doc.opensuse.org/

Basic Information How the Firewall Works

The firewall is used to protect your host against unwanted access via network.

To access your host via network, at least one server process must run on your host. Each kind of server process is accessible via a particular network port. For example a web server process (e.g. the Apache web server) is accessible via the HTTP port 80 and the CUPS print server process is accessible via the IPP port 631 and the Avahi DNS-SD server process is accessible via the mDNS port 5353.

If no server process is running on your host, your host is not accessible via network so that you do not need the firewall. Nevertheless to be on the safe side you should not switch off the firewall because it will protect your host against unwanted access via network when an unintended server process was started by accident.

If one or more server processes are running on your host and you open their matching ports in the firewall, you remove any firewall protection from your host because you only need the firewall to protect running server processes against unwanted access via network.

On the other hand for server processes which should be accessible you must open the matching ports in the firewall. This means that there cannot be firewall protection for those server processes which should be accessible via network. Server processes which are accessible via network must provide sufficient security on their own. This is the reason why you must apply security updates for server processes which are accessible via network plus security updates for all what is related to such server processes (in particular system libraries that are used by your server processes and things like that).

If your host is connected only to a trusted internal network where a dedicated firewall machine protects the whole internal network, you may switch off the firewall on your host.

For example assume you have a server machine where a web server for your web site runs. Additionally the CUPS server process runs because there is a printer connected which you need once in a while to print something directly on the server machine.

Of course any user should be able to view your home page and whatever else you provide via your web site from any location in the Internet.

But on the other hand nothing else on your server machine should be accessible by arbitrary users from the Internet. In particular arbitrary users out there should not waste your paper and print on your printer.

Therefore you let the firewall pass any network traffic to HTTP port 80 (i.e. port 80 is open in the firewall) to allow arbitrary users to access the web server.

On the other hand you let the firewall prevent any network access for any other port (i.e. all other ports are closed in the firewall) so that in particular the CUPS server is not accessible via network and as a consequence your printer is protected against unwanted access via network.

Plain opening and closing ports in the firewall is sufficient for such kind of simple "all or nothing" configuration (allow any network access to the web server but none at all to the CUPS server).

Now assume you have again a server machine with a running web server and a running CUPS server but now the locally connected printer should be accessible by the users of a trusted internal network.

A trusted network means that you trust all users who can access this network. A user who can connect a computer to a network (e.g. a laptop where the user can work as "root") can send and receive any network traffic. Such a user can eavesdrop on the network and he can also fake any server machine in the network (except additional network switch hardware with an appropriate setup limits the user's network access).

Plain opening and closing ports in the firewall is no longer sufficient because if the IPP port for CUPS would be opened without further restrictions in the firewall, also arbitrary users out there from the Internet could waste your paper by printing on your printer.

The crucial point to apply further restrictions in the firewall is to distinguish whether or not network traffic happens in your trusted internal network.

Therefore your trusted internal network traffic must be separated from the other non-trusted network traffic. The best way to get different kind of network traffic separated is when different networks are used. The simplest and most secure solution to maintain separated networks is when separated network hardware is used.

Therefore the network hardware for your trusted internal network should be separated from the network hardware for the rest. In this case you have usually two network interface cards in your server machine, one where your trusted internal network is connected and the other one for the Internet connection. Consequently your network configuration has two network interfaces named for example "eth0" and "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 zone of the firewall and the network interface for the internal network to the internal 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.

Access direction is crucial: 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 or access a mail server web frontend to get your e-mail 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" and the firewall does not protect you when you get for example malicious e-mails. 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 travelling 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 travelling 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 because it belongs to the internal firewall zone) 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 (because it belongs to the external firewall zone).

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 versus 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" (and see below).

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 pay 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 firewall used in openSUSE). Carefully read the documentation for your particular router-box how to set up its built-in firewall and which kind of protection it provides. Often it supports separation of your internal network from the Internet via private IPv4 addresses like 192.168.xxx.xxx together with network address translation (NAT), also known as network masquerading. If your router-box has a built-in firewall and supports private IPv4 addresses together with NAT (and if there is no security flaw in the router-box), your hosts are in a trusted internal IPv4 network where the router-box is a dedicated firewall machine which protects your internal network. With nowadays IPv6 networking things are rather different. Usually each host gets a public IPv6 address so the hosts are no longer separated from the Internet. In this case the router-box built-in firewall (hopefully) protects the hosts against unwanted access from the Internet. To be more on the safe side additionally a firewall should be running on each host.

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 strangers 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 folks out there 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. Furthermore you need to keep yourself continuously up to date regarding security issues with your particular wireless router-box and what you could do against such issues.

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

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 zone of the firewall and the network interface for the internal network to the internal zone of the firewall.

If one same network interface like "eth0" or "wlan0" is used for the Internet connection and for the internal network you may better change your network hardware so that your trusted internal network traffic becomes well separated from the non-trusted network traffic.

Basic Network Security versus Phishing

The above described measures for basic network security do usually not help against phishing attacks, cf. "Phishing" at Wikipedia https://en.wikipedia.org/wiki/Phishing

The reason is that phishing attacks happen via intentionally open channels to receive data from "the outer world" like incoming e-mails or other messaging systems but also SMS on mobile phones and traditional phone calls.

Usually such channels are intentionally open by default for any sender because it is intended that one can receive e.g. e-mails, other messages, SMS, and phone calls from anyone from "the outer world" (e.g. so that an old friend who lives now in a foreign country could still contact one) but this means that one can also get arbitrary unwanted things from possibly malicious senders.

There are also intentionally open channels to receive computer specific data from remote. Usually those open channels are intended to receive announcements (broadcasts/multicasts) from remote servers about available services that those remote servers provide in the network. For example remote print queues are announced this way by remote print servers in the network traditionally via the so called "CUPS Browsing" and/or nowadays via DNS-SD, see "print job phishing" below.

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.

Optionally there could be also the cups-browsed (belongs to 'cups-filters' which is not CUPS but a separated project) which is accessible by default via UDP via IPP port 631 to accept any incoming CUPS Browsing information about remote print queues from any remote host. Normally the cups-browsed.service should not be used because it is a generic security risk when a service accepts any (possibly malicious) incoming information from any remote host so only a proper firewall setup would protect your host.

By default the cupsd should be only accessible via the internal interface of the local host (lo) to accept print jobs. Therefore printing is usually only possible directly from the local host but not from any remote host via network. If the cupsd runs in its default mode, you do not need the firewall to protect the cupsd (and your printer if it is locally connected) against unwanted access. Nevertheless to be on the safe side you should not switch off the firewall because it will protect your CUPS server against unwanted access via network when the cupsd is not running in its default mode. For example for very old CUPS versions or for uncommonly built cups RPM packages the cupsd might be even generally accessible unless the firewall provides protection.

To protect your CUPS server against unwanted access:

Do not open any 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.

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 that controls the printer machine.

Furthermore printing documents via CUPS lets the user access and contol various programs that run on the computer where CUPS runs (i.e. the CUPS server machine which can also be the local host).

Those programs process the print job data (e.g. a PostScript or PDF file) in various ways to produce in the end printer specific data that is finally sent to the printer device. That final printer specific data is the above mentioned program which controls the printer machine.

Those programs are the cupsd (which runs as 'root' on the CUPS server), various filtering programs (e.g. Ghostscript), arbitrary printer drivers, and various backends. The various programs that convert the initial print job data into printer specific data (the filtering programs) and send the result to the printer device (the backend) are usually run as user 'lp' on the CUPS server.

Those programs work with the data in various ways so that in the end all together lead to a zillion of ways how the data is processed (cf. "Background Information" at SDB:How to Report a Printing Issue and "Processing stages of a print job" at SDB:CUPS in a Nutshell).

Furthermore certain kind of print job data (in particular PostScript but also PDF to some extent) is actually a program.

PostScript is a general purpose Turing-complete programming language (cf. https://en.wikipedia.org/wiki/PostScript) that supports in particular file access on the system disk. When Ghostscript processes PostScript it runs a PostScript program as the user who runs Ghostscript (usually the user 'lp', see above). Furthermore when Ghostscript processes PDF it also runs a PostScript program because the PDF interpreter, as supplied with Ghostscript before version 9.56, is written in PostScript where PDF features which have no equivalent in PostScript need to be implemented via special PostScript extensions that have proven to be a security problem. See https://artifex.com/blog/changes-to-the-pdf-interpreter that provides a lot of background information about Ghostscript's PDF interpreter and why it is replaced in Ghostscript version 9.56 by a new PDF interpreter that is written entirely in C. When Ghostscript processes an arbitrary PostScript or PDF file, the user who runs Ghostscript runs an arbitrary program which can do basically anything on the system where Ghostscript runs that this user is allowed to do on that system. To make it safer when Ghostscript runs a PostScript program the Ghostscript command line option '-dSAFER' disables certain file access functionality (for details see /usr/share/doc/ghostscript/*/Use.htm). When printing documents Ghostscript is normally run with the '-dSAFER' option set. Its name 'SAFER' says everything: It makes it 'safer' to let Ghostscript run a PostScript program, but it cannot make things completely safe.

Users who are allowed to submit print jobs are allowed to upload arbitrary data and even certain kind of programs onto the CUPS server.

In theory all those programs that run on the CUPS server are safe against misuse.

In practice there is an endless sequence of various kind of security issues that appear every now and then in this or that particular program which get fixed issue by issue ad infinitum (and ad nauseam).

In the end all that means:

Users who are allowed to submit print jobs to a CUPS server are allowed to upload arbitrary data onto the CUPS server and run arbitrary programs in arbitrary ways (usually as user 'lp') on the CUPS server and finally access and contol the printer hardware as they like.

CUPS cannot be used in an environment where one does not know who the persons are that submit print jobs or where one cannot trust the persons that submit print jobs because there are too many possibilities for users who are allowed to submit print jobs to let "bad things" happen on the CUPS server.

Even if all those programs that run on the CUPS server were safe against misuse, any user who is allowed to submit print jobs could still do some kind of denial of service attack: Either by submitting many small useless print jobs or a few huge nonsense print jobs which waste toner/ink and paper or by submitting specific tiny PostScript or specially crafted PDF print jobs which let PostScript or PDF processing software (like Ghostscript) or a printer's built-in PostScript interpreter do basically endless time consuming processing or even hang up in an endless loop. The latter may result in loss of print jobs when subsequent print jobs of other users were already sent into the printer's memory while the tiny PostScript job is blocking the printer's actual printing unit endlessly. If the blocking job can only be aborted by a printer reset, the other jobs in its memory are usually lost. If you think things like printer accounting would be an easy way out here, have a look at SDB:Printer Accounting and you may get "some new kind of headache regarding printing setup".

In parctice the most feasible way out is to limit access to CUPS to trusted users plus the next items:

It is crucial to limit access to network printer devices to trusted users

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). Those access restrictions must be set up in the network printer device itself. Read the documentation of your network printer device how to do that.

It is crucial to not accept remote printing information from untrusted hosts

Traditionally (i.e. in CUPS up to version 1.5.4) by default the CUPS server process was accessible via UDP via IPP port 631 to accept incoming information about remote print queues from remote hosts. A CUPS print server could 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 accepted by default incoming information about remote print queues via UDP via IPP port 631.

In this way, the queues of the server were available on the clients without any CUPS-specific configuration on the client hosts. Users on the clients could 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.

Nowadays (i.e. since CUPS >= 1.6) remote print queue annoucements and remote printer announcements happen via DNS-SD that is implemented by Avahi instead of and/or in addition to traditional "CUPS Browsing", cf. "Zero-configuration networking" at Wikipedia https://en.wikipedia.org/wiki/Zero-configuration_networking and "Avahi" at Wikipedia https://en.wikipedia.org/wiki/Avahi_(software)

Because CUPS Browsing is dropped in CUPS since version 1.6 the package cups-filters provides the cups-browsed that provides basic CUPS Browsing functionality to maintain backward compatibility with traditional old CUPS Browsing but cups-browsed is a generic security risk, see above.

Regardless what is used for remote printing services announcements:

It is crucial to not accept remote printing information from untrusted hosts.

Otherwise possibly confidential print jobs could be sent to untrusted printers or print servers.

See the "print job phishing" thread on the "cups" mailing list from August 2007

https://lists.cups.org/pipermail/cups/2007-August/thread.html

that 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: It is because CUPS is designed for use in a trusted internal network where usability and convenience (no CUPS-specific configuration on client hosts - i.e. make printing "just work" versus above "Security: Make Things Not Just Work") is considered to outweigh the security risk in an external network where furthermore by default a firewall should provide protection. See the above "print job phishing" thread which contains the following explanation from the CUPS main author: 

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 printing 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.

For example assume you are traveling with your laptop and in your hotel lobby there is a printer for guests. Here you accept remote printing information because you trust that well known reputable "Grand Hotel". You need to print out your admission ticket for a non-public congress that you got right now during a perfectly secure registration via Internet. You submit your print job to the "grand_hotel_lobby_printer" and - voila! - a few seconds later your admission ticket comes out of the printer at the hotel lobby information desk. What you do not know is that those friendly businessman next to you had sent you the "grand_hotel_lobby_printer" print queue information from his laptop so that he got your admission ticket and then (after copying it) forwarded it to the actual printer share of the hotel lobby printer so that you won't notice the deception. Instead of using a print queue that was "just accessible", you had better asked the clerk at the hotel lobby information desk how to correctly access the printer. Now it is too late and nobody may notice the one more listener at that congress. Because it had "just worked" you don't wonder why you didn't have to pay for using a printer at a public accessible location or what (if not money) you actually paid for that printout or even think about "cui bono?" when "the intended purpose of security measures is to make things not just work" (see above).

To protect your host against "print job phishing":

Do not accept DNS-SD information from untrusted (external) hosts.

Do not open any 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 announced print queues of a CUPS server in your internal home network.

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 any 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 must not open the IPP port 631 for UDP for the external zone so that remote print queue information from untrusted (i.e. external) servers is rejected.

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.

You do not need to open any IPP port 631 in the firewall for a "client-only" configuration.

Automated print queue setup via cups-browsed

In general cups-browsed should not be used because it is a generic security risk, see above.

If the cups-browsed.service is started or enabled it does not only accept traditional old CUPS Browsing information from any remote host to make remote printers accessible on the local host.

Additionally it also does automated local print queue setup for remote printers that are announced via CUPS Browsing or via DNS-SD when needed e.g. for legacy PostScript/PCL printers that do not support CUPS driverless printing - i.e. for remote printers which require a local print queue with a printer model specific driver to be able to print on the remote printer from the local host.

If you wonder why there is an automated local setup for remote devices: It is because cups-browsed is designed for use in a trusted internal network where usability and convenience (no configuration on client hosts - i.e. make printing "just work" versus above "Security: Make Things Not Just Work") is considered to outweigh the security risk in an external network where furthermore by default a firewall should provide protection.

To do such an automated print queue setup printer model specific info is needed to be able to set up an appropriate printer model specific driver that makes correct looking printouts.

So cups-browsed queries the remote printer for printer model specific info but this results another generic security issue because a malicious fake remote printer can send malicious info to cups-browsed which results a malicious automated setup of the local print queue.

For an example how this can be misused to run commands (cf. above "printing documents via CUPS lets the user access and contol various programs that run on the computer where CUPS runs") see

https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/

Because cups-browsed queries the remote printer for printer model specific info a malicious fake remote printer can send arbitrary false info to cups-browsed which results that cups-browsed queries an arbitrary remote printer or an arbitrary remote host for printer model specific info.

For an example how this can be misused to do a DDoS attack see

https://www.akamai.com/blog/security-research/october-cups-ddos-threat

Both examples require that users or admins violate crucial conditions how printing services are meant to be used.

Both cupsd and cups-browsed are network services that are designed for use in a trusted internal network and not intended to be exposed to the public Internet or to other non-trusted networks which means:

It is crucial to limit access to cupsd and cups-browsed to trusted users

It is crucial to limit access to network printer devices to trusted users

It is crucial to not accept remote printing information from untrusted hosts

In particular cups-browsed must not be used when cups-browsed could get possibly malicious info from a fake remote printer - i.e. when cups-browsed is not sufficiently restricted by a proper firewall setup to protect your host.

This also proves that it is crucial to not accept remote printing information from untrusted hosts.

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 not be specified so that all ports above 1024 must have been accessible (i.e. open in the firewall) for connections from the clients. Recent saned versions provide 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.

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.

Setup for firewalld

With SuSEfirewall2 some best effort setup is possible when one same network interface is used for the Internet connection and for the internal network by assigning the network interface to the external zone and specifying FW_TRUSTED_NETS, FW_SERVICES_ACCEPT_RELATED_EXT, and FW_LOAD_MODULES appropriately which proves that when trusted and non-trusted network traffic is mixed up there is increased effort (i.e. a more complicated configuration that results a more fragile way of operation) and less network security (i.e. only a best effort attempt to get some kind of network security).

A similar best effort setup for Firewalld is possible for example like:

Create a "private" zone 

firewall-cmd --permanent --new-zone=private
firewall-cmd --permanent --zone=private --add-source=192.168.0.0/24

on the SANE server and on the client.

Additionally on the server set 

firewall-cmd --permanent --zone=private --add-service=sane

The sane helper loads a sane specific conntrack module which takes care of opening any required ports for transferring scanner data - no additional explicit opening of ports is necessary.

In general if possible you may better change your network hardware so that your trusted internal network traffic becomes well separated from the non-trusted network traffic.

Summary

By default the firewall 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 trusted internal network and not intended to be exposed to the public Internet or to 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 firewall 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.

When one same network interface is used for the Internet connection and for the internal network you may better change your network hardware so that your trusted internal network traffic becomes well separated from the non-trusted network traffic or have a dedicated firewall machine which protects your whole internal network.

Bottom Line

To use printers and scanners in a trusted internal network and be protected by the firewall 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.

Further Information

Retrieved from "https://en.opensuse.org/index.php?title=SDB:CUPS_and_SANE_Firewall_settings&oldid=191266"