Leaderboard (728 x 90)

Tuesday, December 21, 2010

How to Restore SQL Server 2005 Suspect Database

Introduction

If your project's database is in suspect mode, then no transaction will take place until and unless you repair your database. That causes a show stopper for your up and running application. Here, you will find a way to get out of this.

Background

Your Database is in Suspect Mode. I guess, you haven't experienced this problem till now. But, if it comes to you and if the database is LIVE, then it's time to read this article to get out of this tension.

Using the Code

If you find your database in Suspect mode, then please keep your nerve strong. Just proceed step by step what I am written below. I think you will get out of this trouble. SQL Server 2005 introduced a new DB Status called Emergency. This mode can change the DB from Suspect mode to Emergency mode, so that you can retrieve the data in read only mode. The steps are... After executing the script given below, you will get back your database in operational mode. Actually I have tried with two of my existing live systems and found no data loss.

Note: Obviously there are two more options available. Run REPAIR_ALLOW_DATA_LOSS to ensure the database is returned to a structurally and transitionally consistent state. Here are a few things to bear in mind about emergency mode repair: it's a one-way operation. Anything it does cannot be rolled back or undone. If this worries you (if someone ever got into that state, then surely don't have the healthy concern about data that they should have in the first place) then make a copy of the damaged database before you run emergency mode repair.
As it's a one-way operation, you cannot wrap it in an explicit user-transaction.
It's the only repair option available in emergency mode - if you try to use REPAIR_REBUILD, then it won't work.
Collapse

EXEC sp_resetstatus 'yourDBname';
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb('yourDBname')
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER

Points of Interest

You will be happy that your database as well as the application are still in workable condition. :)

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author
Suvendu Banik


Reference: http://www.codeproject.com/KB/reporting-services/SQL_2005_Suspect_Database.aspx

Wednesday, October 27, 2010

Using Passive FTP with ProFTPD

1. Edit your ProFTPD configuration file.

vi /usr/local/etc/proftpd.conf


2. Add the following lines anywhere within the section:


# Restrict the range of ports from which the server will select when
# sent the PASV command from a client. Use IANA-registered
# ephemeral port range of 49152-65534
PassivePorts 49152 65534



3. If you are running ProFTPD in standalone mode, restart ProFTPD. No further action is necessary if ProFTPD is called via inetd or xinetd.

Note: You may need to modify the IP Filter ruleset to allow passive FTP connections by allowing incoming traffic to the port range.

Tuesday, October 26, 2010

CentOS 4 / Redhat Enterprise Linux 4 iSCSI Installation and Configuration ( iscsi initiators )

I've received a couple of email about setting up iSCSI under CentOS 4 or RHEL ES 4 server. Previously, I wrote about iSCSI under CentOS 5 / RHEL 5 server.

Requirements

[a] Following instructions tested on RHEL ES 4 and CentOS 4 only. (See RHEL 5/ CentOS 5 / Debian/ Ubuntu Linux specific instructions here).
[b] You need following information
[c] ISCSI Username
[d] ISCSI Password
[e] ISCSI Server IP / hostname

CentOS Linux v4.x - Install iscsi-initiator-utils

Type the following command:
# yum install iscsi-initiator-utils

Redhat ES Linux v4.x - Install iscsi-initiator-utils

Type the following command:
# up2date iscsi-initiator-utils

Configure iSCSI

Open /etc/iscsi.conf file, enter:
# vi /etc/iscsi.conf

Setup it as follows:

DiscoveryAddress=ISCSI_TARGET_HOST_OR_IP
OutgoingUserName=ISCSI_USER_NAME
OutgoingPassword=ISCSI_PASSWORD
LoginTimeout=15
Save and close the file.

Start the iscsi service

Type the following command to start iscsi service so that you can see block device:
# chkconfig iscsi on
# /etc/init.d/iscsi start

Run any one of the following to find out new block device name:
# fdisk -l
# tail -f /var/log/messages
# find /sys/devices/platform/host* -name "block*"

Format iSCSI device

Use fdisk and mkfs.ext3 commands. First, create a partition (assuming that /dev/sdc is a new block device assigned to iscsi) :
# fdisk /dev/sdc
# mkfs.ext3 /dev/sdc1

Create /mnt/iscsi directory:
# mkdir -p /mnt/iscsi

Open /etc/fstab file and append config directive:
/dev/sdc1 /mnt/iscsi ext3 _netdev 0 0

Save and close the file. Mount the parition /dev/sdc1:
# mount -a
# df -H

CentOS / Red Hat Linux: Install and manage iSCSI Volume

Internet SCSI (iSCSI) is a network protocol s that allows you to use of the SCSI protocol over TCP/IP networks. It is good alternative to Fibre Channel-based SANs. You can easily manage, mount and format iSCSI Volume under Linux. It allows access to SAN storage over Ethernet.

Open-iSCSI Project

Open-iSCSI project is a high-performance, transport independent, multi-platform implementation of iSCSI. Open-iSCSI is partitioned into user and kernel parts.

Instructions are tested on:
[a] RHEL 5
[b] CentOS 5
[c] Fedora 7
[d] Debian / Ubuntu Linux

Install Required Package

iscsi-initiator-utils RPM package - The iscsi package provides the server daemon for the iSCSI protocol, as well as the utility programs used to manage it. iSCSI is a protocol for distributed disk access using SCSI commands sent over Internet Protocol networks. This package is available under Redhat Enterprise Linux / CentOS / Fedora Linux and can be installed using yum command:
# yum install iscsi-initiator-utils

A note about Debian / Ubuntu Linux

If you are using Debian / Ubuntu Linux install open-iscsi package, enter:
$ sudo apt-get install open-iscsi

iSCSI Configuration

There are three steps needed to set up a system to use iSCSI storage:

iSCSI startup using the init script or manual startup. You need to edit and configure iSCSI via /etc/iscsi/iscsid.conf file
Discover targets.
Automate target logins for future system reboots.
You also need to obtain iSCSI username, password and storage server IP address (target host)

Step # 1: Configure iSCSI

Open /etc/iscsi/iscsid.conf with vi text editor:
# vi /etc/iscsi/iscsid.conf

