SYN Attack OR DDOS Attack

SYN Attack

Command to check number of connection for port 25:

#netstat -plan|grep :25|awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -nk 1

#iptables -I INPUT -s xxx.xxx.xxx.xxx -j DROP



DDOS Attack

Quick check for a ddos via number of connections
A quick and usefull command for checking if a server is under ddos is:

#netstat -anp |grep 'tcp\|udp' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

That will list the IPs taking the most amount of connections to a server. It is important to remember that the ddos is becoming more sophistcated and they are using fewer connections with more attacking ips. If this is the case you will still get low number of connections even while you are under a DDOS.


A quick and useful command for checking if a server is under ddos:

#netstat -anp |grep ‘tcp\|udp’ | awk ‘{print $5}’ | cut -d: -f1 | sort | uniq -c | sort -n

That will list the IPs taking the most amounts of connections to a server. It is important to remember that ddos is becoming more sophisticated and they are using fewer connections with more attacking ips. If this is the case you will still get low number of connections even while you are under a DDOS.

Another very important thing to look at is how many active connections your server is currently processing.

#netstat -n | grep :80 |wc -l

#netstat -n | grep :80 | grep SYN |wc -l


The first command will show the number of active connections that are open to your server. Many of the attacks typically seen work by starting a connection to the server and then not sending any reply making the server wait for it to time out. The number of active connections from the first command is going to vary widely but if you are much above 500 you are probably having problems. If the second command is over 100 you are having trouble with a syn attack.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To Block a certain IP address that on server .Please use following commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#route add ipaddress reject

for example route add 192.168.0.168 reject

You can check whether given IP is blocked on server by using following command

#route -n |grep IPaddress

~~~~~~~~~~~~~~~~~~~

OR

Use following command to block an ip with iptables on server

#iptables -A INPUT 1 -s IPADRESS -j DROP/REJECT

#service iptables restart

#service iptables save




Then KILL all httpd connection and restart httpd service by using following command:

#killall -KILL httpd

#service httpd startssl


Linux VPS Start Issue

Note: VE is virtual environment, refer as a VPS
Any operation on a VE gives "Cannot lock VE". How do I solve it?
>>
VE is locked when some operation (backup, migration, start / stop, etc.) with this VE is in progress. You can determine which process is holding VE #101 using the following command on the hardware node:

# cat /vz/lock/101.lck

You can kill that process if needed. Make sure that the process is really killed. If there is no process with that PID on the node, just remove the lock file or rename is using mv /vz/lock/101.lck /vz/lock/101.lck.bk
~~~~~~~~~~~~~~~~~~~~~~~

VE starts but then just shuts down in a few minutes
>>
You probably do not have a valid Virtuozzo license installed - it can be expired or number of VEs is exceeded. Please, check the output of 'vzlicview' command. The status of the license should be ACTIVE and 'used VE' should be not more than 've_total'.


Another possible reason - VE was created with so called class 1 (Light VE) and exceeds defined in license limits for a number of resources such as privvmpages, numproc, shmpages and other. You will find error messages like this in /var/log/messages file on a node:

VE 101 violates UB_PRIVVMPAGES
In this case it is recommended to change VE class to 2 (Unlimited VE) using
'vzctl set VE_ID --class 2 --save'.
~~~~~~~~~~~~~~~~~~~~~~~

VE starts but displays error "/bin/bash: no such file" or the like.
>>
The owner of the VE could have removed some important package such as bash or glibc.

In this case you may recover VE private area using 'vzctl recover VEID'.

You may also have OS template the VE is abused on missed on hardware node, you may check it using 'vzpkgls VE_ID' and install missed OS template if it is needed.

The VE can also be compromised.
~~~~~~~~~~~~~~~~~~~~~~~

The VE starts but Segmentation fault occurs very soon after starting.
>>
The VE can be compromised

VE can be compromised if its owner uses insecure or out-of-date software. To detect if VE #101 has any rootkits installed one can use the chkrootkit utility either inside the VE or (better) on the hardware node using -r /vz/root/101 parameter. There is also a way to determine which packages were modified on the VE:

- mount VE private area (it may be needed in case VE can not be started):
# vzctl mount 101

- check packages integrity:
# /usr/share/vzpkgtools/vzrpm/bin/rpm --root=/vz/root/101 --veid 101 -Va | egrep '^..5|missing'

This command shows the files that were modified or removed.

Path to the needed package manger (/usr/share/vzpkgtools/vzrpm/bin/rpm in the example above) may be different for different VEs (it depends on OS template of VE). You may check which package manager (PKGMAN) shoud be used in OS template in the file "/vz/template/$OSRELEASE/conf/$OSRELEASE.conf.$OSVERSION" for standard OS template or in the file "/vz/template/$OS/$RELEASE/$ARCH/config/os/default/package_manager" for EZ template, and use appropriate rpm in the command above.

For example, CentOS 4 uses 'PKGMAN=rpm43x86' so the path will be '/usr/share/vzpkgtools/vzrpm43/bin/rpm'
~~~~~~~~~~~~~~~~~~~~~~~

Follow the instructions from the corresponding article to repair a hacked VE.
>>
There are two ways of restoring a VE which is hacked or cannot be started for some other reasons. Please make sure that you have created a full backup of the VE before applying any of the following solutions.

Solution #1:
# vzctl recover 101

This command will reinstall OS template and all application templates, which were previously installed on the VE. This action will make it possible to start the broken VE but it does not give any guarantee that all rootkits are removed, if any.

Solution #2:
# vzctl reinstall 101

This command will create a brand new VE on the same OS template as the broken one, install the same application templates into it and restore users' credentials. The contents of the old VE will be copied into /old directory.
~~~~~~~~~~~~~~~~~~~~~~~

The VE failed to start with the message like this:
ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0
vzquota : (warning) block_hard_limit [50100] <>
vzquota : (warning) block_hard_limit [50100] <>

>>
This error message means that VE exceeded its disk space quota and cannot be started because it is impossible to change system files during VE startup. Solution - increase diskspace (and probably inodes) alloted to VE using 'vzctl' utility:

# vzctl set VE_ID --diskspace BARRIER:LIMIT --save

#vzctl set VE_ID --diskinodes BARRIER:LIMIT --save

If increasing blocks and inodes limits does not help, try to re-init quota for this VE with:

# vzctl quotainit VE_ID

Then start VE

Exim : Message retry time not reached

What does the message retry time not reached [for any host] on the log mean? Why won't Exim try to deliver the message?

>>> That is not an error. It means exactly what it says. A previous attempt to deliver to that address failed with a temporary error, and Exim computed the earliest time at which to try again. This can apply to local as well as to remote deliveries.
For remote deliveries, each host (if there are several) has its own retry time.

If you are running on a dial-up host, the rest of this answer probably does not apply to you. If your host is permanently online.

Some MTAs have a retrying schedule for each message. Exim does not work like this.
Retry timing is normally host-based for remote deliveries and address-based for local deliveries. (There are some exceptions for certain kinds of remote failure - see Errors in outgoing SMTP in the manual.)

If a new message arrives for a failing address and the retry time has not yet arrived, Exim will log retry time not reached and leave the message on the queue, without attempting delivery.

Similarly, if a queue runner notices the message before the time to retry has arrived, it writes the same log entry. When the retry time has past, Exim attempts delivery at the next queue run. If you want to know when that will be, run the exinext utility on the address, for example:

exinext user@some.domain

You can suppress these messages on the log by including -retry_defer in the setting of log_selector.

You can force a delivery attempt on a specific message (overriding the retry time) by means of the -M option:

exim -M 10hCET-0000Bf-00

If you want to do this for the entire queue, use the -qf option.

Or Login to the server as root and try the following

/scripts/eximup --force

mv /etc/named.conf /etc/named.old

/scripts/rebuildnamedconf > /etc/named.conf

/scripts/fixndc
/etc/init.d/named restart
mail -vv nitinmartand@yahoo.co.in


VE is virtual environment, refer as a VPS

Note: VE is virtual environment, refer as a VPS

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any operation on a VE gives "Cannot lock VE". How do I solve it?

>>

VE is locked when some operation (backup, migration, start / stop, etc.) with this VE is in progress. You can determine which process is holding VE #101 using the following command on the hardware node:

# cat /vz/lock/101.lck

You can kill that process if needed. Make sure that the process is really killed. If there is no process with that PID on the node, just remove the lock file or rename is using mv /vz/lock/101.lck /vz/lock/101.lck.bk

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VE starts but then just shuts down in a few minutes

>>

You probably do not have a valid Virtuozzo license installed - it can be expired or number of VEs is exceeded. Please, check the output of 'vzlicview' command. The status of the license should be ACTIVE and 'used VE' should be not more than 've_total'.


