Violazione computer : Come fare ?
pac
root via ssh. Il pc infatti ha un accesso pubblico con ssh
Da qui si è divertito a sistemare una serie di suoi ssh-keygen ssh-add
ssh-probe
Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
scoperto nuova violazione.
Il log dice
Jul 8 08:04:58 sshd[23885]: Accepted password for root from
79.33.45.194 port 40063 ssh2
Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
root by (uid=0)
Allora la porta che ho cambiato non la 40063 e comunque questa non è
aperta nel router x ssh, anzi non è aperta per nulla.
Quindi volevo sapere cosa è successo secondo voi e come fare ?
--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-ital...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listm...@lists.debian.org
To UNSUBSCRIBE, email to debian-ital...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Luigi di Lazzaro
> Allora pc violato, il nostro cicciobello è riuscito a entrare come
> root via ssh. Il pc infatti ha un accesso pubblico con ssh
> Da qui si è divertito a sistemare una serie di suoi ssh-keygen
> ssh-add ssh-probe
> Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
> scoperto nuova violazione.
> Il log dice
> Jul 8 08:04:58 sshd[23885]: Accepted password for root from
> 79.33.45.194 port 40063 ssh2
> Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
> root by (uid=0)
> Allora la porta che ho cambiato non la 40063 e comunque questa non è
> aperta nel router x ssh, anzi non è aperta per nulla.
> Quindi volevo sapere cosa è successo secondo voi e come fare ?
file di configurazione /etc/sshd_config
PermitRootLogin no
di default e' su yes
Qui non sono sicuro, ma:
whois 79.33.45.194
ti dice chi dovrebbe essere.
Una mail al sysadmin del provider i cui indichi data e ora della
violazione e l'indirizzo ip potrebbe avere qualche effetto.
Luigi
Carlo
Luigi di Lazzaro ha scritto:
>> pac ha scritto:
>> Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
>> scoperto nuova violazione.
>> Il log dice
>> Jul 8 08:04:58 sshd[23885]: Accepted password for root from
>> 79.33.45.194 port 40063 ssh2
>> Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
>> root by (uid=0)
>> Allora la porta che ho cambiato non la 40063 e comunque questa non �
>> aperta nel router x ssh, anzi non � aperta per nulla.
>> Quindi volevo sapere cosa � successo secondo voi e come fare ?
>>
> Non permetttere l'accesso a root via ssh. C'e' un'apposita opzione nel
> file di configurazione /etc/sshd_config
> PermitRootLogin no
> di default e' su yes
>
> Luigi
>
>
Consiglio anche di mettere in /etc/passwd
games:x:5:60:games:/usr/games:/bin/sh
games:x:5:60:games:/usr/games:/bin/false <--- false
per tutti gli utenti tranne root e l'utente che userai per connetterti
visto che non lo potrai fare da root
oppure abbiamo capito male e quella porta non � nattata verso il server
e riesce a raggiungerti lostesso?
Carlo
> Luigi di Lazzaro ha scritto:
>>> pac ha scritto:
>>> Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
>>> scoperto nuova violazione.
>>> Il log dice
>>> Jul 8 08:04:58 sshd[23885]: Accepted password for root from
>>> 79.33.45.194 port 40063 ssh2
>>> Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
>>> root by (uid=0)
>>> Allora la porta che ho cambiato non la 40063 e comunque questa non �
>>> aperta nel router x ssh, anzi non � aperta per nulla.
>>> Quindi volevo sapere cosa � successo secondo voi e come fare ?
>>>
>> Non permetttere l'accesso a root via ssh. C'e' un'apposita opzione
>> nel file di configurazione /etc/sshd_config
>> PermitRootLogin no
>> di default e' su yes
>>
>> Luigi
>>
>>
Completo scrivendo che un bel chkrootkit , rkhunter, fcheck,
un bel giro con clamav, un bel netstat -putan per vedere cosa
c'� che ascolta dovrebbe bastare :)
magari guardati anche la history dei comandi per sapere cosa sta facendo
visto che molto intelligentemente chi accede al server non si premura di
cancellare
i log
pac
>
>
> Luigi di Lazzaro ha scritto:
>>>
>>> pac ha scritto:
>>> Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
>>> scoperto nuova violazione.
>>> Il log dice
>>> Jul 8 08:04:58 sshd[23885]: Accepted password for root from
>>> 79.33.45.194 port 40063 ssh2
>>> Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
>>> root by (uid=0)
>>> aperta nel router x ssh, anzi non è aperta per nulla.
>>> Quindi volevo sapere cosa è successo secondo voi e come fare ?
>>>
>>
>> Non permetttere l'accesso a root via ssh. C'e' un'apposita opzione nel
>> file di configurazione /etc/sshd_config
>> PermitRootLogin no
>> di default e' su yes
>>
>> Luigi
>>
>>
>
> Consiglio anche di mettere in /etc/passwd
> games:x:5:60:games:/usr/games:/bin/sh
>
> games:x:5:60:games:/usr/games:/bin/false <--- false
>
>
> per tutti gli utenti tranne root e l'utente che userai per connetterti
> visto che non lo potrai fare da root
>
> e riesce a raggiungerti lostesso?
>
>
Secondo me il problema è dipeso da un mio grosso errore.
Ieri ho cancellato i file ssh-* in /usr/local/bin ma non essendo stato
attento non avevo notato che c'erano anche i vari scp sftp
che quindi a mio parere ha usato per entrare e uscire con file.
Ora credo non ci siano più vie di accesso.
Una domanda. Nel caso avesse preso il file /etc/passwd questi è decrittabile ?
Contiene anche le password di ssh, sono decrittabili le password di ssh ?
Alessandro Pellizzari
> Allora pc violato, il nostro cicciobello è riuscito a entrare come
> root via ssh.
> Quindi volevo sapere cosa è successo secondo voi e come fare ?
1- spegnere la macchina
2- rimuovere il disco
3- installare nuovo disco
4- installare una distribuzione recente ed aggiornata
4bis- metterla in sicurezza il piu` possibile
5- ripristinare il backup
6- attaccare l'altro disco a un'altra macchina off-line e analizzare
cosa ha combinato il cracker.
Bye.
--
Alessandro Pellizzari
1tmt
Hash: SHA1
Carlo ha scritto lo scorso 08/07/2009 12:19:
>
[...]
>
> magari guardati anche la history dei comandi per sapere cosa sta facendo
> visto che molto intelligentemente chi accede al server non si premura di
> cancellare
> i log
>
...e comunque segnala l'accaduto al provider; servira' almeno a
costringere uno sprovveduto a passare a wpa :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBAgAGBQJKVHYQAAoJECVi+PFMdzdCWQgH/0B8h3Qy4BmkihP5zfRrb6O4
AEJyJltUXfq+Jud7wBFoFwphESmouRfMm/UZh7i5qHPl2GGJ/1w+AVDu2rO2V3p/
64QhmAHbGVgrS57KH5P3r0gpNCfNkbxuCdjwp9k9yQ2eG4w+EeDcOJ+NGX/peChF
XbJxjbBKdPvb9PDPwOwiJwap8PZBoPhKR+WehfNXbi4IyRqDPMm6U+a9Eub9EPMy
NopTvB1sMaxGd6+em2i9+KjRv/Z9kDWVqQWthbQKcmr/tihKncgktPd4u0XdQwlZ
keIbzwFQgYgyOQG2SgQYELNdh+lA/1FetXB9RXbIHbCfT25zTUpyLgqhXCg4LbQ=
=bOWY
-----END PGP SIGNATURE-----
Carlo
>
> La porta � sistemata.
> Secondo me il problema � dipeso da un mio grosso errore.
> Ieri ho cancellato i file ssh-* in /usr/local/bin ma non essendo stato
> attento non avevo notato che c'erano anche i vari scp sftp
> che quindi a mio parere ha usato per entrare e uscire con file.
> Ora credo non ci siano pi� vie di accesso.
> Una domanda. Nel caso avesse preso il file /etc/passwd questi � decrittabile ?
> Contiene anche le password di ssh, sono decrittabili le password di ssh ?
>
al massimo prende il file /etc/shadow
li sono le password e con johntheripper si tirano fuori volendo
si per ssh almeno bisognerebbe ricreare le chiavi rsa tipo cos�
ssh-keygen -t rsa -b 2048
altrimenti diventa un po come telnet
saluti
Carlo
Marco Bertorello
> Una domanda. Nel caso avesse preso il file /etc/passwd questi è decrittabile ?
> Contiene anche le password di ssh, sono decrittabili le password di ssh ?
solo se ha preso anche il file shadow. con quest'accoppiata di file è
possibile fare un bruteforce (puoi provare tu stesso con john the
ripper).
un consiglio, installa denyhosts ;)
ciao
--
Marco Bertorello
System Administrator
http://bertorello.ns0.it
pac
>
>> Luigi di Lazzaro ha scritto:
>>>>
>>>> pac ha scritto:
>>>> Dopo aver eliminato tutto e cambiata porta ssh questa mattina ho
>>>> scoperto nuova violazione.
>>>> Il log dice
>>>> Jul 8 08:04:58 sshd[23885]: Accepted password for root from
>>>> 79.33.45.194 port 40063 ssh2
>>>> Jul 8 08:04:59 arpaca sshd(pam_unix)[23885]: session opened for user
>>>> root by (uid=0)
>>>> aperta nel router x ssh, anzi non è aperta per nulla.
>>>> Quindi volevo sapere cosa è successo secondo voi e come fare ?
>>>>
>>>
>>> Non permetttere l'accesso a root via ssh. C'e' un'apposita opzione nel
>>> file di configurazione /etc/sshd_config
>>> PermitRootLogin no
>>> di default e' su yes
>>>
>>> Luigi
>>>
>>>
>
> Completo scrivendo che un bel chkrootkit , rkhunter, fcheck,
> un bel giro con clamav, un bel netstat -putan per vedere cosa
>
>
> magari guardati anche la history dei comandi per sapere cosa sta facendo
> visto che molto intelligentemente chi accede al server non si premura di
> cancellare
> i log
>
>
>
server di log su cui comunque i log sono stati duplicati e rimasti
integri
pac
E' riuscito a entrare come root, può fare quello che vuole, come mai
si fa "nasare" che è successo qualcosa perché a due utenti non viene
più riconosciuta la password ?
bod...@mail.dm.unipi.it
mi dispiace di aver azzeccato la diagnosi...
> La porta � sistemata.
> Secondo me il problema � dipeso da un mio grosso errore.
Secondo me, invece, dipende da un altro problema. Il furbastro oramai
_conosce_ la password di root. L'hai cambiata?
> Una domanda. Nel caso avesse preso il file /etc/passwd questi �
> decrittabile ?
> Contiene anche le password di ssh, sono decrittabili le password di ssh ?
Il programma ssh protegge le password mentre sono in rete, ma sul disco le
password di ssh sono le stesse di telnet :-)
Il fatto e` che il furbastro ha ottenuto le password compromettendo
qualche computer e inserendo la _propria_ versione di ssh, che, in qualche
modo che ora non indaghiamo, ha rivelato le password usate al suddetto
furbastro.
Ovvero, prima di compromettere un server, probabilmente il furbastro ha
compromesso uno dei client che gli si connette. Bisogna mettere in
sicurezza anche quelli!
Sicuramente sarebbe bene far cambiare password a tutti gli utenti, dopo
avergli fatto verificare di avere un ssh sano... Inoltre rigenerare tutte
le chiavi ssh...
Anche i consigli anti root-kit che altri ti hanno dato, vanno ovviamente
seguiti.
Buona fortuna,
m
pac
> Ciao,
>
> mi dispiace di aver azzeccato la diagnosi...
>
>> Secondo me il problema è dipeso da un mio grosso errore.
>
> Secondo me, invece, dipende da un altro problema. Il furbastro oramai
> _conosce_ la password di root. L'hai cambiata?
>
>> decrittabile ?
>> Contiene anche le password di ssh, sono decrittabili le password di ssh ?
>
> Il programma ssh protegge le password mentre sono in rete, ma sul disco le
> password di ssh sono le stesse di telnet :-)
> Il fatto e` che il furbastro ha ottenuto le password compromettendo
> qualche computer e inserendo la _propria_ versione di ssh, che, in qualche
> modo che ora non indaghiamo, ha rivelato le password usate al suddetto
> furbastro.
> Ovvero, prima di compromettere un server, probabilmente il furbastro ha
> compromesso uno dei client che gli si connette. Bisogna mettere in
> sicurezza anche quelli!
> Sicuramente sarebbe bene far cambiare password a tutti gli utenti, dopo
> avergli fatto verificare di avere un ssh sano... Inoltre rigenerare tutte
> le chiavi ssh...
>
> Anche i consigli anti root-kit che altri ti hanno dato, vanno ovviamente
> seguiti.
>
> Buona fortuna,
> m
>
> --
verso un ip inesistente.
A quel punto ho modificato tutte le password.
Ho cambiato la porta di ssh
Poi inizierò i consigli anti root-kit
pac
Visto che ne capite molto più di me ...chiedevo ragguagli in merito
#! /bin/sh
#
# ssh-chrootmgr
#
# Author: Sami Lehtinen <s...@ssh.com>
#
# Copyright (C) 2000 SSH Communications Security Corp, Helsinki, Finland
# All rights reserved
#
# Script to copy static binaries of ssh-dummy-shell and sftp-server to
# users' home directories, under $HOME/bin. creates the bin directory
# if necessary.
usage="Usage: $0 [-h|--help|-\?] [-n] [-v] [-q] username ..."
# Install required binaries to users home directory, under $USER/bin
# digs users home directory from /etc/passwd, and
user=
userdir=
if test -z "$1"; then
echo $usage >&2
exit 1
fi
while expr $1 >& /dev/null
do
case "$1" in
--help|-h|-\?)
echo $usage >&2
exit 1
;;
-n)
just_show="yes"
;;
-v)
verbose="yes"
quiet=
;;
-q)
quiet="yes"
verbose=
;;
*)
user="$1"
if test -z "$user"; then
echo "No user name given." >&2
exit 1
fi
# dig up user's home directory
userdir=`cat /etc/passwd | egrep "^$user" | sed -n 's/.*:\(.*\):.*/\1/p'`
if test -z "$userdir"; then
echo "Couldn't dig user directory from /etc/passwd. (user
doesn't exist, or malformed /etc/passwd ?)" >&2
exit 1
fi
if test "!" -d "$userdir"; then
echo "User's home directory $userdir doesn't exist." >&2
exit 1
fi
# find the static binaries from PATH environment variable
save_IFS="$IFS"
IFS=":"
for dir in $PATH; do
test -z "$dir" && dir=.
if test -f $dir/ssh-dummy-shell.static; then
full_path_to_progs="$dir"
break
fi
done
IFS="$save_IFS"
if test -z "$full_path_to_progs"; then
echo "Couldn't find static binaries in \$PATH." >&2
exit 1
fi
test -n "$verbose" && echo "Path to static binaries:
$full_path_to_progs" >&2
if test "!" -d "$userdir"/bin; then
test -z "$quiet" && echo "Creating $userdir/bin..." >&2
if test -z "$just_show" && ! mkdir "$userdir/bin"; then
exit 1
fi
fi
for file in ssh-dummy-shell.static sftp-server2.static; do
test -n "$verbose" && echo "Copying $full_path_to_progs/$file
to $user's bin directory..." >&2
if test -z "$just_show" && ! cp $full_path_to_progs/$file
$userdir/bin/`echo $file | sed -e 's/.static//'`; then
echo "Couldn't copy $file to $user's bin-directory." >&2
exit 1
fi
done
(cd $userdir/bin && ln -s sftp-server2 sftp-server)
;;
esac
shift
done
_______________________________________________________________________________________________________
#!/bin/sh
#
# ssh-pubkeymgr - A user public key manager for Secure Shell
#
# Author: Anne Carasik <an...@ssh.com>
#
# Copyright (C) 2000 SSH Communications Security Corp, Helsinki, Finland
# All rights reserved.
#
# It's too much of a pain to create the public key files like identification
# and authorization. This quick little script runs ssh-keygen2, then creates
# the identification and authorization files. Then it runs scp to the remote
# system to copy the public keys there.
########## ChangeLog ######################################
# 18 August 2000 - removed downloading hostkeys because you get them anyway
# during the first connection :)
#
# 12 February 2001 - removed hostname -s because too many bugs were being
# reported from it. Also added config file checks for publickey authentication.
# And comments. Many, many, many more comments.
########## ChangeLog ######################################
############################################################
# Some basic checks... #
############################################################
## Set the default keypair to id_dsa_1024_a for
keypair="id_dsa_1024_a"
## Check for compatibility for the $LOGNAME instead of $USER
if [ -z "$USER" ]; then
if [ -n "$LOGNAME" ]; then
USER=$LOGNAME
else
USER=`whoami`
fi
fi
############################################################
# Check the command line options. #
############################################################
while [ -n "$1" ]
do
case $1 in
-k) keypair="$2"
echo $keypair
echo "Running ssh-pubkeymgr.."
shift 2
;;
-h) echo " "
echo "SSH Secure Shell user public key manager"
echo "Usage: ssh-pubkeymgr [-k keypair]"
echo " "
echo "Type man ssh-pubkeymgr for more information."
exit
;;
*) echo " "
echo "Usage: ssh-pubkeymgr [-k keypair]"
echo " "
echo "Type man ssh-pubkeymgr for more information."
exit
esac
done
#############################################################################
# Checking the configuration files to make sure so publickey authentication #
# will work. Otherwise, program will exit with the return status of 1. #
#############################################################################
echo "Checking for publickey authentication to be enabled in the
client config.."
clientconfigcontains=`grep -v "^#" /etc/ssh2/ssh2_config | grep publickey`
serverconfigcontains=`grep -v "^#" /etc/ssh2/sshd2_config | grep publickey`
if [ -z "$clientconfigcontains" ] ; then
echo "Nothing found in /etc/ssh2/ssh2_config. Add publickey"
echo "authentication to AllowedAuthentications or RequiredAuthentications"
echo "then restart ssh-pubkeymgr."
exit 1
else
echo "Your client configuration is all set."
fi
echo " "
echo "Checking for publickey authentication to be enabled in the
server config.."
if [ -z "$serverconfigcontains" ] ; then
echo "Nothing found in /etc/ssh2/sshd2_config. Add publickey"
echo "authentication to AllowedAuthentications or RequiredAuthentications"
echo "then restart ssh-pubkeymgr."
exit 1
else
echo "Your client configuration is all set."
fi
echo " "
#############################################################################
# Checking DSA public keys. Currently, there is no support for PGP or RSA #
# public keys; however that will change. #
#############################################################################
echo "Checking for existing user public keys.."
## Check for the user's DSA keypair
if [ -s "$HOME/.ssh2/$keypair" -a "$HOME/.ssh2/$keypair.pub" ] ; then
echo "You have public and private keys.. Skipping ssh-keygen2.."
echo " "
else
echo "Couldn't find your DSA keypair.. I'll generate you a new set.."
echo "Running ssh-keygen2... don't forget to give it a passphrase!"
echo " "
ssh-keygen2
fi
#############################################################################
# Setup the identification file. This is so when you login, the client #
# recognizes which private key you're using. #
#############################################################################
echo "If you are logging in from this computer, you need to have an
echo "identification file that defines what private keys will be recognized
echo "when you login. By default, this should be $keypair."
echo " "
## Check for $HOME/.ssh2/identification
if [ -s "$HOME/.ssh2/identification" ] ; then
echo "You already have an identity file.. Skipping.."
echo " "
else
echo "Creating your identity file.."
echo " "
echo IdKey $keypair > $HOME/.ssh2/identification
fi
#############################################################################
# Setup the authorization file. This is so when you login, the server #
# recognizes your public key. #
#############################################################################
## Check for $HOME/.ssh2/authorization
if [ -s "$HOME/.ssh2/authorization" ] ; then
echo " "
else
echo "Creating your authorization file.."
echo " "
touch "$HOME/.ssh2/authorization"
fi
## Ask the user for the hostname of which remote hosts to add.
echo "The next section allows you to add hosts that you wish to login
from using"
echo "public key authentication."
echo " "
echo -n "Do you want to add any hosts to your authorization file?
(Default: yes)"
while read addhosts
do
case "$addhosts" in
"" | [yY] | [yY][eE][sS])
echo " "
echo "Type in their hostname, press return after"
echo "each one. "
echo " "
echo "Add which user?"
read user
echo "Add which host?"
read host
echo Key $user-$host.pub >> $HOME/.ssh2/authorization
echo "You added "$user" at "$host" as a trusted login."
echo "Press return to continue or Ctrl-D to exit."
;;
[nN] | [nN][oO])
echo "Skipping editing the authorization file.."
break
esac
done
echo
echo "All the new files are in your $HOME/.ssh2 directory."
echo
###########################################################################
# Send your public key to remote servers so you can login to them. #
# Don't forget that you need to add this key to the ~/.ssh2/authorization #
# file on the remote server. #
###########################################################################
echo "Now that you have your public keypair generated, you can copy your public"
echo "key up to remote hosts so you can login to them using public key"
echo "authentication. You also need to add this key," $USER"@"$HOSTNAME".pub,"
echo "to the ~/.ssh2/authorization file on the server."
echo " "
echo -n "Do you want to upload " $USER"@"$HOSTNAME" key to a remote
host? (Default: yes)"
while read uploadhost
do
case "$uploadhost" in
"" | [yY] | [yY][eE][sS])
echo "Upload to which host?"
read host
echo "Which user account?"
read user
echo "Where is the " $user"'s home directory? "
echo "(e.g. /home/anne, /u/ahc, etc.)"
read homedir
# Run scp2 to copy the file
echo "Now running scp2 to connect to "$host".."
echo "Most likely you'll have to type a password :)"
scp2 "$HOME/.ssh2/$USER-$HOSTNAME.pub" $user@$host:$homedir/.ssh2/
echo " "
echo "Press return to upload to more hosts or Ctrl-D to exit." ;;
[nN] | [nN][oO])
echo "Skipping local user public key uploads.."
break ;;
esac
done
echo " "
echo "Done."
Davide Prina
> Il giorno mer, 08/07/2009 alle 11.02 +0200, pac ha scritto:
>
>> Allora pc violato, il nostro cicciobello è riuscito a entrare come
>> root via ssh.
>
>> Quindi volevo sapere cosa è successo secondo voi e come fare ?
>
> 1- spegnere la macchina
>
> 2- rimuovere il disco
>
> 3- installare nuovo disco
>
> 4- installare una distribuzione recente ed aggiornata
>
> 4bis- metterla in sicurezza il piu` possibile
>
> 5- ripristinare il backup
>
> 6- attaccare l'altro disco a un'altra macchina off-line e analizzare
> cosa ha combinato il cracker.
+1
non sono un sistemista, ma io farei proprio così:
1) rifarei la macchina reinstallando da zero, cambiando tutte le
password, chiavi, ... e obbligando tutti gli utenti a fare altrettanto
2) cercherei di capire come è riuscito ad entrare
3) controllerei le macchine da quella raggiungibili e al minimo dubbio
le reinstallerei
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Petizione per uso di software interoperabile nell'UE:
http://openparliament.eu/
Non autorizzo la memorizzazione del mio indirizzo su outlook
pac
> Alessandro Pellizzari wrote:
>>
>> Il giorno mer, 08/07/2009 alle 11.02 +0200, pac ha scritto:
>>
>>> Allora pc violato, il nostro cicciobello è riuscito a entrare come
>>> root via ssh.
>>
>>> Quindi volevo sapere cosa è successo secondo voi e come fare ?
>>
>> 1- spegnere la macchina
>>
>> 2- rimuovere il disco
>>
>> 3- installare nuovo disco
>>
>> 4- installare una distribuzione recente ed aggiornata
>>
>> 4bis- metterla in sicurezza il piu` possibile
>>
>> 5- ripristinare il backup
>>
>> 6- attaccare l'altro disco a un'altra macchina off-line e analizzare
>> cosa ha combinato il cracker.
>
> +1
>
> non sono un sistemista, ma io farei proprio così:
> 1) rifarei la macchina reinstallando da zero, cambiando tutte le password,
> chiavi, ... e obbligando tutti gli utenti a fare altrettanto
> 2) cercherei di capire come è riuscito ad entrare
> 3) controllerei le macchine da quella raggiungibili e al minimo dubbio le
> reinstallerei
>
> Ciao
> Davide
>
chiudere l'accesso esterno al router per ssh
Davide Prina
> Il giorno 08 Luglio 2009 19.08, Davide Prina ha scritto:
>> non sono un sistemista, ma io farei proprio così:
>> 1) rifarei la macchina reinstallando da zero, cambiando tutte le password,
>> chiavi, ... e obbligando tutti gli utenti a fare altrettanto
>> 2) cercherei di capire come è riuscito ad entrare
>> 3) controllerei le macchine da quella raggiungibili e al minimo dubbio le
>> reinstallerei
> Non dipende da me, e qui andiamo a settembre, al massimo posso
> chiudere l'accesso esterno al router per ssh
il problema, secondo me, è che se sono entrati nella tua macchina e
hanno avuto l'accesso di root, allora, da quel che so io, non esiste un
metodo sicuro per riprendersi il possesso totale della macchina.
Possono aver cambiato ogni singolo eseguibile, possono aver creato
processi che si mettono in ascolto su una porta una volta all'anno, ...
possono aver modificato il tool per ricercare i rootkit o semplicemente
possono aver installato qualcosa fatto da loro che non è ancora
identificato come tale.
Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
Petizione contro il formato ms-ooxml:
http://www.noooxml.org/petition
Pietro Giorgianni
> il problema, secondo me, è che se sono entrati nella tua macchina e hanno
> avuto l'accesso di root, allora, da quel che so io, non esiste un metodo
> sicuro per riprendersi il possesso totale della macchina.
> Possono aver cambiato ogni singolo eseguibile, possono aver creato processi
> che si mettono in ascolto su una porta una volta all'anno, ... possono aver
> modificato il tool per ricercare i rootkit o semplicemente possono aver
> installato qualcosa fatto da loro che non è ancora identificato come tale.
Concordo pienamente: il server va azzerato totalmente e rifatto ex
novo; tutto ciò che c'era è da corsiderarsi compromesso (non
necessariamente i dati, dipende da che cosa sono e quanto il cracker
avesse motivo di alterarli).
Non consentire mai più l'accesso via ssh a root.
Se davvero l'intruso ha prima compromesso una macchina client, devi
chiederti se le macchine client possono essere considerate affidabili
(se chiunque può metterci le mani la risposta è no, non sono
affidabili: se io ho il controllo di un client, oltre a modificare i
vari comandi ssh, posso intercettare quando scarichi una versione
pulita di ssh e la installi, e taroccarla; posso modificare le
funzioni di accesso ai file per fare in modo che a guardarlo
l'eseguibile sembri pulito, ma ad eseguirlo no; posso non modificare
l'eseguibile, ma intercettarne l'esecuzione, in modo che quando uno
lancia ssh non viene lanciato il vero ssh ma un altro processo...)
Se i client non sono affidabili, gli account che questi utilizzano via
ssh non devono avere sudo abilitato (se non eventualmente per singoli
comandi innocui - e sono molto pochi i comandi innocui); sarebbe anzi
il caso di farli girare sempre in un ambiente fakeroot.
Se qualche utente ha bisogno di collegarsi via ssh e acquisire
privilegi, deve necessariamente poter rispondere del computer che usa.
ah, se scopri come hanno fatto faccelo sapere.
pietro
pac
ha scritto:
router giusto ?
Non vedo come potrebbero entrare per ora. O sbaglio ?
Pietro Giorgianni
> Ok ma per ora può andar bene il togliere l'accesso dall'esterno al
> router giusto ?
> Non vedo come potrebbero entrare per ora. O sbaglio ?
sì, certo, se da fuori non ci si può collegare va bene, ma il server
consideralo comunque infetto.
se hanno lasciato i file di log è probabile che non fossero
bravissimi, ma non si può mai dire: non puoi essere certo che non
abbiano installato un qualcosa che cerca, che so, di azzeccare le
password di eventuali altri computer della rete locale.
che poi la cosa brutta è che non serve essere chissà che, basta saper
cercare, scaricare, cliccare: in giro si trova di tutto per lo script
kiddie.
pietro
Alessandro Pellizzari
> Ok ma per ora può andar bene il togliere l'accesso dall'esterno al
> router giusto ?
Non e` detto.
> Non vedo come potrebbero entrare per ora. O sbaglio ?
Per esempio con un server ssh nascosto in ascolto su una porta pubblica
(per esempio la 80, se il server e` un webserver). Lui sta li`, ascolta
tutto il traffico in arrivo, se gli interessa (e` il suo padrone che
chiama) va in ssh, altrimenti fa da proxy per apache, magari spostato su
una porta alta "di nascosto" tramite regole di iptables.
Non c'e` limite alla fantasia dei crackers. :)
Bye.
--
Alessandro Pellizzari
Alessandro T.
>
> Ok ma per ora può andar bene il togliere l'accesso dall'esterno al
> router giusto ?
>
sei sicuro che basti una cosa del genere?
> Non vedo come potrebbero entrare per ora. O sbaglio ?
>
con un reverse-ssh?
a parer mio quando una macchina è stata compromessa è da considerarsi
pericolosa per l'intera rete. se non puoi staccarla dal resto, perchè
deve fornire qualche servizio interno, devi renderla il meno pericolosa
possibile ad esempio impedendole di iniziare connessioni. a dire il vero
però, quando una macchina è compromessa, io non mi sentirei nemmeno
sicuro dei servizi che offre e per questo la staccherei. poi inizierei a
controllarla per imparare dai miei errori: se son entrati qualcosa avrò
pur sbagliato :-/
ciao
Ale
pac
ha scritto:
> Il giorno mer, 08/07/2009 alle 23.33 +0200, pac ha scritto:
>
>> Ok ma per ora può andar bene il togliere l'accesso dall'esterno al
>> router giusto ?
>
> Non e` detto.
>
>> Non vedo come potrebbero entrare per ora. O sbaglio ?
>
> Per esempio con un server ssh nascosto in ascolto su una porta pubblica
> (per esempio la 80, se il server e` un webserver). Lui sta li`, ascolta
> tutto il traffico in arrivo, se gli interessa (e` il suo padrone che
> chiama) va in ssh, altrimenti fa da proxy per apache, magari spostato su
> una porta alta "di nascosto" tramite regole di iptables.
>
> Non c'e` limite alla fantasia dei crackers. :)
>
> Bye.
>
> --
> Alessandro Pellizzari
>
Allora per ora tolgo il gw al router. Tieni presente che questa
macchina è un'application server e non ha necessità ne della posta e
neppure di navigare o di Internet anche per 2-3 mesi. Ha necessità
esclusivamente dello switch.
A questo punto !!!!
Altra domanda scusa, ma allora una macchina windows violata si trova
in questa medesima situazione o con anti-vari si riesce a ripulire e
quindi avvantaggiata rispetto a linux ?
Pietro Giorgianni
> Scusa, prima di tutto non c'è modo di capirlo ?
di un'intrusione ci si accorge solo perché chi l'ha fatta ha commesso
errori (non ha pulito i file di log, ha alterato in modo visibile il
comportamento del sistema o altro); l'intrusione perfetta dovrebbe
essere totalmente asintomatica. si può disquisire del fatto che
l'intrusione perfetta non esista, ma partire dall'assunto di essere
più furbi e in gamba del nemico è il modo migliore e più rapido per
perdere su tutti i fronti.
> Altra domanda scusa, ma allora una macchina windows violata si trova
> in questa medesima situazione o con anti-vari si riesce a ripulire e
> quindi avvantaggiata rispetto a linux ?
come sopra, gli anti-vari funzionano perché i vari hanno difetti noti;
una macchina windows compromessa va azzerata e reinstallata, stessa
per qualsiasi altro sistema operativo o ambiente software.
pietro
pac
ha scritto:
> Il giorno 09 Luglio 2009 11.41, pac<pac...@gmail.com> ha scritto:
>> Scusa, prima di tutto non c'è modo di capirlo ?
>
> di un'intrusione ci si accorge solo perché chi l'ha fatta ha commesso
> errori (non ha pulito i file di log, ha alterato in modo visibile il
> comportamento del sistema o altro); l'intrusione perfetta dovrebbe
> essere totalmente asintomatica. si può disquisire del fatto che
> l'intrusione perfetta non esista, ma partire dall'assunto di essere
> più furbi e in gamba del nemico è il modo migliore e più rapido per
> perdere su tutti i fronti.
>
>> Altra domanda scusa, ma allora una macchina windows violata si trova
>> in questa medesima situazione o con anti-vari si riesce a ripulire e
>> quindi avvantaggiata rispetto a linux ?
>
> come sopra, gli anti-vari funzionano perché i vari hanno difetti noti;
> una macchina windows compromessa va azzerata e reinstallata, stessa
> per qualsiasi altro sistema operativo o ambiente software.
>
>
> pietro
>
Per cercare di capire.
Una macchina che ha un indirizzo pubblico ssh verso l'esterno e un ftp.
ssh vero e purtroppo con accesso come root.
Password non da vocabolario.
Possono esser entrati attraverso altri servizi ?
l router al momento dell'intrusione aveva in pratica aperte per
l'accesso la porta 22 e la 21.
Un grave problema potrebbe esser il fatto di esser datato e quindi con
ssh1 ? Ma qui non posso farci niente perché non posso aggiornarlo sino
a che non ho il permesso di cambiare pc e aggiornare i programmi
altrimenti lo debbo rifare con la vecchio distro e quindi ssh1.
Alessandro Pellizzari
> Un grave problema potrebbe esser il fatto di esser datato e quindi con
> ssh1 ? Ma qui non posso farci niente perché non posso aggiornarlo sino
> a che non ho il permesso di cambiare pc e aggiornare i programmi
> altrimenti lo debbo rifare con la vecchio distro e quindi ssh1.
Stiamo parlando di una fedora core3, quindi del 2005. Quattro anni senza
aggiornamenti?
Un amministratore di sistema dovrebbe avere diritto di vita e di morte
sui server che gestisce. Vai da chi di dovere (capo, superiore, ecc.) e
digli semplicemente "ci hanno bucato il server perche` aveva software
non aggiornato. Dobbiamo mettere una distro piu` recente e tenerla
aggiornata e in sicurezza ogni giorno, altrimenti ci ricapita in meno di
una settimana".
Fatto questo poi sta a te (se sei tu l'amministratore di sistema) tenere
d'occhio i log, tenere aggiornati i server e informarti sugli exploit di
sicurezza dei software che usi.
Non esiste un computer "sicuro". Esiste una continua guerra tra
amministratori di sistema e cracker. Nella maggior parte dei casi
vincono i primi, ma capita che vincano anche i secondi. Lo scopo e` di
fare in modo che vincano il meno possibile. :)
Bye.
--
Alessandro Pellizzari
--
pac
ha scritto:
> Il giorno gio, 09/07/2009 alle 12.27 +0200, pac ha scritto:
>
>> Un grave problema potrebbe esser il fatto di esser datato e quindi con
>> ssh1 ? Ma qui non posso farci niente perché non posso aggiornarlo sino
>> a che non ho il permesso di cambiare pc e aggiornare i programmi
>> altrimenti lo debbo rifare con la vecchio distro e quindi ssh1.
>
> Stiamo parlando di una fedora core3, quindi del 2005. Quattro anni senza
> aggiornamenti?
>
> Un amministratore di sistema dovrebbe avere diritto di vita e di morte
> sui server che gestisce. Vai da chi di dovere (capo, superiore, ecc.) e
> digli semplicemente "ci hanno bucato il server perche` aveva software
> non aggiornato. Dobbiamo mettere una distro piu` recente e tenerla
> aggiornata e in sicurezza ogni giorno, altrimenti ci ricapita in meno di
> una settimana".
>
> Fatto questo poi sta a te (se sei tu l'amministratore di sistema) tenere
> d'occhio i log, tenere aggiornati i server e informarti sugli exploit di
> sicurezza dei software che usi.
>
> Non esiste un computer "sicuro". Esiste una continua guerra tra
> amministratori di sistema e cracker. Nella maggior parte dei casi
> vincono i primi, ma capita che vincano anche i secondi. Lo scopo e` di
> fare in modo che vincano il meno possibile. :)
>
> Bye.
>
>
> --
> Alessandro Pellizzari
Concordo, ma non sempre si può fare quello che si vuole.
Per ora cambiamo disco, e l'altra domanda mi pare più giusto fare un altro post.
ciao e grazie mille