Discussioni su virus e antivirus
 

Dopo "wannacry" ecco "eternalrocks"

ObiWan 23 Mag 2017 15:37
Buon divertimento :)

https://threatpost.com/eternalrocks-worm-spreads-seven-nsa-smb-exploits/125825/

ed il "bello" (si fa per dire) è che questa nuova versione funziona
come i cosiddetti "sleepers", in breve, infetta il sistema, procede ad
insediarsi a modo, e poi se ne sta silenzioso, senza manifestarsi, in
attesa che "i suoi padroni" gli ordinino di fare qualcosa

ci sarà da "divertirsi"
SB 23 Mag 2017 18:03
Il giorno Tue, 23 May 2017 15:37:40 +0200, ObiWan <obiwan@mvps.org> ha scritto:

>
>Buon divertimento :)
>
>https://threatpost.com/eternalrocks-worm-spreads-seven-nsa-smb-exploits/125825/
>
>ed il "bello" (si fa per dire) è che questa nuova versione funziona
>come i cosiddetti "sleepers", in breve, infetta il sistema, procede ad
>insediarsi a modo, e poi se ne sta silenzioso, senza manifestarsi, in
>attesa che "i suoi padroni" gli ordinino di fare qualcosa
>
>ci sarà da "divertirsi"

Beh, ci sarà chi backupperà anche il virus... :-(

Meglio ricordare una volta di più di tenere in partizioni separate i dati dal
s.o., si ha un'arma in più.



--
ciao
Stefano
qu 23 Mag 2017 18:13
SB wrote:
> Il giorno Tue, 23 May 2017 15:37:40 +0200, ObiWan <obiwan@mvps.org>
> ha scritto:
>
>>
>> Buon divertimento :)
>>
>>
https://threatpost.com/eternalrocks-worm-spreads-seven-nsa-smb-exploits/125825/
>>
>> ed il "bello" (si fa per dire) è che questa nuova versione funziona
>> come i cosiddetti "sleepers", in breve, infetta il sistema, procede
>> ad insediarsi a modo, e poi se ne sta silenzioso, senza
>> manifestarsi, in attesa che "i suoi padroni" gli ordinino di fare
>> qualcosa
>>
>> ci sarà da "divertirsi"
>
> Beh, ci sarà chi backupperà anche il virus... :-(
>
> Meglio ricordare una volta di più di tenere in partizioni separate i
> dati dal s.o., si ha un'arma in più.

E credi serva a qualcosa?

Il messaggio che sta' passsando, nella PA è: "tanto è inutile, li si piglia
lo stesso".

Chiedere al fesso sindaco che, ahimè, mi tocca informare. In teoria, aiutare
ad evitari disastri e YTA

--
qu
qu[levami]@x-planet.org (elimina [levami] per scrivermi)
''se la gente che inculatasi reciprocamente formasse un anello, la Terra
sarebbe Saturno"
Un consiglio per il quote: http://youtube.com/watch?v=kCscWlOiXd0
Greg 23 Mag 2017 19:07
Il 23/05/2017 18:03:28 SB ha scritto:

> Meglio ricordare una volta di più di tenere in partizioni separate i dati dal
> s.o., si ha un'arma in più.

Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
Viene anche un altro dubbio: prima di attaccarci il disco off-line per soli 2
minuti, per fare un backup dei ******* piu
recenti, come diavolo fdaccio a sapere che non l'ho gia preso e rischio di
infettare pure il disco di backup?

--
Greg
Leonardo Serni 23 Mag 2017 19:44
On Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> wrote:

>Il 23/05/2017 18:03:28 SB ha scritto:
>
>> Meglio ricordare una volta di più di tenere in partizioni separate i dati
dal
>> s.o., si ha un'arma in più.

>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>Viene anche un altro dubbio: prima di attaccarci il disco off-line per soli 2
minuti, per fare un backup dei ******* piu
>recenti, come diavolo fdaccio a sapere che non l'ho gia preso e rischio di
infettare pure il disco di backup?

La soluzione che ho trovato io è la seguente: sulle macchine Windows gira
rsyncd (con password non b*****e; si sa mai).

Su un NAS Synology in rete gira uno script che fa il backup incrementale,
leggendo dai vari client.

Il NAS poi esporta i backup (*****linked snapshot) via SMB in sola lettura
nel caso uno volesse riprendere qualche ******* vecchio.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
Greg 24 Mag 2017 08:12
Il 23/05/2017 19:44:36 Leonardo Serni ha scritto:
> On Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> wrote:
>
>> Il 23/05/2017 18:03:28 SB ha scritto:
>>
>>> Meglio ricordare una volta di più di tenere in partizioni separate i dati
dal
>>> s.o., si ha un'arma in più.
>
>> Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>> Viene anche un altro dubbio: prima di attaccarci il disco off-line per soli 2
minuti, per fare un backup dei *******
>> piu recenti, come diavolo fdaccio a sapere che non l'ho gia preso e rischio
di infettare pure il disco di backup?
>
> La soluzione che ho trovato io è la seguente: sulle macchine Windows gira
> rsyncd (con password non b*****e; si sa mai).
>
> Su un NAS Synology in rete gira uno script che fa il backup incrementale,
> leggendo dai vari client.
>
> Il NAS poi esporta i backup (*****linked snapshot) via SMB in sola lettura
> nel caso uno volesse riprendere qualche ******* vecchio.
>
> Leonardo

Questa è una soluzione aziendale o semi-aziendale, e mi pare ottima, ma ancora
non ho capito, al momento di fare il
backup incrementale, come fare ad essere certi che non siano gia infetti?

--
Greg
SB 24 Mag 2017 10:33
Il giorno Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> ha scritto:

>Il 23/05/2017 18:03:28 SB ha scritto:
>
>> Meglio ricordare una volta di più di tenere in partizioni separate i dati
dal
>> s.o., si ha un'arma in più.
>
>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.

L'op parlava di virus dormienti, tipo i troian, questi per potersi attivare
devono essere riconosciuti dal so, ad esempio i trojan spesso stanno nelle
directory Temp mescolandosi ai files temporanei.

Se tu fai un ripristino del so da immagine, un eventuale trojan viene
sovrascitto, mentre non vedo come possa attivarsi un ******* che eventualmente
restasse isolato sulle partizioni dati o sui dischi esterni.

C'era qualcosa sulle flash che usava autoplay per avviarsi, ma quelllo è una
delle prime cose che disattivo sempre.

>Viene anche un altro dubbio: prima di attaccarci il disco off-line per soli 2
minuti,
> per fare un backup dei ******* piu
>recenti, come diavolo fdaccio a sapere che non l'ho gia preso
> e rischio di infettare pure il disco di backup?

Beh, nelle ultime versioni i dischi criptati presentavano una finestra arancione
con le informazioni per pagare, se non la vedi direi che i files sono ok.

Comunque il backup è meglio farlo differenziale o completo tenedo almeno le
ultime 2 versioni diverse, in modo da avere in ogni caso una versione precedente
da cui recuperare qualcosa.

Poi come già detto, accessi in sola lettura al nas in SMB, con permessi di
scittura solo tramite il programma di backup, magari con un altro protocollo.

Qui ad esempio usiamo FTP dal programma di backup.

E ogni tanto faccio anche il ripristino dell'immagine del s.o., ho un firewall
sw oltre a quello hw e naturamente evito di cliccare su allegati strani.

Uso Firefox con Noscipt e ublock, e se vedo che una ricerca mi porta su pagine
non sicure (siti .ru o .ua per esempio ma non solo), continuo la navigazione da
Firefox in un Linux da Virtualbox, i 5 secondi che ci mette la vm a partire li
aspetto volentieri.

Non si è mai completamente sicuri, ma qualche precauzione è meglio prenderla.


--
ciao
Stefano
ObiWan 24 Mag 2017 15:09
:: On Wed, 24 May 2017 10:33:52 +0200
:: (it.comp.sicurezza.virus)
:: <ehfaicdelu35940k4psitdhq80sr1nh30h@4ax.com>
:: SB <stNOOObenevSPAM ******* it> wrote:

>>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>
> L'op parlava di virus dormienti, tipo i troian, questi per potersi
> attivare devono essere riconosciuti dal so, ad esempio i trojan
> spesso stanno nelle directory Temp mescolandosi ai files temporanei.

potresti, cortesemente, chiarire quello che hai scritto sopra ? Mica
per altro, ma sinceramente non ho capito di cosa tu stia parlando, a
meno che... tu non ti stia riferendo ai virus di 20 anni fa.

> Se tu fai un ripristino del so da immagine, un eventuale trojan viene
> sovrascitto, mentre non vedo come possa attivarsi un ******* che

ammesso e non concesso che lo stesso non abbia iniettato del codice di
"ripristino" in qualche posto non affetto dal "ripristino dell'OS"
tipo, ad esempio, nello storage EFI (giusto per citarne uno che viene
nominato spesso, di recente... ma ce ne sono altri)

> Comunque il backup è meglio farlo differenziale o completo tenedo
> almeno le ultime 2 versioni diverse, in modo da avere in ogni caso
> una versione precedente da cui recuperare qualcosa.

differenziale, incrementale, completo o carpiato, la cosa non cambia di
una virgola, se per fare il backup usi una ******* di rete accessibile
al client (infetto) allora sei a rischio, Leo ha spiegato per bene uno
dei possibili sistemi "sicuri" (le virgolette sono obbligatorie e Leo
mi capirà) per effettuare dei backup

> Qui ad esempio usiamo FTP dal programma di backup.

fammi capire, il client fa FTP verso il server di backup ? Oh che
"bello" :P !
Leonardo Serni 24 Mag 2017 16:01
On Wed, 24 May 2017 08:12:32 +0200, Greg <greg@alicie.com> wrote:

>> La soluzione che ho trovato io è la seguente: sulle macchine Windows gira
>> rsyncd (con password non b*****e; si sa mai).

>> Su un NAS Synology in rete gira uno script che fa il backup incrementale,
>> leggendo dai vari client.

>Questa è una soluzione aziendale o semi-aziendale, e mi pare ottima, ma ancora
non ho capito, al momento di fare il
>backup incrementale, come fare ad essere certi che non siano gia infetti?

Ovviamente non lo puoi sapere, però (su Synology di fascia più alta; io ho gli
occhi su un DS-716 :-) ) potresti verificare alcuni parametri.

- numero di ******* variati dall'ultimo backup
- compressibilità media dei ******* C2 rispetto alla versione precedente C1
(in particolare, se C1 >> 1 e C2 ~ 1, o se C1 ~ 1 e C2 > 1)

E se qualcuno dei parametri "sfora" una soglia di sicurezza, i *******
potrebbero
essere impestati.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
ObiWan 24 Mag 2017 16:19
:: On Wed, 24 May 2017 16:01:17 +0200
:: (it.comp.sicurezza.virus)
:: <l84bic5j2gvcd4o8428lds7bhcb3qfbtjt@L.Serni>
:: Leonardo Serni <lserni@gmail.com> wrote:

> DS-716

Io al momento sto guardando un IBM StorVize 7000 e, nel rack, non è
da solo :D
SB 24 Mag 2017 17:11
Il giorno Wed, 24 May 2017 15:09:26 +0200, ObiWan <obiwan@mvps.org> ha scritto:

>:: On Wed, 24 May 2017 10:33:52 +0200
>:: (it.comp.sicurezza.virus)
>:: <ehfaicdelu35940k4psitdhq80sr1nh30h@4ax.com>
>:: SB <stNOOObenevSPAM ******* it> wrote:
>
>>>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>>
>> L'op parlava di virus dormienti, tipo i troian, questi per potersi
>> attivare devono essere riconosciuti dal so, ad esempio i trojan
>> spesso stanno nelle directory Temp mescolandosi ai files temporanei.
>
>potresti, cortesemente, chiarire quello che hai scritto sopra ? Mica
>per altro, ma sinceramente non ho capito di cosa tu stia parlando, a
>meno che... tu non ti stia riferendo ai virus di 20 anni fa.

Stavo pensando ai trojan effettivamente, ma questi dormienti mi ricordano
proprio loro.

>> Se tu fai un ripristino del so da immagine, un eventuale trojan viene
>> sovrascitto, mentre non vedo come possa attivarsi un ******* che
>
>ammesso e non concesso che lo stesso non abbia iniettato del codice di
>"ripristino" in qualche posto non affetto dal "ripristino dell'OS"
>tipo, ad esempio, nello storage EFI (giusto per citarne uno che viene
>nominato spesso, di recente... ma ce ne sono altri)

Vado di MBR :-)

>> Comunque il backup è meglio farlo differenziale o completo tenedo
>> almeno le ultime 2 versioni diverse, in modo da avere in ogni caso
>> una versione precedente da cui recuperare qualcosa.
>
>differenziale, incrementale, completo o carpiato, la cosa non cambia di
>una virgola, se per fare il backup usi una ******* di rete accessibile
>al client (infetto) allora sei a rischio, Leo ha spiegato per bene uno
>dei possibili sistemi "sicuri" (le virgolette sono obbligatorie e Leo
>mi capirà) per effettuare dei backup
>
>> Qui ad esempio usiamo FTP dal programma di backup.
>
>fammi capire, il client fa FTP verso il server di backup ? Oh che
>"bello" :P !

E' proprio per quello che dicevi tu, tutti gli accessi SMB sono RO, per fare il
backup uso FTP, attivato da un programma, che è l'unico che può scrivere sul
nas.

Cobian Backup per esempio consente di fare il backup via FTP, ma si potrebbe
usare anche SCP, tutto pur di non lasciare accessi SMB aperti che il ransom
potrebbe facilmente usare.



--
ciao
Stefano
Arne Saknussemm 25 Mag 2017 11:53
On Tue, 23 May 2017 19:44:36 +0200
"Leonardo Serni" wrote in it.comp.sicurezza.virus
<03t8icd2ogpmg1ev3gjg48g4cc24ppuinb@L.Serni>:

> On Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> wrote:
>
>>Il 23/05/2017 18:03:28 SB ha scritto:
>>
>>> Meglio ricordare una volta di più di tenere in partizioni separate
>>> i dati dal s.o., si ha un'arma in più.
>
>>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>>Viene anche un altro dubbio: prima di attaccarci il disco off-line
>>per soli 2 minuti, per fare un backup dei ******* piu recenti, come
>>diavolo fdaccio a sapere che non l'ho gia preso e rischio di
>>infettare pure il disco di backup?
>
> La soluzione che ho trovato io è la seguente: sulle macchine Windows
> gira rsyncd (con password non b*****e; si sa mai).
>
> Su un NAS Synology in rete gira uno script che fa il backup
> incrementale, leggendo dai vari client.
>
> Il NAS poi esporta i backup (*****linked snapshot) via SMB in sola
> lettura nel caso uno volesse riprendere qualche ******* vecchio.

In alternativa ci sarebbe BareOS (un fork di Bacula)

https://www.bareos.com/en/

https://forum.synology.com/enu/viewtopic.php?t=50593&start=1260#p382858

in breve, il sistema usa degli "agent" da installare sui vari
computers, tali agent girano come daemon in *nix e come servizi in
windows e permettono al bareos "centrale" di avviare i vari jobs di
backup, il tutto senza esporre ******* di rete
Arne Saknussemm 25 Mag 2017 11:57
On Thu, 25 May 2017 11:53:41 +0200
"Arne Saknussemm" wrote in it.comp.sicurezza.virus
<20170525115341.000018df@eternal-september.org>:

> On Tue, 23 May 2017 19:44:36 +0200
> "Leonardo Serni" wrote in it.comp.sicurezza.virus
> <03t8icd2ogpmg1ev3gjg48g4cc24ppuinb@L.Serni>:
>
>> On Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> wrote:
>>
>>>Il 23/05/2017 18:03:28 SB ha scritto:
>>>
>>>> Meglio ricordare una volta di più di tenere in partizioni
>>>> separate i dati dal s.o., si ha un'arma in più.
>>
>>>Mi pare che il virus attacchi tutte le partizioni e tutti i dischi.
>>>Viene anche un altro dubbio: prima di attaccarci il disco off-line
>>>per soli 2 minuti, per fare un backup dei ******* piu recenti, come
>>>diavolo fdaccio a sapere che non l'ho gia preso e rischio di
>>>infettare pure il disco di backup?
>>
>> La soluzione che ho trovato io è la seguente: sulle macchine Windows
>> gira rsyncd (con password non b*****e; si sa mai).
>>
>> Su un NAS Synology in rete gira uno script che fa il backup
>> incrementale, leggendo dai vari client.
>>
>> Il NAS poi esporta i backup (*****linked snapshot) via SMB in sola
>> lettura nel caso uno volesse riprendere qualche ******* vecchio.
>
> In alternativa ci sarebbe BareOS (un fork di Bacula)
>
> https://www.bareos.com/en/
>
> https://forum.synology.com/enu/viewtopic.php?t=50593&start=1260#p382858
>
> in breve, il sistema usa degli "agent" da installare sui vari
> computers, tali agent girano come daemon in *nix e come servizi in
> windows e permettono al bareos "centrale" di avviare i vari jobs di
> backup, il tutto senza esporre ******* di rete

per chiarire

https://www.bareos.org/en/HOWTO/articles/set_up_backup_client.html

https://www.bareos.org/en/HOWTO.html

;-)
Arne Saknussemm 25 Mag 2017 12:25
On Thu, 25 May 2017 11:57:21 +0200
"Arne Saknussemm" wrote in it.comp.sicurezza.virus
<20170525115721.00006b40@eternal-september.org>:

> On Thu, 25 May 2017 11:53:41 +0200
> "Arne Saknussemm" wrote in it.comp.sicurezza.virus
> <20170525115341.000018df@eternal-september.org>:
>
>> On Tue, 23 May 2017 19:44:36 +0200
>> "Leonardo Serni" wrote in it.comp.sicurezza.virus
>> <03t8icd2ogpmg1ev3gjg48g4cc24ppuinb@L.Serni>:
>>
>>> On Tue, 23 May 2017 19:07:59 +0200, Greg <greg@alicie.com> wrote:
>>>
>>>>Il 23/05/2017 18:03:28 SB ha scritto:
>>>>
>>>>> Meglio ricordare una volta di più di tenere in partizioni
>>>>> separate i dati dal s.o., si ha un'arma in più.
>>>
>>>>Mi pare che il virus attacchi tutte le partizioni e tutti i
>>>>dischi. Viene anche un altro dubbio: prima di attaccarci il
>>>>disco off-line per soli 2 minuti, per fare un backup dei ******* >>>
>piu recenti, come diavolo fdaccio a sapere che non l'ho gia
>>>>preso e rischio di infettare pure il disco di backup?
>>>
>>> La soluzione che ho trovato io è la seguente: sulle macchine
>>> Windows gira rsyncd (con password non b*****e; si sa mai).
>>>
>>> Su un NAS Synology in rete gira uno script che fa il backup
>>> incrementale, leggendo dai vari client.
>>>
>>> Il NAS poi esporta i backup (*****linked snapshot) via SMB in sola
>>> lettura nel caso uno volesse riprendere qualche ******* vecchio.
>>
>> In alternativa ci sarebbe BareOS (un fork di Bacula)
>>
>> https://www.bareos.com/en/
>>
>> https://forum.synology.com/enu/viewtopic.php?t=50593&start=1260#p382858
>>
>> in breve, il sistema usa degli "agent" da installare sui vari
>> computers, tali agent girano come daemon in *nix e come servizi in
>> windows e permettono al bareos "centrale" di avviare i vari jobs di
>> backup, il tutto senza esporre ******* di rete
>
> per chiarire
>
> https://www.bareos.org/en/HOWTO/articles/set_up_backup_client.html
>
> https://www.bareos.org/en/HOWTO.html
>

Ops, dimenticavo :(

http://doc.bareos.org/master/html/bareos-manual-main-reference.html#x1-60001.3

"The Bareos ******* Daemon is a program that must be installed on each
(Client) machine that should be backed up. At the request of the Bareos
Director, it finds the files to be backed up and sends them (their data)
to the Bareos Storage Daemon."

da notare che, in windows, il ******* daemon" (il client) è in grado di
usare VSS (Volume Shadow) per copiare anche files bloccati/in uso
ObiWan 25 Mag 2017 14:59
:: On Wed, 24 May 2017 17:11:47 +0200
:: (it.comp.sicurezza.virus)
:: <r8 ******* p73vpr28jduoe8qge80a4kv0pj@4ax.com>
:: SB <stNOOObenevSPAM ******* it> wrote:

> Il giorno Wed, 24 May 2017 15:09:26 +0200, ObiWan <obiwan@mvps.org>
> ha scritto:
>
>>:: On Wed, 24 May 2017 10:33:52 +0200
>>:: (it.comp.sicurezza.virus)
>>:: <ehfaicdelu35940k4psitdhq80sr1nh30h@4ax.com>
>>:: SB <stNOOObenevSPAM ******* it> wrote:
>>
>>>>Mi pare che il virus attacchi tutte le partizioni e tutti i
>>>>dischi.
>>>
>>> L'op parlava di virus dormienti, tipo i troian, questi per potersi
>>> attivare devono essere riconosciuti dal so, ad esempio i trojan
>>> spesso stanno nelle directory Temp mescolandosi ai files
>>> temporanei.
>>
>>potresti, cortesemente, chiarire quello che hai scritto sopra ? Mica
>>per altro, ma sinceramente non ho capito di cosa tu stia parlando, a
>>meno che... tu non ti stia riferendo ai virus di 20 anni fa.

> Stavo pensando ai trojan effettivamente, ma questi dormienti mi
> ricordano proprio loro.

Nah, I trojan non si nascondevano così bene

>>ammesso e non concesso che lo stesso non abbia iniettato del codice
>>di "ripristino" in qualche posto non affetto dal "ripristino dell'OS"
>>tipo, ad esempio, nello storage EFI (giusto per citarne uno che viene
>>nominato spesso, di recente... ma ce ne sono altri)

> Vado di MBR :-)

se il codice di aggancio è nell'EFI, azzerare la MBR (o anche cambiare
HD) non ti serve a nulla

>>fammi capire, il client fa FTP verso il server di backup ? Oh che
>>"bello" :P !

> E' proprio per quello che dicevi tu, tutti gli accessi SMB sono RO,
> per fare il backup uso FTP, attivato da un programma, che è l'unico
> che può scrivere sul nas.

si ma... hai delle utenze FTP (e relative aree di storage) separate per
ciascuna utenza, o usi un unico logon per tutti i PC ? Mica per altro,
ma... pensa a cosa potrebbe accadere se un malware sgamasse le
credenziali di accesso FTP ... :P
SB 25 Mag 2017 18:08
Il giorno Thu, 25 May 2017 14:59:47 +0200, ObiWan <obiwan@mvps.org> ha scritto:

>:: On Wed, 24 May 2017 17:11:47 +0200
>:: (it.comp.sicurezza.virus)
>:: <r8 ******* p73vpr28jduoe8qge80a4kv0pj@4ax.com>
>:: SB <stNOOObenevSPAM ******* it> wrote:
>>
>Nah, I trojan non si nascondevano così bene

Si sono evoluti anche loro, poi non ho nemmeno ben capito di che virus stai
parlando.

>se il codice di aggancio è nell'EFI, azzerare la MBR (o anche cambiare
>HD) non ti serve a nulla

In questo Pc c'è il il BIOS, quindi mi salverei, ma alcuni effettivamente hanno
UEFI..

>> E' proprio per quello che dicevi tu, tutti gli accessi SMB sono RO,
>> per fare il backup uso FTP, attivato da un programma, che è l'unico
>> che può scrivere sul nas.
>
>si ma... hai delle utenze FTP (e relative aree di storage) separate per
>ciascuna utenza, o usi un unico logon per tutti i PC ? Mica per altro,
>ma... pensa a cosa potrebbe accadere se un malware sgamasse le
>credenziali di accesso FTP ... :P

No, ho un accesso comune e differenzio i backup dal nome.

Comunque visto che uso soprattutto uno script in Python per fare il backup, e

le credenziali sono ovviamente in chiaro nello script, dopo la tua osservazione
le ho fatte passare attraverso un rotore prima di salvare lo script in modo che
non siano mai in chiaro sul ******* .

Roba da un minuto, sperando che questi malware non siano in grado di *****izzare
lo script e ricavarsi le credenziali lo stesso ;-)



--
ciao
Stefano
ObiWan 27 Mag 2017 17:00
It was Tue, 23 May 2017 15:37:40 +0200 when
ObiWan <obiwan@mvps.org> wrote:

>
> Buon divertimento :)
>
>
https://threatpost.com/eternalrocks-worm-spreads-seven-nsa-smb-exploits/125825/
>
> ed il "bello" (si fa per dire) è che questa nuova versione funziona
> come i cosiddetti "sleepers", in breve, infetta il sistema, procede ad
> insediarsi a modo, e poi se ne sta silenzioso, senza manifestarsi, in
> attesa che "i suoi padroni" gli ordinino di fare qualcosa
>
> ci sarà da "divertirsi"

Se per caso a qualcuno servissero delle "firme"

https://github.com/stamparm/EternalRocks

ovviamente, si trova anche altro, ma non mi sembra il caso di postarlo
qui :)
Nedo 7 Giu 2017 09:08
Il 25/05/2017 18:08, SB ha scritto:

>
> No, ho un accesso comune e differenzio i backup dal nome.
>
> Comunque visto che uso soprattutto uno script in Python per fare il backup, e

