Jump to content

Search the Community

Showing results for tags 'sicurezza'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Richiesta informazioni e consigli hosting
    • Domini e Registrazioni
    • Shared e Managed Webhosting
    • WebHosting - Primi passi
    • Server dedicati, colocation, connettività e scelta data center
    • VPS - Virtual Private Server
    • Cloud Computing e Cloud Hosting
    • Gestione Server Windows e Server Linux
    • E-mail e Managed Services
    • Pannelli di controllo e Hosting software
    • Professione Hosting Provider
  • Sviluppo Web e Tempo Libero
    • Io Programmo
    • Promozione, advertising e SEO
    • Off-Topic
    • Il tuo sito
  • Guide su hosting, domini, server, CMS e Cloud Computing
    • Articoli e Guide su hosting, domini e cloud computing
    • Annunci e News
    • Offerte Hosting - Provider HostingTalk.it

Calendars

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests


Biografia


Località


Interessi


Cosa fai nella vita?


Il tuo Hosting Provider?

Found 98 results

  1. Ciao a tutti, premetto che nonostante quello che sto per scrivere, mi trovo relativamente bene con il provider citato. Sono un ex utente aruba con esigenze di hosting relativamente modeste, una community che ha integrato un sistema via chat irc con messaggeria privata, sistema di forum e strumenti analoghi, con utenza media di 20-30 uenti online e rari picchi oltre i 40. Dopo essermi trovato malissimo con Aruba, che aldilà dei convenientissimi pacchetti base per qualunque opzione o servizio aggiuntivo azzera la convenzienza del pacchetto base e NON dispone comunque di cronjobs, manco a offrirsi di pagarli in oro, passai a netsons. Per le mie limitate esigenze mi trovo relativamente bene. Ho tutt'ora un piano hosting multidominio e due piani hosting "semicondivisi" (adesso si chiama Hosting professionale PRO), hostati su tre server diversi, e sono quindi anche in grado di dare qualche elemento comparativo. Evidenzio subito una comodità offerta da netsons, ossia la possibilità di frazionare i pagamenti in rateizzazione mensile, una possibilità che per utenti privati e/o amatoriali o a caccia del risparmio, non è da poco. Nell'insieme il servizio è buono, per quello che ho potuto misurare in ormai 5 anni di affezionata clientela, gli uptime sono rispettati rispetto a quelli dichiarati. sempre in un'ottica non proprio entry-level ma sempre in ambito personale/amatoriale, non c'è paragone tra la chiarezza dell'area utenti di netsons e la confusionarietà del portale da cui sono fuggito. Anche questo è un elemento che probabilmente può fare la differenza per un'utenza entry level o poco più. Veniamo a quelle che considero le note dolenti, che considero tali soprattutto perchè NON documentate e non illustrate prima dell'acquisto, a partire dall'approccio standard di Netsons alla sicurezza. Un vecchio adagio tra sistemisti, recita "L'unico computer sicuro è quello scollegato dalla rete". beh sembra che quelli di netsons abbiano preso alla lettera questo antica dottina informatica. Episodio 1, le policy antispam. Come già spiegato, gestisco un sistema integrato con chat, mp, forum vari e altri strumenti di supporto per quella che è fondamentalmente una comunità di giocatori di ruolo. Ora, può capitare che un giocatore scriva la parola "casino" (a intendere "confusione" non "casa da gioco"), o la parola "poker" (ad esempio in una frase come "faccia da poker"). tadaaah... al momento di cliccare sul tasto invio del form che invia la frase in chat, o il messaggio privato, o l'intervento sul forum, scatta la policy antispam di netsons, che "riconosce" la parola chiave (poker, casino, ecc) e fa apparire all'utente colpevole una magnifica pagina bianca 403 Forbidden. Ho impiegato non poco tempo per rintracciare il problema e quando, a forza di tentativi (e di richieste di inutili controlli del MIO codice da parte dell'help desk di Netsons) è stato chiaro che erano delle parole chiave causare l'errore 403, mi è stato risposto che su ogni hosting veniva attivata una wordlist predefinita di parole proibite. E qui veniamo ad un primo problema: Sul server che ospita il mio vecchio hosting frazionabile multidominio ho potuto risolvere il problema tramite file .htaccess, disattivando la sola wordlist. Sul serve su cui è ospitato l'hosting semicondiviso, al contrario, mi è stato risposto che la disattivazione parziale non è possibile e che l'unica soluzione era disattivare l'intero modulo di sicurezza antispam. Non lo iscriverei fra i punti di forza e di eccellenza di netsons, il fatto che a seconda del server su cui si capita (casuale? si può scegliere?), siano possibili differenti possibilità di intervento "a basso livello" sulle configurazioni del server web. Episodio 2, il "famigerato" TOR Browser e la rete anonimizzatrice TOR Premetto che anche qui ho riscontrato differenze tra i tre server su cui sono ospitati i tre servizi hosting da me sottoscritti. Non mi dilungo sulla legittimità o meno di navigare in anonimato. Chiunque gestisca una community online sa bene che, perseguitati politici esclusi, il 99% degli utenti che pretendono di usare la rete TOR per frequentare stabilmente una community (specie community ad alto rischo di litigiosità tra utenti) lo fanno per ragioni che c'entrano molto poco con la protezione della propria privacy e sicurezza personale. Lo fanno il più delle volte nella speranza di minimizzare sanzioni regolamentari dovuto alla violazione di una o più condizioni sottoscritte al momento della registrazione e di poterlo fare "in anonimato". Troll e spammer, per dirla fuori dai denti. Per questa ragione sul primo server (hosting frazionabile) e sul primo semicondiviso acquistato, usato per lo sviluppo e il collaudo della mia community, avevo predisposto un banalissimo controllo sulle connessioni da rete TOR, usufuendo di un tool messo a disposizione dalla rete TOR stessa. Funzionava alla perfezione, lasciando visibili anche da rete TOR le parti di sito "esterne" e consultabili senza registrazione, e bloccando con un bel "marameo" i tentativi di registrazione e login nell'area per gli iscritti. L'utente usante una connessione TOR veniva semplicemente reindirizzato sulla "pagina marameo". Tadaaahh. Arriviamo al terzo server. Lì se ti colleghi usando TOR, non vedi proprio il sito. Timeout infinito finchè non appare la pagina bianca che classifica il sito come "irraggiungibile". Chiedo spiegazioni all'help desk e (dopo la solita richiesta di default di effettuare una serie di inutili controlli sul mio codice), mi viene risposto che le connessioni TOR vengono bloccate da default, per gli stessi motivi per cui io volevo bloccare gli accessi all'area riservata agli iscritti. Ma... scusate un momento: Potrò decidere io quali parti del sito rendere inaccessibili a un probabile spammer o troll che usa TOR per nascondere il suo IP di provenienza? No, ci pensa Netsons, rendendo irraggiungibile di default il sito da parte di chiunque esca con un IP appartenente alla rete TOR. Chiedo se sia possibile modificare questa impostazione e mi viene risposto di no. Allora, scusate, perchè la cosa non viene chiaramente illustrata prima dell'acquisto? Nel mio caso non cambia nulla (anzi mi risparmia codice), ma se avessi voluto mettere in piedi un sito di informazione rivolto ai cittadini di paesi nei quali la censura politica li obbliga ad adottare ogni possibile misura a tutela della loro privacy, avrei acquistato inutilmente un pacchetto da netsons, senza essere informato che il mio sito sarà irraggiungibile proprio per l'utenza a cui mi rivolgo. E, anche qui, devo registrare la CASUALITA' di questa condizione, dal momento che su alcuni server il filtro è attivo e su altri no. Episodio 3, Whitelist vs Blacklist: la FOLLIA lavoro come consulente informatico entro una nota compagnia internazionale di assicurazioni e quando ho un momento libero, a volte mi colego al mio sito, giusto per buttare un'occhio in orari nei quali la maggior parte dei moderatori è al lavoro o in università. A seconda dei casi, la nostra rete aziendale, che è strutturata a livello europeo, mi fa "uscire" con connessioni che apparentemente partono da Parigi, da Amburgo, da Bruxelles o da Londra. Un giorno passo il link del mio sito a un collega della stanza affianco, giusto per farglielo vedere. Due minuti dopo mi richiama e mi dice "guarda che il sito è giù". Sulle prime penso a un disservizio temporaneo, perchè mi collego e anch'io vedo solo la pagina bianca prima che il browser vada in timeout e mi informi che non è riuscito a raggiungere il sito. Combinazione però mi viene detto per telefono che il sito non è affatto "giù". infatti faccio la prova da cellulare e con lo smartphone il sito risulta raggiungibilissimo. uhm... che sarà successo? Contatto l'help desk e dopo varie spiegazioni mi viene detto che il mio IP (in quel momento geolocalizzato a Bruxelles) risulta bloccato per ragioni di sicurezza. Mia faccia davanti alla notizia ---> O___O Comunque la signorina dell'HD si affretta ad assicurarmi di averlo sbloccato e infatti il sito mi torna nuovamente raggiungibile. Peccato che il giorno dopo il problema si ripete e... tadaaaaahhhh... spiegato l'arcano, il giorno dopo avevo un IP diverso, sempre appartenente allo stesso range, ma con la tripletta finale diversa. A quel punto mi "inalbero" un pochino e contatto di nuovo la signorina dell'help desk, chiedendo spiegazioni. E, dopo qualche domanda trabocchetto, ottengo la risposta che temevo di dover sentire. L'INTERO range di IP della mia compagnia (parliamo di una multinazionale delle assicurazioni, eh, non di una società offshore con sede nel Delaware o alle Bahamas) non è nella loro whitelist. Come, come? Piano, un momento. Cosa cavolo significa che non è nella whitelist??? Significa che per sperare che il proprio sito sia visibile fuori dall'Italia bisogna fare domanda di inserimento nella Whitelist??? Ma stiamo scherzando? Questa è una follia ancora peggiore del blocco di default delle connessioni TOR. Comunque mi armi di pazienza e, anceh se non dovrei essere io a farlo, fornisco alla gentile signorina dell'helpdesk tutto il range di IP che, per quanto ne so, è intestato alla rete della mia compagnia. La domanda mi sorge spontanea: quante altre connessioni dall'estero vengono bloccate a mia insaputa, col sito oscurato a mia insaputa, con al scusa delle "ragioni di sicurezza"? Mi rendo conto che Netsons avendo, gli anni passati, hostato un sito di estrema destra si è resa bersaglio di attacchi informatici indiscriminate da parte di cybedeficienti che per colpire un sito "nemico" decidono allegramente di colpire chiunque sia hostato dallo stesso provider, ma la "soluzione" adottata sa di paranoia, non di sicurezza. Ok, "l'unico computer sicuro è il computer non collegato a una rete", ma.... non l'avete preso un po' troppo alla lettera, cari signori di netsons? Anche perchè francamente dubito che dalla rete della assicurazione per cui lavoro siano mai partiti attacchi DoS contro netsons tali da spingerli a inserire l'intera rete aziendale europea in una blacklist. E soprattutto, non sarebbe vostro preciso dovere commerciale informare i potenziali clienti che se vogliono raggiungere un pubblico più esteso del proprio parentado e cerchia di ex compagni di classe rischiano di trovarsi "oscurati" senza saperlo? Episodio 4: Cloudflare, o no? La mia prima (tragica) esperienza con Cloudflare risale a tre, quasi quattro anni fa. Premessa: netsons pubblicizza apertamente tra i propri punti di eccellenza la connettività italiana e la vicinanza della sua server farm al princiapel nodo di Milano. Suggerendo evidentemente, al potenziale cliente, che questo comporterà un vantaggio in termini di velocità e di tempi di risposta del sito. Di più, il servizio Cloudflare viene pubblicizzato, correggetemi se sbaglio, come servizio di ridondanza e di backup, pronto a intervenire in caso di emergenza e a "sostituire" temporanamente il sito originale con una copia nel caso in cui il server che ospita l'originale sia down o sotto attacco. Cosa che per un provider come Netsons, bersagliato di continuo dai cyberdeficienti di cui sopra, dev'essere un investimento indispensabile per garantire la continuità del servizio. ora, la domanda, è: Quando e quanto spesso subentra effettivamente la "copia" su Clodflare in luogo dell'originale hostato sulla tanto pubblicizzata connettività italiana e server farm a un tiro di sputo dal nodo di Milano? Me lo sono chiesto proprio in occasione di quello che allora fu definito il più grande ed esteso attacco DDoS di tutti i tempi. Di cui, udite udite, non fu bersaglio netsons, ma proprio Cloudflare. Me lo sono chiesto perchè in quei giorni fastidiosissimi, si verificò una stranezza. I server italiani di netsons erano raggiungibili, via ping, via traceroute, addirittura via sftp. I webserver che avrebbero dovuto rispondere da quei server fisici, invece, no. Se provavi a collegarti la connessione andava in timeout oppure appariva una pagina di errore dei server californiani di Cloudflare di "server too busy". Morale: i server italiani "protetti" da Cloudflare non erano sotto attacco, ma Cloudflare (che era sì sotto attacco e pesantemente collassata) era subentrata lo stesso. Perchè? Perchè non rispondevano i magnifici server della webfarm a un tiro di sputo dal nodo di Milano e su connettività italiana e subentrava invece un server californiano sotto attacco? Di qui la domanda ovvia: Quando e quanto interviene effettivamente la ridondanza di backup di Cloudflare, se i server italiani non sono affatto sotto attacco nè down per anomalie tecniche? La domanda me la posi anche in altre circostanze, in cui di nuovo senza apparente spiegazione, e senza alcun attacco DoS in corso, nè ai danni di netsons nè ai danni di cloudflare, il server "di backup" subentravano comunque, non richiesti. me ne accorsi facendo degli aggiornamenti al mio codice e caricando ex novo delle pagine nuove via FTP. Caricate le pagine via ftp, le pagine visibili da browser web restavano quelle vecchie. Definire "evasive" le risposte in proposito avute dall'HD di netsons in quel periodo è poco. Ad ogni modo "risolsi" il problema rinunciando alla protezione di Clouflare, che sul vecchio server (hosting frazionabile) fu disattivato. Da allora stranamente non ho più registrato disallineamenti di versione tra gli script appena caricati via ftp e quelli consultabili via browser dagli utenti in circostanze normali. Quando ho acquistato i due pacchetti hosting semicondiviso, tanto per portarmi avanti, ho chiesto preventivamente la disattivazione di cloudflare ma, sopresa!, mi è stato risposto che su quei server il servizio non era comunque attivo. Anche qui: server diversi, configurazioni diverse, nessuna spiegazione preventiva all'acquirente. Perchè? Episodio 5: PHP, file remoti e "controlli il suo codice" Nell'ambito della community ho esigenza che gli utenti possano caricare un loro avatar, un'immagine del profilo, usabile nel gioco e sui forum interni. Non essendo intenzionato a permettere l'upload diretto delle immagini sul mio spazio web, ho sempre lasciato, sul vecchio hosting frazionabile, la possibilità agli utenti di caricare le loro immagini del profilo su un altro server e di hotlinkarle facendole richiamare dalle pagine interessate. Avvalendosi tipicamente di servizi esterni di hosting immagini come imageshack o tinypic, o più banalmente caricando le immagini nella famigerata cartella /_altervista_ht/ dei domini gratuiti di altervista, appositamente configurate per permettere l'hotlink esterno. Ovviamente con qualche controllo preventivo sul formato MIME del file e le sue dimensioni, prima del richiamo nella pagina, per evitare seccanti tentativi di sql injection e XSS. Banalmente, scrissi una funzionacina php che prima di autorizzare il caricamente di un avatar esterno nella pagina html generata da php, controllava il percorso (url), l'estensione, l'esistenza del file, il formato MIME e le dimensioni del file. Sul server che ospita il piano frazionabile, tutto ok. Provo a replicare lo stesso sistema sui due server dove ho l'hosting semidedicato e.. tadaaaah! Appena PHP tenta di leggere un file remoto, la pagina php va in timeout e la funzione php incaricata (si tratti di file_exists() o di getimagesize() e analoghe) di controllare esistenza e formato del file remoto, va in palla, tenendo l'utente a fissare una pagina bianca per una quarantina di secondi prima che il server si degni di rispondere con un errore. Faccio tutti i test del caso per accertarmi che il problema dipenda dal tentativo di accedere a file remoti, confezioni un bel ticket con tanto di spiegazioni preventive (tanto per risparmiarmi la solita, inutile richiesta di "controlli il suo codice" che ogni addetto help desk di Netsons ha in canna e copincolla di default appena risponde a un ticket) e contatto l'help desk. Inutile dire che la prima risposta è stata comunque "controlli il suo codice" e che la prima domanda di merito sul problema segnalato mi è stata posta circa 48 ore dopo l'apertura del ticket e solo al terzo scambio di messaggi. Va beh, facciamo finta di nulla. In quel momento avevo questioni di sviluppo più urgenti e per il momento disattivai quei controlli, lasciando cadere il ticket perchè in tutta sincerità in quel momento avevo troppo da fare per perdere tempo a spiegare all'addetto help desk che gli avevo già fornito tutti gli estremi necessari e che gli sarebbe bastato verificare se sul server era attivo un blocco degli accessi ai file remoti. Resta il fatto che ho acquistato ben DUE piani hosting, pubbblicizzati espressamente da netsons per la loro maggiore efficienza e performance (vengono consigliati appositamente a clienti che vogliano installare CMS pesanti come Drupal, tanto per dirne una) e non posso fare a meno di chiedermi cosa accade a chi prende quel tipo di hosting proprio per installarci drupal e si trova con gli utenti che vanno in timeout appena cercano di caricare un'immagine profilo hostata esternamente. E non posso fare a meno di rilevare, ancora una volta, il problema già verificato in altre circostanze: Server diversi, configurazioni diverse, nessuna informazione preventiva e apparente "casualità" a seconda del server su cui si finisce hostati. ----------------------------------------- Fin qui i casi ascrivibili alla categoria "sicurezza" che mi hanno generato forti perplessità, perchè tirando le somme delle anomalie, mi si prospetta un possibile scenario inquietante: Ossia che la pubblicizzata maggiore prestanza di certi piani hosting non sia ottenuta grazie a minore affollamento e/o grazie a configurazioni hardware più performanti, ma grazie all'applicazione di policy di "sicurezza" quanto meno bizzarre nella gestione di whitelist e blacklist (con potenziale grave danno in termini di oscuramento inatteso e indesiderato del sito al di fuori delle white/blacklist), nell'adozione di configurazioni di sicurezza assurdamente restrittive (per non dire paranoidi) e, cosa ben più grave, senza una preventiva e adeguata informazione all'acquirente. Arriviamo alla ciliegina sulla torta, quella che mi ha fatto definitivamente "sbroccare", come si dice qua a Roma. L'atteggiamento ormai di default degli addetti all'help desk, coloro che DOVREBBERO aiutare il cliente a individuare e risolvere una problema quando viene segnalato e che sempre più spesso si limitano ad agire come quelle segretarie d'ufficio che "fanno filtro" temporeggiando con i clienti che telefonano allo studio, prima di decidersi ad alzare il posteriore dalla poltrona e chiamare il titolare al telefono. Episodio 1, Server down e picchi di consumo: "Controlli il suo codice" e "Adesso il sito funziona" Una settimana fa il sito va down per un'oretta circa. Poco male, è tarda sera e la community è "chiusa" per manutenzione. Collegati c'eravamo solo io e altri due sviluppatori. Apro un ticket, dopo 20 minuti, quando non vedo il server ripartire e il giorno dopo mi viene risposto (conoscendo i miei polli allego anche i grafici di Cpanel sul consumo di risorse) con la solita richiesta di default, di controllare il mio codice perchè probabilmente, mi viene suggerito con tanto di "faccina", il picco di consumo di memoria e cpu è stato causato da "codice non ottimizzato". Tralascio i giramenti di posteriore, dato che in quel momento non stavo lavorando sul codice, e faccio presente che andando indietro di 24 ore si vedono benissimo altri picchi di consumo, in orari in cui non c'era proprio nessuno collegato, nessun cronjob stava girando e già che ci sono mostro come dalle date di modifica degli script PHP sia facile evincere che nessuna modifica era stata introdotta al codice nelle 72 ore precedenti al disservizio. Altre 24 ore prima di una nuova risposta, che consiste in "Abbiamo verificato, il sito risponde regolarmente e senza picchi. Non ci risulta alcun disservizio". Ticket chiuso. No, dico. la pazienza di Giobbe, ci vuole. Tengo per me (oltre alle parolacce) la spiegazione più ovvia, ossia un consumo di risorse non dovuto al MIO codice ma o a interventi sulla macchina, o a qualche "vicino" ingombrante, alla faccia del semicondiviso. Non è la prima volta che succede e 5 anni di esperienza mi hanno insegnato a lasciar cadere la cosa, visto che fortunatamente non si verifica troppo spesso. Episodio 2: Warning PHP/mariaDB per disalliamento header PHP e "Controlli il suo codice" La goccia che, per quanto mi riguarda, ha fatto traboccare il vaso. Non c'è nulla, dico nulla, di più irritante e frustrante, per un sistemista e programmatore, di sentirsi rispondere da un altro (supposto) sistemista con risposte evasive, approssimative e "alla carlona" mentre si sta tentando di risolvere un problema. Nulla. No, beh, un bug logico nel proprio programma, di queli che non causano errori di sistema ma danno risultati inattesi, forse è peggio. Ma di poco. Due giorni dopo l'episodio qui sopra riportato, inizia a verificarsi una stranezza. Tutti gli script php che accedono al database, in lettura o scrittura, buttano fuori un warning ad ogni connessione: PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Di per sè non sarebbe grave. Non è un errore bloccante, è solo un warning. E nella maggior parte dei casi, pagine poco consultate hanno riempito, in poche ore, le loro cartelle di file di log errore pieni del warning di cui sopra. Ma ci sono anche cartelle con pagine molto usate che nel giro di poche ore hanno podotto file di log delle dimensioni di un paio di megabyte. Mi insospettisco, quando noto che caso strano i warning iniziano a verificarsi dopo la fine del blackout di cui sopra, quello in cui per un'oretta e mezza il server è stato down. Tant'é che nel ticket chiedo esplicitamente se non siano stati effettuati aggiornamenti con conseguente disallineamento di versioni. sempre nella (inutile) speranza di risparmiarmi la rituale richiesta di controllare il mio codice, allego anche uno dei log errori contenenti il wanring ed evidenziando che a produrre il warning è la stessa funzione mysql_connect(). Non una query scritta male, non codice mal ottimizzato, non un errore logico che causa qualche loop. No. E' proprio la banalissima funzione che attiva il collegamento al database a buttare fuori il warning, appena PHP prova a bussare a MySql. Puntuale (dopo circa 24 ore) come la morte, arriva lo stesso la solita risposta a pennuto di cane: "con la presente La invito a verificare che il codice utilizzato deve essere compatibile con il PHP 5.6 e la versione del servizio DB MariaDB10" Eh no. Scusate, va bene tutto. Io capisco chi, qui, difende i colleghi per principio e si indigna quando i colleghi vengono messi alla gogna, ma qui si passa ogni limite. Ho citato espressamente la funzione che causa il warning. Ho pure allegato un log completo. Ti ho pure fornito sul piatto d'argento la possibile motivazione del warning, visto che basta cacciare quel warning nella ricerca di google per ottenere la spiegazione ( https://mariadb.com/kb/en/mariadb/installation-issues-with-php5/ ), che ovviamente dipende da una configurazione del server non accessibile al semplice utente "hostato". E tu mi rispondi "controlla il tuo codice"??? Quale sarebbe, il "mio codice" di cui si suggerisce l'incompatibilità con PHP 5.6 e MariaDB10", la funzione mysql_connect() ?? E' esattamente questo che rispondo all'addetto help desk, aggiungendo che se la funzione mysql_connect() fosse "mio codice" oggi probabilmente sarei miliardario. L'addetto lascia passare altre 24 ore e risponde piccatamente offeso, chiudendo il ticket in quanto "non gli ho fornito info rilevanti". Cari signori di netsons. Così non va. Di questo passo, state imboccando lo stesso sentiero di aruba. da sistemista posso capire a mia volta la fretta che può spingere un collega oberato di lavoro a cercare di temporeggiare per non essere sommerso dai problemi in lista di attesa. Ma che diamine: Un "adesso verifichiamo, stiamo lavorando sul problema, le faremo sapere", per quanto irritante è mille volte meglio di una risposta alla carlona dalla quale si evince che il vostro addetto non ha nemmeno fatto lo sforzo di leggere la prima riga del ticket. Non può esistere che la risposta di default dei vostri operatori, ormai, è "controlli il suo codice" qualunque cosa venga scritta nel ticket, anche quando è lampante che il ticket riguarda una configurazione del server e non un malfunzionamento di codice autoprodotto. Se l'unica residua convenzienza del vostro servizio diventa la presenza dei cronjob anche nel pacchetto base e la possibilità di rateizzare i pagamenti, presto o tardi la gente che è fuggita da aruba anni fa venendo da voi perchè aveva un servizio migliore, migrerà da qualche altra parte. Mi spiacerebbe, perchè dopo 5/6 anni con voi, nonostante tutto mi sono in qualche modo affezionato. Ma più passa il tempo, più imboccate questa strada, più passa la voglia.
  2. Devo installare uno script php e mi accingo ad acquistare due domini (.it e .com). Tutto semplice vero? Mica tanto... Tralascio la questione costi e mi concentro su due temi centrali: affidabilità/velocità e sicurezza Affidabilità/velocità: attraverso uno strumento molto utile (reverse ip domain check), ho scoperto che molti provider assegnano allo stesso ip/server centinaia/migliaia di siti, creando così un problema di affidabilità e velocità. Mi chiedo, a questo punto, se non sia il caso di chiedere un IP DEDICATO e se poi effettivamente diventa dedicato. (ho fatto una prova su un dominio che avrebbe dovuto avere un ip dedicato e ho scoperto che condivideva l'indirizzo con altri 43 domini). Inoltre ho letto di servizi di gestione DNS protetti che evitano attacchi di hacker e proteggono la privacy dei dati che i visitatori immetto no sul sito. E' consigliabile utilizzare questo strumento? Sicurezza: anche su questo, molti provider sostengono che sia FONDAMENTALE utilizzare dei certificati SSL o sistemi come SITELOCK....è opportuno? In che casi? spero di avere chiarimenti
  3. Ciao amici, gradirei un vostro parere: è consigliabile utilizzare la gestione automatica degli upgrade di sicurezza tramite "unattended-upgrades" in un sistema Debian Jessie con web server (Apache2) e email server (Postfix)? Qualcuno tra di voi ha mai registrato problematiche successive all'aggiornamento di soli pacchetti di sicurezza? grazie infinite
  4. Ciao a tutti, Mi sono registrato per avere un parere terzo su un provider italiano, conosciuto tramite questo sito, che mi ha deluso. Siccome so di poter sbagliare (non necessariamente tutta la colpa è del provider, non per forza ho ragione io) vorrei chiedere lumi a altri utenti per poter vedere la situazione da altri punti di vista. Ho ordinato una vps managed, con pannello plesk. Effettuo il login nel pannello e mi se presenta il warning del certificato auto-firmato. Siccome uso firefox e l'estensione certificate patrol, accetto il certificato che mi viene memorizzato e contemporaneamente chiedo al provider se mi invia l'impronta del certificato (md5 e sha1) in modo da poter verificare che quel certificato era autentico. Per tutta risposta il provider mi invia tramite mail non cifrata la chiave pubblica e ***privata*** del certificato. Immagino non ci sia bisogno di spiegare perché questo rappresenti un problema di sicurezza. Senza considerare che da informatico ho studiato questa roba, compresi i processi matematici che ci sono dietro. Dopotutto la chiave privata è privata perché deve garantire l'autenticità del server. Se diventa pubblicamente disponibile chiunque può spacciarsi per il server. Abitualmente compro i certificati da gandi.net, gli faccio la domanda stupida chiedendo se sia opportuno inviarmi per mail la chiave privata e loro mi rispondono Per non parlare della documentazione relativa ai certificati What is SSL and what are Certificates? La tesi del provider è che PLESK usa LO STESSO certificato in ogni installazione e quindi quel certificato non offre nessun tipo di sicurezza. La mia tesi è che ogni installazione di PLESK genera un certificato diverso, che dal punto di vista tecnologico da le stesse garanzie di uno commerciale a parte che non è già presente nel browser, quindi ho avuto bisogno di qualche altra informazione per stabilirne l'autenticità (sha1). Di certo compromettere la chiave privata non è una buona pratica di sicurezza. Scusate se non sono stato breve, ma non volevo fare la parte di chi dice di aver sempre ragione e se mi fate capire che sbaglio sono pronto ad ammetterlo, ma non voglio essere trattato dal mio provider come se fossi un'impreparato a cui si possono raccontare favole. Vi ringrazio per l'aiuto a capirne di più
  5. Sicurezza server dedicato anche attraverso IPtables: una raccolta di suggerimenti e guide per iniziare a muovere i primi passi sul firewall di Linux e per imparare a proteggere un server dedicato da eventuali attacchi Continua a leggere, clicca qui.
  6. Data center e sicurezza in un viaggio attraverso gli impianti che trasformano un semplice capannone in un luogo adatto ad accogliere Internet Continua a leggere, clicca qui.
  7. Sicurezza data center secondo Yahoo!: così cambieranno i servizi del noto provider per garantire privacy e tutela agli utenti e ai loro dati Continua a leggere, clicca qui.
  8. Cloud computing e scarsa accortezza: questi due elementi quando si incontrano creano casi di vulnerabilità come quello che ha colpito MongoHQ Continua a leggere, clicca qui.
  9. L'UE vuole facilitare l'adozione delle soluzioni di cloud computing da parte delle aziende, rendendo più chiare e comprensibili le condizioni contrattuali proposte dai fornitori, tutelando i cittadini e ponendosi come garante della sicurezza e della privacy dei dati memorizzati... Continua a leggere, clicca qui.
  10. La National Security Agency americana sfrutterebbe la mancata criptazione delle missive elettroniche per poterne carpire i contenuti, acquisendo i dati proprio lungo il percorso in cui risultano più vulnerabili e meno protetti, ossia lungo i trasferimenti da server a server Continua a leggere, clicca qui.
  11. Suhosin è in un buona sostanza una raccolta di Patch, per migliorare la sicurezza di PHP. Col passare delle versioni, molte di queste patch sono state incluse direttamente nel core di PHP, il quale pian piano ha sempre migliorato la sicurezza nativa, e tra poco giungerà al prossimo step, PHP5.5. Secondo voi è ancora utile utilizzare le patch suhosin? O possiamo ritenere che PHP abbia ormai raggiuntu una maturità tale, da poter essere sicuro da solo?
  12. I provider di servizi Cloud si sono diffusi in tutto il mondo, però possiamo notare due modelli di offerta. Quello anglosassone, fatto di risorse e prestazioni molto "generiche" e banda a consumo per GB. Poi quello "italiano", che tende a fornire più certezza di prestazioni, ma soprattutto un modello di tariffazione della banda più flat o in stock a basso prezzo. Detto in termini semplici, la cloud italiana è un pò più smussata, evitando di esporre il cliente a spese eccessive impreviste. Da parte mia, io vedo l'approccio italiano ben più efficace e sicuro. Come sottilineavo in un topic qualche tempo fà, nutro perplessità nel porre un servizio sul cloud di amazon o rackspace, visto che a causa di un attacco, votato a sprecare banda (considerando che il client utilizzerebbe la banda di download che è elevata anche per gli utenti di casa) si potrebbero generare enormi costi indesiderati (reso possibile dal fatto che entrambi i provider non consentono un limite di budget). Il cloud italiano, con tariffazioni flat come Aruba, CloudUp, e anche Seeweb e Seflow(che sono a consumo, ma con una tariffa molto bassa... a contrasto di chi dice che in italia la banda costa di più :D), mi fà stare ben più tranquillo di mantenere i costi sotto controllo. È un modello secondo me esportabile e da esportate. Voi che ne pensate?
  13. Quando si è ospitati in ambienti shared, sia hosting, dove si condivide la stessa macchina, o magari in ambito di server dedicati, dove si tiene il proprio server in un area condivisa, i nostri dati sono esposti a terzi. Questo non è sicuramente un problema per il sito di un privato, che nella maggior parte dei casi non conterrà nulla di tanto importante. Tuttavia molte volte alcuni utenti, mostrano diffidenza verso il proprio provider e i propri fornitori. Inoltre dobbiamo tener conto che lo "spionaggio industriale", non è una leggenda legata a qualche film, ma talvolta un problema reale... Infatti per quante garanzie si possano dare, le parole possono non corrispondere ai fatti e i disonosti esistono sempre. Quali sono i metodi più efficaci per proteggere i propri dati da fornitori disonesti? (Oltre a mettersi il server in un bunker di proprietà :D)
  14. Più di 90.000 IP facenti parte di una botnet che ormai da giorni continua a bombardare le installazioni Wordpress di tutto il mondo: i Wordpress compromessi sono un bersaglio facile, e spesso vengono utilizzati per creare nuove botnet da utilizzare per attaccare altri siti web. I provider di tutto il mondo, da ResellerClub a GoDaddy, si trovano in queste ore a dovere fare i conti con attacchi c... Continua a leggere, clicca qui.
  15. Umbrella è il nome del nuovo software di casa OpenDNS che permette alle grandi compagnie di proteggere le loro reti aziendali. In poco tempo i clienti sono passati da 3500 a 7000, e ora OpenDNS guarda alla raccolta di nuovi finanziamenti per espandere il proprio business. Nell'era del cloud computing, assicurare la sicurezza delle proprie reti, anche tramite controllo e gestione dei DNS, è un bu... Continua a leggere, clicca qui.
  16. A Dell World la compagnia ha annunciato che oggi sono sempre di più i clienti in tutto il mondo che si affidano ai servizi ed alle soluzioni tecnologiche Dell, da quando la compagnia ha cominciato la... Continua a leggere, clicca qui.
  17. Il terreno ormai affollato del cloud storage vede entrare un nuovo concorrente di tutto rispetto, dal momento che la compagnia Symantec ha lanciato il suo nuovo prodotto di storage Norton Zonecloud. L... Continua a leggere, clicca qui.
  18. Un gruppo di scienziati ha messo a punto un meccanismo basato su browser che gli consente di eseguire calcoli molto pesanti su servizi cloud gratuitamente, e a valle di tale esperimento i ricercatori ... Continua a leggere, clicca qui.
  19. A molte persone piace usare Dropbox, il popolare servizio di cloud storage con client desktop, ma sono in pochi a preoccuparsi di mettere in sicurezza i loro dati presenti su Dropbox, e d'altro canto ... Continua a leggere, clicca qui.
  20. Facebook ha iniziato a criptare tutte le connessioni dei suoi utenti nord americani di default la scorsa settimana, come punto di partenza di un piano per passare le connessioni di tutta la sua utenza... Continua a leggere, clicca qui.
  21. Le botnet, reti di computer e server infettate da malware o progettate per eseguire attacchi informatici fraudolenti, sono motori fortemente sofisticati di calcolo. I creatori di botnet possono ora ve... Continua a leggere, clicca qui.
  22. Gli esperti di sicurezza Florian Ledoux e Nicolas Ruff del dipartimento IT di EADS hanno puntato il loro occhio critico verso il servizio di cloud storage Dropbox e recentemente hanno presentato i ris... Continua a leggere, clicca qui.
  23. Il 15 ottobre McAfee ha annunciato una soluzione composta da quattro nuove Suite, tutte incluse nel nome di*Data Center Security,*progettate per offrire una combinazione di sicurezza per ambienti fi... Continua a leggere, clicca qui.
  24. Questa la scoperta di Alessio Cecchi, che in un post all'interno del blog della sua compagnia spiega come grazie alla segnalazione di un cliente si sia accorto che i server di Difesa.it, sito web utilizzato dal ministero della Difesa italiano, stiano inviando spam e siano quindi stati compromessi, probabilmente all'insaputa completa dei suoi amministratori di sistema. ... Continua a leggere, clicca qui.
  25. Una VPN (Virtual Private Network) è una rete di telecomunicazioni privata, instaurata tra soggetti che utilizzano un sistema di trasmissione pubblico e condiviso nate con lo scopo di offrire alle aziende le stesse possibilità delle linee private in affitto a un costo inferiore sfruttando reti condivise pubbliche. Le VPN sono una conseguenza logica dell'esigenza di connessione tra le sedi remote di un'azienda e l'aumento costante del lavoro in mobilità. ... Continua a leggere, clicca qui.
×