How To Convert Existing ext3 non-root FileSystem to ext4 FileSystem

Any existing Ext3 filesystem can be migrated to Ext4 with an easy procedure (as long as you are converting a filesystem that can be unmounted and which is non-root) which consists in running a couple of commands.

This means that you can improve the performance, storage limits and features of your current filesystems without reformatting and/or reinstalling your OS and software environment.

First, unmount the partition: umount /dev/sda1

Next, run a filesystem check on it to make sure it is in sane condition.

fsck.ext3 -pf /dev/sda1

Enable new features of ext4 on the filesystem

tune2fs -O extents,uninit_bg,dir_index  /dev/sda1

Run a filesystem check. to make sure that the filesystem is now clean.

fsck -pf /dev/sda1

Now edit your /etc/fstab file and replace "ext3" with "ext4" for /dev/sda1. Other options may differ for your system.

/dev/sda1 /disk ext4 defaults 0 2

Try to mount your new ext4 filesystem: mount /disk

Read more

Understanding Packet Filtering using iptables

The Linux kernel uses the Netfilter facility to filter packets, allowing some of them to be received by or pass through the system while stopping others. This facility is built in to the Linux kernel, and has three built-in tables or rules lists, as follows:

    * filter — The default table for handling network packets.
    * nat — Used to alter packets that create a new connection and used for Network Address Translation (NAT).
    * mangle — Used for specific types of packet alteration.

Each table has a group of built-in chains, which correspond to the actions performed on the packet by netfilter.
The built-in chains for the filter table are as follows:

    * INPUT — Applies to network packets that are targeted for the host.
    * OUTPUT — Applies to locally-generated network packets.
    * FORWARD — Applies to network packets routed through the host.

The built-in chains for the nat table are as follows:

    * PREROUTING — Alters network packets when they arrive.
    * OUTPUT — Alters locally-generated network packets before they are sent out.
    * POSTROUTING — Alters network packets before they are sent out.

The built-in chains for the mangle table are as follows:

    * INPUT — Alters network packets targeted for the host.
    * OUTPUT — Alters locally-generated network packets before they are sent out.
    * FORWARD — Alters network packets routed through the host.
    * PREROUTING — Alters incoming network packets before they are routed.
    * POSTROUTING — Alters network packets before they are sent out.

Every network packet received by or sent from a Linux system is subject to at least one table. However, a packet may be subjected to multiple rules within each table before emerging at the end of the chain. The structure and purpose of these rules may vary, but they usually seek to identify a packet coming from or going to a particular IP address, or set of addresses, when using a particular protocol and network service.

Regardless of their destination, when packets match a particular rule in one of the tables, a target or action is applied to them. If the rule specifies an ACCEPT target for a matching packet, the packet skips the rest of the rule checks and is allowed to continue to its destination. If a rule specifies a DROP target, that packet is refused access to the system and nothing is sent back to the host that sent the packet. If a rule specifies a QUEUE target, the packet is passed to user-space. If a rule specifies the optional REJECT target, the packet is dropped, but an error packet is sent to the packet's originator.

Every chain has a default policy to ACCEPT, DROP, REJECT, or QUEUE. If none of the rules in the chain apply to the packet, then the packet is dealt with in accordance with the default policy.

Note: The iptables service starts before any DNS-related services when a Linux system is booted. This means that firewall rules can only reference numeric IP addresses (for example, 192.168.0.1). Domain names (for example, host.example.com) in such rules produce errors.

Read more

How To Identify Which Ports (or Services) Are Listening/Open

There are two basic approaches for listing the ports that are listening on the network. The less reliable approach is to query the network stack using commands such as netstat -an or lsof -i. This method is less reliable since these programs do not connect to the machine from the network, but rather check to see what is running on the system. For this reason, these applications are frequent targets for replacement by attackers. Crackers attempt to cover their tracks if they open unauthorized network ports by replacing netstat and lsof with their own, modified versions.

A more reliable way to check which ports are listening on the network is to use a port scanner such as nmap.The following command issued from the console determines which ports are listening for TCP connections from the network:

nmap -sT -O localhost

The output of this command appears as follows:

Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-05 01:11 IST
Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
Interesting ports on localhost (127.0.0.1):
Not shown: 994 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
80/tcp   open  http
3128/tcp open  squid-http
3306/tcp open  mysql
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.15 - 2.6.27
Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.15 seconds

Next, check for information about the port using netstat or lsof. To check for port 3128 using netstat, use the following command:

netstat -anp | grep 3128

The command returns the following output:

tcp        0      0 127.0.0.1:3128          0.0.0.0:*                        LISTEN      1909/(squid)
tcp        0      0 127.0.0.1:3128          127.0.0.1:52913         TIME_WAIT   -
tcp        0      0 127.0.0.1:3128          127.0.0.1:52914         TIME_WAIT   -

