Greg Kettmann wrote:
>
> Well, I talked to their legal department, a million times better than
> their security department and it appears we can work something out. So,
> my purpose here is two things. One, to vent a little (thanks :-) ) and
> two to ask about known vulnerabilities. My machine is a reformatted RH
> 6.2 installation. I intend (downloading the kernel from a modem really
> stinks) to upgrade to 2.2.18 (any reason to go to .19?) because I heard
> there was some fix there.
There is a very good reason for going to 2.2.19. It fixes the security
holes that are in 2.2.16-2.2.18. Since you don't have time to really
work on this much, I suggest grabbing a copy of Bastille-Linux to do
some system hardening. It will also probably teach you a thing or two
while it works.
> Additionally I am going to get the latest
> BIND to fix that exploit. I'm going to run a fairly tight IPCHAINS
> script. I don't run an HTTP server on the firewall, nor any other
> services.
If you aren't running any services, then I would take that to mean that
you aren't running a DNS server. If you aren't running a DNS server,
then you don't need BIND *at all*. If you don't need to run a DNS
server, which you probably don't unless you are running a domain, then I
wouldn't even have BIND installed. If it's not installed, then it can't
be exploited.
> I will have SSH and FTP open. Other than that I will open
> only things for my Masquerading machines inside to get out. (POP, SMTP,
> HTTP, Time (13), Probably IRC and IDENTD (needed for many IRC's), FTP,
> etc pretty much the standard list. Could one of you really good Network
If you are running SSH, then why do you need FTP? FTP is a bad idea for
several reasons: 1) username and password will be passed in clear text
(see SSH suggestion) 2) There are usually a few vulnerabilities found in
wu-ftpd on a monthly basis. Since you're running SSH anyway, just use
SCP in it's place. If you want to run FTP despite all of the badness,
then I would suggest using public/private keypairs for SSH. If someone
sniffs your username and password from an FTP connection, and you are
using the same username and password for SSH, then the *crackers* will
have access to the system (but in a very secure manor ;-).
As for outgoing/MASQ traffic, you should be careful. There are
vulnerabilities in NTP clients and IRC clients. I would also restrict
the mail ports to specific servers (ie only allow smtp to and from
smtp.ne.mediaone.net and POP3 to/from pop.ne.mediaone.net). That limits
the risk of the opening.
For the ipchains script, you can use Bastille to fashion one for you,
sort of, or you can build it yourself. However, and I *HAVE* to say
this, please don't use Rob Zeiglers utility. You'll only lose your M1
account again in a week or two ;-)
> Admin guys tell me if I'm on the right track? Any other suggestions?
> Thanks.
You seem to be on the right track. Basically, allow all traffic
originating on the internal network out, but don't let anything in. Use
the `! -y` option. A LOT! Use a `default deny` policy. And log log log
log log. Log everything. Heck, set up an internal syslog server so that
you can have a good view of everything. Look into things like portsentry
and snort, but don't count on IDS's to protect you. There is no
substitute for reviewing logs.
> Also, one other vent. I wish those jerks at M1, instead of pulling the
> plug on my account, would first trace the darn thing and go try to catch
> the bad guy instead of harassing their customers. Then they can pull
> the plug and give me a chance to fix it. These procedures of theirs are
> doing nothing to fix the problem and just punishing the victims. Rather
> like punishing someone because their car was stolen. Argh.
It's not their job. Not to mention, Linux is unsupported. Oh, and have
you ever had your car stolen? The police do the same thing ;-)
C-Ya,
Kenny
--
-------------------------------------------------
Kenneth E. Lussier
Geek by nature, Linux by choice
PGP KeyID 0xD71DF198
Public key available @ http://pgp.mit.edu
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