Another possible reason - VE was created with so called class 1 (Light VE) and exceeds defined in license limits for a number of resources such as privvmpages, numproc, shmpages and other. You will find error messages like this in /var/log/messages file on a node:

VE 101 violates UB_PRIVVMPAGES

In this case it is recommended to change VE class to 2 (Unlimited VE) using

'vzctl set VE_ID --class 2 --save'.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

VE starts but displays error "/bin/bash: no such file" or the like.

>>

The owner of the VE could have removed some important package such as bash or glibc.
In this case you may recover VE private area using 'vzctl recover VEID'.

You may also have OS template the VE is abused on missed on hardware node, you may check it using 'vzpkgls VE_ID' and install missed OS template if it is needed.

The VE can also be compromised.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The VE starts but Segmentation fault occurs very soon after starting.
>>
The VE can be compromised

VE can be compromised if its owner uses insecure or out-of-date software. To detect if VE #101 has any rootkits installed one can use the chkrootkit utility either inside the VE or (better) on the hardware node using -r /vz/root/101 parameter. There is also a way to determine which packages were modified on the VE:

- mount VE private area (it may be needed in case VE can not be started):

# vzctl mount 101

- check packages integrity:

# /usr/share/vzpkgtools/vzrpm/bin/rpm --root=/vz/root/101 --veid 101 -Va | egrep '^..5|missing'

This command shows the files that were modified or removed.
Path to the needed package manger (/usr/share/vzpkgtools/vzrpm/bin/rpm n the example above) may be different for different VEs (it depends on OS template of VE). You may check which package manager (PKGMAN) shoud be used in OS template in the file "/vz/template/$OSRELEASE/conf/$OSRELEASE.conf.$OSVERSION" for standard OS template or in the file "/vz/template/$OS/$RELEASE/$ARCH/config/os/default/package_manager" for EZ template, and use appropriate rpm in the command above.
For example, CentOS 4 uses 'PKGMAN=rpm43x86' so the path will be '/usr/share/vzpkgtools/vzrpm43/bin/rpm'

Follow the instructions from the corresponding article to repair a hacked VE.

>>

There are two ways of restoring a VE which is hacked or cannot be started for some other reasons. Please make sure that you have created a full backup of the VE before applying any of the following solutions.

Solution #1:

# vzctl recover 101


This command will reinstall OS template and all application templates, which were previously installed on the VE. This action will make it possible to start the broken VE but it does not give any guarantee that all rootkits are removed, if any.

Solution #2:

# vzctl reinstall 101


This command will create a brand new VE on the same OS template as the broken one, install the same application templates into it and restore users' credentials. The contents of the old VE will be copied into
/old directory.

The VE failed to start with the message like this:
ERROR: Can't write to file /etc/sysconfig/network-scripts/ifcfg-venet0
vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]
vzquota : (warning) block_hard_limit [50100] < block_current_usage [60279]

>>

This error message means that VE exceeded its disk space quota and cannot be started because it is impossible to change system files during VE startup. Solution - increase diskspace (and probably inodes) alloted to VE using 'vzctl' utility:

# vzctl set VE_ID --diskspace BARRIER:LIMIT --save
vzctl set VE_ID --diskinodes BARRIER:LIMIT --save


If increasing blocks and inodes limits does not help, try to re-init quota for this VE with:

# vzctl quotainit VE_ID


Then start VE

HTTPD issue : "(98)Address already in use: make_sock: could not bind to address 0.0.0.0:443"

Error : (98)Address already in use: make_sock: could not bind to address 0.0.0.0:443

Child httpd processes still running and you cannot restart Apache? this is how I fixed the issue of "(98)Address already in use: make_sock: could not bind to address 0.0.0.0:443". If you are getting the error message above it is most likely due to httpd stopping or failing in a faulty manner, you should use the -k graceful option which will advise child processes of httpd to exit after they have completed serving requests, at which time a new 'batch' of child servers can derive from the new confiuration.

Anyways first you need to figure out the PID or process ID listening to the port specified (80 or 443 in my case):

$ lsof -i :80

Kill the httpd child process(es):

$ kill -9 PID

Then find httpd:

$ whereis httpd

Start apache:

$ /usr/sbin/httpd -k start

Reset Plesk’s admin password on windows Server., Reset Plesk’s admin password in Plesk Hosting


Reset Plesk’s admin password on windows Server :

Login to windows server via RDP as a administrator, then open command prompt and run following commands :

C:\Program Files\SWsoft\Plesk\admin\bin\plesksrvclient.exe

