l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
December 2: Social gathering
Next Installfest:
TBD
Latest News:
Nov. 18: Club officer elections
Page last updated:
2002 Apr 05 15:24

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] quake3 serving from behind a firewall
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] quake3 serving from behind a firewall



There have been a slew of security problems with running quake
servers. (This includes DDoS). No need to explain, the hisory is
documented "out there."

Make sure your remain current on versions, and look into running
automated software to detect certain kinds of attacks and kick/ban users.

Also, strongly suggest you set it to run as nobody,nogroup in a chrooted
env. This raises the bar enough to keep most potential exploits away.

Also, if you can run a Linux 2.2.x kernel, then think about Solar
Designer's Owl security patchees for linux including the non-executable
stack patch. 

He (I am assuming S.D. is a he) is not yet ready for 2.4.x yet.

Basicly, treat the Q3 server like a copy of BIND. ;-)

I have briefly run a RtCW server which is based on the Q3 engine and
server. It affords a lot of cool stuff. Change the refresh rate for
special weapons, alter gravity by 50%, alter speed by 150%, make respawn
rate 3 seconds instead of 30 seconds.... you get the idea.

I have thought about building my own script/integration for Q3/RtCW that
uses ipchains and fw rules to ban an IP address by fw rules for all types
(ICMP, UDP, TCP etc) so some unhappy fellow previouasly kicked cant suck
up all the bw. (Cant really stop them from sending, but can stop a
response to them and make them think they are having no effect.)

-ME

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(++) !s !a+++(-----) C++$(++++) U++++$(+$) P+$>+++ 
L+++$(++) E W+++$(+) N+ o K w+$>++>+++ O-@ M+$ V-$>- !PS !PE Y+ !PGP
t@-(++) 5+@ X@ R- tv- b++ DI+++ D+ G--@ e+>++>++++ h(++)>+ r*>? z?
------END GEEK CODE BLOCK------
decode: http://www.ebb.org/ungeek/ about: http://www.geekcode.com/geek.html

On Thu, 4 Apr 2002, Peter Jay Salzman wrote:
> heh.   i'm leaving the server up.   as soon as i learn more about quake3
> serving, i'll set up a lugod quake3 server.   maybe we can form a lugod
> clan?   :-)
> 
> thanks steve; i had fun!  :*)
> 
> pete
> 
> ps- problem solved!
> 
> 
> 
> begin Steven Peck <speck@blkmtn.org> 
> > Quake III test succesful
> > 
> > 
> > -----Original Message-----
> > From: vox-admin@lists.lugod.org [mailto:vox-admin@lists.lugod.org] On
> > Behalf Of Peter Jay Salzman
> > Sent: Thursday, April 04, 2002 10:08 PM
> > To: vox@lists.lugod.org
> > Subject: Re: [vox] quake3 serving from behind a firewall
> > 
> > 
> > begin Jeff Newmiller <jdnewmil@dcn.davis.ca.us> 
> > > On Thu, 4 Apr 2002, Peter Jay Salzman wrote:
> > > 
> > > > ok, after much procrastination, i rolled up my sleeves and set up a
> > > > quake3 server.   here's the topology of my LAN:
> > > > 
> > > > 
> > > > --- 64.164.47.8
> > > >    mephisto
> > > >    LEAF
> > > >    firewall                         192.168.0.2  satan
> > > >    192.168.0.1 -------------------- 192.168.0.3  navalle
> > > >                                     192.168.0.4  lucifer
> > > >                                     192.168.0.4  lucifer
> > > >                                     192.168.0.4  moloch
> > > > 
> > > > on the firewall:
> > > > 
> > > > # ipmasqadm portfw -l
> > > > prot localaddr        rediraddr               lport    rport  pcnt
> > pref
> > > > UDP  adsl-64-164-47-8 satan.diablo.localnet   ntp      ntp    10
> > 10
> > > > UDP  adsl-64-164-47-8 satan.diablo.localnet   27960    27960  8
> > 10
> > > > TCP  adsl-64-164-47-8 lucifer.diablo.localnet 27500    27500  10
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   ntp      ntp    10
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   6346     6346   7
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   ssh      ssh    9
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   24       ssh    10
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   smtp     smtp   9
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   www      www    2
> > 10
> > > > TCP  adsl-64-164-47-8 satan.diablo.localnet   ftp      ftp    10 
> > > > 
> > > > 
> > > > i ran the dedicated server on satan (192.168.0.2):
> > > > 
> > > > q3ded +set dedicated 2 +net_ip 64.164.47.8 +map q3dm17 +set 
> > > > com_hunkmegs 200
> > > > 
> > > > 
> > > > now on satan (192.168.0.2), i *can't* connect to the server by 
> > > > specifying a connect to server 64.164.47.8 which surprises me.  
> > > > however, i can connect to the server by specifying 192.168.0.2 which
> > 
> > > > is no surprise.
> > > 
> > > This is normal behavior.
> >  
> > see below
> > 
> > > > however, on lucifer (192.168.0.4) i *can* connect to the server by 
> > > > specifying a connect to server 64.164.47.8.  i can also specify 
> > > > 192.168.0.2.  this is groovy.
> > > 
> > > This is abnormal behavior.  I have never encountered a linux kernel 
> > > that would do this (reflect a masquerade back into the local network).
> > 
> > i believe the way quake3 works is that the server sends an identifier to
> > a master server run by id software that says "i'm running a server at ip
> > address 64.164.47.8".   the master server keeps track of this.  btw, all
> > communication happens with UDP.
> > 
> > a client then connects to the master server and gets a list of all the
> > servers and their ip addresses.  i'm not sure of the details beyond
> > this.  but it seems reasonable that if i run a server on 192.168.0.2
> > that identifies itself as 64.164.47.8 to the master server, and then use
> > a client from 192.168.0.4 to connect to 64.164.47.8, that it would work.
> > 
> > i guess i'm not really sure what it means to reflect a masq back into
> > the local server.  on one hand, i can't ssh from 192.168.0.2 to
> > 64.164.47.8:
> > 
> >    p@satan% ssh p@64.164.47.8
> >    
> >    (it just hangs)
> > 
> > but i can ping:
> > 
> >    p@satan% ping 64.164.47.8
> >    PING 64.164.47.8 (64.164.47.8): 56 data bytes
> >    64 bytes from 64.164.47.8: icmp_seq=0 ttl=255 time=0.6 ms
> > 
> > (note: after checking with tcpdump on the firewall, the ping doesn't
> > leave my local network; it stays internal while ssh does leave the
> > internal net).
> > 
> > 
> > oi.  this is confusing.  just when i thought i had all this figured out,
> > i learn that i know practically nothing.   :(
> > 
> > 
> > still waiting for a quake3 owner to try to connect to 64.164.47.8 ...
> > :)
> > 
> > pete
> > _______________________________________________
> > vox mailing list
> > vox@lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox
> > 
> > _______________________________________________
> > vox mailing list
> > vox@lists.lugod.org
> > http://lists.lugod.org/mailman/listinfo/vox
> _______________________________________________
> vox mailing list
> vox@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox
> 

_______________________________________________
vox mailing list
vox@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.