Arch Linux

squeakychair

Member

Registered: 2018-04-15

Posts: 15

[SOLVED] Are SANE firewall settings inherently insecure?

I recently realized my laptop didn't have a firewall, so I installed and enabled Gufw. That prevented SANE from finding & accessing my networked multi-function printer. After a lot of digging I found the right firewall rule to make it work - but the rule is so insecure I want a second opinion.

ALLOW IN from *:3702

Unlike every other firewall rule I've encountered, this doesn't open one of my local ports; it opens ALL my local ports for ANY traffic coming from 3702.

My printer uses the WSD protocol (mentioned on the SANE wiki page), which uses port 3702. Opening 3702 locally didn't work, but digging through dmesg I saw all the (blocked) return traffic was FROM 3702 to random dynamic ports on my laptop.

Have I misconfigured something on my laptop?
Am I misunderstanding the implications of accepting all traffic FROM 3702?
Without workarounds (like only opening the port when I need it, or hardcoding my scanner's IP in the rule), it seems I might as well turn off my firewall.

Last edited by squeakychair (2022-03-17 11:01:16)

-thc

Member

Registered: 2017-03-15

Posts: 775

Re: [SOLVED] Are SANE firewall settings inherently insecure?

Consider the possibility that the connection tracking isn't "aware" that this incoming connection is actually a related answer to the outgoing request from your PC - because the helper module "nf_conntrack_sane" isn't loaded by default.

Try loading that module and disabling your firewall exception before network scanning.

squeakychair

Member

Registered: 2018-04-15

Posts: 15

Re: [SOLVED] Are SANE firewall settings inherently insecure?

Thanks for the suggestion! I couldn't find documentation on the "nf_conntrack_sane" kernel module, but tried loading it anyway. Unfortunately I still couldn't probe my scanner. When other documentation (like saned man page and ArchWiki) reference the module, it sounds like that's needed for SANE servers, e.g. a PC serving its USB-connected scanner to clients on the network. The closest thing I found to documentation was this source code, which thankfully has some comments.

I spent a lot more time trying to figure this out, and got to the bottom of it! UFW was only logging blocked packets to dmesg, so I only saw a fraction of the big picture. When I switched to WireShark I realized my PC was initiating the connection via multicast. iptables ESTABLISHED rule expects the response to come from a matching IP, so it doesn't allow multicast.

The internet is filled with terrible solutions to allowing multicast responses through iptables. Disable the firewall... open all ports over 5000... open all data from specific ports (my original post)... that sort of thing. Then I found a gem on ServerFault: Stateful Matching of Multicast Responses in iptables. Copied here for history, tweaked to be more generic.

$ ipset create upnp hash:ip,port timeout 3
$ iptables -A OUTPUT -d 239.255.255.250 -p udp -m udp -j SET --add-set upnp src,src --exist
$ iptables -A INPUT -p udp -m set --match-set upnp dst,dst -j ACCEPT

This solution brilliantly uses ipset to briefly track and allow multicast responses. This immediately fixed my scanner and probably other multicast issues I hadn't realized yet!

I will probably add this to the iptables wiki page and link to it from the SANE page.

-thc

Member

Registered: 2017-03-15

Posts: 775

Re: [SOLVED] Are SANE firewall settings inherently insecure?

I somehow hoped the module would work "in both ways" -  which it doesn't.

Your solution elegantly solves tracking this kind of communication.

Please mark your thread as solved.