Download getmail at http://pyropus.ca/software/getmail/old-versions/getmail-4.20.3.tar.gz

wget http://pyropus.ca/software/getmail/old-versions/getmail-4.20.3.tar.gz
tar xzf getmail-4.20.3.tar.gz
cd getmail*
python setup.py install

Now you have to create a getmailrc , the getmail configuration file inside the home folder of the user. getmailrc need not be inside the home directory. You have to create the folder .getmail where getmail keeps a log of the emails retrieved based on each configuration file you may have.You can have multiple destination and retriever sections in one single getmailrc as well.

I must say getmail is so much flexible and rightly coded when the mailsync or imapsync didn’t do their job right or up to the mark. And is an excellent replacement for fetchmail. It supports POP, POP3S, IMAP4 and IMAPS, and also can store the mails retrieved in mbox or maildir format at the destination.

An extremely simple getmailrc file will look like this

[retriever]
type = SimpleIMAPRetriever
server = mail.domain.com
username = direct@domain.com
password = direct

[destination]
type = Maildir
path = /home/cpusername/mail/.direct@domain_com/

The file format should be pretty self-explanatory. You’re telling getmail to fetch your email from server, mail.domain.com by logging to it using the mentioned username and password. The destination section mentions where to store the retrieved email and in which format (Maildir or mbox or mboxrd). Make sure that the cur, new and tmp are there inside those folder though. However getmail may create those folders automatically though.

Finally to get this going, just run “getmail –rcfile getmailrc”

Once you run it, assuming that the getmailrc is properly configured, you will be welcomed by a below output.

getmail version 4.20.3
Copyright (C) 1998-2009 Charles Cazabon.  Licensed under the GNU GPL version 2.
SimpleIMAPRetriever:direct@domain.com@mail.domain.com:143:
 msg    1/3983 (299328 bytes) delivered
 msg    2/3983 (2815 bytes) delivered

A domain name points to a computer called a “name server”. The name server knows that your domain name corresponds to your web hosting server’s IP address and it routes the person who typed in your domain name to your web hosting server – to your web site. That is how people anywhere in the world can see your web site by typing your domain name.

In 1992, the National Science Foundation granted an exclusive contract to NSI to be the sole registrar of top level domain names. NSI also had a cooperative agreement with United States Department of Commerce (“DoC”). With no competition, consumers were at the mercy of NSI.

In 1998, NSI and the DoC amended their cooperative agreement to allow for competing registrars. NSI was forced to provide domain name registration to the competing registrars at wholesale prices, rather than the standard $34.99 annual fee. NSI still charges $34.99 per year.

In late 1998, the DoC assigned the responsibility of overseeing the transition to a competitive market for domain names and accreditation of new registrars to a new organization called the Internet Corporation for Assigned Names and Numbers (ICANN).

In 1999, ICANN began taking applications from companies who wanted to become registrars – and then capitalism took over: companies had to compete for business. Prices came down and service improved, however some are better than others. For a more detailed history of this transition, visit www.icann.org/registrars/accreditation-history.htm.

Even with the positive effects of competition in the domain name marketplace, the process of internet domain name registration remains a mystery for many.

There are a lot of companies that want to charge you hundreds of dollars to do the simple task of domain name registration for you. There are some registration companies who will charge you $35 just to register a domain. And there are web site consultants who charge over $100 to do the work for you. But you can do it yourself in about 15 minutes and it can cost as little as $1.99 for a year. If you do some research, learn a little and work smart, you can save yourself some money – and some headaches.

What is Traceroute ?

Traceroute is the program that shows you the route over the network between two systems, listing all the intermediate routers a connection must pass through to get to its destination. It can help you in analyzing why the connections from your end to a server is poor, and can often help you to spot what exactly is the problem. It always shows you how your machine is connected to ISP and ISP to the rest of the network, collectively the connection between your end and server.

When we initiate Traceroute, it sends a sequence of Internet Control Message Protocol (ICMP) packets addressed to a destination host. It passes through a series of intermediate routers, which involves a TTL (Time-to-Live) value. TTL refers to how many routers your packet can go through before its expires. Routers will discard a packet when the TTL has reached zero, returning an ICMP error message Code 11 (ICMP Time Exceeded) to the sender.

