Ho un progetto di sito web Django che è in diretta (chiamiamolo esempio.com). È un forum in cui gli utenti possono inviare commenti e rispondere a loro. Ha un database Postgresql e un proxy inverso gunicorn + nginx come server web configurato. Sono ospitato su una macchina virtuale azionata da Azure, con Ubuntu 14.04 lt Debian come sistema operativo. Infine, si noti che l'applicazione Web e il server siedono su due istanze separate della macchina virtuale.
Sospetto che i miei server potrebbero essere compromessi - Sono nella fase di raccolta dei dati in cui sto accertando se (i) i miei server sono effettivamente compromessi (ii) se anche i miei dati sono compromessi (iii) come ha fatto il compromesso capita, in modo da non essere più hackerato.
Nelle applicazioni Django, c'è un file base.html che tutti gli altri file .html ereditano (o extend in Django). Questo file base.html contiene il tag <head> con i meta tag richiesti eccetra, quindi non è necessario replicarlo in ogni file di modello.
Il mio file base.html contiene un codice javascript che non ho scritto . In effetti, non uso affatto javascript nel mio codice. Questo snippet javascript dannoso reindirizza i miei utenti agli annunci pubblicitari (è un trucco per fare soldi). Se accedo al server di produzione della mia applicazione Web e nano al file base.html (ad esempio, aprilo in un editor di testo), i frammenti offensivi di javascript non appaiono lì .
In secondo luogo, quando controllo l'elemento sul mio sito web attivo (browser: Firefox), vedo un pulsante ev accanto al tag compresso del mio sito web:
QuestoèapparentementeunpulsanteeventipereseguireildebugdiJSnell'ispettoredelcodicediMozilla.Selopreme,vedo:
Nonsonosicurodicosasia:37(porta37?).Inoltre,sepremoilpulsantedipausa(debug)davantiaclick,vengoportatoaunodeiframmentidiJScherisiedononelmiocodicebase.html:
La mia confusione riguarda come possono questi frammenti JS essere parte del mio sito web live quando i file nel mio server di produzione sembrano senza loro?
Immagino che trovare la fonte dell'hack richiederebbe approfondire la questione. Non ho ancora installato SSL, ma sospetto che il mio problema non possa essere aiutato da questo. Questo è un progetto a due persone - e l'altra persona è un'antropologia culturale, un'antropologia culturale specializzata negli studi dell'Asia meridionale, quindi sono sicuro che non ha nulla a che fare con questo.
Ho impostato rules.v4 per iptables su:
*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]
# Acceptable UDP traffic
# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
-A TCP -p tcp --dport 80 -j ACCEPT
# Acceptable ICMP traffic
# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT
# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP
# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP
# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
# Commit the changes
COMMIT
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
1COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT