[vox-tech] DNS and security

[Rick Moen]

Hi, Matt!

Quoting Cylar Z (cylarz at yahoo.com):

> Someone posted a reply to my query on the LUGOD mailing list already -
> perhaps you saw it. (Or was that you?)

That was indeed I.  FYI, every single vox-tech posting is broadcast
with a header that points to the Web-based archive of prior postings,
which you will probably find useful for finding out who has posted what
and when.

> 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.

I hope you kept some kind of record of what you did.

> Well, my box is now broken. I can't even ping it. 

Thus, at minimum, I suspect you shut down networking -- which has the
effect of deconfiguring the network interfaces and removing any IP
routes.

> I can only guess that I wound up shutting off something that was vital
> to the system. 

Well, that depends on what you call "the system", doesn't it?   Any time
you have root access on a Linux or similar system (collectively, *ix
systems), you have the ability to shut down each of the many optional
subsystems, including networking.  However, even after you do that, the
system is still running and can be logged into locally -- unless and
until you shut down the entire 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?

Oops!  When you shut down sshd, you (of course) eliminated the option of
you or anyone else opening a remote ssh connection to the box, until you
or someone else restarts it.  Shutting down "network" was a further
obstacle, as that remove all IP routing and deconfigured the network
interfaces.

No, not portmap, and not anacron.  I would be glad to explain what those
are, but that's not vital at the moment.

And I should point out that you _nowhere_ mentioned that this machine
isn't physically in front of you.  If you had done so, I would have said
"by the way, take care not to run the /etc/init.d/network or
/etc/init.d/sshd scripts with 'stop' options, since that'd be like
locking your front door and leaving your keys on the kitchen counter."

> Both you and the other poster...

Me and myself.  ;->

Off-list, I advised you that you _really, really_ needed to consult the 
prior-posts archive before reposting in public your private e-mail.  It
appears that you didn't take the time to do that.  Oh well.  Not a big
deal -- but you could have saved yourself a bit of confusion, perhaps.

> ...mentioned modifying the file /etc/resolv.conf. Is that really going
> to accomplish anything?

Answered below.

> 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.

Your understanding needs a bit of correcting, then.  I'll explain.

Let me, if you don't mind, quote my prior message on that point, with
emphasis added, this time:

  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).

At the risk (well, cost) of saying the same thing _three_ times, perhaps 
making the point that I really do mean it, /etc/resolv.conf is the
configuration file of a *ix host's DNS CLIENT.  Not the DNS server.

> Named isn't running on my system. 

ISC's "named" (i.e., BIND) is a DNS _server_.  /etc/resolv.conf is NOT 
the configuration for BIND.  Got that?

> 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.

Your other source's information is a) somewhat defective, but also b)
not relevant -- since we're (as noted) not talking about BIND or any
other DNS daemon in the first place.  When I said /etc/resolv.conf is
the configuration file of your host's DNS _client_, I actually
(surprise, surprise!) really did mean exactly that.  ISC's BIND 9.x 
(often known as "named") is an example of a DNS _server_, and is not at
all what I was talking about.

> I need to get outgoing DNS working so that I can surf the Web from the
> console, and run the yum updater command properly.

Then you need a functional DNS _client_, nicht wahr?

> 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? 

If I understand your problem description correctly, your main problem is
that you can ping hosts by IP address but not by hostname (not even
fully qualified hostnames like "www.apple.com").  If that is the case,
then the likely reason is that you didn't have suitable "nameserver"
lines in resolv.conf.  Of course, given that you've in the meantime
deconfigured all your network interfaces, you'll need to fix the latter
problem before you can test that surmise.

> 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):

Please note that I spoke, in this regard, only of the obvious security
exposure from use of plainext passwords in _regular_ non-anonymous ftp:
I carefully qualified what I said, in that regard.  E.g., there's no
such exposure from SSL-wrapped ftp -- and a rather different threat
model if the plaintext passwords are (somehow made to be) different from
the ones usable for remote shell login.

> 1. What do you suggest as a safer alternative? 

Personally, I make a lot of use of scp.  That's a file-transfer service 
using an ssh daemon.

> 2. What's the best way of "shutting off" FTP? Just close its port on
> the firewall? 

Er, unless I'm badly misunderstanding the question, if you're speaking
of a machine you have root access on, the best way to not run an ftp
daemon is to not run an ftp daemon.

> There's no FTP "server" per se running on my box, nor does there need
> to be. 

Then, I'm not sure I understand your question.

> As to our conversation about xinetd, do I need it and it's "child
> daemons" or not?

That's really up to you to decide.  But personally, I rather doubt that
you do.  I hope that helps!

-- 
Cheers,             $n=99;sub b{"$n bottle${[s=>]}[$n==1] of beer"}
Rick Moen           print$b=b, $w=' on the wall',
rick at linuxmafia.com ",$b! Take one down, pass it around, ",b($n--),"$w! "while$n
                                                -- Ben Okopnik