[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: we were attacked



thanks for all of the answers. I am not a sysadmin, only a person with experience in linux and we work in a non for profit organization , because of that, we don't have resources to pay a good sys admin :-) . All the mails for you , tought me something. Today finally we are in serious problem. The sintom was that web server answer with 403 forbidden and we couldn't login with ssh . After an hour of working we found that log of sshd told login_get_lastlog couldn't find user id ..... . Now I just found that we have a / directory changed to mode 700 and tmp directory to 1700

well , I am working now in the server, If I learn somthing more I will share it with you

thanks again

dl

Ward Vandewege wrote:

On Sun, Apr 09, 2006 at 10:31:55AM +1000, Craig Sanders wrote:
On Sat, Apr 08, 2006 at 09:50:58AM -0400, Ward Vandewege wrote:
4) use wrapper for emails - I have one which includes special headers to
mails sent from php, I'm going to modify it to support limits on no. of
mails sent in timeframe
I hope you share this.
Here's an example of such a wrapper:
this is useful but far from foolproof. any script can open a connection
to "localhost:25" and speak SMTP directly to the local mail server. if
the web server isn't running an smtp server (which is very unlikely -
most do, if only to cater for formmail scripts, and to forward system
mail to the sysadmin) the attacker can check the MX record for the
domain being attacked and connect directly to port 25 of the mail host.

Quite - and you need to tell php to use sendmail rather than smtp for the
mail() function, etc. I assumed it was obvious that any mailserver on the
same host/other hosts that are accesible from it on port 25 should be
firewalled. After all this wrapper only traps php's mail() function.

# Just make all e-mail come from webmaster@ the domain. That address _should_
# always be defined.
(out, s) = popen2('/usr/sbin/sendmail -t -i -f webmaster@' + sys.argv[1])
i do the exact opposite. i require all mail sent by web scripts to go
to a real person, whoever is responsible for that script (which may be
webmaster for the domain or it may not)....and failing to set a sender
address (so that it goes to www-data) is grounds for deletion/disabling
of the script.

Yes, that's another way of dealing with it. Hardcoding the sender to
webmaster@ was a bit of an experiment - it's mostly to make sure that there
is a valid sender address - otherwise my mailservers will simply refuse to
accept the message for delivery.

Ward.




Reply to: