Monthly Archives: February 2010

Zardari saying Shutup to reporter

Posted on by
Reply

Share

HTML:Iframe-inf wordpress Infection

Posted on by
Reply

Here is an article that really helped me getting my server back up and running.

HTML:Iframe-inf wordpress Infection

If your blog has been infected by the HTML:Iframe-inf  infection according to avast here are two scripts that can help you.

FirstWhat is the HTML:Iframe infection?– Its just a line of text that is inserted at the end of every index.php and/or index.htm in your website. Nothing to freak out about but you want to fix it. And Its probably due to wordpress not being secure.

Anyways, here is what you do : This is something you run on the commmand line – See the video below for an idea.

You will need to find infected files first.

find / -type f | xargs grep -l ‘<iframe’  2>/dev/null or you could print out a list of files possibly comprimised. by typing find / -type f | xargs grep -l ‘<iframe’  2>/dev/null >infectedFileslist.txt

The first step is figuring out what is going on with your virus infection.

If you know the time frame of when the virus ran then you could narrow the list of infected files even more by tweaking the find command.

Lets say you know it infected your website about 5 days ago.

Then you would modify the find command to search all files modified less than 10 days ago.

find / -type f -mtime -10 | xargs grep -l ‘<iframe’  2>/dev/null >infectedFileslist.txt

More info on the find command here

http://content.hccfl.edu/pollock/Unix/FindCmd.htm my short version find . -mtime +5 -mtime -10 # find files modifed between 5 and 10 days ago Ok so now you have a list of infected files … This is VERY HELPFUL as you are halfway there to cleaning up your server.

Remove infected text

find / -type f -mtime -10 | xargs grep -l ‘<iframe’| xargs perl -pi -e ‘s/^.*\<iframe.*$/ /g’ Here is an explanation of what the script does line by line so you can adjust per your situation. find / -type f -mtime -10 – looks all files that were modified in the last 10 days ( you adjust as needed) xargs grep -l ‘<iframe’ – of that list of files modified recently look for a line that says <iframe xargs perl -pi -e ‘s/^.*\<iframe.*$/ /g’ – search and replace that line with a blank space Understanding this last line – perl -pi -e is important — http://www.linux.org/lessons/short/perlpie/perl_pie.html You want to be sure that you know whats going on there because this is where the search and the replace happens – Check out this article — http://www.linux.org/lessons/short/perlpie/perl_pie.html You can modify the script line by line to

Here is a video explaining this:

My Contribution:

You can also use this linux command to find files that were changed in last 10 days

find /directory-path-to-search-files-from/ -type f -mtime -10 > infectedFileslist.txt
find . -name "*.js" > /home/star/public_html/infectedJSlist.txt
grep command: Recursively Search All Files For A String
cd /path/to/dir
 grep -r "word" .
 grep -r "string" .
 Ignore case distinctions:
 grep -ri "word" .
   
To display print only the filenames with GNU grep, enter:
 grep -r -l "foo" .
 You can also specify directory name:
 grep -r -l "foo" /path/to/dir/*.c
find command: Recursively Search All Files For A String
find command is recommend because of speed and ability to deal with filenames that contain spaces.
 cd /path/to/dir
 find . -type f -exec grep -l "word" {} +
 find . -type f -exec grep -l "seting" {} +
 find . -type f -exec grep -l "foo" {} +
 Older UNIX version should use xargs to speed up things:
 find /path/to/dir -type f | xargs grep -l "foo"
 It is good idea to pass -print0 option to find command that it can deal with filenames that contain spaces or other metacharacters:
 find /path/to/dir -type f -print0 | xargs -0 grep -l "foo"
 
   
I found this command to be really helpful if you are not certain if its an iframe attack or not.
Share
  
 
 
Tuning / Optimizing my.cnf file for MySQL
 Posted on   by  
 Reply
 
This one really helped me.
Had to do some fine tuning of MySQL 4.1.9 and here is what my.cnf file looks like for a 2GHz machine with 1GB of memory.
[mysqld]
socket=/path/to/mysql.sock
datadir=/var/lib/mysql
skip-locking
skip-innodb
# MySQL 4.x has query caching available.
# Enable it for vast improvement and it may be all you need to tweak.
query_cache_type=1
query_cache_limit=1M
query_cache_size=32M
# max_connections=500
# Reduced to 200 as memory will not be enough for 500 connections.
# memory=key_buffer+(sort_buffer_size+read_buffer_size)*max_connections
# which is now: 64 + (1 + 1) * 200 = 464 MB
# max_connections = approx. MaxClients setting in httpd.conf file
# Default set to 100.
#max_connections=200
#interactive_timeout=180
interactive_timeout=100
#wait_timeout=180
#wait_timeout=100
# Reduced wait_timeout to prevent idle clients holding connections.
#wait_timeout=30
wait_timeout=15
connect_timeout=10
# max_connect_errors is set to 10 by default
#max_connect_errors=10
#table_cache=256
#table_cache=1024
# Checked opened tables and adjusted accordingly after running for a while.
table_cache=512
#tmp_table_size=32M by default
#thread_cache=128
# Reduced it to 32 to prevent memory hogging. Also, see notes below.
thread_cache=32
# key_buffer=258M
# Reduced it by checking current size of *.MYI files, see notes below.
key_buffer=128M
# Commented out the buffer sizes and keeping the default.
# sort_buffer_size=2M by default.
#sort_buffer_size=1M
# read_buffer_size=128K by default.
#read_buffer_size=1M
# 1Mb of read_rnd_buffer_size for 1GB RAM -- see notes below.
# read_rnd_buffer_size=256K by default.
#read_rnd_buffer_size=1M
# myisam_sort_buffer_size used for ALTER, OPTIMIZE, REPAIR TABLE commands.
# myisam_sort_buffer_size=8M by default.
#myisam_sort_buffer_size=64M
# thread_concurrency = 2 * (no. of CPU)
thread_concurrency=2
# log slow queries is a must. Many queries that take more than 2 seconds.
# If so, then your tables need enhancement.
log_slow_queries=/var/log/mysqld.slow.log
long_query_time=2
[mysql.server]
user=mysql
basedir=/var/lib
[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
open_files_limit=8192
[mysqldump]
quick
max_allowed_packet=16M
[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates
[isamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M
[myisamchk]
key_buffer=64M
sort_buffer=64M
read_buffer=16M
write_buffer=16M
[mysqlhotcopy]
interactive-timeout
[client]
socket=/path/to/mysql.sock
Below are notes on some of the important variables, I took down while tuning the config file.
   
  1. query_cache_size:
    • MySQL 4 provides one feature that can prove very handy – a query cache. In a situation where the database has to repeatedly run the same queries on the same data set, returning the same results each time, MySQL can cache the result set, avoiding the overhead of running through the data over and over and is extremely helpful on busy servers.
  2. key_buffer_size:
    • The value of key_buffer_size is the size of the buffer used with indexes. The larger the buffer, the faster the SQL command will finish and a result will be returned. The rule-of-thumb is to set the key_buffer_size to at least a quarter, but no more than half, of the total amount of memory on the server. Ideally, it will be large enough to contain all the indexes (the total size of all .MYI files on the server).
    • A simple way to check the actual performance of the buffer is to examine four additional variables: key_read_requests, key_reads, key_write_requests, and key_writes.
    • If you divide the value of key_read by the value of key_reads_requests, the result should be less than 0.01. Also, if you divide the value of key_write by the value of key_writes_requests, the result should be less than 1.
  3. table_cache:
    • The default is 64. Each time MySQL accesses a table, it places it in the cache. If the system accesses many tables, it is faster to have these in the cache. MySQL, being multi-threaded, may be running many queries on the table at one time, and each of these will open a table. Examine the value of open_tables at peak times. If you find it stays at the same value as your table_cache value, and then the number of opened_tables starts rapidly increasing, you should increase the table_cache if you have enough memory.
  4. sort_buffer:
    • The sort_buffer is very useful for speeding up myisamchk operations (which is why it is set much higher for that purpose in the default configuration files), but it can also be useful everyday when performing large numbers of sorts.
  5. read_rnd_buffer_size:
    • The read_rnd_buffer_size is used after a sort, when reading rows in sorted order. If you use many queries with ORDER BY, upping this can improve performance. Remember that, unlike key_buffer_size and table_cache, this buffer is allocated for each thread. This variable was renamed from record_rnd_buffer in MySQL 4.0.3. It defaults to the same size as the read_buffer_size. A rule-of-thumb is to allocate 1KB for each 1MB of memory on the server, for example 1MB on a machine with 1GB memory.
  6. thread_cache:
    • If you have a busy server that’s getting a lot of quick connections, set your thread cache high enough that the Threads_created value in SHOW STATUS stops increasing. This should take some of the load off of the CPU.
  7. tmp_table_size:
    • “Created_tmp_disk_tables” are the number of implicit temporary tables on disk created while executing statements and “created_tmp_tables” are memory-based. Obviously it is bad if you have to go to disk instead of memory all the time.
Share