La Eos Net srl

Augura un Buon Natale
e
Felice Anno Nuovo

Ringraziamo tutti i clienti per la gradita collaborazione che ci hanno voluto fonire nel 2011, anno in cui ci ha visto crescere moltissimo soprattutto come punto di riferimento per la registrazione dei domini .it

Sperando che il 2012 possa a VOI e a noi portare nuovi successi
UN GRANDE AUGURIO AL NOSTRO MASSIMO che finalmente stà migliorando…AUGURI MASSIMO!

Lo Staff

Comunicazione:
il 23/30 dicembre il supporto telefonico avrà i seguenti orari 09.15 – 12.15
Non subiranno modifiche di orario altre tipologie di supporto

Vi informiamo che, ancora una volta, ci giungono numerose segnalazioni di utenti che hanno ricevuto lettere da un sedicente “Registro italiano in Internet per le imprese” tramite le quali si chiede, apparentemente, la verifica dei dati relativi alla propria attivita’: i moduli sono in realta’ una proposta di contratto per adesione per la fornitura di un servizio a pagamento.

L’Istituto di Informatica e Telematica del Cnr che gestisce il Registro .it e’ del tutto estraneo a tale iniziativa e avviera’, ancora una volta, le azioni necessarie per la tutela dell’eventuale diritto leso.

L’Autorita’ garante della concorrenza e del mercato (http://www.agcm.it) ha piu’ volte sanzionato analoghe iniziative in quanto fattispecie di pubblicita’ ingannevole.

ES:

il registrante non può recuperare per nessun motivo via email l’auth info (email dismessa o non memorizzata o disabilitata)
il registrante non può per un qualche motivo modificare la email dove poter ricevere l’auth info
il registrante non può leggere nell’area clienti l’uathinfo

SEGUIRE LE ISTRUZIONI
inviarci via email o via fax (preferibile via email con allegato file pdf firmato)  la presente richiesta

OGGETTO: richiesta auth info

Io sottoscritto ……………… codice fiscale ……….. nato a ………….
il ………………, responsabile del dominio …………………..,
responsabile legale della ditta ………………………………….
con cod. fiscale /p.iva …………………………………………
sono a richiedere AUTHINFO per il su indicato dominio e si prega comunicarlo via
MAIL ………………
o
FAX ……………….

In FEDE
NOME COGNOME

ALLEGARE documento Identità del firmatario

Creare account ftp aggiuntivo CPANEL

3)scegliere il nome login, la password, il nome della directory dove questo account ftp può caricare e scaricare files e impostare una quota in MB massimi di uplodad

4) cliccare Crea

L’utente potrà entrare in ftp inserendo come
host= nome dominio
login: nome_scelto@nomedominio
psw:psw
fine

La Eos Net srl

Augura un Buon Natale
e
Felice Anno Nuovo

Ringraziamo tutti i clienti per la gradita collaborazione che ci hanno voluto fonire nel 2010, anno in cui ci ha visto crescere moltissimo soprattutto come punto di riferimento per la registrazione dei domini .it
Oramai è passato un anno dal passaggio di gestione e dobbiamo ritenenerci soddisfatti soprattutto per l’uptime dei nuovi server (99.98)  di quest’ anno e per i positivi feedback ricevuti dai clienti soddisfatti del ns operato.
Sicuramente l’anno del 2010 iniziò con molti disagi causati dal trasferimento dei siti sui ns server.
Purtroppo alcuni non han saputo apprezzare il ns sforzo e ciò che è stato fatto, soprattutto,  per i loro siti/dati/domini, ma ciò non toglie che la stragrande maggioranza ci ha supportato e aiutato nel difficile lavoro di quei duri mesi di inizio anno.

GRAZIE ANCORA!

Sperando che il 2011 possa a VOI e a noi portare nuovi successi

Lo Staff Eos Net srl

Comunicazione:
dal 22/12/2010 al 28/12/2010 il supporto telefonico avrà i seguenti orari
09.15 – 12.15
14.15 – 15.30

Dopo un lungo travaglio, una dura lotta morale interna, abbiamo deciso di accontentare i clienti che spesso chiamavano e ci contattavano per chiedere come attivare la PEC (posta elettronica certificata).

Da oggi grazie alla partnership con PEC.it possiamo offrire la PEC per il Vostro dominio.

