Qual è il possibile^null $ exploit segnalato da LogWatch?

LogWatch è uno strumento piacevole che fornisce report giornalieri sui file di log di Linux. Include diversi riepiloghi di informazioni, come il traffico, gli utenti che hanno effettuato il log in, i motori di ricerca che hanno analizzato il tuo apache, ecc ...

Una sezione include gli indirizzi IP che hanno utilizzato gli exploit noti tentano di hackerare il tuo server. Non hanno necessariamente avuto successo, ma sono comunque elencati nella relazione per conoscenza. Questo è quello che sembra.

Attempts to use known hacks by 4 hosts were logged 4 time(s) from: 
    187.13.156.179: 1 Time(s) 
     ^null$ 1 Time(s) 
    187.60.121.62: 1 Time(s) 
     ^null$ 1 Time(s) 
    189.123.240.18: 1 Time(s) 
     ^null$ 1 Time(s) 
    189.70.214.124: 1 Time(s) 
     ^null$ 1 Time(s)

La mia domanda è che cosa è esattamente questo ^null$ attacco? Ho provato a cercarlo su google, ma non sembra che sia rilevante.

fonte

2013-04-06 JulioHM

Hai già capito? Sto avendo lo stesso problema. Sto avendo più di 200 tentativi ogni giorno. Notato questo dopo ho installato Logwatch. Ho anche installato fail2ban e il mio ssh è anche su una porta casuale. Non trovo da nessuna parte che tipo di attacco sia. Si prega di aiutare – Yashvit

Non ancora. Ho [postato una domanda sul loro forum di aiuto] (http://sourceforge.net/projects/logwatch/forums/forum/1115929/topic/8164121), ma nessuno ha dato alcuna risposta ad esso. Sto ancora aspettando – JulioHM

^significherebbe l'inizio della riga e $ significherebbe la fine della riga se stiamo parlando di un'espressione regolare. Forse significa che l'autore dell'attacco sta inviando solo 1 carattere null singolo. In che registro si trova questo? Ti dice da quale servizio è stato attivato? – cogsmos

Questo di solito non è qualcosa di cui preoccuparsi, non è necessariamente un attacco reale. L'attacco "^null$" è semplicemente una connessione client che termina senza inviare alcuna richiesta HTTP (ad esempio, una connessione viene stabilita sul server Web, ma non viene ricevuta alcuna richiesta).

Se sul server si sono verificati più tentativi da un singolo IP o più voci ^null$ per IP, è possibile che vi siano prove di un tentativo concertato. Così com'è, ti suggerirei di poter tranquillamente ignorare il log di esempio che hai fornito sopra.

fonte

2013-05-17 07:38:55

Sarebbe lo stesso un syn sweep? Potrebbe essere testato facilmente con netcat: nc -zvw5 hostname 80 – cogsmos

Un syn sweep potrebbe essere responsabile per l'avviso, ma non è l'unica spiegazione. Se questo è un problema, suggerirei di installare un sistema di rilevamento delle intrusioni più completo; questo probabilmente catturerebbe un appropriato sweep syn, oltre a essere in grado di rilevare le azioni successive intraprese contro il server. –

Mi stavo chiedendo solo per la mia curiosità. In tal caso, il comando netcat che ho fornito emetterebbe quel messaggio di registro. – cogsmos

E 'interessante notare che Heartbleed sondaggio si traduce in tali avvertimenti da LogWatch:

Attempts to use known hacks by 1 hosts were logged 1 time(s) from: 54.82.203.167: 1 Time(s) ^null$ 1 Time(s)

La voce di registro Apache SSL corrispondente è:

XXXXXX:443 54.82.203.167 - - [10/Apr/2014:00:19:45 +0200] "quit" 301 1313 "-" "-"

(usando http://filippo.io/Heartbleed/)

fonte

2014-04-11 00:41:15 2072

Diversi tipi di monito i servizi di suoneria faranno anche questo; per esempio uptimerobot.com:

I tentativi di utilizzare hack conosciuti da 10 host stati registrati 107 tempo (s) da: 74.86.158.106: 91 Tempo (s) ^ nullo $ 91 Tempo (s)

74.86.158.106 - - [09/Feb/2015: 01: 09: 54 -0500] "GET/HTTP/1.1" 200 17896 "-" "Mozilla/5.0 + (compatibile, UptimeRobot/2.0; http://www.uptimerobot.com/)"

74.86.158.106 - - [09/Feb/2015: 01: 10: 47 -0500] "HEAD/HTTP/1.1" 200 - "-" "Mozilla/5.0 + (compatibile; UptimeRobot/2.0; http://www.uptimerobot.com/)"

Cert anche i tipi di applicazioni di failover potrebbero impostarlo come heartbeat e ldirectord (a seconda della loro configurazione).

fonte

2015-02-09 20:28:09

Qual è il possibile^null $ exploit segnalato da LogWatch?

risposta

Problemi correlati