Here is a good online scanner to find the spam or any other false positive:
http://www.unmaskparasites.com/security-report/
Sometimes we face one problem that we have shells in our server. It's so borring so I use this tutorial. Here it is
http://www.unmaskparasites.com/security-report/
Sometimes we face one problem that we have shells in our server. It's so borring so I use this tutorial. Here it is
IMPORTANT NOTICE
This script is a Unix SHELL SCRIPT and not useful for everybody.
This script is a Unix SHELL SCRIPT and not useful for everybody.
PHP Developers
If any smart-cookie PHP Developer would like to convert this from a shell script to either a standalone, single user, browser ready php script or a Joomla! Extension, feel free to go for it.
File comment: SploitFinder Shell Script v1.00 (2011)
Go Ahead:
The simple logic is by no means "fool proof" or "exhaustive" but gives a reasonably good indication that the target script maybe part of an exploit set. False positives are extremely possible due to the fact that many valid scripts make use of the same logic/technologies to acheive required activities, therefore some "human intelligence" must be applied to the final reports.
Installation:
1) FTP/Copy sploitFinder.sh.txt to your server
2) Rename to either sploitFinder.sh or just sploitFinder
3) Make the file executable (chmod 755 sploitFinder) or run "sh sploitFinder.sh"
4) READ the comments and instructions in the file (it is fully documented)
5) run it to test with all the different switches, setup crons etc etc
sploitFinder: list possible exploit scripts and optionally email output
Usage: ./sploitFinder(.sh) [-a] [-c] [-m ] [egrep pattern]
-m : email output to instead of writing to stdout
-a : shows all files not just changes since last run
-c : shows matching lines with context
-r : reset/delete history
The script is well commented, only a couple of internal variables to be configured and select your command line execution switches.
Configuration:
searchpath=/home (Default : /home)
sploitdir=/sploitFind (Default : none)
This is the search pattern criteria. Listed are some of the signitures of some exploits we have heard of, these ARE NOT exhaustive. Obviously, the more variables there are, the longer each run will take.
sploitpattern='r0nin|m0rtix|upl0ad|r57shell|c99shell|shellbot|phpshell|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute *force|multiviews|cwings|vandal|bitchx|eggdrop|guardservices|psybnc|dalnet|undernet|vulnscan|spymeta|raslan58|Webshell'
(Feel free to post additions to the sploitpattern to enhance the scripts capability and share your experience and knowledge.!)
This script may be run adhoc if prefered, another option is via crom, for example: TWO regular cron jobs.
The first cron runs every 4 hours on Monday through Sunday at 02.10hrs, 06.10hrs, 10.10hrs, 14.10hrs, 18.10hrs & 22.10hrs
- Showing only new files since the previous run and mailing the report
The second cron runs once a week on Sunday at 01.10hrs
- Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)
EG:
10 2,6,10,14,18,22 * * * //sploitFinder.sh -m your@emailaddress.com.au >& /dev/null
10 1 * * 0 //sploitFinder.sh -rm your@emailaddress.com >& /dev/null
As ever, This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY or support; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
Installation:
1) FTP/Copy sploitFinder.sh.txt to your server
2) Rename to either sploitFinder.sh or just sploitFinder
3) Make the file executable (chmod 755 sploitFinder) or run "sh sploitFinder.sh"
4) READ the comments and instructions in the file (it is fully documented)
5) run it to test with all the different switches, setup crons etc etc
sploitFinder: list possible exploit scripts and optionally email output
Usage: ./sploitFinder(.sh) [-a] [-c] [-m ] [egrep pattern]
-m : email output to instead of writing to stdout
-a : shows all files not just changes since last run
-c : shows matching lines with context
-r : reset/delete history
The script is well commented, only a couple of internal variables to be configured and select your command line execution switches.
Configuration:
searchpath=/home (Default : /home)
sploitdir=/sploitFind (Default : none)
This is the search pattern criteria. Listed are some of the signitures of some exploits we have heard of, these ARE NOT exhaustive. Obviously, the more variables there are, the longer each run will take.
sploitpattern='r0nin|m0rtix|upl0ad|r57shell|c99shell|shellbot|phpshell|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute *force|multiviews|cwings|vandal|bitchx|eggdrop|guardservices|psybnc|dalnet|undernet|vulnscan|spymeta|raslan58|Webshell'
(Feel free to post additions to the sploitpattern to enhance the scripts capability and share your experience and knowledge.!)
This script may be run adhoc if prefered, another option is via crom, for example: TWO regular cron jobs.
The first cron runs every 4 hours on Monday through Sunday at 02.10hrs, 06.10hrs, 10.10hrs, 14.10hrs, 18.10hrs & 22.10hrs
- Showing only new files since the previous run and mailing the report
The second cron runs once a week on Sunday at 01.10hrs
- Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)
EG:
10 2,6,10,14,18,22 * * * //sploitFinder.sh -m your@emailaddress.com.au >& /dev/null
10 1 * * 0 //sploitFinder.sh -rm your@emailaddress.com >& /dev/null
As ever, This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY or support; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
Script setup and installation
Code:
# Where you want to search
searchpath=public_html
## The location where the sploitFinder DB is to stored. This will be auto-generated at first execution
## Example: /opt/adminTools/ is where the sploitFinder script is and you want the DB stored in /opt/adminTools/sploitFinderDB/
sploitdir=sploitFinderDB
searchpath=public_html
## The location where the sploitFinder DB is to stored. This will be auto-generated at first execution
## Example: /opt/adminTools/ is where the sploitFinder script is and you want the DB stored in /opt/adminTools/sploitFinderDB/
sploitdir=sploitFinderDB
* Save the file as sploitfinder.sh
* Upload the file to your domain placing the file outside of public_html. You do not want the script (or any other shell scripts) accessible from a public_area as this could be considered a security risk.
* Now we need to set the permissions on the script to 700 so that the script owner has read, write and execute privileges while we are testing.
* The script should now be ready to test.
Testing the script operation
Testing the script can be accomplished in a couple ways. The method you use for testing depends on your host service and your level of experience.
a. Testing the script if you have shell access to your account.
b. Testing the script if you do not have shell access
Testing the script if you have shell access:
Using PuTTY open a terminal session to your account and change the directory to where you uploaded the sploitfinder.sh script.
Enter the following command and press return:
./sploitFinder.sh -ac
The result of the command will scroll by on the screen. View the result and make sure no errors were generated. If there were errors, correct them before proceeding.
If no errors were generated check and make sure the directory sploitFinderDB was created. It should have permissions of 700.
Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.
If everything checks out you can set up a cron job to run the script automatically.
Testing the script if you do not have shell access
If you do not have shell access to your account, you can use a cron job to test the script. Most hosting services will have this ability.
Go to your domains control panel and create a cron process following the procedure your domains control panel provides.
In the minute field enter
*/2
This will run the script every 2 minutes. Leave the rest of the time date settings as asterisks (*)
In the command line enter the command desired.
/<your_loacation>/sploitFinder.sh -ac -m your@emailaddress.com
Save the cron job and if the cron runs without errors it will create the directory "sploitFinderDB" and the directory should have permissions of 700.
Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.
If everything checks out you can set up a cron job to run the script automatically.
Scheduling the script to run from Cron at a reasonable times.
Create or set the cron job you made above in testing to run at something reasonable such as every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs.
Add the >/dev/null 2>&1 to the end of the command when your making modifications to the time and days.
Example:
10 2,10,18 * * 1-6 /<your_loacation>/sploitFinder.sh -c -m your@emailaddress.com.au >/dev/null 2>&1
This cron job runs every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs only of files changed since last report, showing context information and email report.
The second cron below runs once a week on Sunday at 02.10hrs and Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)
Example:
10 2 * * 0 /<your_location>/sploitFinder.sh -rm your@emailaddress.com >/dev/null 2>&1
Once you are done with testing the script you should be able to change the permissions to 500 (read, execute) to make it more secure.
Troubleshooting
Most issues with the script will be the result of the wrong path information being supplied to the script.
Example error:
find: /public_html: No such file or directory
This error generally means that the search path is incorrect
Errors of permission denied when attempting to run the script can be the result of improper permissions on the script.
The permissions on the script should be 500 (700 while testing) and permissions on the directory sploitFinderDB should be 700.
Another cause of permission denied errors can be that your host has changed the command find to something else to increase security. In this case you will need to ask what the command to use instead of find and change the find command in the script ( ~ line 191) to the correct command.
* Upload the file to your domain placing the file outside of public_html. You do not want the script (or any other shell scripts) accessible from a public_area as this could be considered a security risk.
* Now we need to set the permissions on the script to 700 so that the script owner has read, write and execute privileges while we are testing.
* The script should now be ready to test.
Testing the script operation
Testing the script can be accomplished in a couple ways. The method you use for testing depends on your host service and your level of experience.
a. Testing the script if you have shell access to your account.
b. Testing the script if you do not have shell access
Testing the script if you have shell access:
Using PuTTY open a terminal session to your account and change the directory to where you uploaded the sploitfinder.sh script.
Enter the following command and press return:
./sploitFinder.sh -ac
The result of the command will scroll by on the screen. View the result and make sure no errors were generated. If there were errors, correct them before proceeding.
If no errors were generated check and make sure the directory sploitFinderDB was created. It should have permissions of 700.
Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.
If everything checks out you can set up a cron job to run the script automatically.
Testing the script if you do not have shell access
If you do not have shell access to your account, you can use a cron job to test the script. Most hosting services will have this ability.
Go to your domains control panel and create a cron process following the procedure your domains control panel provides.
In the minute field enter
*/2
This will run the script every 2 minutes. Leave the rest of the time date settings as asterisks (*)
In the command line enter the command desired.
/<your_loacation>/sploitFinder.sh -ac -m your@emailaddress.com
Save the cron job and if the cron runs without errors it will create the directory "sploitFinderDB" and the directory should have permissions of 700.
Check inside of directory sploitFinderDB for 2 text files; one called pid and one called last.
If everything checks out you can set up a cron job to run the script automatically.
Scheduling the script to run from Cron at a reasonable times.
Create or set the cron job you made above in testing to run at something reasonable such as every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs.
Add the >/dev/null 2>&1 to the end of the command when your making modifications to the time and days.
Example:
10 2,10,18 * * 1-6 /<your_loacation>/sploitFinder.sh -c -m your@emailaddress.com.au >/dev/null 2>&1
This cron job runs every 8 hours on Monday through Saturday at 02.10hrs, 10.10hrs & 16.10hrs only of files changed since last report, showing context information and email report.
The second cron below runs once a week on Sunday at 02.10hrs and Resets/rebuilds the Baseline and mails out a full report of ALL files (-a implied)
Example:
10 2 * * 0 /<your_location>/sploitFinder.sh -rm your@emailaddress.com >/dev/null 2>&1
Once you are done with testing the script you should be able to change the permissions to 500 (read, execute) to make it more secure.
Troubleshooting
Most issues with the script will be the result of the wrong path information being supplied to the script.
Example error:
find: /public_html: No such file or directory
This error generally means that the search path is incorrect
Errors of permission denied when attempting to run the script can be the result of improper permissions on the script.
The permissions on the script should be 500 (700 while testing) and permissions on the directory sploitFinderDB should be 700.
Another cause of permission denied errors can be that your host has changed the command find to something else to increase security. In this case you will need to ask what the command to use instead of find and change the find command in the script ( ~ line 191) to the correct command.
NOTICE AGAIN:
IF IT FAILS THEN UPLOAD YOUR SITE THEN SCAN WITH A GOOD ANTIVIRUS
Follow This Again Make a good result:
http://docs.joomla.org/Category:Security_Checklist
IF IT FAILS THEN UPLOAD YOUR SITE THEN SCAN WITH A GOOD ANTIVIRUS
Follow This Again Make a good result:
http://docs.joomla.org/Category:Security_Checklist
No comments:
Post a Comment