Come è nostro “uso e costume” non ci vogliamo nascondere dietro una non idonea pubblicità facendo finta di essere noi i diretti venditori di questo servizio visto che solo pochi Gestori possono vantare il titolo di Certificatore PEC.
A chiare lettere lo indichiamo su questo blog…. rivenditamo il servizio di PEC.it. Beati gli altri che hanno il coraggio di non dirlo:)
Questa decisione è nata più per semplificare la vita ai nostri clienti che entrare in un filone di mercato che ci interessa poco visto che non siamo certificatori PEC come il la grande maggiornza di coloro che la offrono sui loro siti.

E’ possibile attivare la PEC con 3 soluzioni

1) utilizzare il ns dominio @eos-pec.it > (attivazione in pochi minuti)

2) chiedere la certificazione di un proprio dominio (email@nomedominio.it) > certifcazione in 24/48 ore

3) chiedere la certificazione di un proprio dominio di terzo livello (email@pec.nomeodminio.it) > certifcazione in 24/48 ore

Il ns consiglio è di attivare caselle di posta su dominio di terzo livello per un semplice fatto, dedicare la PEC a determinati indirizzi di posta senza intaccare in nessun modo la funzionalità di caselle di posta già esistenti sul dominio di secondo livello.

Esempio pratico

Ho un dominio con 5 caselle di posta già funzionanti col metodo tradizionale.
Desidero certificare il dominio. Nel momento in cui decido di certificare il dominio le caselle di posta cesseranno di funzionare e per poterle far funzionare sarà necessario chiedere la certificazione anche per queste 5 caselle che erano funzionanti.
Ogni email che vorrò creare successivamente per questo dominio, dovrò per forza farle certificare.
Dal momento della certificazione queste email non saranno più funzionanti sui ns server, non saranno più gestibili dal ns webmail, ma si dovrà utilizzare
una diversa impostazione sul proprio client di posta.

Quanto su indicato potrebbe essere semplificato se il dominio su cui si far attivare la cetificazione è un nuovo dominio, ma se è un dominio già esistente, potrei crearmi dei problemi importanti. Se su quel dominio ho 50/80 caselle di posta aziendali, il danno che vado a crearmi sarà “interessante”.

Consiglio, come da punto 3.
Chiedere l’attivazione di un dominio di terzo livello( esempio pec . dominio . it) e chiedere la certificazione su dominio di terzo livello.
In questo modo non intaccherò il funzionamento delle caselle di posta già attive e soprattutto non sarò limitato nel creare caselle di posta sul dominio
principale.
In questo modo la spesa sarà limitata, il danno sarà inesistente.

Vi sono anche siti italiani dove tramite forum questi “Bravi Ragazzi” notificano il loro operato. Lo notificano se pur precisano che non lo fanno a scopo lamer ma scopo didattico.

Fino a qualche tempo fà (2004-2005) i siti defacciati erano qualche migliaio al giorno poi, grazie ad alcune sicurezze
implementate sui server e lo studio approfondito delle problematiche dei popolarissimi CMS, hanno fatto in modo che
il numero dei siti crakkati diminuisse…….però di poco

Solo oggi son stati notificati 2800 defacciamenti e negli ultimi 16gg circa 68000.

Questo mini articolo non vuol essere nè una guida, nè un memorandum di cosa è la sicurezza vuol solo dare alcune piccole informazioni
su cosa accade nel web…una sorta di faq.

Uno dei metodi più utilizzati per defacciare i siti è l’uso di espressioni/link inserite nelle url sfruttando i bug dei più noti CMS.
Molte volte non vengono usati i bug del cms stesso bensì i bug presenti nei plugin dei medesimi CMS, quei plugin utilissimi ma allo stesso modo delicati.

Il metodo molto utilizzato per protegger, in parte, i siti dei clienti da questi tentativi è il mod_security.
Senza entrare nel tecnico cerchiamo di spiegare in modo molto semplice come funziona il mod_security.
Utente apre un link, aggiunge nel medesimo qualche bella parolina chiave oppure inserisce un post in un forum sempre con certe paroline oppure, il più classico, apre il link del sito aggiungendo un link ad un file esterno utile per iniziare il lavoro.
A questo punto il mod_security và a cercare all’interno di files ben precisi installati sul server, se le stringhe richiamate sono simili ai tentativi di defacciamento .
Se nel link, nel post, nell’url esterna, trova conformità con le regole, apache restituisce un errore 403 o 406 limitando poi l’accesso al server dall’ip che stà “tentando” di defacciare il sito

Questi file richiamati dal mod_security sono fatti da centinaia di stringhe studiate nel corso degli anni da “GURU” del settore, i quali
studiano i defacciamenti, studiano gli script e poi mandano in aggiornamento i files con le loro stringhe, stringhe complicate da interpretare.

Problemi: gestendo qualche area admin del sito, scrivendo su un forum, può capitare che si riscontrino falsi positivi scontrandosi con errori 403 e 406.
All’apparire degli errori si pensa subito che il server non funziona, che vi sia qualche errore di configurazione, che si stà perdendo tempo per errori dell’hoster.
I falsi positivi possono nascere per un plugin non aggiornato e non ancora conforme alle nuove regole di sicurezza, per esagerata sicurezza di una stringa o anche “errore”
di chi ha creato le stringhe di sicurezza del mod_sec.
Sicuramente questi noiosi errori, falsi positivi, creano perdita di tempo, problemi temporanei di blocco lavoro…..tutti ne sono a conoscenza.
La perdita di tempo è anche da parte dell’hoster in quanto deve prodigarsi a sbannare gli ip, cercare la regola che ha creato il problema, segnalare la regola a chi di competenza…. ..Pensiamo però ad una cosa:
se fosse il “Bravo Ragazzo” a cercar realmente di entrare nel sito e sul medesimo non vi è quella sicurezza (stringa)?
Quali problemi si avrebbero? Il tempo perso al ripristino quanto sarebbe? e la perdita di immagine del sito a seguito del defacciamento?.
Regole noiose ma utili? Forse utilissime anche se non in grado di bloccare del tutto i problemi di defacciamento.

Quando accade un errore 403 o 406 non continuamo a provare a inserire l’articolo o il post. Contattate l’hoster chiedendo quale regola fà “esplodere” l’errore
e nel mentre che attendiamo la risposta dell’hoster, andiamo sul sito del plugin o del cms a cercare se vi è un aggiornamento e se qualcuno ha avuto i soliti problemi con
il mod_security.
A volte può bastare un aggiornamento, la modifica di una stringa dello script e il gioco è fatto senza dover richiedere l’inibizione della regola sito.
La cancellazione di quella regola di sicurezza sul dominio è utile per lavorare ma utile anche ad aprire una porta verso il possibile “bravo ragazzo”

Giornalmente sui ns server blocchiamo circa 800 tentativi (media) di accesso non consono su url.

Il valore varia molto in base alla popolarità dei siti presenti su un server e la quantità di CMS presenti sul medesimo.
Altro fattore è la longevità del CMS presenti.

Sicuramente alcuni di questi accessi sono falsi positivi. In base a segnalazione dei clienti circa 5/10 al giorno sono “falsi positivi”.
In questi giorni, in cui abbiamo disabilitato ad un sito alcune stringhe di sicurezza per dar modo di aggiornare lo script,
abbiamo ricevuto questa domanda: ma non è possibile avere CMS+sicurezza+funzionalità?
Non è semplice rispondere. Proviamo anche se l’esempio è un pò banale.
“Pensiamo ad un server.”
Per poter sfruttare un server al 100% senza problemi quale è l’unico modo? Togliere il firewall e le sicurezze.
In questo modo non si avranno problemi di numero invio email, di sbagliare 100 volte password, di mettere password a 2 cifre, di inviare email senza autenticazione,
di venir bannati se faccio degli scan, etc, etc. Sicuramente si potrebbero fare altri esempi più concreti ma anche questo esempio banale aiuta a capire che
per lavorare con un minimo di sicurezza si deve usare gli strumenti che la rete ci mette a disposizione, soprattutto regole che sono studiate appositamente
sui defacciamenti di siti altrui.

NB: ovviamente non tutte le regole sono create e inviate in tempo reale. Come per ogni problema, la soluzione viene fuori sempre dopo che è stato riscontrato il BUG, pertanto non affidateVi solo a queste regole lato server, ma cercate anche Voi, gestori di CMS e non CMS, di tenere sempre aggiornato lo script, limitare accessi in aree riservate, cambiare spesso password di amministrazione, inserire password importanti e non “nomedominio” “nomeblog” “nomepersona”, cercare di modificare il nome dei link alle aree di amministrazione.

Server col SUPHP abilitato. Funzionalità nata per ovviare al problema su indicato, cioè dei chown assegnati ad apache e non all’account ftp.
Grazie al SUPHP i files sono, se pur uplodati via web, modificabili al 100% anche da ftp
Grazie al SUPHP il cliente è autonomo persino con la configurazione del php inserendo un file php.ini nel suo account
A differenza dei server senza il SUPHP, le directory e i files sono in scrittura via web dal proprio account senza dover settare nessun tipo di chmod.
Se i chmod sono diversi da 755 per le dir e 644 per i files, le dir e i files diventano inutilizzabili
Il SUPHp è nato proprio per quei cms come joomla che hanno bisogno di essere gestiti sia via web sia via ftp senza dover chiedere di modificare i chown e i chmod
Se via web un files non è aggiornabile il problema è al 99% il fatto che quella dir o files è a 777 o 666 oppure che in precedenza non vi era il SUPHP e allora quel file ha ancora il chown apache nobody (99)

Qualche consiglio!

Tempo fà avevamo parlato di PEC
pec e una realtà tutta e solo italiana/
evidenziando alcune stranezze sulla medesima a livello legale e burocratico.
Da qualche tempo i blog del settore, gli illuminanti, non stanno più seguendo la vicenda e a breve, da quanto sembra, alcuni dovranno obbligatoriamente decidere come e dove attivare la PEC per il proprio studio professionale.

Quell’articolo era stato concluso con la frase:
Perchè noi non la offriamo?
Perchè per offrirla, come fanno molti ns competitor, dobbiamo attivarci presso un fornitore PEC accreditato e pertanto diventare rivenditori.
Se proprio dovessimo scegliere un fornitore si attiverebbe il contratto presso coloro che sono stati all’avanguardia in questo settore e hanno una
struttura consolidata a livello di PEC..chi sono questi? sono, ahimè..mi dispiace dirlo, quelli di aruba
Purtroppo siamo arrivati al “dunque” e dovendo andare incontro alle esigenze
dei ns clienti, stiamo pensando che fare… E’ dura ingoiare il boccone del rivendere il servizio. Vedremo che fare a anno nuovo.

A titolo informativo
Le possibilità di attivazione sono:

1) attivare caselle di posta su dominio di secondo livello
(email@nomedominio.it)
2) attivare caselle di posta su dominio di terzo livello
(email@pec.nomeodminio.it)

Il ns consiglio è di attivare caselle di posta su dominio di terzo livello per un semplice fatto, dedicare la PEC a determinati indirizzi di posta senza intaccare in nessun modo la funzionalità di caselle di posta già esistenti sul dominio di secondo livello

Esempio pratico

Ho un dominio con 5 caselle di posta già funzionanti col metodo traidzionale.
Desidero certificare il dominio. Nel momento in cui decido di certificare il dominio le caselle di posta cesseranno di funzionare e per poterle far funzionare sarà necessario chiedere la certificazione anche per queste 5.
Ogni email che vorrò creare successivamente per questo dominio, dovrò per forza farle certificare.
Dal momento della certificazione queste email non saranno più funzionanti sui ns server, non saranno più gestibili dal ns webmail, ma si dovrà utilizzare
un secondo webmail, una diversa impostazione sul proprio client di posta.

Quanto su indicato potrebbe essere semplificato se il dominio su cui si far attivare la cetificazione è un nuovo dominio, ma se è un dominio già esistente, potrei crearmi dei problemi importanti. Se su quel dominio ho 50/80 caselle di posta aziendali, il danno che vado a crearmi sarà “interessante”.

Consiglio, come da punto 2.
Chiedere l’attivazione di un dominio di terzo livello( esempio pec . dominio . it) e chiedere la certificazione su dominio di terzo livello.
In questo modo non intaccherò il funzionamento delle caselle di posta già attive e soprattutto non sarò limitato nel creare caselle di posta sul dominio
principale.
In questo modo la spesa sarà limitata, il danno sarà inesistente.
Quando attivo la PEC su (es) pec.dominio. it, dovrò farmi fornire dal certificatore la configurazione named da far inserire sul server dove è presente il dominio principale.
Tutto qui.