Setup username and password:
node.session.auth.username = My_ISCSI_USR_NAME
node.session.auth.password = MyPassword
discovery.sendtargets.auth.username = My_ISCSI_USR_NAME
discovery.sendtargets.auth.password = MyPassword

Where,

node.session.* is used to set a CHAP username and password for initiator authentication by the target(s).

discovery.sendtargets.* is used to set a discovery session CHAP username and password for the initiator authentication by the target(s)

You may also need to tweak and set other options. Refer to man page for more information. Now start the iscsi service:
# /etc/init.d/iscsi start

Step # 2: Discover targets

Now use iscsiadm command, which is a command-line tool allowing discovery and login to iSCSI targets, as well as access and management of the open-iscsi database. If your storage server IP address is 192.168.1.5, enter:
# iscsiadm -m discovery -t sendtargets -p 192.168.1.5
# /etc/init.d/iscsi restart

Now there should be a block device under /dev directory. To obtain new device name, type:
# fdisk -l

or
# tail -f /var/log/messages

Output:

Oct 10 12:42:20 ora9is2 kernel: Vendor: EQLOGIC Model: 100E-00 Rev: 3.2
Oct 10 12:42:20 ora9is2 kernel: Type: Direct-Access ANSI SCSI revision: 05
Oct 10 12:42:20 ora9is2 kernel: SCSI device sdd: 41963520 512-byte hdwr sectors (21485 MB) Oct 10 12:42:20 ora9is2 kernel: sdd: Write Protect is off
Oct 10 12:42:20 ora9is2 kernel: SCSI device sdd: drive cache: write through
Oct 10 12:42:20 ora9is2 kernel: SCSI device sdd: 41963520 512-byte hdwr sectors (21485 MB) Oct 10 12:42:20 ora9is2 kernel: sdd: Write Protect is off
Oct 10 12:42:20 ora9is2 kernel: SCSI device sdd: drive cache: write through
Oct 10 12:42:20 ora9is2 kernel: sdd: unknown partition table
Oct 10 12:42:20 ora9is2 kernel: sd 3:0:0:0: Attached scsi disk sdd
Oct 10 12:42:20 ora9is2 kernel: sd 3:0:0:0: Attached scsi generic sg3 type 0
Oct 10 12:42:20 ora9is2 kernel: rtc: lost some interrupts at 2048Hz.
Oct 10 12:42:20 ora9is2 iscsid: connection0:0 is operational now

/dev/sdd is my new block device.

Step # 3: Format and Mount iSCSI Volume

You can now partition and create a filesystem on the target using usual fdisk and mkfs.ext3 commands:
# fdisk /dev/sdd
# mke2fs -j -m 0 -O dir_index /dev/sdd1

OR
# mkfs.ext3 /dev/sdd1

Tip: If your volume is large size like 1TB, run mkfs.ext3 in background using nohup:
# nohup mkfs.ext3 /dev/sdd1 &

Mount new partition:
# mkdir /mnt/iscsi
# mount /dev/sdd1 /mnt/iscsi

Step #4: Mount iSCSI drive automatically at boot time

First make sure iscsi service turned on at boot time:
# chkconfig iscsi on

Open /etc/fstab file and append config directive:
/dev/sdd1 /mnt/iscsi ext3 _netdev 0 0

Save and close the file.

Thursday, October 21, 2010

How can I check the password of the IUSR and IWAM local accounts on a machine?

Usually the IUSR_ and IWAM_ passwords are set automatically and are never known. However, I've seen cases in which for some reason the passwords get out of sync or corrupted and need to be reset. The easiest way to reset these passwords is to extract the passwords that Microsoft IIS has in its metabase and update the accounts in Local Users and Groups to use that password.

You first need to update the adsutil.vbs script, which you'll find in the AdminScripts folder under the Inetpub folder, to display sensitive information (e.g., passwords) instead of just asterisks. Open the adsutil.vbs file in Notepad and search for the text "IsSecureProperty = True", replace this text with "IsSecureProperty = False" and save the file. Now run the following commands to return the passwords (/anonymoususerpass is the IUSR account; /wamuserpass is the IWAM_ account).

C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/anonymoususerpass

anonymoususerpass : (STRING) "/XEv`J01T"!69I"

C:\Inetpub\AdminScripts>cscript adsutil.vbs get w3svc/wamuserpass

