thanks a lot for you sample script, It gave me a clue on the problem
-> IGMP !
I needed to open 224.0.0.0/28 to let beacon work, now I only open
224.0.0.0/28 on protocol igmp and everything works fine. Maybe my rules
are less paranoid than yours, but still less opened than opening
globally 10004, 10003 and 10002 ports. And openning only these ports
is not enough regardless on what is told in the beacon FAQ ! maybe it
should be changed to insist on openning igmp ! I've documented my
working rules for FC2 system on my beacon doc page:
http://www.int-evry.fr/mci/user/procacci/Doc/Beacon/beacon.html#htoc12
One more question ... -> traffic:
I get 13 packets of lenght 26 send every seconds from mu client beacon
on RTP port 10002 !
in the FAQ it is said that I should be 64 bytes/second/Beacon .
Am I generating too much traffic, is it tunnable ?
18:57:00.954798 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.036795 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.118768 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.200764 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.282781 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.364741 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.446736 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.528716 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.610693 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.692675 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.763073 IP petra.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.763138 IP petra.int-evry.fr.10003 > 233.157.159.21.10003:
UDP, length 104
18:57:01.774689 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.856659 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:01.938629 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
18:57:02.020663 IP calaz.int-evry.fr.10002 > 233.157.159.21.10002:
UDP, length 26
Thanks.
Andrew Daviel wrote:
On Tue, 16 Nov 2004, jehan.procaccia wrote:
I fanally found the firewall rules (iptables on fedora) to let beacon
clients and server speak to each other :-)
However I still don't explain why the theorical and optimized (closed as
much as possible) rules I tried don't work !?
I thought I would play with this and have wasted entirely too much time
on it .... :-)
I use a shell script to set up bastion hosts, similar to what I did with
ipchains prior to RedHat's inclusion of a firewall, so it looks a bit
different. Using variables makes it easy to maintain and I can
test bits just by cut/paste into a shell prompt.
"service iptables save" will save the current rules in sysconfig to
survive a reboot.
This is a fairly paranoid set that seems to work:
#!/bin/sh
PATH=/sbin:/bin
# "accept" initially so we can use DNS to look things up
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
ME=`hostname`
TRIUMF=142.90.0.0/16
ANY=0.0.0.0/0
ETH=eth0
GROUP=233.4.200.19
RTPPORT=10002
RTCPPORT=10003
SRVPORT=10004
SERVER=beacon.dast.nlanr.net
# flush INPUT chain
iptables -F INPUT
# localhost
iptables -A INPUT -i lo -s $ANY -j ACCEPT
# ssh from TRIUMF - set this up first in case of mistakes later
iptables -A INPUT -i $ETH -p tcp -s $TRIUMF -d $ME --dport ssh -j ACCEPT
# DNS lookups
iptables -A INPUT -i $ETH -p udp -s dns1 --sport domain -d $ME \
--dport 1024: -j ACCEPT
# auth
iptables -A INPUT -i $ETH -p tcp -s $TRIUMF -d $ME --dport auth -j ACCEPT
# ntp
iptables -A INPUT -i $ETH -p udp -s time1 --sport ntp -d $ME -j ACCEPT
# allow ping from TRIUMF
iptables -A INPUT -i $ETH -p icmp -s $TRIUMF -d $ME -j ACCEPT
#beacon mcast
iptables -A INPUT -i $ETH -p udp -d $GROUP --dport $RTPPORT -j ACCEPT
iptables -A INPUT -i $ETH -p udp -d $GROUP --dport $RTCPPORT -j ACCEPT
iptables -A INPUT -i $ETH -p igmp -d $GROUP -j ACCEPT
#beacon server
iptables -A INPUT -i $ETH -p tcp -s $SERVER --sport $SRVPORT -d $ME \
-j ACCEPT
# ignore NetBEUI
iptables -A INPUT -i $ETH -p udp -s $TRIUMF --sport 137:139 -j DROP
# ignore broadcasts
iptables -A INPUT -i $ETH -p udp -d $ALL -j DROP
iptables -A INPUT -i $ETH -p udp -d $BCAST -j DROP
# allow ICMP replies
iptables -A INPUT -i $ETH -p icmp -d $ME -j ACCEPT
# log everything else
iptables -A INPUT -i $ETH -j LOG
# default policy drop
iptables -P INPUT DROP
# flush OUTPUT chain
iptables -F OUTPUT
# ssh
iptables -A OUTPUT -o $ETH -p tcp -s $ME --sport ssh -j ACCEPT
# DNS lookups
iptables -A OUTPUT -o $ETH -p udp -s $ME --sport 1023: -d dns1 \
--dport domain -j ACCEPT
#ntp (may be too lax)
iptables -A OUTPUT -o $ETH -p udp -d $ANY --dport ntp -j ACCEPT
# localhost
iptables -A OUTPUT -o lo -j ACCEPT
# beacon mcast
iptables -A OUTPUT -o $ETH -p udp -s $ME -d $GROUP --dport $RTPPORT \
-j ACCEPT
iptables -A OUTPUT -o $ETH -p udp -s $ME -d $GROUP --dport $RTCPPORT \
-j ACCEPT
iptables -A OUTPUT -o $ETH -s $ME -d 224.0.0.2 -j ACCEPT
iptables -A OUTPUT -o $ETH -p igmp -d $GROUP -j ACCEPT
# beacon server
iptables -A OUTPUT -o $ETH -p tcp -d $SERVER --dport $SRVPORT \
-j ACCEPT
# log everything else
iptables -A OUTPUT -o $ETH -j LOG
# default policy drop
iptables -P OUTPUT DROP
Using itpables logging makes it easier to see what is being filtered
compared to tcpdump, as the earlier rules will cut down on the amount of
"noise". The log output goes in syslog (/var/log/messages on RedHat by
default)
It seems necessary (or at least a good idea to get IGMP v2 to work
properly) to allow traffic to 224.0.0.2 (all-routers), and it's necessary
to allow IGMP as well as UDP to the beacon group (otherwise you'll not
get registered with the router and it won't know to let the multicast
traffic through)
Turning on output rules is paranoid - that's when you don't trust your
users not to spam or install trojans, or you are concerned about a
backdoor being installed via a hole in a service you let through, like
bind or http.
|