headers
K. Elo | 1 Sep 2005 14:11
Picon
Picon
Favicon

Re: NFS connection dropped

Hi again,

I have now checked out the configuration of Guarddog and found out on 
the laptop the connection between "local" and "h-network" was not 
permitted. This was a self-made mistake and caused the laptop to drop 
the outgoing connection from the client.

However, this did NOT result in a functioning nfs-connection. The server 
still refuses to establish a connection. Here the output of my 
server-side firewall log produced when I tried to browse the available 
nfs-servers (192.168.1.2 ist the non-public static IP address attached 
to the laptop NIC):

Sep  1 09:03:30 Elot kernel: DROPPED IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:c0:9f:bc:fd:a2:08:00 SRC=192.168.1.2 
DST=192.168.1.255 LEN=120 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=UDP 
SPT=1025 DPT=111 LEN=100 
Sep  1 09:03:36 Elot kernel: DROPPED IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:c0:9f:bc:fd:a2:08:00 SRC=85.76.255.219 
DST=85.76.255.255 LEN=120 TOS=0x00 PREC=0x00 TTL=64 ID=4 DF PROTO=UDP 
SPT=1025 DPT=111 LEN=100 
Sep  1 09:03:36 Elot kernel: DROPPED IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:c0:9f:bc:fd:a2:08:00 SRC=192.168.1.2 
DST=192.168.1.255 LEN=120 TOS=0x00 PREC=0x00 TTL=64 ID=5 DF PROTO=UDP 
SPT=1025 DPT=111 LEN=100 
Sep  1 09:03:44 Elot kernel: DROPPED IN=eth0 OUT= 
MAC=ff:ff:ff:ff:ff:ff:00:c0:9f:bc:fd:a2:08:00 SRC=192.168.1.2 
DST=192.168.1.255 LEN=120 TOS=0x00 PREC=0x00 TTL=64 ID=7 DF PROTO=UDP 
SPT=1025 DPT=111 LEN=100 
Sep  1 09:03:54 Elot kernel: DROPPED IN=eth0 OUT=
(Continue reading)

Permalink | Reply | 6 comments |
headers
Carsten Schmidt | 1 Sep 2005 21:03
Picon
Favicon

Tutorial: Using Zones - mailserver with security ports

hello there,

I wanna say thank You to Simon Edwards for this realy nice and "good to 
read" Guarddog Handbook .
Nevertheless I failed in the "Tutorial: Using Zones", because I didn't 
realize, that my client is connecting to my ISP via Port 465 
(mail.gmx.net) - which seems not to be covered by the standard mail 
protocolls.
https://www.grc.com/PortDataHelp.htm named this port "urd", which I 
couldn't find in the guarddog list. (?)
So I decided, to make a "user defined protocoll".
May it would be a good idea, to make a hint in this Handbook section 
about checking the ports.

Nevertheless, Your interface & handbook helps me very much to get rid of 
  my "fear" about this iptables stuff -- thank you!!

carsten
munich, germany
Attachment (stalky.vcf): text/x-vcard, 113 bytes
Permalink | Reply | 1 comment |
headers
Dr. Michael J. Chudobiak | 1 Sep 2005 21:45
Favicon

Re: NFS connection dropped

K. Elo wrote:
 > Sep  1 09:03:30 Elot kernel: DROPPED IN=eth0 OUT=
 > MAC=ff:ff:ff:ff:ff:ff:00:c0:9f:bc:fd:a2:08:00 SRC=192.168.1.2
 > DST=192.168.1.255 LEN=120 TOS=0x00 PREC=0x00 TTL=64 ID=3 DF PROTO=UDP
 > SPT=1025 DPT=111 LEN=100
...
 > The port 111 the client is trying to connect to is the SUN remote
 > procedure call. In my GD configuration this protocol _is_ served from
 > both "local" and "h-network" to clients in "h-network"/"local"!!! So
 > why on earth are connections to this port dropped by GD?!?!?! The
 > "h-network" zone address range is 192.168.1.0/255.255.255.0 so the DST
 > 192.168.1.255 should fit into this range, right??
 >
 > Once again: the protocols permitted between "local" and "h-network" are:
 > NFS, rsync, SUN remote procedure call, ssh, ping, ident/auth. Should
 > there be some in addition to these (e.g. ftp)?
 >
 > Any ideas?
 >
 > Kind regards,
 > Kimmo

Kimmo,

Port 1025 is the problem in the above log. Its being blocked, not 111. 
However, the ports used by NFS are usually NOT static. It might be 1025 
today, 9999 tomorrow. You have to "pin" the NFS ports, and open the 
firewall for them. To do this:

1. Create the file "/etc/sysconfig/nfs" and add the following contents:
(Continue reading)

Permalink | Reply | 5 comments |
headers
K. Elo | 2 Sep 2005 10:29
Picon
Picon
Favicon

Re: NFS connection dropped

Hi Michael, hi list,

thanks for your help.
Dr. Michael J. Chudobiak wrote (1.9.2005, 22:45):
> Port 1025 is the problem in the above log. Its being blocked, not
> 111. However, the ports used by NFS are usually NOT static. It might
> be 1025 today, 9999 tomorrow. You have to "pin" the NFS ports, and
> open the firewall for them. To do this:

OK, so if the protocol is allowed then the guarddog's log message could 
point either on a SPT or DPT problem, right? What I mean is that a 
connection might be refused because a) the protocol is not permitted, 
b) the source port the connection is coming from is not allowed or c) 
the destination port the connection is trying to connect to is not 
allowed. Which one is the _real_ reason for dropping the connection 
cannot be extracted from the log message - this makes error-tracking a 
little bit tricky...

