[Savannah-hackers-public] Re: cvspserver: moving, but firewall? is in the way

[Sylvain Beucler]

On Sun, Sep 16, 2007 at 04:56:53PM +0200, Jim Meyering wrote:
> Hi Sylvain,
> 
> I'm ready to set up and test git-cvsserver.
> In the cvs vserver, I created this file (please take a look):
> 
>     /etc/xinetd.d/git-cvspserver

I added the 'pserver' argument. Maybe we'll have to do something
around --export-all as well. Do you understand what --strict-paths
means?


> and restarted xinetd.  Now, I can connect to the server from inside:
> 
>     address@hidden telnet 199.232.41.75 cvspserver
>     Trying 199.232.41.75...
>     Connected to 199.232.41.75.
>     Escape character is '^]'.
> 
> but not from the outside:
> 
>     rho$ telnet 199.232.41.75 cvspserver
>     Trying 199.232.41.75...
>     telnet: Unable to connect to remote host: Connection refused
> 
> I poked around in infra/ and see routing-related things,
> but figured it'd be safer to let you do that.

OK I opened the pserver port.

I don't think that old old stuff is documented. I'll do now, feel free
to add it somewhere in infra/ :)

The VServer model is: one firewall for everybody (no per-vserver
firewall at the moment).

So there's a centralised configuration for the firewall. This
configuration uses the super-deprecated Debian Woody model, with
/etc/init.d/iptables start|stop|restart, which reads
/var/lib/iptables/active and /var/lib/iptables/inactive. It's been
working pretty well and nobody likes playing with the firewall, so for
now it stays as-is. A more proper way to enable it would be to add a
pre-up entry in /etc/network/interfaces.

The firewall rejects everything directly, with --with-tcp-reset to be
more efficient, instead of DROPing packets. I like being able to nmap
Savannah and see at once what ports are opened and which one ought to
be closed. This also makes testing more efficient. The RSH port is
rejected with a special irrelevant "protocol not available" error
message, which allows an immediate diagnostic when somebody forgot to
'export CVS_RSH=ssh' ;)

There are some outgoing rules as well; they are not meant for
filtering (the default policy is ACCEPT), but they provide accounting,
so a 'iptables -vL' can tell you how much traffic was delivered per
service when since the last iptables restart.

To update the firewall, you essentially edit /var/lib/iptables/active,
praise, and issue 'invoke-rc.d iptables restart'. In case of troubles,
ask an admin with serial access to log as root2 and fix the firewall.

-- 
Sylvain