Executing traceroute

The only required parameter is the name or IP address of the destination host . The optional packet length is the total size of the probing packet (default 60 bytes for IPv4 and 80 for IPv6).

In Unix machines : traceroute server-name (traceroute supportsages.com)
In Windows machines : tracert server-name (tracert supportsages.com)

We will be discussing in detail about traceroute in IPv4, Unix environment

In general, traceroute can be found in /usr/sbin. So the traceroute command can be also run as

/usr/sbin/traceroute server-name

You can check where traceroute is located using the command :

root@server:~$ which traceroute
/usr/sbin/traceroute

Traceroute main options

traceroute [-m] [-q] [-w]

-m : Specifies the maximum number of hops (max Time-To-Live value). The default is 30.
-q : Sets the number of UDP packets per hop. The default is 3
-w : Set the time (in seconds) to wait for a response to a probe. Default 5 seconds

Reading the Output

When a traceroute command is executed, generally it will go for a maximum of 30 hops. On the Internet, most data packets need to go through several routers before they reach their final destination. Each time the packet is forwarded to the next router, a Hop occurs. The more hops, the longer it takes for data to go from source to destination. So the fewer hops it takes to get your data, the faster your access will be. Such 30 hops are counted when executing a traceroute command.

Syntax of the result of a traceroute command

linx-1.init7.net (195.66.224.175) 252.199 ms 253.216 ms 253.359 ms
(Target Server) (IP address) (RTT 1) (RTT 2) (RTT 3)

Here is the full result of a traceroute command :

root@server:~$ traceroute supportsages.com
traceroute to supportsages.com (188.40.112.243), 30 hops max, 60 byte packets
1  192.168.1.1 (192.168.1.1)  24.361 ms  24.371 ms  24.394 ms
2  ABTS-KK-dynamic-001.0.172.122.airtelbroadband.in (122.172.0.1)  38.161 ms  39.415 ms  40.911 ms
3  ABTS-KK-Static-093.32.166.122.airtelbroadband.in (122.166.32.93)  43.195 ms  43.587 ms  48.054 ms
4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  48.304 ms  49.512 ms  51.947 ms
5  122.175.255.29 (122.175.255.29)  53.312 ms  55.444 ms  57.223 ms
6  59.145.36.230 (59.145.36.230)  235.823 ms  212.100 ms  212.298 ms
7  linx-1.init7.net (195.66.224.175)  252.199 ms  253.216 ms  253.359 ms
8  r1ams2.core.init7.net (77.109.128.34)  252.791 ms  253.008 ms  255.776 ms
9  r1ams1.core.init7.net (77.109.128.145)  255.973 ms  256.212 ms  256.592 ms
10  r1fra1.core.init7.net (77.109.128.153)  345.600 ms  345.906 ms  346.151 ms
11  gw-hetzner.init7.net (77.109.135.18)  358.110 ms  358.565 ms  358.808 ms
12  hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  359.089 ms hos-bb1.juniper1.fs.hetzner.de (213.239.240.242)  233.990 ms hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  233.347 ms
13  hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  235.315 ms hos-tr2.ex3k10.rz10.hetzner.de (213.239.227.171)  233.554 ms hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  242.239 ms
14  main.supportsages.com (188.40.112.203)  235.676 ms  241.867 ms  242.565 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Analyzing the Output

The first line shows the target server, that server’s IP address, the maximum number of hops that will be allowed, and the size of the packets being sent. The following line for each system or router in the path between your machine and the target server. Each line shows the name of the server (as determined from DNS, if it cannot perform a Reverse DNS, only the IP address is shown), the system’s IP address, and three Round Trip Times (RTTs) in milliseconds. These RTTs shows the time it took a packet to get from your machine to the server and back again, called the latency between the two systems. By default, three packets are sent to each system along the route, so it shows three RTTs.

Understanding the issues

1) Some times the output may have one or two of the RTTs missing

linx-1.init7.net (195.66.224.175) 252.199 ms * *

