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:
August 5: Social gathering
Next Installfest:
TBD
Latest News:
Jul. 4: July, August and September: Security, Photography and Programming for Kids
Page last updated:
2005 Aug 19 23:31

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

Report this post as spam:

(Enter your email address)
Re: [vox-tech] DNS and security
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] DNS and security



Can anyone help? See below.

--- Cylar Z <cylarz@yahoo.com> wrote:

> Date: Thu, 18 Aug 2005 22:08:24 -0700 (PDT)
> From: Cylar Z <cylarz@yahoo.com>
> Subject: Re: [vox-tech] DNS and security
> To: Rick Moen <rick@linuxmafia.com>
> 
> Rick:
> 
> Thanks so much for the information-packed response.
> It's going to take me some time to wade through
> everything you said, and some of it frankly is over
> my
> head. I suppose this will be a learning experience
> for
> me. I'm a newbie and have a LOT to learn, since the
> Linux courses I took at ARC didn't cover anything
> related to system administration.
> 
> Someone posted a reply to my query on the LUGOD
> mailing list already - perhaps you saw it. (Or was
> that you?) In any case, I took his advice and shut
> down all the daemons that weren't on the list I made
> during my original posting.  Well, my box is now
> broken. I can't even ping it. I can only guess that
> I
> wound up shutting off something that was vital to
> the
> system. I can't determine what, until I actually get
> to where the server is physically located (about an
> hour away) and then hope I can log in directly.
> Basically, I killed EVERYTHING except sshd, httpd,
> sendmail, and cron. Could it have been "portmap"
> that
> was the vital one? Network? Anacron? I have no idea,
> do you?
> 
> Once I undo whatever it was I did, I'll be back at
> square one with the original problem, and so I
> wanted
> to ask you a follow-up question. Both you and the
> other poster mentioned modifying the file
> /etc/resolv.conf. Is that really going to accomplish
> anything? I modified the file as directed, but never
> got a chance to see if it worked or not, since the
> system quit responding after I did this, modified
> the
> startup daemon scheme, and rebooted.
> 
> My understanding is that resolv.conf is the
> configuration file for the "named" daemon. Named
> isn't
> running on my system. I was told by another source
> that A) it's a security risk, B) no longer required,
> since the server's domain registrar can handle
> incoming DNS and C) it wasn't running on a prior
> Linux
> install (Xandros, based on Debian) and yet both
> incoming and outgoing DNS functionality were perfect
> then. Please render your input on this situation.
> 
> I need to get outgoing DNS working so that I can
> surf
> the Web from the console, and run the yum updater
> command properly.
> 
> Just FYI, my system hosts 2 virtual domains in
> addition to the "main" one. In the event resolv.conf
> really does need to be modified as you prescribed,
> would I need to mention the virtual domains in the
> resolv file? I wouldn't think so, since they only
> come
> into play as per incoming HTTP requests, and my
> registrar is handling the DNS on that.
> 
> As to FTP, I won't be running it anonymously. I
> simply
> need a means of transfering my webpage files to the
> server remotely. My server only has one user - me.
> At
> present, nobody else has any reason to be connecting
> to it at any time. If FTP is unsecure in your view
> (due to its lack of encryption):
> 
> 1. What do you suggest as a safer alternative? 
> 2. What's the best way of "shutting off" FTP? Just
> close its port on the firewall? 
> 
> There's no FTP "server" per se running on my box,
> nor
> does there need to be. All I need to do is upload
> webpage files.
> 
> As to our conversation about xinetd, do I need it
> and
> it's "child daemons" or not? I'm a bit confused.
> Both
> you and the other guy asked the same question, "Why
> do
> you need xinetd?" I don't know if I do or not -
> that's
> what I'm asking! :) I simply assumed I did since it
> seems to control so many other things.
> 
> You know my requirements - mail server, http server,
> secure ftp access, command-prompt via SSH2. That's
> all.
> No file-sharing, no print server, no routing, no
> Samba, no anonymous FTP, none of that stuff. I want
> to
> shut off anything that isn't absolutely necessary,
> but
> I can't seem to locate a comprehensive guide to what
> each service does so I can figure out if it's needed
> or not.
> 
> Thanks again for all your help.
> 
> Matt
> 
> --- Rick Moen <rick@linuxmafia.com> wrote:
> 
> > Quoting Cylar Z (cylarz@yahoo.com):
> > 
> > > I'm a fairly new Linux admin, running Fedora
> Core
> > from
> > > Redhat. 
> > 
> > Hi, Matt.  For a good overview, please see Linux
> > Journal editor Don
> > Marti's overview, which I just saw him mention on
> a
> > different Linux
> > mailing list: 
> >
> http://zgp.org/~dmarti/blosxom/tips/new-server.html
> > 
> > > 1. Outgoing DNS isn't working properly on my
> > server.  The box will
> > > respond properly to incoming http requests (and
> > even allowed me to
> > > host 2 virtual domains, which also respond
> > properly). However, it does
> > > NOT surf the web from the console or ping by
> > domain name. It WILL ping
> > > by IP so I know the issue is DNS and not my
> actual
> > connection per se.
> > > How do I put in the DNS info in Fedora Core? I
> > tried logging on as
> > > root, typing "setup" and entering the IP's in
> the
> > designated spaces,
> > > but no luck. Is there another way?
> > 
> > The IP-address locations of the DNS servers your
> box
> > will be consulting
> > are always recorded in /etc/resolv.conf, the
> > configuration file of your
> > host's DNS resolver library (i.e., of the DNS
> client
> > software your box
> > uses to deal with DNS questions that must be
> > referred to a DNS daemon
> > running somewhere).
> > 
> > Here's my own server's /etc/resolv.conf:
> > 
> >   search linuxmafia.com deirdre.org
> >   nameserver 198.144.192.2
> >   nameserver 198.144.192.4
> >   nameserver 198.144.195.186
> > 
> > Distributions differ in what tools they prefer you
> > to use, in editing
> > your system configuration files.  Of course, you
> can
> > always ignore those
> > intentions and use $MY_FAVOURITE_TEXT_EDITOR --
> > which is what I
> > personally tend to do -- but your Fedora
> > documentation may well have
> > something to say about that.
> > 
> > 
> > > 2. In the interest of system security, I want to
> > run the absolute
> > > minimum number of daemons/services. Which ones
> do
> > I really, really
> > > need?
> > 
> > That's an excellent and really important question.
> > 
> > Many people approach this question from a
> functional
> > perspective.  That
> > is, they say, if you want to determine which
> daemons
> > you need, try
> > switching each of them off, in turn, and find out
> if
> > anything you care
> > about breaks.  Of course, in a strict sense,
> nobody
> > but you can tell you
> > what your box needs to run, anyway, because only
> you
> > know what roles
> > your box needs to fulfill.
> > 
> > > So far I've established that I need httpd, sshd,
> > sendmail, xinetd, and
> > > possibly cron.
> > 
> > Please note that "xinetd" is an example of what is
> > called a
> > "superserver", i.e., a server whose purpose is to
> > load and launch other
> > servers (daemons) under its control and
> supervision,
> > in part so that
> > those servers don't need to be loaded into RAM all
> > the time, but instead
> > can be loaded only when there's an incoming
> request
> > for them.
> > 
> > One consequence of this is that xinetd has its own
> > configuration file,
> > /etc/xinetd.conf, and a directory of configuration
> > files for each
> > supervised server, /etc/xinetd.d/ .  The files in
> > /etc/xinetd.d/
> > specify, among other things, whether xinetd shall
> be
> > willing to launch
> > this daemon at all, if there's an incoming
> request.
> > 
> > Here, for example, is /etc/xinetd.d/chargen , with
> > the option
> > "disable=yes":
> > 
> >   # default: off
> >   # description: An xinetd internal service which
> > generate characters. \
> >   # The xinetd internal service which continuously
> > generates characters \
> >   # until the connection is dropped.  The
> characters
> > look something like
> >   # this: \
> >   #  
> >
>
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefg
> >   #   \
> >   # This is the tcp version.
> >   service chargen
> >   {
> >           disable = yes
> >           type            = INTERNAL
> >           id              = chargen-stream
> >           socket_type     = stream
> >           protocol        = tcp
> >           user            = root
> >           wait            = no
> >   }
> > 
> > Given that you've elected to leave xinetd running,
> > it's in your interest
> > to go through each of the files in /etc/xinetd.d/
> > individually, and
> > decide for each one whether you can imagine any
> > reason why you want to
> > offer up that daemon as an available service to
> > remote machines.
> > 
> > I picked "chargen" (a character-stream generator
> > that, if running, spews
> > out a stream of ASCII on TCP or UDP port 19;
> really,
> > that's _all_ it
> > does) as an example because it examplifies pretty
> > well the point that
> > many xinetd services are leftover antiques of no
> > real use to most people
> > -- and who knows what mischief someone might carry
> > out using them?  The
> > paranoiac's view would be:  If you don't know why
> > you need a running
> > daemon, shut it off until and unless you determine
> > otherwise.
> > 
> > By the way, your system almost certainly needs to
> > run cron because it
> > supervises periodic housekeeping scripts that need
> > to be run at specific
> > regular times.  Fortunately, it is not
> > network-accessible from
> > elsewhere.
> > 
> > >  Are there any others that are suggested that I
> be
> > running? 
> > 
> > And the answer to that depends entirely on what
> the
> > machine needs to do.
> > 
> > > This server responds to web requests and lets me
> > SSH in remotely. (I
> > > don't use Telnet.) That's about all it needs to
> > do.
> > 
> > This begs the question of why you say it also
> needs
> > to run xinetd.  
> > You might, or you might not.  It depends on
> whether
> > you have any use for
> > any of the couple-dozen minor services xinetd is
> > capable of offering.
> > You decided.
> >  
> > > Also, is FTP a security risk, or is it safe to
> > leave this port open?
> > 
> > This is a controversial question.
> > 
> > Many people feel that ftp is redundant in an era
> of
> > pervasive http
> > implementations.  (Note that http is a simpler
> > protocol and doesn't have
> > the slightly problematic feature of using a
> control
> > TCP port as well 
> > as a data-transmission TCP port.  That feature of
> > ftp tends to make it
> > slightly difficult to control at IP-filtering
> > firewalls, and you end up
> > having to adopt palliative measures like running
> all
> > ftp sessions in 
> > what is called "passive ftp mode".)
> > 
> > I personally got a little tired of hearing that
> > stated as a blanket
> > 
> === message truncated ===
> 
> 
> 
> "Our nation has defended itself and served the
> freedom of all mankind. I'm proud to lead such an
> amazing country and I'm proud to lead it forward."  
> - President George W Bush, November 3 2004
> 
> God give wisdom to our leaders. God bless America.
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> 


"Our nation has defended itself and served the freedom of all mankind. I'm proud to lead such an amazing country and I'm proud to lead it forward."   - President George W Bush, November 3 2004

God give wisdom to our leaders. God bless America.


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



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:
O'Reilly and Associates
For numerous book donations.