Re: cgi e sicurezza

[Lorenzo "Palinuro" Faletra]

secondo me (ma mi sento un profano), qua do di mezzo c'è cgi non c'è da 
affrontare la cosa dal punto di vista della sicurezza quanto della sua 
obsolescenza e del disinteresse nel far si che cgi resti una tecnologia moderna 
e ottimizzata.
la scarsità di informaziomi relativi alla sua sicurezza è solo un sintomo, ma 
il vero problema è che non è piu una tecnologia di cui la gente vuole sentir 
parlare.

my 1/2 cent.



Il 11 settembre 2017 23:01:54 CEST, Paride Desimone  ha 
scritto:
>Il 11/09/2017 17:10 Davide Prina ha scritto:
>
>> https://wiki.debian.org/Apache/Hardening
>
>Qui mi dice di disabilitare i moduli che non mi servono, incluso cgi
>:-D
>
>> https://www.debian.org/doc/manuals/debian-handbook/
>
>Sul debian handbook, invece, mi dice come abilitare o disabilitare i 
>moduli per apache, incluso quello per i cgi
>
>> https://www.debian.org/doc/user-manuals#securing
>
>Anche qui nulla.
>
>
>Inizio a pensare che debbo cercare direttamente qualche cosa che tratti
>
>della sicurezza dei cgi...
>
>Attendiamo altri pareri, magari di qualcuno che li usa quotidianamente.
>
>Paride

-- 
Lorenzo "Palinuro" Faletra

Parrot Security

GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4

GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4
GPG Key: http://pgp.mit.edu/pks/lookup?op=get=0x97CAA129F4C6B9A4

Re: Desktop e e parallel computing

[Lorenzo "Palinuro" Faletra]

nel caso raspberry vs catorcio del 2008 la questione è differente

il problema dei drivers nasce solo quando c'è da trattare robe specifiche come 
accelerazione hardware per operazioni di decodifica video che senza il giusto 
supporto vanno tutte in emulazione software