In this case, the server is up and responding, but for some reason it did not respond to the second and third packets. This does not necessarily indicate a problem; in fact, it is usually normal, and just means that the system discarded the packet for some reason. These are most often computers, rather than dedicated routers. Systems running Solaris routinely show an asterisk instead of the second RTT.

It’s important to remember that timeouts are not necessarily an indication of packet loss.

2) Sometimes you will see an entry with just an IP address and no server name :

77.109.128.153 255.973 ms 256.212 ms 256.592 ms

This simply means that a reverse DNS lookup on the address failed, so the name of the server could not be determined.

3) If your traceroute ends in all timeouts, like this:

12 gw-hetzner.init7.net (77.109.135.18) 358.110 ms 358.565 ms 358.808 ms
13 * * *
14 * * *
15 * * *

This means that the target host could not be reached. Precisely, it means that the packets could not reach there and back. They may actually be reaching the target system but encountering problems on the return. This is possibly due to some kind of problem, but it may also be an intentional block due to a firewall or other security measures, and the block may affect traceroute but not real server connections.

After the trip time, some additional annotation can be printed

!H Host unreachable

!N Network unreachable

!P Protocol  unreachable

!S  Source  route failed

!F Fragmentation needed

!X Communication administratively prohibited

!V Host precedence violation

!C Precedence  cutoff  in effect

!<num>  ICMP unreachable code <num>.

If almost all the probes result in some kind of unreachable, traceroute will give up  and exit.

How it Works

As mentioned earlier, Routers will discard a packet when the TTL has reached zero, returning an ICMP error message Type 11 (ICMP Time Exceeded) to the sender. This is the basic principle behind Traceroute command. This ICMP error message will give more information about each hop in the path.

root@server:~$ traceroute supportsages.com
traceroute to supportsages.com (188.40.112.243), 30 hops max, 60 byte packets
1  192.168.1.1 (192.168.1.1)  24.361 ms  24.371 ms  24.394 ms
2  ABTS-KK-dynamic-001.0.172.122.airtelbroadband.in (122.172.0.1)  38.161 ms  39.415 ms  40.911 ms
3  ABTS-KK-Static-093.32.166.122.airtelbroadband.in (122.166.32.93)  43.195 ms  43.587 ms  48.054 ms
4  ABTS-KK-Static-009.32.166.122.airtelbroadband.in (122.166.32.9)  48.304 ms  49.512 ms  51.947 ms
5  122.175.255.29 (122.175.255.29)  53.312 ms  55.444 ms  57.223 ms
6  59.145.36.230 (59.145.36.230)  235.823 ms  212.100 ms  212.298 ms
7  linx-1.init7.net (195.66.224.175)  252.199 ms  253.216 ms  253.359 ms
8  r1ams2.core.init7.net (77.109.128.34)  252.791 ms  253.008 ms  255.776 ms
9  r1ams1.core.init7.net (77.109.128.145)  255.973 ms  256.212 ms  256.592 ms
10  r1fra1.core.init7.net (77.109.128.153)  345.600 ms  345.906 ms  346.151 ms
11  gw-hetzner.init7.net (77.109.135.18)  358.110 ms  358.565 ms  358.808 ms
12  hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  359.089 ms hos-bb1.juniper1.fs.hetzner.de (213.239.240.242)  233.990 ms hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  233.347 ms
13  hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  235.315 ms hos-tr2.ex3k10.rz10.hetzner.de (213.239.227.171)  233.554 ms hos-tr4.ex3k10.rz10.hetzner.de (213.239.227.235)  242.239 ms
14  main.supportsages.com (188.40.112.203)  235.676 ms  241.867 ms  242.565 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

In the first step, an ICMP request was sent from the router (Here it is 192.168.1.1) to 188.40.112.243 with TTL 1. Since the server was not directly connected to the router, an ICMP Error message, Code 11 (TTL Exceeded) was returned along with it’s source address. It is clear that the very first hop to 188.40.112.243 is from our local router. Thus the router IP (192.168.1.1) is shown along with three RTTs.

Traceroute will always search for a Server Name, if possible. So the server name is displayed along with its IP address (if it cannot perform a Reverse DNS, the IP addres is only shown)

