server di registrazione compromesso (IptabLes e IptabLex)

Non dovresti mai lasciare Elasticsearch aperto al mondo, nello stesso modo in cui non lascerai nessun server database aperto al mondo. Metti sempre un proxy di fronte ad esso e usa (almeno) l'autenticazione HTTP. Preferibilmente, il tuo proxy dovrebbe limitare ciò che può essere fatto dall'esterno, ad esempio solo consentendo le richieste GET, altrimenti qualsiasi utente potrebbe cancellare tutti i tuoi dati o spegnere i tuoi server.

Dalla versione 1.2.0 in poi, lo scripting dinamico (passando uno script come parte di una richiesta di ricerca) è stato disabilitato per impostazione predefinita. Nelle versioni precedenti è abilitato per impostazione predefinita, il che significa che qualsiasi utente esterno può fare qualsiasi cosa sul tuo server che l'utente di Elasticsearch può fare.

Se stai utilizzando una versione precedente, desideri aggiungerla al tuo config/elasticsearch.yaml :

script.disable_dynamic: true

Vedi link per ulteriori informazioni e link

@Justin Ho lo stesso problema. Ho un server di monitoraggio in DigitalOcean che usa anche ElasticSearch.

Penso che il problema non sia in ssh perché il mio server utilizza le chiavi e nessuna autenticazione con password e login disabilitato per gli utenti root.

Alcuni utenti DO hanno avuto lo stesso problema con ElasticSearch: link

EIDT: Ecco la soluzione su come pulirlo link ma non risolve il problema in un futuro

Ho avuto lo stesso problema (IpTablex trojan) su una casella di Debian 7 con solo ssh aperto tramite connessione DSL. Gestiva solo un server di database postgresql che ascoltava solo le connessioni interne. La causa altamente probabile era una password di root debole, il login root ssh era aperto. L'unica altra causa potrebbe essere una macchina Windows compromessa utilizzata per l'accesso alla macchina con ssh, ma non abbiamo visto nessun'altra macchina infetta dove sono stati usati i computer Windows.

L'unica buona soluzione è capire la causa dell'infezione, eseguire il backup dei dati importanti e reinstallare l'intero sistema e correggere la causa dell'infezione. Gli script che rimuovono solo / boot / IpTablex e i relativi file non sono una soluzione in quanto non garantiscono che nessun altro rootkit sia rimasto da qualche altra parte nel sistema e non risolve la causa dell'infezione.

Bene, immediatamente, vedo un grosso difetto nella tua postura di sicurezza:

➜  ~  iptables -L Chain INPUT (policy ACCEPT) 
target     prot opt   source    destination
ACCEPT     all  --    anywhere  anywhere

La tua prima regola su INPUT è accettare qualsiasi connessione in entrata su qualsiasi porta ... quindi il tuo respingere tutto alla fine (e in effetti nessuna delle tue altre regole INPUT) è importante ....

Quindi qualsiasi tuo servizio di esecuzione / ascolto sul server avrebbe potuto essere preso di mira, solo FYI.

[ EDIT ] Vedi la prova di seguito

Script started on Sun 27 Jul 2014 11:32:04 AM EDT
]0;nick@fakeit:/tmp[?1034h[nick@fakeit tmp]$ sudo iptables -L
[sudo] password for nick: 
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
The authenticity of host '172.16.16.110 (172.16.16.110)' can't be established.
RSA key fingerprint is fc:86:c7:f6:1a:31:5b:9b:4d:a7:85:ca:7c:f2:29:ec.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.16.110' (RSA) to the list of known hosts.

[email protected]'s password: 
Last login: Sun Jul 27 11:30:55 2014 from localhost

]0;iptables_demo@fakeit:~[?1034h[iptables_demo@fakeit ~]$ echo "I got in with a default INPUT policy of DROP, an explict DROP ALL at the end, but an ACCEPT ALL rule at the beginning"
I got in with a default INPUT policy of DROP, an explict DROP ALL at the end, but an ACCEPT ALL rule at the beginning
]0;iptables_demo@fakeit:~[iptables_demo@fakeit ~]$ exit
logout
Connection to 172.16.16.110 closed.


]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
[email protected]'s password: 
Last login: Sun Jul 27 11:32:52 2014 from 172.16.16.110

]0;iptables_demo@fakeit:~[?1034h[iptables_demo@fakeit ~]$ echo "I got in with an ACCEPT ALL as the first rule, an ACCEPT HTTP as the second rule, and a DROP ALL as the end rule with a default policy of DROP"
I got in with an ACCEPT ALL as the first rule, an ACCEPT HTTP as the second rule, and a DROP ALL as the end rule with a default policy of DROP
]0;iptables_demo@fakeit:~[iptables_demo@fakeit ~]$ exit
logout
Connection to 172.16.16.110 closed.


]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
ssh: connect to host 172.16.16.110 port 22: Connection timed out

]0;nick@fakeit:/tmp[nick@fakeit tmp]$ echo "I was unable to connect when the only ACCEPT rule was for HTTP and a default DROP policy and an explicit DROP rule"
I was unable to connect when the only ACCEPT rule was for HTTP and a default DROP policy and an explicit DROP rule



]0;nick@fakeit:/tmp[nick@fakeit tmp]$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ ssh [email protected]
ssh: connect to host 172.16.16.110 port 22: Connection timed out

]0;nick@fakeit:/tmp[nick@fakeit tmp]$ echo "I was unable to connect with the only ACCEPT rule being HTTP and a default ACCEPT policy but an explicit DROP rule at the end of the INPUT filter"
I was unable to connect with the only ACCEPT rule being HTTP and a default ACCEPT policy but an explicit DROP rule at the end of the INPUT filter
]0;nick@fakeit:/tmp[nick@fakeit tmp]$ exit



Script done on Sun 27 Jul 2014 11:38:54 AM EDT