Wednesday, July 6, 2011

scrip to check php functions

Script to check if a php function "fwrite" is enabled or not

if(function_exists('fwrite')) {
echo "fwrite function is enabled";
}
else {
echo "fwrite is not enabled";
}
?>

Saturday, July 2, 2011

Disable ModSec2 per domain per folder

When a client complaints for a modsec error, it is not advisable to turn off a specific rule he has issue with globally. Nor it is not advisable to turn off the modsec completely for that domain. Prior to modsec2, we were able to turn off the modsec completely and per rulewise through .htaccess of a domain. From modsec2 onwards, it is not possible to use .htaccess to disable modsec. We need to add rules inside the file "/usr/local/apache/conf/whitelist.conf" or disable using the modsec rule id.

We can disable modsec for a domain completely using the following rule added to the whitelist.conf.

SecRule SERVER_NAME "domain.com" phase:1,nolog,allow,ctl:ruleEngine=off

So what does these words specify? Some are pretty straight forward:

nolog:Prevents rule matches from appearing in both the error and audit logs.
allow: Stops rule processing on a successful match and allows the transaction to proceed.
ctl: The ctl action allows configuration options to be updated for the transaction. This means what action should be taken to the configuration options. For eg, ruleEngine is "on" by default. We are telling modsec to turn it "off", when the server name matches domain.com. So this means the action to be taken.

Now what is the stuff called phase:1 ?
ModSecurity 2.x allows rules to be placed in one of the following five phases:
Refer for more details here
http://www.modsecurity.org/documentation/modsecurity-apache/2.5.12/modsecurity2-apache-reference.html#processing-phases

I will explain phase:1 now.
Phase 1
Phase Request Headers
Rules in this phase are processed immediately after Apache completes reading the request headers (post-read-request phase). At this point the request body has not been read yet, meaning not all request arguments are available. Rules should be placed in this phase if you need to have them run early (before Apache does something with the request), to do something before the request body has been read, determine whether or not the request body should be buffered, or decide how you want the request body to be processed (e.g. whether to parse it as XML or not).

Modsec applies the rules specified as phase:1 at the first time the apache request is received. Not much would have been done to the request. this time. I will explain with an example now.

Lets come back to the initial situation. We had disabled modsec for a domain completely. But this is not a good practice. It is recommended to disable modsec per domain, per location and per rule wise. Don't you think it is ideal case? How do we do it in modsec2?

In modsec2, we can see there comes a lot of default rules. If you see such a rule, you will notice there is an id attached to the rules. See below.

----
#Generic PHP exploit signatures
SecRule REQUEST_URI "(chr|fwrite|fopen|system|e?chr|passthru|popen|proc_open|shell_exec|exec|proc_nice|
proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|
posix_setsid|posix_setuid)\(.*\)\;" "id:330001,rev:1,severity:2,msg:'Generic PHP exploit pattern denied'"
---

We can disable the above modsec rule for a domain using the id by adding the following line inside the file /usr/local/apache/conf/whitelist.conf

SecRule SERVER_NAME "domain.net" phase:1,nolog,allow,ctl:ruleRemoveById=330001

But what we need not disabling fully a rule per domain. But disable per folder or location. How to do this?

In Modsec, there is an option called SecRuleRemoveById. We can use this inside the httpd.conf, virtualhost entry of the domain for which we need to disable a specific modsec rule on a specific folder. If we need to disable the above rule id for the location domain.com/help ie /home/username/public_html/help, we can add these lines to the virtualhost entry of the domain "domain.com". This means domain.com/paypal will give modsec error while domain.com/help/paypal will not show error.


SecRuleRemoveById 330001


The above stuff is useful in cases like below. Here you can see the modsec causes when a page is loaded with an image named paypal.png inside the folder images. You can apply the above entry insdie the VH of domain.com for folder images.

----
[Thu Jun 03 13:53:42 2010] [error] [client 90.210.133.41] ModSecurity: Access denied with code 406 (phase 2). Pattern match "/paypal" at REQUEST_URI. [file "/usr/local/apache/conf/modsec2.global.conf"] [line "101"] [hostname "domain.com"] [uri "/image/paypal.png"] [unique_id "TAfsJkJH8oIAAFEcNNwAAAAA"]
----
As the logs says, the rule responsible for this error is in the line 101 inside the file /usr/local/apache/conf/modsec2.global.conf. Lets see that.