Traceroute will again send 3 more packets, with  TTL 2. The same thing will happen, the next router will respond with its IP address and RTTs. This will go on until the target server or maximum hop count is reached. If the target server is reached, the ICMP Code 0, Echo Reply will be sent and thus Traceroute knows the job is finished. In this case the target server is reached well before the maximum hop counts. So what we saw is a successful traceroute attempt. No issues at all !

The image explains it all – A series of Routers are skipped for the sake of representation

http://www.mediacollege.com/internet/troubleshooter/traceroute.html

http://www.exit109.com/~jeremy/news/providers/traceroute.html

http://www.akmos.com/support/techsupport/traceroute.html

http://www.ehow.com/how_6468192_understand-traceroute-output.html

http://mellowd.co.uk/ccie/?p=609

• How many times your clients have asked you whether you are offering Managed VPSes ?
• How many times you wished you had QUALITY support team with you to offer 24/7 managed VPSes ?
• Do you realize your clients prefer to have the issues solved over LiveChat insted of opening a ticket ?
• Does your current support, provide with quality you wish to offer your clients ?

Through us, now you can!!! If you are someone who places quality of service over all, opt us. You will never regret the decision.

Maximum of 15 minutes response time and 6 hours resolution time – Best response times in the industry (delivered by a technical support firm). Average is far far below that – 5 mins response time and 45 mins resolution time.

Here is our VPS management offer details

• 24/7 Live Chat for you, the server owner (at no extra charge)
• 24/7 transparent support for end user – We login to your helpdesk and do the tickets
• 24/7 Proactive VPS node Monitoring
• 15 minutes guaranteed response time – Often a ticket is responded or resolved in 5 minutes time.
• 6 hours guaranteed resolution time – Often an issue is resolved in less than one hour time.
• Installation of 3rd Party Software/Scripts in the VPSes, as per your client requests
• Level 1, 2 and 3 Support
• We can provide Pre-Sales & Sales support too at this rate
• We monitor each VPSes inside the node as well (upto 20 VPSes and for 20+ VPSes monitoring is charged $3 per VPS)
• Level I,II & Sales Chat support for end user
• Firewall Installation and hardening of VPSes
• Reactive, regular updates for the VPSes
• Free setup of billing scripts and such for your VPS clients

Trust us! we really care for your clients. We take pride in the reviews they give for you here, while we remain anonymous to them.

With this plan, you just need to arrange for the backup space of the VPSes and start offering managed VPS very easily.

Pricing

One VPS node – $249 per month
2 – 5 VPS nodes – $229 per month
5 – 10 VPS nodes – $199 per month
10 – 20 VPS nodes – $179 per month
20+ VPS nodes – $149 per month

For order links, please contact our sales or chat us via IM.

Here is a brief of our other offers

24×7 Shared support – $999 per month (Live chat included + Unlimited tickets)
24×7 Dedicated support – $2999 per month (Live chat included + Unlimited tickets)

Till this offer lasts, we also offer dedicated Level III admin for just $1299 per month, while a semi-dedicated level III admin can be hired for just $799 per month.

With our dedicated staff,

• You can chat in person as if he is your hired employee
• 5-10 mins response times
• 10 mins – 3 hours resolution of issues
• Server monitoring
• Live chat
• Forum postings

And any customized requirements you would want (y)our staff to do.

For placing an order, please chat with us online from any of the instant messenger or Live Chat service provided to you from our website at http://www.supportsages.com or email sales [a][t] supportsages.com .

NB : SS supports all virtualization technologies and multi-platforms also.

The next step is to set up the URL you want to use to access Webmail. In most cases, this is either webmail.example.com or simply mail.example.com. To make this change, click on the ‘Service Settings‘ tab in the top menu of the dashboard. Then, click ‘Email‘. From there, specify that you want to use a custom URL, and enter the appropriate subdomain for your domain.

Submit that form, and Google will then provide you with information about adding a CNAME entry for your new subdomain. You should make corresponding entries in the DNS zone to implement this. For example if the URL with which you wish to access your mail is webmail.example.com then you must give a CNAME record ‘ ghs.google.com. ‘ in the DNS zone for webmail. This is shown below :

Step VI : MX Record Changes

