SCIENTIFIC-LINUX-USERS Archives

August 2008

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephen Isard <[log in to unmask]>
Reply To:
Stephen Isard <[log in to unmask]>
Date:
Fri, 15 Aug 2008 11:14:07 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (41 lines)
>On Thu, 14 Aug 2008, Shane Voss wrote:
>...
>> You may be able to use  "recent" - something like this:
>>
>> # Record the port being used when cups sends a broadcast
>> iptables -A OUTPUT -m recent --name cups-snmp --dport 161 --pkt-type
>> broadcast --set --rdest -j ACCEPT
>>
>> # Accept incoming packets presumed "in reply" from port 161
>> # but only for the number of seconds configured in cups-snmp.conf
>> iptables -A INPUT -m recent --rcheck --seconds 10 --sport 161 ... -j A
C
>CEPT
>>
>> (I haven't tested any of this!)

Shane,

People on the netfilter list gave me a pair of rules very close to yours
that seem to work.
-A OUTPUT -d xxx.yyy.zzz.255 -p udp --dport 161 -m recent --name cups_snm
p
--rsource --set -j ACCEPT
-A INPUT -p udp -s xxx.yyy.zzz.255/24 --sport 161 -m recent --name cups_s
nmp
--rdest --rcheck -j ACCEPT

The only problem is that "-m recent --rsource --set" only records the out
put
ip address, not the port number, so that the INPUT line accepts packets t
o
any port, not just the port that cups sent its broadcast from.  However, 
the
use of "recent" means that such packets will only be accepted during a br
ief
time window following a broadcast.  Since printer discovery doesn't need 
to
be done very often, the risk (if there really is a risk in the first plac
e)
is reduced.

ATOM RSS1 RSS2