leggasi: hai una calcolatrice con le 4 operazioni ma siccome nessuno ti ha 
detto dove sono * e /, moltiplicazioni e divisioni ti tocca farle con + e - 
(volendo fare un'analogia), alias il video va a scatti

ma ti ricordo che la questione raspi vs catorcio andrebbe posta su un altro 
piano, ossia che consumando 5 watt per ora hai una potenza X, mentre per avere 
una potenza 8 volte superiore devi consumare 30 o 40 volte di piu

con uma board arm non pensata per il basso profilo ma pensata per lavorare, per 
avere 8 volte piu potenza avresti al piu 8 volte piu consumi, non 30 o 40 come 
nel caso dell'intel, ed è qui che risiede la vera convenienza di arm

semmai il confronto andrebbe fatto tra un allwinner A64 e un intel baytrail-T 
z3735 (l'ho fatto di persona con un pinebook e un asus x205), e ti posso 
assicurare che l'allwinner si è macinato il baytrail, e uno stress test su 
aircrack macinava 900 chiavi al secondo sul baytrail mentre il pinebook me ne 
faceva 1400, il pinebook consumava poco piu di 2 watt, il baytrail ne consumava 
sopra i 7 quando cominciava a lavorare, inoltre entrambi i portatili avevano 
dissipazione passiva ma sul baytrail si sentiva molto di piu l'effetto del 
thermal throttling








comunque anzichè un cluster di tanti piccoli computers molto piu scarsi della 
media, la tua idea avrebbe senso unendo pochi computers che già da soli 
potrebbero essere utilizzabili, a quel punto si che il tutto acquisterebbe 
senso.



p.s. scrivo do fretta dal cellulare, "chiedo scudo" per errori di morfologia e 
sintassi.



Il 11 settembre 2017 20:19:20 CEST, maxlinux duemila  
ha scritto:
>effettivamente la faccenda di avere cosí poca potenza di calcolo è
>scocciante.
>
>qui hanno fatto un benchmark di una raspberry p3b
>
>https://www.element14.com/community/community/raspberry-pi/blog/2016/02/29/the-most-comprehensive-raspberry-pi-comparison-benchmark-ever
>
>e ci sono questi risultati:
>Total time 477.0617 s
>
>per requeststatistics  
>min47.69   ms
>avg47.7ms
>max49.91   ms
>
>diff between min and max
>2.22 ms
>
>
>poi ho provato nel mio vecchio portatile (core 2 t7250) senza neppure
>spengere Xorg, chrome con 15 tabs aperti, android studio, ecc... con
>le stesse opzionie mi da questo:
>
>$ sysbench --num-threads=1 --test=cpu --cpu-max-prime=2 --validate
>run
>
>Test execution summary:
>total time:  54.0525s
>total number of events:  1
>total time taken by event execution: 54.0426
>per-request statistics:
> min:  5.36ms
> avg:  5.40ms
> max: 22.17ms
> approx.  95 percentile:   5.46ms
>
>
>Ovvero, l'Intel del 2008, è 8.83 volte più rapido del ARMv7 Processor
>rev 4 (v7l)...
>
>Potrebbe anche essere colpa del software, non metto in dubbio, ma
>chiaramente io non posso riscrivere tutti i driver per ottimizzarli
>alla architettura arm.
>
>quindi direi chiuso l'argomentoalmeno con architettura arm.
>Sarebbe forse interessante vedere alcune mainboard all-in-one basate
>su intel/amd x64.
>
>
>On 11/09/2017, Davide Prina  wrote:
>> On 10/09/2017 15:53, maxlinux duemila wrote:
>>
>>> capiterá anche a voi che gli anni passano e il portatile diventa
>>> sempre più lento, quando compila o fa un rendering di un video
>>
>>> Montare in casa un cluster con 8 o 10 raspberry o derivati e usare
>la
>>> loro potenza di calcolo assieme a quella del vecchio e fedele
>>> portatile.
>>
>> secondo me vale la pena di usare più unità distinte se ad ognuna
>assegni
>> un task tutto suo del tipo esegui il browser eseguito sul PC X e
>> visualizzi l'output sul portatile (X forwarding).
>>
>> Altrimenti ottieni maggiori risultati:
>> 1) aumentando RAM (se puoi)
>> 2) ricompilando Linux e togliendo tutto quello che non ti serve
>> 3) disattivando tutti i processi attivi e che non usi
>> 4) spegnendo i demoni che in quel momento non usi o anche solo per il
>> periodo di compilazione
>>
>> Ciao
>> Davide
>>
>> --
>> Dizionari: http://linguistico.sourceforge.net/wiki
>> I didn't use Microsoft machines when I was in my operational phase,
>> because I couldn't trust them.
>> Not because I knew that there was a particular back door or anything
>> like that, but because I couldn't be sure.
>> Edward Snowden
>>
>>
>
>
>-- 
>ciao,
>MaX

-- 
Lorenzo "Palinuro" Faletra

Parrot Security

GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4

GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4
GPG Key: 

Re: cgi e sicurezza

[Paride Desimone]

Il 11/09/2017 17:10 Davide Prina ha scritto:


https://wiki.debian.org/Apache/Hardening


Qui mi dice di disabilitare i moduli che non mi servono, incluso cgi :-D


https://www.debian.org/doc/manuals/debian-handbook/


Sul debian handbook, invece, mi dice come abilitare o disabilitare i 
moduli per apache, incluso quello per i cgi



https://www.debian.org/doc/user-manuals#securing


Anche qui nulla.


Inizio a pensare che debbo cercare direttamente qualche cosa che tratti 
della sicurezza dei cgi...


Attendiamo altri pareri, magari di qualcuno che li usa quotidianamente.

Paride

Re: Desktop e e parallel computing

[maxlinux duemila]

effettivamente la faccenda di avere cosí poca potenza di calcolo è scocciante.

qui hanno fatto un benchmark di una raspberry p3b

https://www.element14.com/community/community/raspberry-pi/blog/2016/02/29/the-most-comprehensive-raspberry-pi-comparison-benchmark-ever

