lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EDDD0C7.8030808@asp64.com>
Date: Tue, 06 Dec 2011 09:22:31 +0100
From: Guillaume Friloux <guillaume.friloux@...64.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: one of my servers has been compromized

On 05/12/2011 18:20, John Jacobs wrote:
> Tim, while I do believe there is some truth in what you are saying here, I respectfully disagree in that this tends to be a run-of-the-mill IRC bot as evidenced by the Undernet advisory.  This looks like a skiddie-de-jour attack against PHPMyAdmin and nothing to be concerned with regarding cloning disk images and full forensics.  I do respect your input and thoughts though for a more targeted attack; not an IRC bot in /tmp.
>
> That being said, I strongly believe in preserving bash_history as well as vital log data.  It's best/wise to ship this off to a separate Syslog server.  If you're paranoid turn up stunnel between the devices.  For example and as evidenced by many of the documented attacks here purging of bash_history is common ala 'history -c' after fun.  To thwart this I like the idea of logging to syslog often, ensure permissions are strict for the syslog messages, and shipping the syslog data off to a separate box.  I like to:
>
> 1) Generate an E-Mail alert when someone logs in, by adjusting /etc/bash.bashrc (or similar based on distribution) to:
>
> #Email alert for login
> echo -e "Subject: Login from $(/usr/bin/whoami) on $(/bin/hostname) at $(/bin/date)\n\n$(/usr/bin/last -ian 10)\n"|/usr/sbin/sendmail recipient@...mple.com
>
> 2) Preserve, via Syslog, commands executed at the prompt, by adjusting /etc/profile.  Adjust /etc/syslog.conf or /etc/rsyslog.conf to forward these syslog messages off-box to another asset.  If you're paranoid use stunnel.
>
> export PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo "$$ $USER $(history 1)"|/usr/bin/logger -p user.alert -t bash_history'
> readonly PROMPT_COMMAND
>
> 3) Preserve bash_history by adjusting /etc/profile:
>
> #Secure the Bash History
> export HISTSIZE=1500
> export HISTCONTROL=''
> export HISTIGNORE=''
> export HISTTIMEFORMAT='%F %T '
> readonly HISTFILE
> readonly HISTFILESIZE
> readonly HISTSIZE
> readonly HISTCONTROL
> readonly HISTIGNORE
> readonly HISTTIMEFORMAT
>
> 4) Optionally use chattr to set ~/.bash_history to append-only:
>
>   #Secure .bash_history (poke fun of the while subshell if you wish)
>   /usr/bin/find / -maxdepth 3|/bin/grep -i bash_history|while read line; do /usr/bin/chattr +a "$line"; done
>
> 5) Use of an IP Recorder, something like daemonlogger, in ring-buffer mode, as a way to record all ingress/egress traffic using a percentage of the disk.  See http://www.snort.org/users/roesch/Site/Daemonlogger/Daemonlogger.html
>
> I am eager to hear any additional thoughts or methods for security information such as this.
>
> Thanks,
> John
>
Hello,
You have been giving a lot of good practices, and i would like to add some :
Logs can be easilly compromised. Here, we send store logs locally, but
we also send them over the network to another server that store them “as
is” but also store them in a database (a “locked from the outside”
elasticsearch).

We also log every PTS session using scripts, so even if there is more
than one PTS open, we get accurate logs (we choosed to use the 'script'
proggy to record sessions, and be able to replay them later, and we
automaticcally archive them as sessions get closed). For this, you can
do it in bashrc, also monitor from ssh public keys, you can also replace
/bin/sh with a logger generating unique logs indexed in an external DB.

Logs cleaners will not be able to erase that stuff.

View attachment "guillaume_friloux.vcf" of type "text/x-vcard" (173 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (555 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