> le credenziali sono ovviamente in chiaro nello script, dopo la tua
osservazione
> le ho fatte passare attraverso un rotore prima di salvare lo script in modo
che
> non siano mai in chiaro sul ******* .
>
> Roba da un minuto, sperando che questi malware non siano in grado di
*****izzare
> lo script e ricavarsi le credenziali lo stesso ;-)
>
>
>

La soluzione allora sarebbe che il "motore" di tutto il sistema di
backup stia nel NAS (che potrebbe essere un minipc con linux) che quindi
deve essere attivo e non passivo: faccio un esempio, supponendo di usare
l'FTP come protocollo di trasferimento, deve essere il NAS a essere il
client e il PC a essere il server.
A quel punto il NAS periodicamente si connette a ogni PC e via FTP pesca
i files. In nessun caso il PC puo' accedere ai files del nas perche' sul
nas non gira nessun servizio ftp , smb, ecc. Il giorno che hai bisogno
di ripristinare uno o piu' files colleghi una tastiera e un monitor al
NAS, una chiavetta "pulita" e copi dal nas alla chiavetta.
Ma via rete non deve esserci la possibilità di connettersi al nas, in
nessun modo. Nemmeno via ssh perché se hai il virus che logga i
keystroke potrebbe inQlarti la password e poi collegarsi lui come root e
farti un bell'rm -r * sul nas :-)
SB 7 Giu 2017 19:14
Il giorno Wed, 7 Jun 2017 09:08:12 +0200, Nedo <nedo@oden22.it> ha scritto:

>Il 25/05/2017 18:08, SB ha scritto:
>
>>
>> No, ho un accesso comune e differenzio i backup dal nome.
>>
>> Comunque visto che uso soprattutto uno script in Python per fare il backup, e

>> le credenziali sono ovviamente in chiaro nello script, dopo la tua
osservazione
>> le ho fatte passare attraverso un rotore prima di salvare lo script in modo
che
>> non siano mai in chiaro sul ******* .
>>
>> Roba da un minuto, sperando che questi malware non siano in grado di
*****izzare
>> lo script e ricavarsi le credenziali lo stesso ;-)
>>
>>
>>
>
>La soluzione allora sarebbe che il "motore" di tutto il sistema di
>backup stia nel NAS (che potrebbe essere un minipc con linux) che quindi
>deve essere attivo e non passivo: faccio un esempio, supponendo di usare
>l'FTP come protocollo di trasferimento, deve essere il NAS a essere il
>client e il PC a essere il server.
>A quel punto il NAS periodicamente si connette a ogni PC e via FTP pesca
>i files. In nessun caso il PC puo' accedere ai files del nas perche' sul
>nas non gira nessun servizio ftp , smb, ecc. Il giorno che hai bisogno
>di ripristinare uno o piu' files colleghi una tastiera e un monitor al
>NAS, una chiavetta "pulita" e copi dal nas alla chiavetta.
>Ma via rete non deve esserci la possibilità di connettersi al nas, in
>nessun modo. Nemmeno via ssh perché se hai il virus che logga i
>keystroke potrebbe inQlarti la password e poi collegarsi lui come root e
>farti un bell'rm -r * sul nas :-)

Mi sembra eccessivo, il ransom non può sapere che uso un script per il backup,
e
come si chiama.

Ho messo il rotore soprattutto per evitare che i dati fossero in chiaro nello
script, perchè così sarebbero stati disponibili per chiunque avesse aperto il
******* con un notepad, mentre adesso deve capire un minimo di Python, anche
perchè
ho messo diverse funzioni con nomi particolari.

Gli accessi in SMB sono tutti read-only, un utente SMB non può in ogni caso
criptare i dati sul NAS, l'unica cosa che un ransomware potrebbe fare è
criptare
i dati in locale.

Chiaro che se il bakup non fosse differenziato per giorno lo script FTP potrebbe
salvare dati farlocchi, ma se il ransom chessò cripta pure i files .py lo
script
non partirebbe neppure.

Poi come ho già scritto la miglior difesa da queste cose è il controllo del
dito
indice ;-)

--
ciao
Stefano

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni su virus e antivirus | Tutti i gruppi | it.comp.sicurezza.virus | Notizie e discussioni sicurezza virus | Sicurezza virus Mobile | Servizio di consultazione news.