e ci sono questi risultati:
Total time 477.0617 s

per request statistics  
min 47.69   ms
avg 47.7ms
max 49.91   ms

diff between min and max
2.22 ms


poi ho provato nel mio vecchio portatile (core 2 t7250) senza neppure
spengere Xorg, chrome con 15 tabs aperti, android studio, ecc... con
le stesse opzionie mi da questo:

$ sysbench --num-threads=1 --test=cpu --cpu-max-prime=2 --validate run

Test execution summary:
total time:  54.0525s
total number of events:  1
total time taken by event execution: 54.0426
per-request statistics:
 min:  5.36ms
 avg:  5.40ms
 max: 22.17ms
 approx.  95 percentile:   5.46ms


Ovvero, l'Intel del 2008, è 8.83 volte più rapido del ARMv7 Processor
rev 4 (v7l)...

Potrebbe anche essere colpa del software, non metto in dubbio, ma
chiaramente io non posso riscrivere tutti i driver per ottimizzarli
alla architettura arm.

quindi direi chiuso l'argomentoalmeno con architettura arm.
Sarebbe forse interessante vedere alcune mainboard all-in-one basate
su intel/amd x64.


On 11/09/2017, Davide Prina  wrote:
> On 10/09/2017 15:53, maxlinux duemila wrote:
>
>> capiterá anche a voi che gli anni passano e il portatile diventa
>> sempre più lento, quando compila o fa un rendering di un video
>
>> Montare in casa un cluster con 8 o 10 raspberry o derivati e usare la
>> loro potenza di calcolo assieme a quella del vecchio e fedele
>> portatile.
>
> secondo me vale la pena di usare più unità distinte se ad ognuna assegni
> un task tutto suo del tipo esegui il browser eseguito sul PC X e
> visualizzi l'output sul portatile (X forwarding).
>
> Altrimenti ottieni maggiori risultati:
> 1) aumentando RAM (se puoi)
> 2) ricompilando Linux e togliendo tutto quello che non ti serve
> 3) disattivando tutti i processi attivi e che non usi
> 4) spegnendo i demoni che in quel momento non usi o anche solo per il
> periodo di compilazione
>
> Ciao
> Davide
>
> --
> Dizionari: http://linguistico.sourceforge.net/wiki
> I didn't use Microsoft machines when I was in my operational phase,
> because I couldn't trust them.
> Not because I knew that there was a particular back door or anything
> like that, but because I couldn't be sure.
> Edward Snowden
>
>


-- 
ciao,
MaX

Re: Downgrade pacchetti

[Davide Prina]

On 10/09/2017 08:16, Mattia Oss wrote:


Avete suggerimenti per clonare il server? Pensavo a rsync escludendo le
cartelle di sistema.


perché rsync? Non devi clonarlo una volta e basta?

dd

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
I lati oscuri del secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Petizione contro il secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: cgi e sicurezza

[Davide Prina]

On 10/09/2017 09:06, Paride Desimone wrote:

Quacuno sa consigliarmi un po' di documentazione sulla sicurezza dei 
cgi? Configurazione apache, permessi, ecc.?


non sono un esperto, ma puoi iniziare a leggere un po' dalla 
documentazione ufficiale di Debian:


https://wiki.debian.org/Apache/Hardening
https://www.debian.org/doc/manuals/debian-handbook/
https://www.debian.org/doc/user-manuals#securing

Ciao
Davide


--
Dizionari: http://linguistico.sourceforge.net/wiki
Esci dall'illegalità: utilizza LibreOffice/OpenOffice:
http://linguistico.sf.net/wiki/doku.php?id=usaooo
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: Desktop e e parallel computing

[Davide Prina]

On 10/09/2017 15:53, maxlinux duemila wrote:


capiterá anche a voi che gli anni passano e il portatile diventa
sempre più lento, quando compila o fa un rendering di un video



Montare in casa un cluster con 8 o 10 raspberry o derivati e usare la
loro potenza di calcolo assieme a quella del vecchio e fedele
portatile.


secondo me vale la pena di usare più unità distinte se ad ognuna assegni 
un task tutto suo del tipo esegui il browser eseguito sul PC X e 
visualizzi l'output sul portatile (X forwarding).


Altrimenti ottieni maggiori risultati:
1) aumentando RAM (se puoi)
2) ricompilando Linux e togliendo tutto quello che non ti serve
3) disattivando tutti i processi attivi e che non usi
4) spegnendo i demoni che in quel momento non usi o anche solo per il 
periodo di compilazione


Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
I didn't use Microsoft machines when I was in my operational phase, 
because I couldn't trust them.
Not because I knew that there was a particular back door or anything 
like that, but because I couldn't be sure.

Edward Snowden

Re: cgi e sicurezza

[Pol Hallen]

Quacuno sa consigliarmi un po' di documentazione sulla sicurezza dei 
cgi? Configurazione apache, permessi, ecc.?


mi aggrego alla richiesta in quanto anch'io sto facendo qualche script :-)

Pol

Re: Desktop e e parallel computing

[Lorenzo "Palinuro" Faletra]

Il 11 settembre 2017 13:17:41 CEST, maxlinux duemila  
ha scritto:
>in effetti hai ragione riguardo alla latenza, cmq stavo pensando, a
>operazioni lunghe + adatte ad un cluster che a un multiprocessore
>Del tipo... compilazione in parallelo con gradler, compressione di
>video con ffmpeg, rendering di video con blender. Questi programmi
>sono adatti al calcolo in cluster, pur tenedo conto della inevitabile
>latenza.

allora ne possiamo parlare, ma spesso le applicazioni vanno riscritte 
appositamente per essere clusterizzabili (mpich ed il protocollo MPI sono un 
buon punto di partenza per studiare la cosa)

soluzioni integrate per rendere trasparente il processo e creare una vera e 
propria VM "spalmata" su piu computers? personalmente non ne conosco e passo la 
palla ad altri

>
>Stavo anche pensando di non usare la porta ethernet, e usare
>direttametne usb3 via otg (ethernet on usb) per aumentare la velocità
>di trasferenza.

può essere una buona idea, altrimenti si può pensare a usb-c o semplicemente ad 
un upgrade a ethernet 10gbps (costosissimo), magari in fibra, come si fa ormai 
in molti datacenters, ma forse usb3 è la via piu economica ed alla portata di 
tutti


>
>Poi per la navigazione in internet o riproduzione di film in 4k... non
>mi preoccupa. Posso continuare a farlo dal portatile e i film non
>guardo proprio, visto il scarso contenuto dei film di qualsiasi tipo
>negli ultimi anni.

gr8


>
>CMQ la cosa che più mi preoccupa invece è la velocità di calcolo.
>Secondo i benchmark l'architettura arm esce con le ossa rotte
>comparata persino con un intel di bassa categoria.
>Peró non vorrei che fosse per colpa del benchmark stesso.

ARM è un'architettura RISC, quindi un set ridotto di istruzioni, che consuma 
molto meno, fa molto uso dei registri limitando le pull e le push dalla ram 
(tipicamente molto lenta) e occupando molta meno superficie di silicio, dando 
vita o a processori completi molto compatti ed economici (ma stracciati nei 
benchmarks classici), o a processori di dimensioni classiche dove nella 
superficie di un intel baytrail è possibile far entrare senza troppe difficoltà 
anche 96 core o piu.

infatti arm è il futuro del mondo server (con le architetture ppc e mips che 
stanno nuovamente prendendo piede nei mainframe e nei supercomputer)


personalmente come parrotsec stiamo provando ad investire molto in arm64 e in 
board come pine64, rock64 e alcune nuove orangepi, ma prima purtroppo nel 
mercato consumer, i produttori hanno freato una vera e propria mafia di drivers 
proprietari e hardware packs inutilizzabili, con kernel vecchi e con varie 
problematiche di performance, ma fidati, i benchmark di una board allwinner con 
debian non sono in nessun modo rappresentativi della qualità dell'architettura 
arm, che secondo me deve ancora vedere la sua vera rivincita o attraverso una 
nuova board progettata seriamente o attraverso tutte le legnate date ad 
allwinner e ad altri produttori simili che hanno progettato ottimi processori 
confezionando pessimi hardware packs per le comunità opensource