To Mike's suggestions:
> 1. Create the file "/etc/sysconfig/nfs" and add the following
> contents:
>
> STATD_PORT=4001
> LOCKD_TCPPORT=4002
> LOCKD_UDPPORT=4002
> MOUNTD_PORT=4003

This makes the nfs and mountd ports to be static instead of being 
dynamically set, right?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dr. Michael J. Chudobiak | 2 Sep 2005 14:08
Favicon

Re: NFS connection dropped

Kimmo,

 > allowed. Which one is the _real_ reason for dropping the connection
 > cannot be extracted from the log message - this makes error-tracking a
 > little bit tricky...

Yes, for sure. However, Guarddog is just a GUI editor for iptables. 
iptables is responsible for the log format. I don't think the iptables 
log format is user-adjustable.

 >> STATD_PORT=4001
 >> LOCKD_TCPPORT=4002
 >> LOCKD_UDPPORT=4002
 >> MOUNTD_PORT=4003
 >
 > This makes the nfs and mountd ports to be static instead of being
 > dynamically set, right?

Yes. Actually, beware that the "/etc/sysconfig/nfs" file might be Red 
Hat specific. Check that your nfs daemon init script actually reads this 
file. It might not in Suse.

 > But, in my /etc/services the nfs (tcp/udp) is connected to 2049, mountd
 > to 763 and the following lines exist, too:
 > terabase        4000/tcp   # Terabase
...
 > pxc-roid        4004/udp   # pxc-roid
 >
 > Do I see a problem here??
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Edwards | 3 Sep 2005 12:28
Favicon

Re: Tutorial: Using Zones - mailserver with security ports

Hi,

On Thursday 01 September 2005 21:03, Carsten Schmidt wrote:
> I wanna say thank You to Simon Edwards for this realy nice and "good to 
> read" Guarddog Handbook .
> Nevertheless I failed in the "Tutorial: Using Zones", because I didn't 
> realize, that my client is connecting to my ISP via Port 465 
> (mail.gmx.net) - which seems not to be covered by the standard mail 
> protocolls.
> https://www.grc.com/PortDataHelp.htm named this port "urd", which I 
> couldn't find in the guarddog list. (?)

It's actually SMTP over SSL.

I can add it.

--

-- 
Simon Edwards             | Guarddog Firewall
simon <at> simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 0 comments |
headers
Simon Edwards | 3 Sep 2005 13:16
Favicon

Re: NFS connection dropped

Hello,

On Friday 02 September 2005 14:08, Dr. Michael J. Chudobiak wrote:
> So... ideally the developer would modify GD to become aware of and open 
> portmap-assigned ports for enabled services. Whether that's actually 
> possible, I have no idea! But it would be an extremely useful feature...

It gets very tricky very quickly. You can look up the allocated port numbers 
on the machine that is running Guarddog, but that doesn't really work when 
you want to connect (as a client) to a remote NFS share. (= need the port 
numbers for the remote machine). And it doesn't work when Guarddog is on a 
gateway machine and NFS is just passing through Guarddog. In that case you 
need to know the port numbers for the NFS servers on either side of the 
gateway. very ugly. NFS was put together before firewalls were a concern, 
which is why it sucks so much. The only remotely practical solution is to pin 
down the ports numbers on all of your NFS machines.

cheers,

--

-- 
Simon Edwards             | Guarddog Firewall
simon <at> simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
(Continue reading)

Permalink | Reply | 1 comment |
headers
sargon | 3 Sep 2005 17:24

Guarddog and IPv6

If I missed this when checking through the archives, I apologize....

Are there plans to add IPv6 support to Guarddog?

Thanks.

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 0 comments |
headers
Paul Cupis | 4 Sep 2005 13:16
Picon
Gravatar

German translation

Jens Seidel has submitted the attached revision to the German PO file
for guarddog.
Attachment (guarddog_2.4.0-1_de.po.diff.gz): application/x-gzip, 1091 bytes
Permalink | Reply | 0 comments |
headers
Matt Randolph | 5 Sep 2005 00:13
Picon

All ports are closed after rebooting

I'm using Guarddog 2.4.0 on Gentoo.

All of my ports are closed after a reboot unless I manually run Guarddog 
and click OK or Apply.  When I do run Guarddog, the appropriate ports 
are opened and I can use the web, etc.

The first time I rebooted after installing and configuring Guarddog, 
iptables failed to load because it couldn't find a configuration file.  
I believe the error message was:

Not starting iptables.  First create some rules then run:
/etc/init.d/iptables save

I ran Guarddog and then did `/etc/init.d/iptables save` and iptables 
loaded succesfully on my next reboot.

Nonetheless, all of my ports continue to be closed upon rebooting.  I 
still have to explicitly run Guarddog to get any ports to open.

I have tried to find out just what it is that changes when I run 
Guarddog.  One thing that does change is that the ip_conntrack_ftp 
module gets loaded by Guarddog.  I have tried loading this module 
manually instead of running Guarddog, but it doesn't solve the problem.  
As a side note, if I build ip_conntrack_ftp into the kernel instead of 
as a module, Guarddog reports that the module is missing in the form of 
a fatal error.

I'd be happy to post my configuration files or that error message if 
that would be helpful.  I can also list the relevant lines of my kernel 
configuration.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane