I log di Port Knock suggeriscono che la macchina è stata compromessa?

Question

I log di Port Knock suggeriscono che la macchina è stata compromessa?

#1 da (1 voti)

2

Sulla mia macchina CentOS, tutte le mie porte sono filtrate con la regola Iptables:

DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

Quindi da Internet, ogni timeout della porta.

L'unico modo per ssh nella macchina, è di fare una sequenza Port Knock come segue:

6        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 53853 recent: SET name: KNOCK1 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "ssh port knocking 1 "
7        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 6663 recent: CHECK seconds: 15 name: KNOCK1 side: source mask: 255.255.255.255 recent: SET name: KNOCK2 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 2 "
8        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 96563 recent: CHECK seconds: 15 name: KNOCK2 side: source mask: 255.255.255.255 recent: SET name: KNOCK3 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 3 "
9        x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 77799 recent: CHECK seconds: 15 name: KNOCK3 side: source mask: 255.255.255.255 recent: SET name: KNOCK4 side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 4 "
10       x   x LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example 12263 recent: CHECK seconds: 15 name: KNOCK4 side: source mask: 255.255.255.255 recent: SET name: OPEN_SESAME side: source mask: 255.255.255.255 limit: avg 5/min burst 5 LOG flags 0 level 6 prefix "ssh port knocking 5 "
11       x   x ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:example SSH REAL PORT state NEW,RELATED,ESTABLISHED recent: CHECK seconds: 15 name: OPEN_SESAME side: source mask: 255.255.255.255 
12       x   x ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Ora controllando i log, ogni volta che cambio la sequenza delle porte, trovo nel diario di journalctl che un tentativo di quella specifica porta di esempio knock 1, knock 2 ... etc è stato fatto.

kernel: ssh port knocking 1 IN=eth0 OUT= MAC=example MAC SRC=Attacker IP, always the same DST=My IP LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=xxxx DF PROTO=TCP SPT=source DPT=**ANY SEQUENCE I CHOOSE** WINDOW=29200 RES=0x00 SYN

Non ci sono log per nessun'altra porta, né alcun altro probe di qualsiasi tipo.

È come se l'attaccante conoscesse la sequenza ogni volta che la cambio.

Poiché non c'è assolutamente nessun altro log per nessun altro tentativo, e il monitoraggio di tcpdump mostra che nessun probe è stato eseguito, è sicuro assumere che l'hacker conosce la sequenza perché la macchina è compromessa e ottiene il informazioni ogni volta che lo cambio?

attacks system-compromise ports scan

posta Jonas 08.07.2018 - 00:46

fonte

1 risposta

Leggi altre domande sui tag attacks system-compromise ports scan

Identifica l'utente di un telefono cellulare anonimo dai partecipanti alla rete TLS 1.2 Messaggio mancante mancante

score 1 · Answer 1

La tua idea di bussare alla porta funziona fondamentalmente avanzando da uno stadio di bussare alla successiva ogni volta che lo stesso client IP invia un pacchetto TCP alla porta segreta del nuovo stadio entro 15 secondi dall'ultima fase.

Tieni presente che non prevede penalità per ipotesi errate e che non prevede limiti di velocità per le ipotesi (il limite di avg 5/min si applica solo alle ipotesi corrette). Ciò significa che tutto ciò che un utente malintenzionato deve compiere per passare da uno stadio all'altro è quello di eseguire la scansione di tutte le porte della macchina entro 15 secondi, un'attività che può essere facilmente raggiunta quando si utilizzano socket raw (ovvero non si attende l'handshake TCP per completo).

is it safe to assume the attacker knows the sequence because the machine is compromised and he gets the information everytime I change it?

Sulla base delle informazioni che hai fornito fino ad ora, non si può pretendere questo. Ti suggerisco di cercare tentativi di autenticazione falliti o riusciti da questo specifico indirizzo IP per vedere se qualcuno ha effettivamente provato a effettuare il login (e forse ci è riuscito) invece di fare solo la scansione delle porte e solo per sbaglio ha innescato le tue regole sulla porta. Inoltre, se la macchina è realmente e profondamente compromessa, non dovresti fidarti dei tuoi registri locali poiché l'autore dell'attacco potrebbe averli modificati.

A parte questo:

There are no logs for any other port, nor any other probe whatsoever

In base alle regole mostrate di registrare solo se la porta corrisponde, cioè non ci sono altri log previsti.