SecRule REQUEST_URI "paypal" "deny,log,status:406"

Well did you get the "id" from the above rule? No right? The unique_id seen in the log should not be confused with the "id". unique_id is the unique id created by the modsec for a log message. So, without the id, we cannot disable the specific rule for a domain and location wise. How can we create an id for a specific rule? Modify the rule as follows inside the file /usr/local/apache/conf/modsec2.global.conf

SecRule REQUEST_URI "/paypal" "id:900000,deny,log,status:406"

Now we have created an ID for the specific rule. Now you can block this as explained above.

I will explain the phase:1 and phase:2 a bit more with an example. Imagine I am adding the phase:1 as follows to the above rule.

SecRule REQUEST_URI "/paypal" "phase:1,id:900000,deny,log,status:406"

This means when the request like domain.com/paypal reaches the apache, it ignores the request at the first stage of apache request processing. It will not even check if any is specified in the httpd.conf file.

If we change the rule as follows, ie add phase:2 instead of phase:1

SecRule REQUEST_URI "/paypal" "phase:2,id:900000,deny,log,status:406"

Here, the rule is applied to the request domain.com/paypal, during the later stage of apache request processing, ie not at the first stage. So the apache has got time and checks if there is any for the specific rule id. If it finds the below rule inside the httpd.conf file, the request is not checked again. ie it get whitelisted for the path /home/username/public_html/help.


SecRuleRemoveById 900000

Sunday, June 5, 2011

Super blocks

*. Super blocks are used to store file system informations
*. Each file system has a superblock

A superblock stores the following informations

*. file system type
*. Size
*. Status
*. Information about other metadata structures

Thursday, June 2, 2011

Split command

Split command is used to split a larger file into smaller ones

syntax: split -bytes = 1m path to large files path/prefix

$ split –bytes=1m /path/to/large/file /path/to/output/file/prefix

* You can change the output file size by changing the –bytes=1m to your preference. You can use b, k, or m. b represent bytes, k represent kilobytes, m represent megabytes.

To restore the original file, you can use cat command.
To join all the smaller file to restore the original file type:-

$ cat prefix* > NEWFILENAME


Eg:

split --bytes=1m thetruth_wrdp2.sql thetruth_wrdp2.sql_

Tuesday, May 24, 2011

System log files:

/var/log/messages - system messages
/secure - Logging by PAM of network access attempts
/dmesg - Log of system boot. Also see command dmesg
/boot.log - Log of system init process
/xferlog.1 - File transfer log
/lastlog - Requires the use of the lastlog command to examine contents
/maillog - log from sendmail daemon

find commands

Search and list all files from current directory and down for the string ABC:
find ./ -name "*" -exec grep -H ABC {} \;
find ./ -type f -print | xargs grep -H "ABC" /dev/null
egrep -r ABC *
Find all files of a given type from current directory on down:
find ./ -name "*.conf" -print
Find all user files larger than 5Mb:
find /home -size +5000000c -print
Find all files owned by a user (defined by user id number. see /etc/passwd) on the system: (could take a very long time)
find / -user 501 -print
Find all files created or updated in the last five minutes: (Great for finding effects of make install)
find / -cmin -5
Find all users in group 20 and change them to group 102: (execute as root)
find / -group 20 -exec chown :102 {} \;
Find all suid and setgid executables:
find / \( -perm -4000 -o -perm -2000 \) -type f -exec ls -ldb {} \;
find / -type f -perm +6000 -ls

Note: suid executable binaries are programs which switch to root privileges to perform their tasks. These are created by applying a "sticky" bit: chmod +s. These programs should be watched as they are often the first point of entry for hackers. Thus it is prudent to run this command and remove the "sticky" bits from executables which either won't be used or are not required by users. chmod -s filename
Find all world writable directories:
find / -perm -0002 -type d -print
Find all world writable files:
find / -perm -0002 -type f -print
find / -perm -2 ! -type l -ls
Find files with no user:
find / -nouser -o -nogroup -print
Find files modified in the last two days:
find / -mtime 2 -o -ctime 2
Compare two drives to see if all files are identical:
find / -path /proc -prune -o -path /new-disk -prune -o -xtype f -exec cmp {} /new-disk{} \;

wordpress .htaccess file


RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]