iptables rules for cups printer discovery

iptables rules for cups printer discovery

[Stephen Isard]

I'm wondering whether there are iptables rules that will permit cups 
snmp printer discovery to operate without creating a serious security 
risk.

Cups printer discovery works by sending a broadcast from a high numbered 
port (a different one each time) to the snmp port (161) of every device 
on the local network.  Printers are then supposed to send back replies 
from their port 161 to the high numbered port on the computer that the 
broadcast came from.  Since the replies are to a broadcast, they are not 
treated as ESTABLISHED or RELATED by iptables rules.  My question is 
really whether there is some way of identifying replies to such a 
broadcast, so that I don't have to let through all udp packets from port 
161 of any machine on the local network to all high numbered ports on my 
machine, at any time, which looks as if it might be unsafe, especially 
when I can't be certain that the local network is absolutely secure 
against break-ins.

Thanks.

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Thursday 2008-08-14 14:51, Stephen Isard wrote:

> I'm wondering whether there are iptables rules that will permit
> cups snmp printer discovery to operate without creating a serious
> security risk.

CUPS does not actually use SNMP, does it? The way I have seen its
output are regular UDP transmissions from and to port 631, without
any replies (much like most NBT packets).

	-d 192.168.0.255 -p udp --dport 631

Re: iptables rules for cups printer discovery

[Stephen Isard]

On Thu, 14 Aug 2008, Jan Engelhardt jengelh-at-medozas.de |netfilter| wrote:

> CUPS does not actually use SNMP, does it? The way I have seen its
> output are regular UDP transmissions from and to port 631, without
> any replies (much like most NBT packets).
>
> 	-d 192.168.0.255 -p udp --dport 631

It does that too, but yes, recent (I'm not sure since when) cups also 
uses snmp.  The port 631 transmissions are for finding other computers 
that share their printers.  Snmp is used for finding standalone printers 
with their own ip addresses on your local network.  See 
http://www.cups.org/documentation.php/network.html#SNMP

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Thursday 2008-08-14 16:23, Stephen Isard wrote:
> On Thu, 14 Aug 2008, Jan Engelhardt jengelh-at-medozas.de |netfilter| wrote:
>
>> CUPS does not actually use SNMP, does it? The way I have seen its
>> output are regular UDP transmissions from and to port 631, without
>> any replies (much like most NBT packets).
>>
>>  -d 192.168.0.255 -p udp --dport 631
>
> It does that too, but yes, recent (I'm not sure since when) cups also uses
> snmp.  The port 631 transmissions are for finding other computers that share
> their printers.  Snmp is used for finding standalone printers with their own ip
> addresses on your local network.

Makes sense. It is only natural that the reply packet is not
associated with the original connection, because the sender address
is not 192.168.0.255. You could write a layer-4 connection tracker
that observes packets to 192.168.0.255:631, verifies that they are of
SNMP nature (or not verify at all and Just Do It), and then
instantiate a new expectation, therefore making replies matching -m
conntrack --ctstate RELATED.

Re: iptables rules for cups printer discovery

[Stephen Isard]

On Thu, 14 Aug 2008, Jan Engelhardt jengelh-at-medozas.de |netfilter| wrote:
>
> On Thursday 2008-08-14 16:54, Stephen Isard wrote:
>>
>>> You could write a layer-4 connection tracker
>>
>> Maybe you could, but I'm not sure that I could :-)  At what level
>> would this operate?  Kernel?
>
> Kernel. Parallel to things like nf_conntrack_ftp.

Mm.  I'm sure it would be educational to try, but I think I may just do 
my printer discovery by social engineering - ask the departmental 
computing officers for the ip numbers.

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 8/14/2008 1:51 PM, Stephen Isard wrote:
> I'm wondering whether there are iptables rules that will permit cups 
> snmp printer discovery to operate without creating a serious security risk.

I wonder if you could not use the "recent" match extension to ""remember 
when a cups broadcast has gone through.  If there is a reply packet from 
a unicast IP going back to a unicast host that has recently sent a 
broadcast packet.

I suppose you would have to set / update a recent list every time a 
unicast source sends a broadcast (high -> low port) to the service in 
question.  That way you could allow the reply (low -> high port) from a 
unicast source to the unicast destination that recently sent a broadcast.

This type of rule should help by not having to allow all traffic from 
the source port through.



Grant. . . .

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Thursday 2008-08-14 21:35, Grant Taylor wrote:

> On 8/14/2008 1:51 PM, Stephen Isard wrote:
>
>> I'm wondering whether there are iptables rules that will permit
>> cups snmp printer discovery to operate without creating a serious
>> security risk.
>
> I wonder if you could not use the "recent" match extension to
> ""remember when a cups broadcast has gone through.

Nope that would not work because the source and destination
addresses are flipped on return packets, and then you even
have the .255 thing.

That smells like a feature request - me to the rescue!
(I think that would be much preferable over having a ton of
connection helpers)

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 8/14/2008 8:53 PM, Jan Engelhardt wrote:
> Nope that would not work because the source and destination addresses 
> are flipped on return packets, and then you even have the .255 thing.

Ah.  I forgot about the fact that recent only dealt with the source IP 
and that you could not specify source or dest in the set / update / 
check parameters to recent.  :(

> That smells like a feature request - me to the rescue! (I think that 
> would be much preferable over having a ton of connection helpers)

*nod*  It would be very nice to be able to specify whether or not the 
given recent list is suppose to use the source or dest IP.  I wonder if 
it would be possible to add a new flag that indicates act on the 
destination IP.  That way it would be possible to default to just source 
like it currently is but still be able to specify dest when desired.  I 
suppose to make things clean it would be better to add a flag to 
indicate source and use that flag as the default when no flag is specified.



Grant. . . .

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Thursday 2008-08-14 22:00, Grant Taylor wrote:

> On 8/14/2008 8:53 PM, Jan Engelhardt wrote:
>> Nope that would not work because the source and destination addresses are
>> flipped on return packets, and then you even have the .255 thing.
>
> Ah.  I forgot about the fact that recent only dealt with the source IP and that
> you could not specify source or dest in the set / update / check parameters to
> recent.  :(

You can specify --rsrc/--rdest (patch just merged that documents them).
But somehow I am not sure...

-A INPUT -d 192.168.0.255 -p udp --dport 161 -m recent --name snmp
--rsrc --set

-A OUTPUT -p udp --sport 161 -m recent --name snmp
--rdest --rcheck

Try?

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 8/14/2008 9:04 PM, Jan Engelhardt wrote:
> You can specify --rsrc/--rdest (patch just merged that documents 
> them).

So the options did exist, but they were undocumented?

> -A INPUT -d 192.168.0.255 -p udp --dport 161 -m recent --name snmp 
> --rsrc --set
> 
> -A OUTPUT -p udp --sport 161 -m recent --name snmp --rdest --rcheck

*nod*  That is the general idea.

So I take it that the default is --rsrc but you can specify --rdest and 
act on the destination IP for all options of recent, i.e. --update and 
--remove too?



Grant. . . .

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Thursday 2008-08-14 22:14, Grant Taylor wrote:

> On 8/14/2008 9:04 PM, Jan Engelhardt wrote:
>> You can specify --rsrc/--rdest (patch just merged that documents them).
>
> So the options did exist, but they were undocumented?

Correct. Blame it on ... 

commit f33c46140f0e0a230aba5d739ce40cb14e066b13
Author: Jonas Berlin <xkr47@outerspace.dyndns.org>
Date:   Fri Apr 1 06:54:23 2005 +0000


>> -A INPUT -d 192.168.0.255 -p udp --dport 161 -m recent --name snmp --rsrc
>> --set
>> 
>> -A OUTPUT -p udp --sport 161 -m recent --name snmp --rdest --rcheck
>
> *nod*  That is the general idea.
>
> So I take it that the default is --rsrc but you can specify --rdest
> and act on the destination IP for all options of recent, i.e.
> --update and --remove too?

Right. It seems that when done cleverly, you can mix --rsrc and
--rdest for a given --name even.

Re: iptables rules for cups printer discovery

[Stephen Isard]

On Thu, 14 Aug 2008, Jan Engelhardt jengelh-at-medozas.de |netfilter| wrote:
...
> You can specify --rsrc/--rdest (patch just merged that documents them).
> But somehow I am not sure...
>
> -A INPUT -d 192.168.0.255 -p udp --dport 161 -m recent --name snmp
> --rsrc --set
>
> -A OUTPUT -p udp --sport 161 -m recent --name snmp
> --rdest --rcheck
>
> Try?

I've tried, but my system doesn't seem to like --rsrc/--rdest.

Just to make sure I'm not completely confused, you've made a typo and 
reversed INPUT and OUTPUT, right?  That is, I think we want --set to 
happen on output when we broadcast to the destination port 161.

After making that adjustment, when I try to load the rules, I get an 
error message:
Applying iptables firewall rules: iptables-restore v1.3.5: Unknown arg 
`--rsrc'

This is on Scientific Linux 5.2 with its latest kernel, 
2.6.18-92.1.10.el5.  So do I need a much more recent kernel?  If so, I 
can set up a virtual machine for a test.  Can you recommend a 
reasonably lightweight distribution that would serve?  Obviously it 
needs a fairly recent cups as well.  The latest KNOPPIX?

Can you comment on my understanding of the "recent" rules as set out 
below?

"-m recent --set" stores an address, just as an address, not marked as 
source or dest.  This address is taken from either the source or 
destination address of a packet, depending on the use of --rsrc/--rdest. 
In order for the rules to do what we want them to, the address has to 
include the port number as well as the ip address.

"-m recent --rcheck" looks to see whether the stored address is the same 
as either the source or destination address on a packet, depending on 
the use of --rsrc/--rdest.

If that is correct and the port is stored as part of the address, then 
the logic of your rules looks good to me.  If the port isn't stored, 
then all we are storing is the address of our own interface and we match 
any packet coming in from a port 161.  That's still an improvement 
because we only let in the packets during a relatively short window 
after a broadcast, but it's not quite what we'd really like.

By the way, googling around for help on this issue, I came across a 
forum thread from 2004 discussing the same problem with respect to 
samba.  Evidently samba uses the same broadcast/response tactic. 
Unfortunately the thread seemed to peter out without resolution.  But is 
there an approved firewall setup for samba these days?  (I don't use 
samba myself.)  If so, maybe we could adapt it.

Re: iptables rules for cups printer discovery

[Jan Engelhardt]

On Friday 2008-08-15 09:10, Stephen Isard wrote:
> On Thu, 14 Aug 2008, Jan Engelhardt jengelh-at-medozas.de |netfilter| wrote:
>
>> You can specify --rsrc/--rdest (patch just merged that documents
>> them). But somehow I am not sure...
>>
>> -A INPUT -d 192.168.0.255 -p udp --dport 161 -m recent --name snmp
>> --rsrc --set
>>
>> -A OUTPUT -p udp --sport 161 -m recent --name snmp
>> --rdest --rcheck
>>
>> Try?
>
> I've tried, but my system doesn't seem to like --rsrc/--rdest.
> Applying iptables firewall rules: iptables-restore v1.3.5: Unknown arg `--rsrc'

Oh it's --rsource not --rsrc. But --rdest is correct.

> Just to make sure I'm not completely confused, you've made a typo
> and reversed INPUT and OUTPUT, right?  That is, I think we want
> --set to happen on output when we broadcast to the destination port
> 161.

Oh yeah, depends on which side you are looking at. I was assuming,
from what you told me, that a standalone printer spews SNMP to a
broadcast address and a Linux box replies, but now it looks like that
hardly makes sense ;-)

> This is on Scientific Linux 5.2 with its latest kernel, 2.6.18-92.1.10.el5.  So
> do I need a much more recent kernel?

Nope, this is fine.

> Can you recommend a reasonably lightweight distribution that would
> serve?  Obviously it needs a fairly recent cups as well.  The latest KNOPPIX?

I am of course biased, so you will only hear openSUSE 11 from me. The
default minimal install is like ~500 M but one can strip it down to
like 300 (fits on a CF card!) by throwing out unneeded pkgs and
translation files.

> Can you comment on my understanding of the "recent" rules as set
> out below?
>
> "-m recent --set" stores an address, just as an address, not marked
> as source or dest.  This address is taken from either the source or
> destination address of a packet, depending on the use of
> --rsrc/--rdest. In order for the rules to do what we want them to,
> the address has to include the port number as well as the ip
> address.

Correct.

> "-m recent --rcheck" looks to see whether the stored address is the
> same as either the source or destination address on a packet,
> depending on the use of --rsrc/--rdest.

Correct.

> If that is correct and the port is stored as part of the address,

The port is not stored, since in common sense, it is not part of the
address. An (address,port) tuple is however not stored.

> then the logic of your rules looks good to me.  If the port isn't
> stored, then all we are storing is the address of our own interface
> and we match any packet coming in from a port 161.  That's still an
> improvement because we only let in the packets during a relatively
> short window after a broadcast, but it's not quite what we'd really
> like.
>
> By the way, googling around for help on this issue, I came across a forum
> thread from 2004 discussing the same problem with respect to samba.  Evidently
> samba uses the same broadcast/response tactic. Unfortunately the thread seemed
> to peter out without resolution.  But is there an approved firewall setup for
> samba these days?  (I don't use samba myself.)  If so, maybe we could adapt it.

If by approved you mean what distributions use, then that's something
simple along the lines of
-A INPUT -p udp --dport 137:139 -j ACCEPT

Re: iptables rules for cups printer discovery

[Stephen Isard]

> Oh it's --rsource not --rsrc. But --rdest is correct.

Ok!  Now I find the printers.  (I also had to stick -j ACCEPT at the 
ends of the lines.  You were probably taking that for granted.)

> I was assuming,
> from what you told me, that a standalone printer spews SNMP to a
> broadcast address and a Linux box replies, but now it looks like that
> hardly makes sense ;-)

No, the printers don't spew.  They sit there demurely waiting for 
broadcasts.

> The port is not stored, since in common sense, it is not part of the
> address. An (address,port) tuple is however not stored.

Assuming you really mean that last "not", then my description
>> If the port isn't
>> stored, then all we are storing is the address of our own interface
>> and we match any packet coming in from a port 161.  That's still an
>> improvement because we only let in the packets during a relatively
>> short window after a broadcast, but it's not quite what we'd really
>> like.
seems to apply.  So if a bad guy knew how take advantage of udp 
broadcasts to arbitrary high numbered ports, he could sit there waiting 
for a cups broadcast and then send his evil packets from his port 161 to 
whichever of my ports he wanted.  Fortunately, such broadcasts will not 
be very frequent, since once the printers are discovered, there is no 
need to rediscover them until something changes.  But still it would be 
better to match the broadcast port number.  A new feature?

>> But is there an approved firewall setup for samba these days?  (I 
>> don't use samba myself.)  If so, maybe we could adapt it.

> If by approved you mean what distributions use, then that's something
> simple along the lines of
> -A INPUT -p udp --dport 137:139 -j ACCEPT

Hmm.  That doesn't seem to address the issue at all.  Maybe samba has 
changed, or I was misunderstanding.

Thanks for your help!

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 08/15/08 09:17, Stephen Isard wrote:
> Ok!  Now I find the printers.  (I also had to stick -j ACCEPT at the 
> ends of the lines.  You were probably taking that for granted.)

Good!

> Assuming you really mean that last "not", then my description
> seems to apply.  So if a bad guy knew how take advantage of udp 
> broadcasts to arbitrary high numbered ports, he could sit there waiting 
> for a cups broadcast and then send his evil packets from his port 161 to 
> whichever of my ports he wanted.  Fortunately, such broadcasts will not 
> be very frequent, since once the printers are discovered, there is no 
> need to rediscover them until something changes.  But still it would be 
> better to match the broadcast port number.  A new feature?

If you are worried about someone else spoofing an IP in your recent 
list, look in to the --rttl option to have the recent list remember the 
TTL values of packets and require them to be the same.  This way if some 
jerk off who is more hops away from you is trying to pretend to be you, 
his traffic will appear to be at a different TTL than yours.  This is 
not fool proof, but it will sure help reduce the risk of exposure that 
you are referring to.



Grant. . . .

Re: iptables rules for cups printer discovery

[Stephen Isard]

On Fri, 15 Aug 2008, Grant Taylor wrote:

> If you are worried about someone else spoofing an IP in your recent list, 
> look in to the --rttl option to have the recent list remember the TTL values 
> of packets and require them to be the same.  This way if some jerk off who is 
> more hops away from you is trying to pretend to be you, his traffic will 
> appear to be at a different TTL than yours.  This is not fool proof, but it 
> will sure help reduce the risk of exposure that you are referring to.

Thanks, Grant.

I don't think any spoofing is required.  I had in mind someone who had 
gained access to my local network (not simple, but not out of the 
question) and who was essentially pretending to be a printer by sending 
packets from his port 161 immediately following a cups broadcast.  I'm 
not worried about people without access to the local network because 
they wouldn't see the broadcast that opens the "recent" time window.

Am I fussing over nothing here?  Is it clear that much harm can be done 
by getting upd packets through my firewall to arbitrary high numbered 
ports?  Denial of service is probably not a big issue because of the 
short time window.

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 08/15/08 10:38, Stephen Isard wrote:
> Thanks, Grant.

*nod*

> I don't think any spoofing is required.  I had in mind someone who had 
> gained access to my local network (not simple, but not out of the 
> question) and who was essentially pretending to be a printer by sending 
> packets from his port 161 immediately following a cups broadcast.  I'm 
> not worried about people without access to the local network because 
> they wouldn't see the broadcast that opens the "recent" time window.

Um, if they have gotten a system in to your LAN I think you have bigger 
problems.  If this is a real concern, I'd suggest that you look in to 
802.1x (port) authentication.

Also remember that you can adjust the length of time for the "recent" 
window.  You can probably also mitigate the window by looking for the 
closing connection (at least with TCP) and do a --remove to clear the 
connection from the recent list.

> Am I fussing over nothing here?  Is it clear that much harm can be done 
> by getting upd packets through my firewall to arbitrary high numbered 
> ports?  Denial of service is probably not a big issue because of the 
> short time window.

I don't think you are fussing over nothing, but you certainly should 
consider other things first.  Now if you have already considered the 
other things, then by all means, continue discussing here.  ;)



Grant. . . .

Re: iptables rules for cups printer discovery

[Stephen Isard]

> Um, if they have gotten a system in to your LAN I think you have bigger 
> problems.  If this is a real concern, I'd suggest that you look in to 802.1x 
> (port) authentication.

This is a large university department where students and visitors use 
the lan.  The computing officers are highly competent and doing their 
best to provide security, but, as you know, it's a constant battle.

> Also remember that you can adjust the length of time for the "recent" window.

Right.

> You can probably also mitigate the window by looking for the closing 
> connection (at least with TCP)

This particular case involves udp.

Thanks for your advice.

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 08/15/08 11:28, Stephen Isard wrote:
> This is a large university department where students and visitors use 
> the lan.  The computing officers are highly competent and doing their 
> best to provide security, but, as you know, it's a constant battle.

Sounds like it is time to divide the different access networks up in to 
smaller pieces and route between them.  Make sure that you do some 
sanity checking (filtering) as part of the routing process too.  Try to 
help prevent spoofing as close to the edge as possible.  ;)

> This particular case involves udp.

*nod*

> Thanks for your advice.

You are welcome.



Grant. . . .

Re: iptables rules for cups printer discovery

[Grant Taylor]

On 08/15/08 08:10, Stephen Isard wrote:
> "-m recent --set" stores an address, just as an address, not marked as 
> source or dest.  This address is taken from either the source or 
> destination address of a packet, depending on the use of --rsrc/--rdest. 
> In order for the rules to do what we want them to, the address has to 
> include the port number as well as the ip address.
> 
> "-m recent --rcheck" looks to see whether the stored address is the same 
> as either the source or destination address on a packet, depending on 
> the use of --rsrc/--rdest.

The default is to use --rsource if neither --rsource or --rdest are 
specified.

> By the way, googling around for help on this issue, I came across a 
> forum thread from 2004 discussing the same problem with respect to 
> samba.  Evidently samba uses the same broadcast/response tactic. 
> Unfortunately the thread seemed to peter out without resolution.  But is 
> there an approved firewall setup for samba these days?  (I don't use 
> samba myself.)  If so, maybe we could adapt it.

There is now a connection tracking helper in the kernel specifically 
meant to help some NetBIOS traffic.



Grant. . . .