execute this file and you will be prompted to enter in a new password for your “admin” plesk user.


You can then log into the plesk interface again and use as normal.



Setting up Private Nameservers in Cpanel

This guide will show you the ropes in how to setup cpanel nameservers and configure them properly so you can run ns1 and ns2.yoursite.com. Once your nameservers are setup clients can then use your own private nameservers for their domains.
1. Regiser your domain
Register the domain name you would like to use, you can register a domain here if you need one.This domain will be used as your nameservers - eg ns1.yourdomain.com and ns2.yourdomain.com
2. Additional IPs
Have 2 available IP addresses for your server that aren't in use.You will need to contact you provider to obtain these IP addreses.
3. Registering the Nameservers
Now login to your domain management page for the domain you registered and register ns1.newdomain.com and ns2.newdomain.com as nameservers (registries normally have a special facility for doing that). The registry may also have a facility to propogate these nameservers around the foreign registries - if so, you should use this facility.
These registrations may take a few days to propagate (often as many as 3 days).

4. Reverse DNS
You may also need to get your data centre to enter a reverse DNS pointer for your nameservers. You'll need to let them know each nameserver and its IP address. Sometimes you can suffer non-delivery of mail if you don't so this. Reverse DNS pointers can take a while to propagate.
Setup a reverse on the IP address for your domain
5. Broken NDC/BIND
My version of WHM/CPanel came with a broken NDC.

To fix this:
SSH into your box as root.
(a) Type: cd /scripts
(b) Type: ./updatenow
(c) Type: ./fixndc
Go back into WHM, go to the Restart Services section in the left menu and click DNS/Nameserver (BIND).
You will need to do this if you start getting 'ndc' errors when you are doing anything DNS related in WHM.
6. Setup Nameservers In WHM
Go into WHM (Web Host Manager) and select Edit Setup from the Server Setup menu on the left. Enter ns1.newdomain.com in the Primary Nameserver field. Hit 'Assign IP Address', then hit 'Add an A Entry for this nameserver'.
Repeat this process for the Secondary Nameserver field.
7. Tidy Up Junk Nameservers
Go into WHM (Web Host Manager) and select Manage Nameserver IPs from the Server Setup menu on the left. Remove any nameservers you don't recognise. This is just a tidy up exercise in case anyone's set anything up on the box before you.
8. Initial Nameserver Setup
Go into WHM (Web Host Manager) and select Initial NameServer Setup from the Server Setup menu on the left. Run this.

9. Restart BIND
Restart BIND (step 7 restarts BIND, but we've known it to need a proper stop and start for it to work) from SSH with:
service named stop
service named start
10. Manual Checks
I don't know what it is about this process, but it doesn't always work, so there are some things you can check manually via SSH.

/etc/wwwacct.conf
Check that the nameservers are correctly specified on NS, NS2 etc.
EG: scroll to the name servers section.....
NS ns1.yournameserver.com
NS2 ns2.yournameserver.com
/etc/resolv.conf
Check that there are nameserver entries for each IP. There may also be one for 127.0.0.1 - this is okay. I'm led to believe (by the 'man' entry for resolv.conf) that this isn't a particularly important file, but I changed mine to read:
domain mybox.com
search mybox.com
nameserver 127.0.0.1
nameserver 111.111.111.111
nameserver 222.222.222.222
Where 'mybox.com' is the main domain of my server, and '111.111.111.111' and '222.222.222.222' are the IP addresses of my primary and secondary nameservers.
resolv.conf is used to lookup names that are not in FQDN format.
/etc/nameserverips
Check that there are entries for each IP acting as a nameserver.
EG:
IP = ns1.yournameserver.com
IP = ns2.yournameserver.com




How to reduce the size of usr by cropping Domlogs

Copy the following contents to a file and execute it.

#!/bin/bash

for domain in /usr/local/apache/domlogs/*;
do
# Find the domain having more than 100 Mb log file size

if [ 3000 -lt `du $domain | awk {'print $1'} 2> /dev/null` ]

then
{
echo $domain;

echo “splitting the file into sizes of 50 Mb each…”;

/usr/local/cpanel/bin/cpuwatch 7.0 split -b 2m $domain ${domain};

echo “Appending the last two sets of files generated”;

for i in `ls ${domain}a*| tail -n 2`;

do

tail -n 2 $i;echo $i;

cat $i >> ${domain}.test;

done

}

cp -f ${domain}.test ${domain};

rm -f ${domain}a* ${domain}.test;

echo “done”;

fi


Pages