The lsof command reveals similar information to netstat since it is also capable of linking open ports to services:

lsof -i | grep 3128

Read more

How to Verify Signed Fedora Packages

All Fedora packages are signed with the Fedora GPG key. GPG stands for GNU Privacy Guard, or GnuPG, a free software package used for ensuring the authenticity of distributed files. For example, a private key (secret key) locks the package while the public key unlocks and verifies the package. If the public key distributed by Fedora does not match the private key during RPM verification, the package may have been altered and therefore cannot be trusted.

The RPM utility within Fedora automatically tries to verify the GPG signature of an RPM package before installing it. If the Fedora GPG key is not installed, install it from a secure, static location, such as an Fedora installation CD-ROM or DVD.

Assuming the fedora installation disc is mounted in /mnt/cdrom, use the following command to import it into the keyring (a database of trusted keys on the system):

rpm --import /mnt/cdrom/RPM-GPG-KEY

To display a list of all keys installed for RPM verification, execute the following command:

rpm -qa gpg-pubkey*

The output will look similar to the following:

gpg-pubkey-db42a60e-37ea5438

To display details about a specific key, use the rpm -qi command followed by the output from the previous command, as in this example:

rpm -qi gpg-pubkey-db42a60e-37ea5438

It is extremely important to verify the signature of the RPM files before installing them to ensure that they have not been altered from the original source of the packages. To verify all the downloaded packages at once, issue the following command:

rpm -K /tmp/updates/*.rpm

For each package, if the GPG key verifies successfully, the command returns gpg OK. If it doesn't, make sure you are using the correct Fedora public key, as well as verifying the source of the content. Packages that do not pass GPG verifications should not be installed, as they may have been altered by a third party.

After verifying the GPG key and downloading all the packages associated with the errata report, install the packages as root at a shell prompt.

Read more

How to Use & Configure Google Public DNS on Linux System

When you use Google Public DNS, you are changing your DNS operator from your ISP to Google Public DNS.

In most cases, the IP addresses used by your ISP's domain name servers are automatically set by your ISP via the Dynamic Host Configuration Protocol (DHCP). To use Google Public DNS, you need to explicitly change the DNS settings in your operating system or device to use the Google Public DNS IP addresses. The procedure for changing your DNS settings varies according to operating system and version (Windows, Mac or Linux) or the device (computer, phone, or router).

Benefits and enhancements:
Performance: Many DNS service providers are not sufficiently provisioned to be able to support high-volume input/output and caching, and adequately balance load among their servers. In addition to load-balancing user traffic to ensure shared caching, Google Public DNS implements "smart" caching to increase the speed of responses. Google Public DNS independently resolves domain names and keeps the resolutions in the cache until their time-to-live (TTL) expires, at which point they are automatically refreshed. The cycle of caching and refreshing is performed offline, asynchronously with user requests, so that responses are almost always available directly from cache.

Security: DNS is vulnerable to various kinds of spoofing attacks that can "poison" a nameserver's cache and route its users to malicious sites. The prevalence of DNS exploits means that providers have to frequently apply server updates and patches. In addition, open DNS resolvers are vulnerable to being used to launch denial-of-service (DoS) attacks on other systems. To defend against such attacks, Google has implemented several recommended solutions to help guarantee the authenticity of the responses it receives from other nameservers, and to ensure Google servers are not used for launching DoS attacks. These include adding entropy to requests, rate-limiting client traffic, and more.

Correct results: Google Public DNS does its best to return the right answer to every query every time, in accordance with the DNS standards. Sometimes, in the case of a query for a mistyped or non-existent domain name, the right answer means no answer, or an error message stating the domain name could not be resolved. Google Public DNS never blocks, filters, or redirects users, unlike some open resolvers and ISPs.

Configuration:
Note: Before you change your DNS settings to use Google Public DNS, be sure to write down the current server addresses or settings on a piece of paper. It is very important that you keep these numbers for backup purposes, in case you need to revert to them at any time.

The Google Public DNS IP addresses are as follows:

    8.8.8.8
    8.8.4.4

You can use either number as your primary or secondary DNS server. You can specify both numbers, but do not specify one number as both primary and secondary.

1) Edit /etc/resolv.conf:

sudo vi /etc/resolv.conf

2) Replace the nameserver lines with, or add, the following lines:

nameserver 8.8.8.8
nameserver 8.8.4.4

3) Save and exit.
4) Restart any Internet clients you are using.

Configuring DHCP client for dynamic ip address:
1) Edit /etc/dhclient.conf:

sudo vi /etc/dhclient.conf

2) If there is a line containing domain-name-servers, write down the IP addresses for future reference. Replace that line with, or add, the following line:

prepend domain-name-servers 8.8.8.8, 8.8.4.4;

2) Save and exit.
4) Restart your system.

Read more