I have a Django website project that is live (let's call it example.com). It's a forum where users can submit comments and reply to them. It has a Postgresql database, and gunicorn + nginx reverse proxy as the web server set up. I'm hosted on an Azure-powered virtual machine, with the Debian-based Ubuntu 14.04 lts as the OS. Lastly, note that the web application and the server sit on two separate virtual machine instances.
I suspect my servers might be compromised - I'm at the data-gathering stage where I'm ascertaining whether (i) indeed my servers are compromised (ii) whether my data is compromised too (iii) how did the compromise happen, so that I don't get hacked again.
In Django applications, there's a base.html file that all other .html files inherit (or extend in Django). This base.html file contains the <head> tag with required meta tags etcetra, so one doesn't have to replicate it in every template file.
My base.html file has some javascript code in it that I did not write. In fact, I don't use javascript in my code at all. This malicious javascript snippet redirects my users to adverts (it's a money making hack). If I log into my web application's production server and nano to the base.html file (i.e. open it in a text editor), the offending snippets of javascript do not appear there.
Secondly, when I inspect element on my live website (browser: Firefox), I see an ev button next to the collapsed tag of my website:
This is apparently an events button to debug JS in Mozilla's code inspector. If I press it, I see:
I'm unsure what's :37 (port 37?). Moreover, if I press the pause (debug) button in front of click, I am taken to one of the JS snippets residing in my base.html code:
My confusion is regarding how can these JS snippets be part of my live website when the files in my production server appear to be without them?
I'm guessing finding the source of the hack would require going deeper into this. I haven't installed SSL yet, but I suspect my problem can't be helped by that. This is a two-person project - and the other person is a non-techie, cultural anthropology major specializing in South Asian studies, so I'm sure she has nothing to do with it.
I have set rules.v4 for iptables to:
*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
<scripttags at all in your header file?new relic,google analytics), but most are some kind of ad-related script tags that I never put. @silverpenguin: Yes, I'm just trying to get as much information right now as possible. It was flagged in my previous ques that my servers might be compromised. So I'm now quite confused about why my files on the production server aren't defaced, but those being served are. Your SSL theory does make sense to me.curlcertainly will.