Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Paul Cupis <paul <at> cupis.co.uk>
Subject: [Fwd: Bug#345759: guarddog: Guarddog fails to allow bidirectional UDP traffic for User Defined Protocols]
Newsgroups: gmane.network.guarddog
Date: Tuesday 3rd January 2006 23:10:06 UTC (over 12 years ago)
-------- Original Message --------
Subject: Bug#345759: guarddog: Guarddog fails to allow bidirectional UDP
traffic for User Defined Protocols
Date: Sat, 03 Dec 2005 03:40:37 -0600
From: Chema 
Reply-To: Chema , [email protected]
To: Debian Bug Tracking System 

Package: guarddog
Version: 2.4.0-1
Severity: important

Hi there.

Guraddog doesn't writes the second bidirectional iptables command for
User Defined UDP protocols.  The resutling script has:

# Traffic from 'Internet' to 'Local'
# Allow 'userdefined3'
iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT

Instead of:

# Traffic from 'Internet' to 'Local'
# Allow 'userdefined3'
iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
iptables -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT


The full history:

After setting up Guarddog, my TeamSpeak server stoped working.  I had
enabled it in Guarddog User Defined Protocols of course.

Looking at /var/log/messages, I found:

Dec  3 02:06:01 severo kernel: DROPPED IN= OUT=eth1 SRC=10.10.10.1
DST=10.10.10.10 LEN=464 TOS=0x00 PREC=0x00 TTL=64 ID=2 DF PROTO=UDP
SPT=8767 DPT=2636 LEN=444

10.10.10.1 is my server, 10.10.10.10 is my client, so it seemed the
server was receiving the client request, but the answer packets were
being dropped.  I then went on checking what was Guarddog's script
actually doing with the Teamspeak port (8767):

# perl -nwe 'if(/^# Traffic/){$section=$_;$s=0;}
# elsif(/^#/){$title=$_;$t=0;} elsif(/8767/i){print( ($s++? "":$section)
# . ($t++? "": $title) . $_);}' rc.firewall.test
# Traffic from 'Internet' to 'Local'
# Allow 'userdefined3'
ipchains -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
ipchains -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Local' to 'Internet'
# Allow 'userdefined3'
ipchains -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
ipchains -A f0to1 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Red Local' to 'Internet'
# Allow 'userdefined3'
ipchains -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
ipchains -A f0to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Red Local' to 'Local'
# Allow 'userdefined3'
ipchains -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
ipchains -A f1to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Internet' to 'Local'
# Allow 'userdefined3'
iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
# Traffic from 'Local' to 'Internet'
# Allow 'userdefined3'
iptables -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
# Traffic from 'Red Local' to 'Internet'
# Allow 'userdefined3'
iptables -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
# Traffic from 'Red Local' to 'Local'
# Allow 'userdefined3'
iptables -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT

At this point it was clear to me that Guarddog was not writing the
bidirectional iptables commands for User Defined UDP Protocols (ipchains
commands look fine though).  After manually adding those:


# Traffic from 'Internet' to 'Local'
# Allow 'userdefined3'
iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
iptables -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Local' to 'Internet'
# Allow 'userdefined3'
iptables -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
iptables -A f0to1 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Red Local' to 'Internet'
# Allow 'userdefined3'
iptables -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
iptables -A f0to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT
# Traffic from 'Red Local' to 'Local'
# Allow 'userdefined3'
iptables -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT
iptables -A f1to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT


and then restarting Teamspeak, my server was functional again (seems TSS
is a bit "sensible" to not being able to answer back, and will not
accept new connections after an "EIdSocketError.Host not found." error).


Ciao.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages guarddog depends on:
ii  gawk               1:3.1.4-2             GNU awk, a pattern scanning
and pr
ii  kdelibs4           4:3.3.2-6.2           KDE core libraries
ii  libart-2.0-2       2.3.17-1              Library of functions for 2D
graphi
ii  libc6              2.3.5-6               GNU C Library: Shared
libraries an
ii  libfam0c102        2.7.0-6               client library to control
the FAM
ii  libgcc1            1:3.4.3-13            GCC support library
ii  libice6            4.3.0.dfsg.1-14sarge1 Inter-Client Exchange library
ii  libidn11           0.5.13-1.0            GNU libidn library,
implementation
ii  libpng12-0         1.2.8rel-1            PNG library - runtime
ii  libqt3c102-mt      3:3.3.4-3             Qt GUI Library (Threaded
runtime v
ii  libsm6             4.3.0.dfsg.1-14sarge1 X Window System Session
Management
ii  libstdc++5         1:3.3.6-10            The GNU Standard C++ Library
v3
ii  libx11-6           4.3.0.dfsg.1-14sarge1 X Window System protocol
client li
ii  libxext6           4.3.0.dfsg.1-14sarge1 X Window System
miscellaneous exte
ii  libxrender1        0.8.3-7               X Rendering Extension
client libra
ii  xlibs              4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB)
configu
ii  zlib1g             1:1.2.2-4.sarge.2     compression library - runtime

-- no debconf information




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
 
CD: 3ms