dai, sugli smartphone i video in 8k non vanno affatto a scatti, mentre un 
pine64 lo metti in crisi con un 720p, e solo per una questione software non 
legata alla comunità opensource ma legata al produttore

my 2 cents


>
>Qualcuno ha maggiori info a riguardo?
>
>
>On 11/09/2017, Lorenzo "Palinuro" Faletra 
>wrote:
>> ma stai tenendo in considerazione latenza e throughput?
>>
>> questo tipo di clusters va bene solo per applicativi server con varie
>> istanze che scalano orizzontalmente su questo tipo di configurazioni,
>ma un
>> macchinone virtuale nato dalla fusione di tanti piccoli nodi farebbe
>un po
>> schifo per applicativi interattivi poichè coinvolgere lo stack di
>rete e dei
>> sistemi operativi per virtualizzare trasmissioni che normalmente un
>computer
>> compie in modo diretto verso memoria e periferiche, comporta seri
>> rallentamenti
>>

-- 
Lorenzo "Palinuro" Faletra

Parrot Security

GPG FINGERPRINT: B350 5059 3C2F 7656 40E6 DDDB 97CA A129 F4C6 B9A4

GPG Info: http://pgp.mit.edu/pks/lookup?op=vindex=0x97CAA129F4C6B9A4
GPG Key: http://pgp.mit.edu/pks/lookup?op=get=0x97CAA129F4C6B9A4

Re: Desktop e e parallel computing

[Gian Uberto Lauri]

> "md" == maxlinux duemila  writes:

md> compressione di video con ffmpeg,

Credo si guadagni di più riuscendo ad utilizzare le SSE avendo una
multiprocessore multicore che andando su una VM in cluster...

md> rendering di video con
md> blender.

Con un intervento minimo e l'uso di Cilk Plus, credo che a parità di
processori la macchina parallela faccia mangiare la polvere al
cluster...

Cilk Plus è disponibile con GCC 5.0.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: Desktop e e parallel computing

[maxlinux duemila]

in effetti hai ragione riguardo alla latenza, cmq stavo pensando, a
operazioni lunghe + adatte ad un cluster che a un multiprocessore
Del tipo... compilazione in parallelo con gradler, compressione di
video con ffmpeg, rendering di video con blender. Questi programmi
sono adatti al calcolo in cluster, pur tenedo conto della inevitabile
latenza.

Stavo anche pensando di non usare la porta ethernet, e usare
direttametne usb3 via otg (ethernet on usb) per aumentare la velocità
di trasferenza.

Poi per la navigazione in internet o riproduzione di film in 4k... non
mi preoccupa. Posso continuare a farlo dal portatile e i film non ne
guardo proprio, visto il scarso contenuto dei film di qualsiasi tipo
negli ultimi anni.

CMQ la cosa che più mi preoccupa invece è la velocità di calcolo.
Secondo i benchmark l'architettura arm esce con le ossa rotte
comparata persino con un intel di bassa categoria.
Peró non vorrei che fosse per colpa del benchmark stesso.

Qualcuno ha maggiori info a riguardo?


On 11/09/2017, Lorenzo "Palinuro" Faletra  wrote:
> ma stai tenendo in considerazione latenza e throughput?
>
> questo tipo di clusters va bene solo per applicativi server con varie
> istanze che scalano orizzontalmente su questo tipo di configurazioni, ma un
> macchinone virtuale nato dalla fusione di tanti piccoli nodi farebbe un po
> schifo per applicativi interattivi poichè coinvolgere lo stack di rete e dei
> sistemi operativi per virtualizzare trasmissioni che normalmente un computer
> compie in modo diretto verso memoria e periferiche, comporta seri
> rallentamenti
>