понеделник, 13 януари 2014 г.

How to limit bad bandwidth on your site

I think I'm a star for the Chinese bots. Not this blog, but my site where I pay for hosting, I get thousands and thousand of hits, which suck my bandwidth and make me communicate with the hosting sys-admins way too often. So, here is what I found so far in how to protect my precious bandwidth.
1. No hotlinks
I never thought of this, but it turns out this can be a significant drain of your bandwidth and CPU time. Basically, somebody links to your images and use your hosting to display them, thus stealing both your images and costing you money. So how to stop it? I found the answer here and here:
You need to edit your .htaccess to add: 
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?your-site.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ http://i.imgur.com/g7ptdBB.png [NC,R,L]
Where you need to  change your-site.com with your domain.
What this code does is that it redirects all viewers but those from your site to the link on the row number 4. This way, people won't be able to hotlink to your images.

2. Preventing bad bots to crawl your site.
Yes, there are bad bots. In my case, I have some unidentified bot who steals 300MB of traffic per day from my site. A very good tutorial what to do in this case can be found on this post: Protect your site from spam bots which I will summarize below, so that I don't forget what I did.
The steps are as follow:
2.1. Add to your .htaccess the content of this file. It is a list of the known bad bots.
2.2. Create 403.php in your top level/home directory and paste this. This script will log forbidden requests.
2.3. Create forbidden.html  in your top level/home directory and use the content of this file.
2.4. Create a trap directory and name it something interesting to humans, we'll call it /your_trap_directory. 
2.5. Create robots.txt and put in it:
User-agent: *
Disallow: /your_trap_directory
 2.6. In your_trap_directory place the following index.php.
2.7. Make sure both index.php and forbiddent.html have the 644 permissions.
2.8. Put some links to your_trap_directory on your site, so that you can lure bots. You can use something like:
<a href="http://your_site/your_trap_directory/" style="display: none;">check this hot offer</a>
in the html of your site or put it as HTML plugin on your blog.
VERY IMPORTANT! DO NOT VISIT THIS DIRECTORY from your site!
Because you will be added to the ban list and you'll need to go to cpanel, open .htaccess and remove your ip from it. This links are not meant to be read by humans, but only from bots.
I recommend you to visit the source site: Protect your site from spam bots to find a way to check whether what you did is working.
3. Check your AWstats for suspicious ip-s and then ban then from IP Deny Manager or directly in your .htaccess. I know some people ban entire countries, but I find this for too restrictive. We'll see if this will help my problem.
4. Ok, I did some additional research (like source1 and source2), I decided to use :
RewriteEngine on
Options -Indexes
    RewriteEngine on 
RewriteCond %{HTTP_REFERRER} !=http(s)?://(www\.)?mysite.com/index.php [NC] 
RewriteCond %{HTTP_REFERRER} !=http(s)?://(www\.)?mysite.com/*.php [NC] 
RewriteRule ^comment\.php$    -                                   [F]

So far that's what I did. I'll add stuff when I change something else. But for the moment, the bad traffic and cpu use seems under control.

вторник, 17 декември 2013 г.

Not enough place on my /tmp???

Today, I realized just how small is my /tmp partition by default. It turned out that it's only 100MB and if you happen not to like restarting, just like me, you will run out of space sooner rather than later.
In principle, the /tmp partition gets emptied upon reboot (you can check for your reboot rules with $nano /etc/conf.d/bootmisc ) , but in my case, this is no good. So what can you do?
First, you can change your /tmp size.
1. $su -c "nano /etc/fstab"
2. Change the line concerning the /tmp. In my case, I made it:
tmpfs                   /tmp                    tmpfs   noexec,nosuid,nodev,size=1000M 0 0
3. After restart, check your tmp size with:
$df -h
I still have to restart to see if it works. In the mean time,you can try deleting your /tmp to free some space. Like
$cd /tmp
$sudo rm -r *
Do the last one only from inside your /tmp dir! Otherwise, you might delete more than you want and much more than it is healthy!!!
Another smart way to increase the /tmp size without restarting can be found here
Finally, I just discovered this Sabayn wiki on how to optimize your system, where you can find how to mount your /tmp partition on your ram so that everything runs faster. I currently have 16GB ram so I guess it makes some sense to do that.

Ram Drive using tmpfs

Because temp folders are cleared during shutdown, it is safe to place their storage locations in RAM. This reduces the number of disk operations, making programs that use temp folders faster. Open the file and append the lines: file: /etc/fstab
  ...
  tmp     /tmp      tmpfs rw,mode=1777 0 0
  vartmp  /var/tmp  tmpfs rw,mode=1777 0 0 
"mode=1777" option allows all users write access, but prevents deletion of files belonging to other users.

I'll try this later, and we'll see how it works. 


събота, 7 декември 2013 г.

Atheros AR9485 kills my wifi router (solved)

Ok, here's the story:
I have a laptop with atheros ar9485. The wired connection works fine, but the moment I connect to my wifi TENDA router, the wireless network dies. And by dies, I mean that it disappears and the router needs to be manually rebooted.
I used another router (OpenWrt), and it doesn't crash. But the connection is very unstable, it drops at random.
I still don't know whether the problem was between the Atheros and the Tenda router (I read somewhere that Atheros has a problem with Netgear routers), but it doesn't matter. Here's how I fixed it.
First, as suggested in the Sabayon Forum (link), I got the outputs from:
uname -a
rfkill list
iwconfig (before the router crash)
iwconfig (after)
dmesg|tail -25

The output from the dmesg looked like this:
[ 5858.487813] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5858.487817] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[ 5858.487821] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5858.487824] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[ 5859.529403] wlan0: authenticate with c8:3a:35:27:51:58
[ 5859.548446] wlan0: send auth to c8:3a:35:27:51:58 (try 1/3)
[ 5859.550322] wlan0: authenticated
[ 5859.551076] wlan0: associate with c8:3a:35:27:51:58 (try 1/3)
[ 5859.612983] wlan0: RX AssocResp from c8:3a:35:27:51:58 (capab=0x11 status=0 aid=1)
[ 5859.613012] wlan0: associated
[ 5859.613079] cfg80211: Calling CRDA for country: CN
[ 5859.614768] ath: regdomain 0x809c updated by CountryIE
[ 5859.614771] ath: EEPROM regdomain: 0x809c
[ 5859.614772] ath: EEPROM indicates we should expect a country code
[ 5859.614773] ath: doing EEPROM country->regdmn map search
[ 5859.614774] ath: country maps to regdmn code: 0x52
[ 5859.614775] ath: Country alpha2 being used: CN
[ 5859.614776] ath: Regpair used: 0x52
[ 5859.614790] cfg80211: Regulatory domain changed to country: CN
[ 5859.614791] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[ 5859.614793] cfg80211:   (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[ 5859.614794] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 3000 mBm)
[ 5859.614796] cfg80211:   (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 2800 mBm)
[ 5859.614797] cfg80211:   (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 4400 mBm)
[ 5859.614798] cfg80211:   (63720000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 2800 mBm)


So after some digging, I discovered that there seems to be a problem with CRDA and the network adapter identification. You can see more on the story here and here. There you can find also some recommended solutions, but what I did is the following:

sudo equo install crda (if you don't have it)
sudo nano /etc/default/crda

and added this line: 
REGDOMAIN=BG 
And that was it. I got this solution from this site. It turned out it worked. Now, the connection is stable and the router - alive. 
I lost half a day on this, but now I feel quite happier. And I have wireless :) 
Enjoy!