wamuserpass : (STRING) "ikI37Q"W5\[,uu%"


If you want to reset the passwords to match the passwords you had already set in Local Users and Groups, use the following command:

C:\Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/anonymoususerpass "Pa55word"

anonymoususerpass : (STRING) "Pa55word"

C:\Inetpub\AdminScripts>cscript adsutil.vbs set w3svc/wamuserpass "Pa55word"

wamuserpass : (STRING) "Pa55word"

You should now run the command below to sync the password from IIS with Microsoft Transaction Server (MTS) and component services:


C:\Inetpub\AdminScripts>cscript.exe synciwam.vbs -v

IIS Applications Defined:
Name, AppIsolated, Package ID

You should now restart IIS via the "All Tasks" context menu option of the IIS server in the MMC Internet Information Services (IIS) Manager snap-in.

Retrieve the IUSR (Anonymous) password using the IIS Resource Kit Metabase Explorer

Download and install the IIS Resource Kit and used it to retrieve the password of the IUSR account (IIS Anonymous User.)

After installing the IIS Resource Kit, follow these steps to retrieve the IUSR password using the Metabase Explorer:

  1. Open the IIS Metabase Explorer by going to Start > All Programs > IIS Resources > Metabase Explorer > Metabase Explorer
  2. Go to the "View" menu and click on "Secured Data" (this will make sure the password is not displayed as asterisks) and Inherited Data (this will display any data that the web site is inheriting from the default)
  3. Expand the W3SVC Branch
  4. Expand the Branch of an IIS site that is running anonymous access

    Note: To determine the ID of the IIS Site; select the "Web Sites" node in IIS and look for the Identifier column in the right pane.

  5. Select the "Root" node and look for the AnonymousUserPass property in the right pane.

Tuesday, October 12, 2010

How To Change PostgreSQL Root Password

Here is how to change the PostgreSQL root password from the Linux command line. Replace “root” with any user name to change any password. It is important to note that PostgreSQL does not have an actual “root” user name. The “postgres” user is the super-user for PostgreSQL.

# su postgres
# psql -d template1
template1=# ALTER USER postgres WITH PASSWORD '${POSTGRESQL_POSTGRES_PASSWORD}';


You can replace “postgres” with any user name

Monday, October 4, 2010

Getting OpenSSL to Trust the College CA

The location for certificate store for OpenSSL varies by version:

Red Hat Enterprise Linux 5: /etc/pki/tls/certs
Red Hat Enterprise Linux 4: /usr/share/ssl/certs
Fedora: /etc/pki/tls/certs

1. Change to the directory:

# cd /etc/pki/tls/certs

2. Next download the College root certificate:

# wget http://icca1.cc.ic.ac.uk/cdp/icrootca.cer

3. Create a link with the certificate hash:

# ln -s icrootca.cer `openssl x509 -hash -noout -in icrootca.cer`.0

4. You now need to repeat this for the College intermediate CA:

# wget http://icca1.cc.ic.ac.uk/cdp/icca.cer
# ln -s icca.cer `openssl x509 -hash -noout -in icca.cer`.0

The installation is now complete. You can verify that this has been successfull as follows - ensure both command return "OK":

# openssl verify -CApath /etc/pki/tls/certs icrootca.cer
icrootca.cer: OK
# openssl verify -CApath /etc/pki/tls/certs icca.cer
icca.cer: OK

Now you can connect to an SSL enabled web server that uses the College CA:

# openssl s_client -showcerts -connect icca1.cc.ic.ac.uk:443 -CApath /etc/pki/tls/certs

Ensure the resulting output displays the certifcates and gives no errors.

If you want to enable LDAPS (LDAP over SSL) under OpenLDAP, you need to repeat the above process but in /etc/openldap/cacerts (and make the appropriate changes in ldap.conf).

Reference: http://www3.imperial.ac.uk/ict/services/securitynetworkdatacentreandtelephonyservices/security/securityservices/publickeyinfrastructure/installcaonlinux

Friday, September 24, 2010

LVM in rescue mode

e2fsck:

  • Boot into rescue mode (in RHEL/Fedora this means putting in CD 1 and typing "linux rescue" at the boot prompt -- but it's essentially any minimal live CD). Rescue mode does not do anything with LVM by defualt: to activiate the volume groups, you need to issue these:

    #lvm vgscan
    #lvm vgchange -ay
    #lvm lvs

  • lvs will simply display your volume group and logical volume names, use this output to issue the e2fsck command: e2fsck /dev/volumegroupname/logicalvolumename. Of course, pass what ever options ot e2fsck you normally would (like -y or -c).
Re-name the / volume group:

  • I never thought I'd have a legitimate reason to do this, until I found myself wanting to back up data from one disc (from a dead system) on to another system. I always choose the default names for VGs and LVs, so when I put my extra disc into my live system it choked finding two volume groups named "VolumeGroup00".


    Take out that second disc, then boot into rescue mode (do not mount anything and do not run the lvm commands from the previous example):

    #vgrename VolumeGroup00 newname

    Where VolumeGroup00 is the old name, and "newname" is the newname. If this was not the root filesystem we would be done and could happily reboot as normal. But, since this IS the root file system, we need to remake the initial ramdisk first (if you don't have one of those, you're off the hook):


    #mount /dev/newname/LogVol00 /mnt/sysimage
    #mount /dev/sda1 /mnt/sysimage/boot
    #chroot /mnt/sysimage
    #cp /boot/initrd-kernelversion.img /boot/kernelversion.img.old
    #mkinitrd -v -f /boot/initrd-kernelversion.img kernelversion

    Don't forget to change all references to the old VG name. Typically this would be in grub.conf and fstab. After that, reboot with that second disc added and you should be fine

    Reference: http://samfw.blogspot.com/2005/12/lvm-in-rescue-mode.html

  • Thursday, September 23, 2010

    How to change the listening port for Remote Desktop

    Warning! The Remote Assistance feature in Microsoft Windows XP may not work correctly if you change the listening port.

    1. Start Registry Editor.
    2. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
    3. On the Edit menu, click Modify, and then click Decimal.
    4. Type the new port number, and then click OK.
    5. Quit Registry Editor.

    Tuesday, September 21, 2010

    How to uninstall Parallels Virtuozzo for Linux

    1. stop Virtuozzo services
    service vz stop

    2. uninstall all Virtuozzo packages
    rpm -qa|grep swsoft|grep vz|xargs yum remove -y
    rpm -qa|grep swsoft|grep -E "virtu|-ez-|-tmpl-"|xargs yum remove -y

    3. remove /vz contents (directories: actionlog, backups, lock, private, root, template, vzup2date)
    cd /vz/ && mkdir _before_reinstall && mv * _before_reinstall

    4. remove configs from /etc
    mkdir -p /vz/_before_reinstall/etc && find /etc -name vz\* -exec mv {} /vz/_before_reinstall/etc \;

    5. check /etc/grub.conf if it has a proper configuration (no Virtuozzo kernel, Red Hat kernel is default)

    6. check /etc/sysctl.conf for tuned parameters which you might not need

    7. reboot the server

    Reference: http://forum.parallels.com/showthread.php?t=72613 by Alec@sw

    Friday, September 17, 2010

    Viewing a Name Server's Cache

    You want to view a name server's cached data.

    Solution
    Use rndc dumpdb (BIND 9) or ndc dumpdb (BIND 8) to dump the cache to disk, then look through the dump file.

    Discussion
    BIND 9 name servers only dump the contents of the cache to disk by default, but BIND 8 name servers dump both the contents of cache and authoritative zone data to disk, so you'll have to find the cached records in the file.

    To determine which records in a BIND 8 database dump were cached, look at the TTLs and the contents of the comment field. Authoritative zone data will have the nice, round TTLs you configured, while cached records will have had their TTLs decremented by the number of seconds they've been in the cache. Cached records will also have "Cr=" as a comment at the end of the record, giving the credibility level of the record (an indication of the quality of the cached record). For example, these records were cached from an authoritative response from the name server at 128.9.0.107:

    . 518380 IN NS I.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS E.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS D.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS A.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS H.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS C.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS G.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS F.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS B.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS J.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS K.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS L.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]
    518380 IN NS M.ROOT-SERVERS.NET. ;Cr=auth [128.9.0.107]

    Remember that dumping the cache to disk has no effect on the contents of the cache. If you want to flush (clear) the cache, see Flushing (Clearing) a Name Server's Cache.

    Flushing (Clearing) a Name Server's Cache
    Problem
    You want to flush bad records from a name server's cache.

    Solution
    If you run a BIND 9.2.0 or newer name server, you can flush the cache with rndc flush. With older name servers, you need to kill the name server and restart it to flush the cache. You can do that in one fell swoop with rndc restart or rndc exec.

    Discussion
    Clearing the cache is really a side effect of killing the name server, since BIND name servers only store cached data in memory. Since restarting the name server takes time, especially if the name server is authoritative for many zones, rndc flush is a better option.

    If you run multiple views on your BIND 9.2.0 or newer name server, you can flush the cache in only one view using rndc flush viewname. For example:

    # rndc flush internal
    BIND 9.3.0 will support flushing all of the records attached to a particular domain name with rndc flushname. For example:

    # rndc flushname cnn.com

    Modifying Zone Data Without Restarting the Name Server
    Problem

    You want to modify your zone data without restarting the name server.

    Solution
    Make the change to the zone data file. For BIND 9, run:

    # rndc reload domain-name-of-zone
    For BIND 8, run:

    # ndc reload domain-name-of-zone
    If you've modified multiple zones, just list them after reload. For example:

    # rndc reload foo.example bar.example
    Discussion
    Remember to increment the serial number in your zone's SOA record after changing the zone data. The primary master reloads the zone regardless of whether you've incremented the serial number, since the file's modification time has changed, but your zone's slaves only have the serial number to tell them whether the zone has been updated.

    Reloading individual zones, as shown above, was introduced in BIND 8.2.1 and again in 9.1.0. With older versions of BIND, just use rndc reload or ndc reload, as appropriate. That takes a little more time, since the name server checks all zone data files to see which have changed.

    If you're reloading a zone that exists in multiple views on a BIND 9 name server, specify the view with rndc reload domain-name-of-zone class view. For example:

    # rndc reload foo.example in external
    Unfortunately, you can't leave out the class, even though you're unlikely ever to reload a non-Internet class zone.

    Telling a BIND 9 name server to reload a dynamically updated zone has no effect, since the name server doesn't expect you to update the zone manually. Telling a BIND 8 name server to reload a dynamically updated zone may work--or you may lose your manual changes.

    Dynamic update is, of course, another way to update zone data without restarting the name server

    Thursday, August 26, 2010

    Changing your default language for redhat-based Linux Distribution

    Gnome GUI
    method 1. Go to System => Administration => Language then change your default language.
    method 2. Open terminal then run system-config-language then change your default language.


    Manually Edit Configuration
    1. cd /etc/sysconfig

    Make backup copy of your language setting file
    2. cp i18n i18n.bak

    Edit language setting file to allow english as default
    3. vi i18n
    5. Edit the file to include these lines as the first three lines of the file:
    LANG="en_US.UTF-8"
    SYSFONT="latarcyrheb-sun16"
    SUPPORTED="en_US.UTF-8:en_US:en"

    6. Save the file and restart system. If you can not restart the system you need to have permission to restart init.d

    Thursday, August 5, 2010

    Where is default configuration path for spamassassin?

    The default rules directory is /usr/share/spamassassin
    The site rules directory is /etc/mail/spamassassin
    The updated rules directory is /var/lib/spamassassin

    Clarification of changes on "allow-recursion" and "allow-query-cache" in BIND 9.4.1

    Everyone upgrading from older BIND versions to BIND 9.4.1 or newer should check if this change has effects on the nameserver:

    There has been some confusion surrounding the changes to the "allow-recursion" and "allow-query-cache" options made with BIND 9.4.1-P1.

    This document will attempt to clarify the change and the impact that it makes on BIND servers.

    In BIND 9.3, there was no segregation of queries between cache and authoritative data.

    The release of BIND 9.4 added fine-grained differentiation between queries against authoritative data ("allow-query") and cached data ("allow-query-cache"). This allows more precise control, particularly if you do not want your clients to use any cached data, for example, in an authoritative-only nameserver.

    Prior to the release of BIND 9.4.1-P1, the default action of "allow-recursion" and "allow-query-cache" was to permit the query. The P1 patch to BIND 9.4.1 caused two changes in this behavior:

    1) If not explicitly set, the ACLs for "allow-query-cache" and "allow-recursion" were set to "localnets; localhost;".

    2) If either "allow-query-cache" or "allow-recursion" was set, the other would be set the same value.

    Upgrading from the BIND 9.3 branch to BIND 9.4.1-P1 will significantly restrict those servers that were previously recursive servers for more than "localhost; localnets;" unless configuration changes are made.

    To retain the behavior prior to BIND 9.4.1-P1, the following entries should be created in your named.conf file:
    Code:

    options {
    ...
    allow-recursion { any; };
    allow-query { any; };
    allow-query-cache { any; };
    ...
    };

    We strongly advise against this configuration because clients spoofing queries can use your servers to launch distributed denial-of-service attacks.

    The recommended method is to create ACLs that match hosts that should be allowed access to cache and recursion on the servers. For example, if you wanted to provided recursion and access to the cache to clients you trusted, you could list them in an ACL such as the following:
    Code:

    acl "trusted" {
    192.168.0.0/16;
    10.153.154.0/24;
    localhost;
    localnets;
    };
    options {
    ...
    allow-query { any; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };
    ...
    };

    This example ACL includes 192.168.0.0/16 and 10.153.154.0/24 as sample networks that would require access. You must replace these sample networks with networks that correctly reflect your environment. This will allow anyone to query your server for authoritative data, but only those hosts within the "trusted" ACL access to your cache and recursion.

    Wednesday, August 4, 2010

    How to list running application pool in IIS 6.0?

    You can use the command-line script iisapp.vbs, which is stored in systemroot\system32, to view any worker processes that are currently running. This command is often used for troubleshooting.

    The computer issuing the command must be running Windows XP or a member of the Windows Server 2003 family. The computer that the command affects must be running a member of the Windows Server 2003 family with IIS 6.0.

    !!! Important

    You must be a member of the Administrators group on the local computer to run scripts and executables. As a security best practice, log on to your computer by using an account that is not in the Administrators group, and then use the runas command to run your script or executable as an administrator. At a command prompt, type runas /profile /User:MyComputer\Administrator cmd to open a command window with administrator rights and then type cscript.exeScriptName (include the script's full path and any parameters).

    This topic includes the following information:

    Syntax: The order in which you must type a command and any arguments and options that follow it.

    Parameters: The values that are given to variables in the command.

    Examples: Sample code and an explanation of the results.

    Syntax

    iisapp [/a AppPoolName | /p PID]

    Parameters

    /aAppPoolName

    Optional. Specifies the name of a particular application pool.

    /pPID

    Optional. Specifies an application pool by its ID number.

    Examples

    Example 1:

    The following command displays all of the application pools that are running on the local computer:

    iisapp

    In response, iisapp displays all of the currently running applications, identifying each application pool by its process ID (PID) and application pool ID (AppPoolID). Iisapp omits all of the optional parameters and accepts the default values.

    W3wp.exe PID: 2232 AppPoolID: DefaultAppPool

    W3wp.exe PID: 2608 AppPoolID: MyAppPool

    Example 2:

    Use the following command to view a specific application by entering its PID:

    iisapp /p 2608

    In response, iisapp displays the specified application.

    W3wp.exe PID: 2608 AppPoolID: MyAppPool

    Tuesday, August 3, 2010

    how to upgrade CPAN module for perl

    run these command

    perl -MCPAN -e 'shell'

    then enter these command
    # install Bundle::CPAN
    # reload cpan

    how to install perl module

    method 1:

    run command

    perl -MCPAN -e 'install Module::Name'

    or run

    perl -MCPAN -e 'shell'

    then enter these command
    # install Module::Name

    Module::Name is name of module which need to install

    method 2:

    download module source code you need to install

    - extract source code archive (untar and unzip)
    - change directory to source code path
    - run these commands.
    # perl MakeFile.PL
    # make
    # make test
    # make install

    Prereq 'v0.002.1' for 'Net::DNS::Resolver::Programmable' is not supported by Module::Build::Compat

    Problem:

    When I run

    perl -MCPAN -e 'install Mail::SPF'

    I get this

    CPAN: Storable loaded ok
    Going to read /root/.cpan/Metadata
    Database was generated on Sat, 06 Feb 2010 07:43:02 GMT
    Running install for module Mail::SPF
    Running make for J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
    CPAN: Digest::MD5 loaded ok
    CPAN: Compress::Zlib loaded ok
    Checksum for /root/.cpan/sources/authors/id/J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz ok
    Scanning cache /root/.cpan/build for sizes
    Mail-SPF-v2.007
    Mail-SPF-v2.007/MANIFEST
    Mail-SPF-v2.007/TODO
    Mail-SPF-v2.007/CHANGES
    Mail-SPF-v2.007/META.yml
    Mail-SPF-v2.007/MANIFEST.SKIP
    Mail-SPF-v2.007/INSTALL
    Mail-SPF-v2.007/README
    Mail-SPF-v2.007/Makefile.PL
    Mail-SPF-v2.007/LICENSE
    Mail-SPF-v2.007/Build.PL
    Mail-SPF-v2.007/SIGNATURE
    Mail-SPF-v2.007/lib
    Mail-SPF-v2.007/lib/Mail
    Mail-SPF-v2.007/lib/Mail/SPF.pm
    Mail-SPF-v2.007/lib/Mail/SPF
    Mail-SPF-v2.007/lib/Mail/SPF/Server.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Util.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mod.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Result.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Request.pm
    Mail-SPF-v2.007/lib/Mail/SPF/MacroString.pm
    Mail-SPF-v2.007/lib/Mail/SPF/SenderIPAddrMech.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Exception.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Base.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Term.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Record.pm
    Mail-SPF-v2.007/lib/Mail/SPF/v1
    Mail-SPF-v2.007/lib/Mail/SPF/v1/Record.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mod
    Mail-SPF-v2.007/lib/Mail/SPF/Mod/Redirect.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mod/Exp.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/PTR.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/A.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/All.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/IP6.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/MX.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/Include.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/Exists.pm
    Mail-SPF-v2.007/lib/Mail/SPF/Mech/IP4.pm
    Mail-SPF-v2.007/lib/Mail/SPF/v2
    Mail-SPF-v2.007/lib/Mail/SPF/v2/Record.pm
    Mail-SPF-v2.007/debian
    Mail-SPF-v2.007/debian/libmail-spf-perl.install
    Mail-SPF-v2.007/debian/spf-tools-perl.postinst
    Mail-SPF-v2.007/debian/rules
    Mail-SPF-v2.007/debian/compat
    Mail-SPF-v2.007/debian/changelog
    Mail-SPF-v2.007/debian/watch
    Mail-SPF-v2.007/debian/spf-tools-perl.prerm
    Mail-SPF-v2.007/debian/copyright
    Mail-SPF-v2.007/debian/spf-tools-perl.install
    Mail-SPF-v2.007/debian/control
    Mail-SPF-v2.007/bin
    Mail-SPF-v2.007/bin/spfquery
    Mail-SPF-v2.007/t
    Mail-SPF-v2.007/t/Mail-SPF-Test-lib.pm
    Mail-SPF-v2.007/t/90-author-pod-validation.t
    Mail-SPF-v2.007/t/00.01-class-util.t
    Mail-SPF-v2.007/t/10.00-rfc4408.t
    Mail-SPF-v2.007/t/rfc4408-tests.yml
    Mail-SPF-v2.007/t/10.01-rfc4406.t
    Mail-SPF-v2.007/t/00.04-class-server.t
    Mail-SPF-v2.007/t/00.05-class-macrostring.t
    Mail-SPF-v2.007/t/00.00-class-misc.t
    Mail-SPF-v2.007/t/00.02-class-request.t
    Mail-SPF-v2.007/t/rfc4406-tests.yml
    Mail-SPF-v2.007/t/00.99-class-misc.t
    Mail-SPF-v2.007/t/00.03-class-result.t
    Mail-SPF-v2.007/sbin
    Mail-SPF-v2.007/sbin/spfd
    Removing previously used /root/.cpan/build/Mail-SPF-v2.007

    CPAN.pm: Going to build J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz

    # running Build.PL
    Creating new 'MYMETA.yml' with configuration results
    Creating new 'Build' script for 'Mail-SPF' version 'v2.7.0'
    Prereq 'v0.002.1' for 'Net::DNS::Resolver::Programmable' is not supported by Module::Build::Compat
    Running make test
    Make had some problems, maybe interrupted? Won't test
    Running make install
    Make had some problems, maybe interrupted? Won't install

    Resolution:

    run this command

    perl -MCPAN -e 'install Bundle::CPAN'

    with successfully installed

    Thursday, July 29, 2010

    Default Seach Provider corrupt in IE8

    When you install IE7 or IE8 on winxp sp2 before upgrade windows to sp3, you will can't remove IE7/IE8 by Add and Remove Program.

    If you upgrade IE7 to IE8 on winxp sp3, you may receive following error when you launch IE.


    Resolution:

    1. Click Start.
    2. Click Run.
    3. Type in regedit and press enter.
    4. In the registry editor, expand and navigate to the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders.
    5. Right click User Shell Folders.
    6. Select New and then Expandable String value.
    7. A new value is added in right pane.
    8. Type in AppData and press enter.
    9. Double click AppData.
    10. Under value data type in:

    %USERPROFILE%\Application Data

    11. Note: If there is already AppData in the right pane, double click and correct it to %USERPROFILE%\Application Data

    If the above steps do not work,
    1. Click Start.
    2. Click Control Panel.
    3. Click User Accounts.
    4. Click Create a new user account.
    5. Choose appropirate name for the new user account.
    6. Choose Administrator or Limited or Standard user. It's upto you.
    7. Click Create.
    8. Click Start, Log out from the current user account and log back in with the new one.
    9. If the new user account is working for you, obviously, the old user account has got corrupted and you will have to use the new user account. Also, FYI: you can transfer old user settings and files to the new user account.

    Controlling Core Dump Files in Linux

    การเกิด core dump ได้นั้น สาเหตุหลักๆคือ การทำงานผิดพลาดของโปรแกรม (program crash) หรือ อีกสาเหตุเกิดจากการที่ program พยายาม access memory ในส่วนที่ไม่ได้รับอนุญาต จึงทำให้ OS สั่งปิดโปรแกรม (Kill process) นั้นซะ จากเหตุการณ์ทั้งสอง OS ก็ได้สร้าง Core dump file ขึ้นมาเพื่อช่วยให้เหล่า programmer ทั้งหลายพบจุดผิดพลาดของโปรแกรม หรือ ช่วยในการ debug โปรแกรมนั้นเอง

    ลักษณะของ core file นั้นสามารถสังเกตุได้ว่าไฟล์จะชื่อขึ้นต้นด้วยคำว่า core และตามด้วยจุดกับตัวเลข (ซึ่งก็คือ PID) เช่น core.20 เป็นต้น

    เรามาดูกันว่าเราจะจัดการเจ้า core file ได้อย่างไรบ้างกันดีกว่า

    ถ้าต้องการปิดไม่ให้มีการสร้าง core file ขึ้นมาให้ใช้คำสั่ง

    #ulimit -S -c 0 > /dev/null 2>&1

    ถ้าต้องการเปิดให้มีการเขียน core file ได้ให้ใช้คำสั่ง

    #ulimit -S -c 25000 > /dev/null 2>&1 //กำหนดให้ core file มีขนาดเท่ากับ 25,000 byte
    #ulimit -S -c unlimited > /dev/null 2>&1 //กำหนดให้ core file มีขนาดไม่จำกัด

    -c คือขนาดสูงสุดของ core file

    หรือถ้าต้องการให้ใช้งานตลอดไปให้แก้ไขไฟล์ /etc/profile แล้วเพิ่มคำสั่งข้างต้นลงไป

    เรายังสามารถกำหนด path ที่เก็บและชื่อของ core file ว่าจะขึ้นต้นว่าอะไรได้ด้วย ซึ่งก็ให้ใส่ค่า path และชื่อไฟล์ที่ต้องการไปในไฟล์ proc/sys/kernel/core_pattern โดยใช้คำสั่ง echo เช่น กำหนดให้ core file ไปถูกเขียนใน directory ที่ /path/corefile และชื่อ file ชื่อว่า core

    #echo “/path/corefiles/core” > /proc/sys/kernel/core_pattern

    ด้านล่างนี้เป็น parameter ที่สามารถใช้ได้กับคำสั่งการแก้ไข core pattern

    • %% – A single % character
    • %p – PID of dumped process
    • %u – real UID of dumped process
    • %g – real GID of dumped process
    • %s – number of signal causing dump
    • %t – time of dump (secs since 0:00h, 1 Jan 1970)
    • %h – hostname (same as the ‘nodename’ returned by uname(2))
    • %e – executable filename

    จากข้างต้นโดย default แล้วเวลาเกิดการเขียน core file จะมีการใส่เลข .PID เข้าไปหลังชื่อ core file เราสามารถกำหนดไม่ให้มีการใส่ .PID เข้าไปหลังจากระบบ dump core file ได้โดยใช้คำสั่ง

    #echo “0″ > /proc/sys/kernel/core_uses_pid

    สุดท้ายทดสอบการเซตค่าการสร้าง core file โดยใช้คำสั่ง

    #kill -s SIGSEGV $$

    Reference:

    http://www.ezylinux.com/system/controlling-core-dump-files-in-linux/

    Enable Core Dumps for Daemons or Services in Red Hat Enterprise Linux

    โดยทั่วไปแล้ว daemon เป็นการทำงานในรูปแบบ background process การสั่งให้ deamon ทำงานสามารถทำได้โดยใช้ service command หรือ ใช้ init script การเปิดใช้งาน core dump (ดูรายละเอียดของ core dump ได้ที่ Core dump file) เพื่อใช้งานการ debug ของโปรแกรมหรือตามความต้องการเพื่อตรวจสอบข้อผิดพลาดของโปรแกรม

    การ enable core dump สำหรับ daemon หรือ service สามารถทำได้ดังนี้

    1. แก้ไขไฟล์ /etc/profile ด้วยคำสั่ง vi /etc/profile
    2.     แก้ไขบรรทัด     ulimit -S -c 0 > /dev/null 2>&1      แก้ไขเป็น
                              ulimit -c unlimited >/dev/null 2>&1
    3. แก้ไขไฟล์ /etc/sysconfig/init ด้วยการเพิ่ม DAEMON_COREFILE_LIMIT=’unlimited’ เข้าไป
    4. โดยทั่วไปแล้ว core dump ไม่สามารถสร้างโดยโปรแกรมที่รันด้วย setuid เพื่อป้องกันข้อมูลรั่วไหลออกไปยัง user อื่น ดังนั้นเราจึงต้องแก้ไขให้สามารถทำ core dump ใน setuid program ด้วย
      • สำหรับ Red Hat Enterprise Linux 5:
      • echo 2 > /proc/sys/fs/suid_dumpable
      • สำหรับ Red Hat Enterprise Linux 4:
      • echo 2 > /proc/sys/kernel/suid_dumpable
      • สำหรับ Red Hat Enterprise Linux 3:
      • echo 1 > /proc/sys/kernel/core_setuid_ok
    5. แก้ไขไฟล์ /etc/sysctl.conf เพื่อเพิ่มข้อความด้านล่างลงไป
    6. fs.suid_dumpable = 2      # RHEL 5 only 
      kernel.suid_dumpable = 2  # RHEL 4 only 
      kernel.core_setuid_ok = 1 # RHEL 3 only 
      kernel.core_pattern = /tmp/core
    7. Reload settings ด้วยการใช้คำสั่ง sysctl -p
    Reference:

    Sunday, July 25, 2010

    TCP/IP Stack Hardening

    If you run a UNIX-like operating system, you can make it more secure by slightly modifying the behavior of its TCP/IP implementation.

    This page lists modifications for the various TCP/IP protocols. For the most part, these are commands that would go into a boot script such as /etc/rc.sysinit or /etc/rc.local.

    The tables only list the possible commands — some tuning steps are not possible (at least as far as I know) on certain UNIX implementations.

    If there is a dangerous type of packet that might be allowed under a strict interpretation of the protocols, but which is currently considered to be risky, the listed commands frequently list how to both ignore inbound packets and refuse to send outbound packets. This prevents your host from being victimized and prevents it from being used to launch attacks.

    This page only describes how to harden the TCP/IP stack on UNIX-like operating systems. It is based on the recommendations found in the following pages, plus my commentary and explanation:

    ARP

    Decrease the ARP cache cleanup interval.

    AIXno -o arpt_killc=20
    FreeBSDsysctl -w net.link.ether.inet.max_age=1200
    Solarisndd -set /dev/arp arp_cleanup_interval 60000

    Consider static ARP (but also consider the maintenance problems!). This does not scale well to routine use on LANs, but it might be worth its trouble on a small sensitive LAN — a DMZ LAN in your network perimeter, or a small LAN populated by a few sensitive servers and a router port.Remember that if you change the Ethernet card in one machine, you must then modify and re-run the static ARP script boot script on every host on that LAN!

    If you want to do this, you will need a script like the following, with IP and MAC addresses changed as needed. For thorough paranoia, define a MAC address for all possible IP addresses on the LAN, even ones not in use. For the unused IP addresses, use a MAC address that you know will not exist on that LAN (maybe that of an Ethernet card on another LAN).

    arp -s 10.1.1.1 00:02:E3:05:9F:A3
    arp -s 10.1.1.2 00:08:C7:29:E7:31
    arp -s 10.1.1.3 00:60:97:B9:3B:B5
    ... and so on ...

    ICMP

    Disable ICMP broadcast echo activity. Otherwise, your system could be used as part of a Smurf attack:

    AIXno -o directed_broadcast=0
    FreeBSDsysctl -w net.inet.icmp.bmcastecho=0
    HP-UXndd -set /dev/ip ip_respond_to_echo_broadcast 0
    ndd -set /dev/ip ip_forward_directed_broadcasts 0
    IRIXsystune allow_brdaddr_srcaddr 0
    Linuxsysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
    OpenBSDAlready ignores these by default
    Solarisndd -set /dev/ip ip_respond_to_echo_broadcast 0
    ndd -set /dev/ip ip6_respond_to_echo_multicast 0
    ndd -set /dev/ip ip_forward_directed_broadcasts
    0

    Disable ICMP routing redirects. Otherwise, your system could have its routing table misadjusted by an attacker.

    AIXno -o ipignoreredirects=1
    no -o ipsendredirects=0
    FreeBSDsysctl -w net.inet.ip.redirect=0
    sysctl -w net.inet.ip6.redirect=0
    HP-UXndd -set /dev/ip ip_send_redirects 0
    ndd -set /dev/ip ip_forward_directed_broadcasts 0
    IRIXsystune icmp_dropredirects 1
    Linuxsysctl -w net.ipv4.conf.all.accept_redirects=0
    sysctl -w net.ipv6.conf.all.accept_redirects=0
    sysctl -w net.ipv4.conf.all.send_redirects=0
    sysctl -w net.ipv6.conf.all.send_redirects=0
    OpenBSDsysctl -w net.inet.icmp.rediraccept=0
    sysctl -w net.inet6.icmp6.rediraccept=0

    Those two disable the
    acceptance of ICMP Redirect.
    To disable
    sending ICMP Redirect messages:
    sysctl -w net.inet.ip.redirect=0
    sysctl -w net.inet6.ip6.redirect=0
    Solarisndd -set /dev/ip ip_ignore_redirect 1
    ndd -set /dev/ip ip6_ignore_redirect 1
    ndd -set /dev/ip ip_send_redirects 0
    ndd -set /dev/ip ip6_send_redirects 0


    Disable ICMP router solicitations and advertisements, and ICMP subnet mask requests and replies. An attacker might be able to use unsolicited advertisements and replies to misadjust host routing tables. An attack also might be able to use solicitations and requests to reverse engineer some details of your network infrastructure. It appears that you will have to do this with packet-filtering rules on the host.

    Disable ICMP broadcast probes. Otherwise, an attacker might be able to reverse engineer some details of your network infrastructure.

    AIXno -o icmpaddressmask=0
    FreeBSDsysctl -w net.inet.icmp.maskrepl=0
    HP-UXndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
    ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
    IRIXYou will have to block these with a packet filter like ipfilterd
    LinuxYou will have to block these with a packet filter like iptables
    OpenBSDAlready ignores these by default
    Solarisndd -set /dev/ip ip_respond_to_address_mask_broadcast 0
    ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0

    IP

    Disable IP source routing. The only use of IP source routing these days is by attackers trying to spoof IP addresses that you would trust as internal hosts.

    AIXno -o ipsrcroutesend=0
    no -o ipsrcrouteforward=0
    FreeBSDsysctl -w net.inet.ip.sourceroute=0
    sysctl -w net.inet.ip.accept_sourceroute=0
    HP-UXndd -set /dev/ip ip_src_route_forward 0
    IRIXsystune ipforward 2
    Linuxsysctl -w net.ipv4.conf.all.accept_source_route=0
    sysctl -w net.ipv4.conf.all.forwarding=0
    sysctl -w net.ipv4.conf.all.mc_forwarding=0
    OpenBSDAlready ignores these by default
    Solarisndd -set /dev/ip ip_forward_src_routed 0
    ndd -set /dev/ip ip6_forward_src_routed 0

    Enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived.

    Linuxsysctl -w net.ipv4.conf.all.rp_filter=1

    Log and drop "Martian" packets. A "Martian" packet is one for which the host does not have a route back to the source IP address (it apparently dropped in from Mars). These days most hosts have a default route, meaning that there would be no such thing as a Martian packet, but to be safe and complete...

    Linuxsysctl -w net.ipv4.conf.all.log_martians=1

    Enforce strict multi-homing for non-forwarding multi-homed systems. If a host is connected to more than one LAN, but it should not act as an IP router, make certain that it does not forward IP datagrams between networks. Maybe it is a firewall, or maybe it is just a multi-homed host.

    Solarisndd -set /dev/ip ip_strict_dst_multihoming 1
    ndd -set /dev/ip ip6_strict_dst_multihoming 1


    TCP

    Increase resiliance under heavy TCP load (which makes the system more resistant to SYN Flood attacks). There are five major steps to making a system more resiliant under heavy, possibly malicious, TCP load:

    • Buy more RAM. Each inbound SYN packet is intended to establish a TCP circuit, which requires resources on the server. The TCP buffers require memory to be allocated.
    • Use TCP SYN Cookies (Linux and BSD only). With TCP Syn Cookies, the kernel does not really allocate the TCP buffers unless the server's ACK/SYN packet gets an ACK back, meaning that it was a legitimate request.
    • Reduce the allowed number of HALF_OPEN TCP circuits. Further requests are refused, a denial of service, but at least the server hasn't run out of memory.
    • Reduce the amount of time an opening TCP circuit can stay in the HALF_OPEN state. The server is made less patient — if the TCP circuit is not fully established quickly, it is dropped and the client, if legitimate but very slow, must start again.
    • Reduce the amount of time a closing TCP circuit can stay in the TIME_WAIT state. Some clients are very rude, apparently Microsoft Explorer is particularly bad. They establish a connection, get their data, but then refuse to participate in cleanly shutting down the TCP circuit. At least for busy web servers, make them very impatient with such nonsense, dropping these no longer active connections and freeing resources.

    The following show the vendor recommendations for tuning the TCP queue length and circuit establishment timers, and how to reduce TCP TIME_WAIT to 60 seconds.

    AIXno -o clean_partial_conns=1
    FreeBSDsysctl -w kern.ipc.somaxconn=1024
    HP-UXndd -set /dev/tcp tcp_syn_rcvd_max 1024
    ndd -set /dev/tcp tcp_conn_request_max 200 ndd -set /dev/tcp tcp_time_wait_interval 60000
    IRIXsystune tcp_2msl 60
    The kernel automatically limits the queue of pending connections.
    Linuxsysctl -w net.ipv4.tcp_max_syn_backlog=1280
    sysctl -w net.ipv4.tcp_syncookies=1

    Already drops inactive TCP connections within 60 seconds
    OpenBSDAlready has a resilient TCP implementation by default
    Solarisndd -set /dev/tcp tcp_conn_req_max_q 1024
    ndd -set /dev/tcp tcp_conn_req_max_q0 4096
    ndd -set /dev/tcp tcp_time_wait_interval 60000

    Defend against TCP connection hijacking by following the recommendations of RFC 1948. Most UNIX implementations use RFC 1948 recommendations to generate initial sequence numbers, but Solaris (at least up through Solaris 8) needs a little help.

    Solarisndd -set /dev/tcp tcp_strong_iss 2
    To configure this behavior to be the default after future reboots, put the line
    TCP_STRONG_ISS=2 in the file /etc/default/inetinit

    Increase TCP send and receive window sizes to at least 32 kbytes. But do not increase these above 64 kbytes unless you fully understand and support both RFC 1323 andRFC 2018.

    AIXno -o tcp_sendspace=32768
    no -o tcp_recvspace=32768
    FreeBSDsysctl -w net.inet.tcp.sendspace=32768
    sysctl -w net.inet.tcp.recvspace=32768
    HP-UXThe TCP send and receive spaces are 32 kbytes by default.
    IRIXThe TCP send and receive spaces are 64 kbytes by default.
    LinuxThe kernel supports RFC 1323 and RFC 2018 and dynamically adjusts the TCP send and receive space by default
    OpenBSDThe kernel supports RFC 1323 and RFC 2018 and dynamically adjusts the TCP send and receive space by default
    Solarisndd -set /dev/tcp tcp_xmit_hwat 32768
    ndd -set /dev/tcp tcp_recv_hwat 32768


    Reference: