Re: sendmail compromised - Somebody help me!

Ohmster <notareal@emailaddress.com> wrote:

> Yes, I just found out that I had backdoors on the system. phpbb 2.0.6 no
> doubt was the culprit.

You also mentioned running awstats as a CGI, which I myself was doing
until February 2005, when my recklessness caught up with me -- and I'm a
pro at this stuff, Ohmster. AIDE and Tripwire told me the box had been
rooted; I got confirmation by noticing that my Web site's front page had
been "defaced" (replaced with some illiterate brag sheet from the kiddie
who'd run an automated exploit via the CGI's input stream).

I pulled the plug, rebooted from an LNX-BBC disk, updated my backups of
the data files and installed-packages list, made a copy of my /etc tree
for reference (but not re-use), blew away (reformatted) the entire
system, reinstalled from trusted, known-good media, copied back the data
files, disabled users' dotfiles (as they were suspect), disabled
password authentication for remote users entirely (switching over to
allowing SSH public key auth only), worked for many hours recreating
desired system configuration -- not trusting the prior configuration
files or executables in so doing -- studied system security to try to
make sure I hadn't recreated any of the same hazards as before, _only then_
put the machine back on the network, and contacted my users via other
means ("out of band") to let them know what happened. Total elapsed
time: 22 hours.

I also discovered, to my shock, that the default PHP configuration was
grossly security-reckless, and started the job of tightening down
php.ini. See system bulletin: http://linuxmafia.com/news.html .

Your CGIs are a potential problem: Running awstats as a CGI is the path
of least resistence, but you really should run it instead, if at all, as
a cronjob generating a static HTML page _not_ subject to the same sorts
of input attacks. Your PHP configuration, if typical, is a veritable
Typhoid Mary of risk -- as, judging by its sorry security history, is
phpbb. And of course an unmaintained, end-of-lifed distribution such as
RH9 in 2005 is a ghastly, unbelievable risk.

Welcome to the ranks of the slightly scarred but wiser. ;-> You may
find a few of my security articles of interest. They're linked from my
home page, http://linuxmafia.com/~rick/

(And I'm sorry to hear about the pain being visited on you -- though I
insist I have an alibi. ;-> )

Good fortune and good hunting!

--
May those that love us love us; and those that don't love us, may
God turn their hearts; and if he doesn't turn their hearts, may
he turn their ankles so we'll know them by their limping.

Rick Moen wrote:
> I also discovered, to my shock, that the default PHP configuration was
> grossly security-reckless, and started the job of tightening down
> php.ini. See system bulletin: http://linuxmafia.com/news.html .
>
After reading this I took another look at my php.ini on my new Fedora
Core 3 http server. The defaults are now almost all set as you describe
in your news.html. This was not the case for the old RedHat 9 server
where most of the stuff was defaulted 'on' (I manually change the
php.ini under RedHat 9 a long time ago).

It is always good practice to revisit configuration scripts from time to
time. What seemed okay a few months ago may not be good practice today.
As oh so many have said on this group 'security is a moving target' and
'constant vigilance is the price' one pays.

Mike <honey@michaelmoyse.co.uk> wrote in
news:NbCdnVguW6VGjO_fRVnyvw@pipex.net:

> No!!! Stop faffing about! Your first priority is to secure that
machine.
>
> Why do you have an FTP server accepting anonymous connections with a
> world writeable directory????
>
> Why are you exposing ntp to the world? Are you an official time source?
>
> Do you really use ntalk???
>
> I'd say sort your firewall but it looks much more to me like you need
to
> get one.

Definitly doing that today. The redhat 9 EOL machine is history. I
learned a lot in the past several years with it, am wiping it today and
replacing it with FC3, have the iso files already. New OS will be up
today with much hardened firewall, will add the rest of the stuff as I
need it, securing it as I go. I had expermimented with ntalk in the past
but found it to be of little or no use in this day and age, there will be
no ntalk on the new system.

Thanks for all of the good advice, Mike.

--
~Ohmster
ohmster at newsguy dot com

Barton L. Phillips <bartonphillips@sbcglobal.net> wrote:

> After reading this I took another look at my php.ini on my new Fedora
> Core 3 http server. The defaults are now almost all set as you describe
> in your news.html. This was not the case for the old RedHat 9 server
> where most of the stuff was defaulted 'on' (I manually change the
> php.ini under RedHat 9 a long time ago).
>
> It is always good practice to revisit configuration scripts from time to
> time. What seemed okay a few months ago may not be good practice today.
> As oh so many have said on this group 'security is a moving target' and
> 'constant vigilance is the price' one pays.

Indeed.

My distro furnishes a couple of prototype php.ini files:

/usr/share/doc/php4/examples/php.ini-paranoid
/usr/share/doc/php4/examples/php.ini-recommended

The former was evidently furnished by Javier Fernández-Sanguino Peña
<jfs@debian.org>.[1] I'll soon be diff'ing it against my own. There
might be an article in it. ;->

http://phpsec.org/ (PHP Security Consortium site)
http://www.php.net/features.safe-mode (Safe mode features of PHP)
http://shiflett.org/archive/81 (Chris Shiflett's talks on PHP security)
http://www.phpsecure.info/ (PHP secruity site)

[1] Googling on that filename, one finds
http://bender.ecap.it/doc/php4-imap/...p.ini-paranoid ,
which is probably the same file.

--
Cheers, The other day, upon the stair,
Rick Moen I met a man who wasn't there.
rick@linuxmafia.com He wasn't there again today;
I think he's from the CIA.

Rick Moen wrote:
> Barton L. Phillips <bartonphillips@sbcglobal.net> wrote:
>
>
>>After reading this I took another look at my php.ini on my new Fedora
>>Core 3 http server. The defaults are now almost all set as you describe
>>in your news.html. This was not the case for the old RedHat 9 server
>>where most of the stuff was defaulted 'on' (I manually change the
>>php.ini under RedHat 9 a long time ago).
>>
>>It is always good practice to revisit configuration scripts from time to
>>time. What seemed okay a few months ago may not be good practice today.
>>As oh so many have said on this group 'security is a moving target' and
>>'constant vigilance is the price' one pays.
>
>
> Indeed.
>
> My distro furnishes a couple of prototype php.ini files:
>
> /usr/share/doc/php4/examples/php.ini-paranoid
> /usr/share/doc/php4/examples/php.ini-recommended
>
> The former was evidently furnished by Javier Fernández-Sanguino Peña
> <jfs@debian.org>.[1] I'll soon be diff'ing it against my own. There
> might be an article in it. ;->
>
> http://phpsec.org/ (PHP Security Consortium site)
> http://www.php.net/features.safe-mode (Safe mode features of PHP)
> http://shiflett.org/archive/81 (Chris Shiflett's talks on PHP security)
> http://www.phpsecure.info/ (PHP secruity site)
>
> [1] Googling on that filename, one finds
> http://bender.ecap.it/doc/php4-imap/...p.ini-paranoid ,
> which is probably the same file.
>
His list of disabled functions would surely break some of my php apps.
Of course it is pick your own and some of the ones he has in his list
might be good choices.

; Note: The list of functions disabled here might break some applications
; however, they are considered dangerous and often subverted by attackers
; remotely
disable_functions = dl, phpinfo, system, mail, include, shell_exec,
exec, escapeshellarg, escapeshellcmd, passthru, proc_close, proc_open,
proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose,
chown, disk_free_space, disk_total_space, diskfreespace, fileinode,
max_execution_time, set_time_limit,highlight_file, show_source