Ho appena ricevuto un linode VPS una settimana fa e sono stato contrassegnato per la scansione SSH

Possibile duplicazione:
Il mio server è stato hackato EMERGENCY

Ho un Debian VPS a 32 bit da http://linode.com e non ho realizzato alcun tipo di configuration avanzata per la protezione (port 22; password abilitata).

Sembra in qualche modo che ci sia la scansione di ssh che va dal mio IP, sono stato contrassegnato come questo è contro il TOS. Sono stato SSHing solo dalla mia casa di Comcast ISP che gestisco Linux.

È una cosa comune quando si ottiene un nuovo vps? Esistono consigli di configuration standard di sicurezza? Sono abbastanza confuso riguardo a come la mia macchina è stata accusata di questa scansione di ssh.

  • il nameserver di un dominio è un sottodominio di quel dominio, come?
  • Il nostro VPS viene utilizzato come mulo Warez
  • Come Hacker può accedere ai contenuti VPS CentOS 6?
  • Impostazione del dominio su VPS
  • Come scoprire il tipo di virtualizzazione di un VPS di Linux?
  • Come posso configurare il DNS quando tutto quello che ho è un VPS con un IP statico?
  • 4 Solutions collect form web for “Ho appena ricevuto un linode VPS una settimana fa e sono stato contrassegnato per la scansione SSH”

    Personalmente, sembra che tu sia stato compromesso. Ri-installerei il sistema operativo e riconfigurare SSH con:

    • solo authentication basata su chiave
    • utilizzare AllowUsers o AllowGroups per bloccare gli utenti consentiti sulla casella
    • utilizzare iptables per bloccare gli indirizzi IP consentiti.

    Molti compromessi di sistema sono il risultato di essere sottoposti a scansione e una debole password per essere brutale forzata. Purtroppo questo è diventato parte della vita quotidiana di Internet e occorre proteggere il server da tali attacchi. Ecco una buona guida per iniziare:

    http://library.linode.com/using-linux/security-basics

    Questo ha fissato come un commento sulla risposta di freedom_is_chaos, ma è cresciuto troppo grande …

    @Meder: Altri servizi, come SSHd, mantengono i registri – non solo Apache. Sebbene qualsiasi exploit ben codificato (o uno sfruttamento creato da un buon off-the-shelf-exploit-generator) probabilmente avrà nascosto i suoi brani una volta che entra.

    Una password scarsamente scelta per root o un account che dispone di privilegi sufficienti sudo è il vector di attacco più probabile qui, dato che l'exploit sta facendo molte connessioni SSH (per cercare di diffondersi in altri server in modo identico a quello che ha infettato). Devi arrestare immediatamente la VM. Il più a lungo è più lungo è un problema, causando potenzialmente ulteriori infezioni.

    Se avete dei dati sulla VM che vuoi mantenerlo ancora chiuso immediatamente – non preoccuparti di prendere i backup innanzitutto perché a less che le cose non siano cambiate da quando ho usato l'ultima volta i servizi di Linode è ansible creare un VM fresco, non utilizzato e albind vecchio drive ad esso per tirare i dati fuori. Fai attenzione a non fidarsi di questi dati, specialmente i binari e gli script eseguibili, sebbene – controllate dappertutto quello che utilizzi nel caso in cui sia stato modificato per facilitare gli exploit futuri (non si desidera copiare accidentalmente la nuova VM è stato installato nel vecchio).

    Dai anche alla pagina collegata da tasaro una lettura. Questo sembra un buon riepilogo di come provare a garantire una semplice VM. Se non si può (non può per qualche motivo) utilizzare l'authentication basata su chiave utilizzare alless password forti – non ti preoccupare di essere memorabili, in quanto puoi memorizzarli in qualcosa di simile a keepass invece di ricordarli (assicuratevi solo tenete la tua data di salvataggio in una cassaforte). Mentre uno sfruttamento remoto potrebbe facilmente arrivare a qualcosa come "elephant4" attraverso un dictionary basato guadagno bruto-forza è improbabile colpire su qualcosa come "eGz3nk7aVdN7OIChoPy7". Inoltre, assicurati di utilizzare password diverse per diversi servizi – in questo modo se si riesce a scivolare in qualche modo, comprometterebbe solo un servizio non molti altri.

    La spiegazione più probabile è che il server è stato compromesso.

    Cosa accadrà?

    Una volta ottenuta una nuova image nuova, non dimenticare di disabilitare il login di root tramite SSH. In questo modo, è necessario prima accedere tramite un account utente, quindi elevare a root utilizzando il su . Non regolare alcun regolare account utente sudo privilegi che non ne hanno bisogno.

    È anche una buona idea utilizzare AllowUsers nella configuration SSH per limitare l'accesso SSH a quelli che ne hanno bisogno. Se ansible, assicurati che questi utenti dispongano di password forti in qualche modo.

    Perché reinstallare da zero?

    Se continui a utilizzare lo stesso sistema, non puoi mai essere sicuri di aver rimosso tutte le ultime retro-port che l'attaccante ha installato. Se l'attaccante ha sfruttato una scalata di privilegi bug per get la radice , allora avrebbe potuto anche sostituire i binari di sistema e / o di avvio.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.