Once you have finished creating all of the users, you can return to the dashboard and click ‘Activate email‘  and follow the MX change instructions provided by Google. If you are lucky enough to use one of the hosts included in the dropdown menu there, you should be able to get clear, specific instructions explaining how to make the changes in your domains control panel.

Google will have you add seven new MX records to your DNS zone file. Those entries will probably look like:

MX Server address                                  Priority

ASPMX.L.GOOGLE.COM.                 10
ALT1.ASPMX.L.GOOGLE.COM.       20
ALT2.ASPMX.L.GOOGLE.COM.       20
ASPMX2.GOOGLEMAIL.COM.         30
ASPMX3.GOOGLEMAIL.COM.         30
ASPMX4.GOOGLEMAIL.COM.         30
ASPMX5.GOOGLEMAIL.COM.         30

It’s important that you copy and paste those addresses exactly as they appear in the Google instructions. They all include dots at the end of the addresses, and that dots need to be included. I am attaching a screenshot below which will hopefully give you an idea on how it should be entered.

Your new entries will need to look similar to:

your-domain.com    14400    IN    MX    10    ASPMX.L.GOOGLE.COM.

Where your-domain.com is your domain name, the second spot is the TTL or Time To Live (which can be left blank if required), the word ‘IN‘ is in the third spot, the fourth spot is filled with ‘MX‘ , the fifth spot is the ‘Priority‘ and the last spot includes the address provided by Google.

Also, in most of the cases you can only add four or five entries to the zone file at a time, so you’ll have to add this first, save the file, and then add the rest.
Once you’ve made those changes, click the  ‘I’ve made these changes‘ button in the Google Apps window.
Finally you can return to dashboard and click on the ‘Activate email‘ tab which you will find right below the ‘Email‘ option. See below :

The last and most difficult Step : Waiting.

At this point, you’re pretty much done. You now simply have to wait because It can take anywhere from one hour to 48 hours before the changes are complete.

Once the changes have completed, though, you can set up your e-mail client (Outlook, Thunderbird etc.) to check your e-mail. The Gmail IMAP settings are fairly simple. They are as follows:

IMAP (incoming) mail:
Server: imap.gmail.com
Port: 993
Encryption: SSL

SMTP (outgoing) mail:
Server: smtp.gmail.com
Port: 465 or 587
Encryption: TLS

***********************************************************************************************************

The praises can be sung without a pause but its better I stop the boasts here and get down to the original topic.  I’m going to explain, step-by-step, on how to accomplish this task. It’s actually very simple, but it might take quite some time depending on how good a techy you are. To begin with, head on over to Google and sign up for an account. I am siting the link below where you can do this :

http://www.google.com/apps/intl/en/business/index.html

In the above page click on the ‘ Apps Editions ‘ tab and you will be able to view different schemes they offer, from which you will be able to select the one which suits you the most. For most of us, the standard edition offered by Google is more than enough. However, they do offer a “Premier edition” if your needs exceed the services of the free accounts. In addition to the Standard edition and Premier edition there are  Educational schemes, Govermental schemes etc etc. Once you choose the package required you will be directed to a page with a blue colored ‘ Get started ‘ tab on the right most top corner of the page. This is your key, click on it and you are on your way to setting Google apps for your domain. I am going to list  everything step by step from here on in a detailed manner.

Step I : Tell them your registered Domain name.

In the very first step you need to provide your domain name as prompted. Obviously enough you should possess a registered domain or you can buy a new domain name through Google which automatically sets everything up for you. You also need to verify that you own the domain or if you are a member of the domain.

Step II : Tell them who you are.

Fill in all of your contact information. At least make sure that you fill in all the boxes which have an aestrics symbol (*) to the right of the label with proper and valid information. If you don’t provide the required information, you will receive an error when you submit the form.
An important thing that you should be absolutely sure of before filling up the form is that you are able to edit your server’s DNS zone files. If you cannot edit your DNS zone files, do not proceed. You will have to enter MX records pointing to the Google mail servers in your DNS configuration. Signing up for the Google Apps account is useless if you’re not going to be able to modify your server appropriately to have the e-mail go where it’s intended.

The screenshot above was limited by my monitor boundaries, but you will be able to see the ‘ Continue ‘ tab at the bottom of your screen. Click this and you are on step III.

Step III : Create your first administrator account.

Create your first e-mail account. This e-mail account will be used as the administrative account for the Google Apps services.

Below this you will be able to see the terms and conditions, which mostly contains the usual stuff but still worth a read, where you should click on the ‘ I accept. Continue with setup ‘ tab to proceed to the next step.

Step IV : Verify Domain Ownership.

The next step in the process is to prove to Google that you own and have administrative rights to the domain you chose.

Here you will have an option to do it later, but sooner the better. Once you choose the option to continue you will be prompted for the password you chose in the previous step.
You have three options to prove that you own the domain. The first option is to modify your DNS entries to add a unique CNAME record. Next option is to add a meta tag to your site’s home page.  The last option is to simply create and upload an HTML file to your Web server. Okay now there is no reason for you to panic from hearing all the complex terms, all you need to do is click on these options and viola, all the information you need on ‘How to’ gets detailed (or rather spoon fed) right on the screen.

As you can see the screenshot above you will have a drop down menu for a list of domain registrars among which you can choose yours and do as instructed. Otherwise you can simply choose the ‘ Others ‘ option from the drop down menu and follow the simple set of instructions which gets listed.
This will look somewhat like the following :

<<

A TXT record is an entry within the Domain Name System (DNS) that provides supplemental information about your domain. You can create a TXT record that proves to Google that you own the domain.

1. Add the TXT record below to the DNS configuration for your-domain.com.
google-site-verification=Zy5aERjpb4-T1S0Ig36pGuHDOE5MycRBGsVmCtVeTLY
2. Click verify below.
When Google finds this DNS TXT record, we’ll make you a verified owner of the domain. (Note: DNS changes may take some time. If we don’t find the record immediately, we’ll check for it periodically.)
Leave the TXT record in place even after verification succeeds.

>>

For adding the TXT record in the DNS zone log into your domain control panel and choose the edit DNS zone option. The name of the option might vary between control panels, but they provide the same functionalities. I am pasting yet another screenshot which might help you through this simple process.

NOTE : For the rest of the article I will be siting examples and providing screenshots only from, and in reference to, the cPanel. But it will not be difficult to figure out how it is done in other control panels once you get an idea on what we are doing here.

You can see that I simply pasted the text mentioned in the instructions. After doing this you can click on ‘Verify‘ which will, quite obviously, verify if the entry is made and thereby confirming your authority over the domain.

ruby -v
ruby 1.8.7 (2009-06-08 patchlevel 173) [i686-linux]

But when updating the gems and the gem itself, we were getting error as below,


gem update --system
Updating RubyGems...
ERROR: While executing gem ... (Gem::RemoteSourceException)
HTTP Response 302 fetching http://gems.rubyforge.org/yaml


Solution was to specify another source as below, which was the 302 redirection of http://gems.rubyforge.org/yaml . May be gem now handles the 302 redirection properly.

gem install rubygems-update --source http://production.s3.rubygems.org/ 

followed by the gem update itself.

sudo gem update --system --source http://production.s3.rubygems.org/

To add the source permanently, use the command below and for more help

gem help sources

gem sources -a http://production.s3.rubygems.org/

Full Disclosure here  - http://seclists.org/fulldisclosure/2010/Sep/268 & mitigation at http://seclists.org/fulldisclosure/2010/Sep/273

Details about the 0 day exploit and how to test whether your system is exploitable or not. However no need to get panicked as this particular exploit was with l33t hackers for last 2 years as you can see at the above link. Now since it is public now, take an extra care if uname -m gives you a x86_64.

http://sota.gen.nz/compat2/

http://sota.gen.nz/compat1/

Two CVE candidates are there – CVE-2010-3081 and CVE-2010-3301. One will affect the server and other don’t.

Temporary solution would be to follow https://access.redhat.com/kb/docs/DOC-40265

IFS or Internal Field Seperator holds the value which seperates the various entities. This can be file names, values read into a script by read etc. It is the character or characters designated as whitespace by the operating system.

The IFS is set to the newline and space character. The global variable $IFS stores the value. To view the exact value stored in IFS execute:

echo "$IFS" | cat -vTE
 ^I$
$

Running echo “$IFS” will not give you any visible output (after all, you are going to see a space and a newline). cat -vTE displays non printable characters , tabs as ^I and ends each line with a $ sign.

In a script which utilises filenames (with spaces), it is always preferable to change the IFS to include only the newline character opposed to the default space and newline character. Lets check out one such script which accepts filenames wih spaces. This scripts simply prints the file names in your current directory. (Remember to create some files in your currenct directory which has spaces. You may try the same script removing the lines with the IFS variable in reference to see the difference)

#!/bin/bash
OIFS=$IFS # Original IFS

IFS=$(echo -en "\n\b") # New IFS

for fil in $(ls -1 $PWD); do
	echo $fil
done

IFS=$OIFS # Restore earlier IFS

IFS can also be used to read files with lines sepearated by a special character. For example in the /etc/passwd, to store the various entries like username, homedirectory etc.

The following script uses the while construct to determine the users who have the shell portion as /bin/false

#!/bin/bash

OIFS=$IFS
IFS=':'

while read username password userid groupid comments homedir shell_avail
do
	if [[ $shell_avail == /bin/false ]]; then
                echo "$username has no shell"
        fi

done < /etc/passwd
IFS=$OIFS

In the above script each of the 7 portions of the /etc/passwd file is assigned to the 7 variables
username password userid groupid comments homedir shell_avail with the read command. The if portion in the script compares the seventh variable – shell_avail to /bin/false to determine the username and outputs it.

From now on you can use the IFS variable for all those files with spaces and extracting values separated by a special character.

Attackers after getting access to a server, will install a rootkit to hide their identity and run desired scripts anywhere within the server. It makes the life of a hacker easy once installed. Rootkits are not easily detectable. Sometimes, if the rootkit is one of the latest ones without a diagnosis, the server will have to be rebuild from scratch.

A rootkit will have multiple applications for cracking the entire server, some of them are:

Server Access Applications (Back door application)
These applications will create a backdoor to log in to the hacked system without using the exploit again.

Log clearing Applications
These applications clear the logs of the events performed by the hacker or the applications used. They all the associated log files in the server.

Packet sniffing Applications
These applications monitor the data through the various interfaces in the server at particular ports.

Malicious Scripts
Many scripts will be installed like IRC bots, ddos daemons, spam servers, trojans, worms etc.

There are mainly two kinds of root kits. The application rootkit and the kernel rootkit.

Application rootkits
These rootkits mimic a particular application and will hide the attackers files/processes from being revealed by the original application. To illustrate, a rootkit ls application will perform all the task of a normal ls but will not display any of the files of the attacker. Other application rootkits will create backdoors for unauthorised access, packet sniffers etc which go undetected or are hidden by renaming. Application rootkits are the most common.

Kernel rootkits
Kernel rootkits modify the kernel and apply patches to the kernel and device drivers. They also hide the applications and files of the attacker. As antivirus and other applications run beneath the kernel, they are the most undetectable rootkits.

‘Prevention is better than cure’ – as this saying goes, it is always better to keep the system secure and updated when ever possible to stop these installations. There are some applications which help detect any known rootkits running in the system. One such is the chkrootkit.

chkrootkit is one of the popular rootkit detectors (an anti-rootkit) and it is know to detect common rootkits on unix/linux servers. chkrootkit relies on basic string processing techniques to determine the presence of rootkits. It scans specific sytem files and binaries targeted by rootkits for known signatures.

The following are the instructions to install chkrootkit version 0.49 in a server.

cd /usr/local/

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.md5

md5sum -c chkrootkit.md5 # to check if the downloaded file is intact

tar -xzf chkrootkit.tar.gz

cd chkrootkit-0.49/

make sense

./chkrootkit

chkroootkit will check all the files and display the status of the files analysed. This information may be logged for future reference. For this a cron job may be setup to be run at least once a month.

Inserting an entry like the one below into the systems cron tasks (executed atleast once a month) will send the report of the chkrootkit vulnerabilities to the administrator conserned.

/usr/local/chkrootkit-0.49/chkrootkit | mail -s "chkrootkit report $(date +%d/%m/%y)" "admin@domain.com"