These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for iptables not working #EMERGENCY on the new forum.
I recently found http://computerhomecall.com/ copying my entire website to http://computerhomecall.com/test
They are attempting to steal all of my content and copy it, and furthermore they ruined my database, took the site down and I had to pull in backups to get the website back up.
I found there ip address and put them in the webmin ip tables as -A INPUT -s 94.0.0.0/8 -j DROP
and -A INPUT -s 94.195.189.224 -j DROP
yet I still see further traffic from these thieves listed in my statcounter account.
IS IP TABLES NOT WORKING AT ALL?
What's the output of
iptables -L
?I also tried to attach a screenshot, but this website is not working correctly. (virtualmin) the shot was a 60 k .jpg, not sure why it wont attach.
well here is the last 5 lines of the output.
DROP all -- customer-static-2-60-178.iplannetworks.net anywhere DROP all -- p84047c.tokynt01.ap.so-net.ne.jp anywhere DROP all -- 94-195-189-224.zone9.bethere.co.uk anywhere DROP all -- 5e000000.bb.sky.com/8 anywhere DROP all -- host-213-248-210-54.nominet.org.uk anywhere DROP all -- starka.x10hosting.com anywhere DROP all -- 5e000000.bb.sky.com/24 anywhere
the uk stuff is the hackers but I input it as stated in the last post. also added /24 a min ago
I can't really make heads or tails of that output, sorry. Can you please post the entire result for `iptables -L INPUT -n" and enclose it in
tags?
sorry guess theres no pm in this forum, edited last post with your request. did not want to put full output for security reasons. If you have a pm I can give you the full output.
Hmm... Looks okay to me so far. Can you for a test put an IP address of some system under your control in there and then test accessing the server?
difference between the /8 and the /24
strange though because there CIDR says /8 but that did not block them. they were on just today in my logs, but when I expanded it to /24 it stoped them.
Resolve Host: 94-195-189-224.zone9.bethere.co.uk IP Address: 94.195.189.224 [Whois] [Reverse-Ip] [Ping] [DNS Lookup] [Traceroute] NetRange: 94.0.0.0 - 94.255.255.255 CIDR: 94.0.0.0/8 OriginAS:
You notice I did have their ip in there from the start, should that be enough? So is that the only way to have the 1 offending user blocked, to block out an entire ISP?
seems a bit of overkill.
BTW thank you for your help. @Locutus
I will try your suggestion and report back.
I'm not fully sure about the inner workings of iptables, but I don't really see a reason why a /8 block should not work while a /24 does. The iptables rules are - if I'm not mistaken and recall correctly from my times when I fiddled rather intensely with it - executed on a "first match" basis. Though a rule can also "continue with the next one" if the chain it jumps to does not end with a "terminal" like DENY or ACCEPT but "returns from subroutine" like it is done in the LOG chain.
So in your case it's possible that there's some problem in the ruleset, causing the part you wish to block to be processed by different rules first. I'd need the full output of
iptables -L
to say more about that. You can email it to "admin #at# tianet #dot# de".As for blocking IPs in general that have been offenders towards your web pages... I guess that's rather a fight against windmills. If someone really wants to "steal" your web page contents, they won't be stopped from doing that by blocking IPs... There are literally too many for that. :) And blocking a whole /8 to stop one offender is indeed overkill. Except you're sure that ONLY offenders will come from that block. Otherwise you might end up blocking the entire net, cause in each /8 there will probably be at least one offender (which is certainly true since the recent vast distribution of botnets / virus infected end user boxes).
So, in addition to trying to block them for "stealing" what exactly were you referring to when you say they "ruined your database" and "took your site down so that you had to restore a backup"?
While stealing just needs read access, which you can't efficiently block for everyone, that stuff sounds like it requires write access, and if people attained that without authorization, it sounds rather like your web code contains security issues. In which case you shouldn't be blocking IPs, but quickly fixing those issues. :)
@Locutus
Just wanted to mention, you really helped a bunch, your tip lead me exactly to the answer to why I could not block him, I had the IpTables written incorrectly. Now the next question I will look into is exactly what you mention, how did these databases get ruined with an outside live website and a copy, calling my server....hmmm. they were created with virtualmin, CentOs, etc, but im not blaming Virtualmin, I know its something I did wrong or setup incorrectly.
Looking at the timing, it doesnt seem that he went through anything very fast, just copied it to his local dir and then put it to his live .mx server using an offline browser program http://www.spadixbd.com/backstreet/ but your right, that is all publicly available, and maybe they needed some :inspiration.
I was led back to his testing domain .mx from inside my statcounter, and the .mx domain was in fact live with a copy of my content and shopping cart, which then called my server from his DNS/server. So I got some interesting screenshots of that, then tried to block him with no luck. He is blocked now.
Thanks again for your help. cddrummer
As a final note, you should not be so concerned with iptables-blocking offending IP addresses (serious hackers can get fresh un-blocked ones of those anytime), but rather about quickly finding out how the hacker was (allegedly) able to retrieve your MySQL login data.
I suppose some directory where the data files resides is readable when it should not be or similar, or some security flaw in the used software, or a PHP misconfiguration... there are many possible reasons, and without further information about the software in question, it's just wild guesses.