fgrep

fgrep is a faster version of grep which does not support regular expressions and therefore is considered to be
faster. fgrep is equal to grep -F. Simple proof that fgrep does not interpret regular expressions (regex):

fgrep linux$ *
egrep linux$ *
grep linux$ *

nslookup

Queries a name server for a host or domain lookup.

Syntax

nslookup [ - option ] ... host [ server ]

all List the current settings

d2 Set exhaustive debug mode on
nod2 Set exhaustive debug mode off
debug Set debug mode on
nodebug Set debug mode off
defname Set domain-appending mode on
nodefname Set domain-appending mode off
domain=string Establish the appendable domain
ignoretc Set it to ignore packet truncation errors
noignoretc Set it to acknowledge packet truncation errors
host Inquires about the specified host. In this non-interactive command
format, nslookup Does not prompt for additional commands.
- Causes nslookup to prompt for more information, such as host names,
before sending one or more queries.
server Directs inquiries to the name server specified here in the command line
rather than the one read from the /etc/resolv.conf file. server can be
either a name or an Internet address. If the speci- fied host cannot be
reached, nslookup resorts to using the name server specified in
/etc/resolv.conf.

Examples
This command is often used to perform a reverse lookup on an IP address as shown in the below example.

nslookup 204.228.150.3

Server: 198.60.22.2
Address: 198.60.22.2#53

Non-authoritative answer:
3.150.228.204.in-addr.arpa name = www.computerhope.com.

Authoritative answers can be found from:

150.228.204.in-addr.arpa nameserver = ns.xmission.com.
150.228.204.in-addr.arpa nameserver = ns1.xmission.com.
150.228.204.in-addr.arpa nameserver = ns2.xmission.com.
ns.xmission.com internet address = 166.70.254.2
ns1.xmission.com internet address = 204.228.159.2
ns2.xmission.com internet address = 207.135.133.2

traceroute

Print the route packets take to network host.

Syntax

traceroute [-d] [-F] [-I] [-n] [-v] [-x] [-f first_ttl] [-g gateway [-g gateway] | -r] [-i iface] [-m max_ttl] [-p
port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime ] host [packetlen]

-d Set the SO_DEBUG socket option.

-F Set the "don't fragment" bit.
-I Use ICMP ECHO instead of UDP datagrams.
-n Print hop addresses numerically rather than symbolically and
numerically. This saves a nameserver address-to-name lookup for each
gateway found on the path.
-v Verbose output. For each hop, the size and the destination of the
response packets is displayed. Also ICMP packets received other than
TIME_EXCEEDED and UNREACHABLE are listed as well.
-x Prevent traceroute from calculating checksums. Note that checksums
are usually required for the last hop when using ICMP ECHO probes.
See the -I option.
-f first_ttl Set the starting ttl value to first_ttl, to override the default value 1.
traceroute skips processing for those intermediate gateways which are
less than first_ttl hops away.
-g gateway Specify a loose source route gateway. The user can specify more than
one gateway by using -g for each gateway. The maximum that can be
set is 8.
-r Bypass the normal routing tables and send directly to a host on an
 attached network. If the host is not on a directly-attached network, an
error is returned. This option can be used to send probes to a local host
through an interface that has been dropped by the router daemon.
-i iface Specify a network interface to obtain the source IP address for
outgoing probe packets. This is normally only useful on a multi-homed
host. The -s option is also another way to do this. Note that this option
does not provide a way to specify the interface on which the probe
packets are sent.
-m max_ttl Set the maximum ttl used in outgoing probe packets. The default is 30
hops, which is the same default used for TCP connections.
-p port Set the base UDP port number used in probes. The default is 33434.
traceroute hopes that nothing is listening on UDP ports (base+(nhops-
1)*nqueries) to (base+(nhops*nqueries)-1)at the destination host, so
that an ICMP PORT_UNREACHABLE message will be returned to
terminate the route tracing. If something is listening on a port in the
default range, this option can be used to select an unused port
range.nhops is defined as the number of hops between the source and
the destination.
-q nqueries Set the desired number of probe queries. The default is 3.
-s src_addr Use the following address, which usually is given as an IP address, not
a hostname, as the source address in outgoing probe packets. On multi-
homed hosts, those with more than one IP address, this option can be
used to force the source address to be something other than the IP
address traceroute picks by default. If the IP address is not one of this
machine's interface addresses, an error is returned and nothing is sent.
When used together with the -i option, the given IP address should be
configured on the specified interface. Otherwise, an error will be
returned.
-t tos Set the tos(type-of-service) in probe packets to the specified value. The
default is zero. The value must be an integer in the range from 0 to
255. Gateways along the path may route the probe packet differently
depending upon the tos value set in the probe packet.
-w waittime Set the time, in seconds, to wait for a response to a probe. The default
is five (5) seconds.
host The network host.

Examples

traceroute computerhope.com - would display results similar to the following:

traceroute to computerhope.com (166.70.10.23), 30 hops max, 40 byte packets

1 198.60.22.1 (198.60.22.1) 2.303 ms 1.424 ms 2.346 ms
2 krunk3.xmission.com (198.60.22.6) 0.742 ms * 1.521 ms

Note: in this example because we are local to the address we are tracerouting the amount of hops is very
minimal. However, when you traceroute computerhope.com you may hop more than we do.
This command is very useful for distinguishing network / router issues. If the domain does not work or is not
available you can traceroute an IP.

iptables - administration tool for IPv4 packet filtering and NAT

SYNOPSIS

iptables [-t table] -[ADC] chain rule-specification [options]

iptables [-t table] -I chain [rulenum] rule-specification [options]
iptables [-t table] -R chain rulenum rule-specification [options]
iptables [-t table] -D chain rulenum [options]
iptables [-t table] -[LFZ] [chain] [options]
iptables [-t table] -N chain
iptables [-t table] -X [chain]
iptables [-t table] -P chain target [options]
iptables [-t table] -E old-chain-name new-chain-name

DESCRIPTION

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several
different tables may be defined. Each table contains a number of built-in chains and may also contain user-
defined chains.

Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that
matches. This is called a `target', which may be a jump to a user-defined chain in the same table.

TARGETS

A firewall rule specifies criteria for a packet, and a target. If the packet does not match, the next rule in the
chain is the examined; if it does match, then the next rule is specified by the value of the target, which can be
the name of a user-defined chain or one of the special values ACCEPT, DROP, QUEUE, or RETURN.
ACCEPT means to let the packet through. DROP means to drop the packet on the floor.QUEUE means to pass
the packet to userspace (if supported by the kernel). RETURN means stop traversing this chain and resume at
the next rule in the previous (calling) chain. If the end of a built-in chain is reached or a rule in a built-in chain
with target RETURN is matched, the target specified by the chain policy determines the fate of the packet.

TABLES

There are currently three independent tables (which tables are present at any time depends on the kernel
configuration options and which modules are present).

-t, --table table

This option specifies the packet matching table which the command should operate on. If the kernel is
configured with automatic module loading, an attempt will be made to load the appropriate module for
that table if it is not already there.

The tables are as follows:

filter
 This is the default table (if no -t option is passed). It contains the built-in chainsINPUT (for packets
coming into the box itself), FORWARD (for packets being routed through the box), and OUTPUT (for
locally-generated packets).

nat
This table is consulted when a packet that creates a new connection is encountered. It consists of three
built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering
locally-generated packets before routing), andPOSTROUTING (for altering packets as they are about
to go out).

mangle
This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in
chains: PREROUTING (for altering incoming packets before routing) and OUTPUT(for altering
locally-generated packets before routing). Since kernel 2.4.18, three other built-in chains are also
supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being
routed through the box), andPOSTROUTING (for altering packets as they are about to go out).

OPTIONS

The options that are recognized by iptables can be divided into several different groups.

COMMANDS

These options specify the specific action to perform. Only one of them can be specified on the command line
unless otherwise specified below. For all the long versions of the command and option names, you need to use
only enough letters to ensure that iptablescan differentiate it from all other options.

-A, --append chain rule-specification

Append one or more rules to the end of the selected chain. When the source and/or destination names
resolve to more than one address, a rule will be added for each possible address combination.

-D, --delete chain rule-specification

-D, --delete chain rulenum

Delete one or more rules from the selected chain. There are two versions of this command: the rule can
be specified as a number in the chain (starting at 1 for the first rule) or a rule to match.

-I, --insert chain [rulenum] rule-specification

Insert one or more rules in the selected chain as the given rule number. So, if the rule number is 1, the
rule or rules are inserted at the head of the chain. This is also the default if no rule number is specified.

-R, --replace chain rulenum rule-specification

Replace a rule in the selected chain. If the source and/or destination names resolve to multiple addresses,
the command will fail. Rules are numbered starting at 1.
PARAMETERS

The following parameters make up a rule specification (as used in the add, delete, insert, replace and append
commands).

-p, --protocol [!] protocol

The protocol of the rule or of the packet to check. The specified protocol can be one oftcp, udp, icmp,
or all, or it can be a numeric value, representing one of these protocols or a different one. A protocol
name from /etc/protocols is also allowed. A "!" argument before the protocol inverts the test. The
number zero is equivalent to all. Protocol allwill match with all protocols and is taken as default when
this option is omitted.

-s, --source [!] address[/mask]

Source specification. Address can be either a network name, a hostname (please note that specifying any
name to be resolved with a remote query such as DNS is a really bad idea), a network IP address (with
/mask), or a plain IP address. The mask can be either a network mask or a plain number, specifying the
number of 1's at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0. A
"!" argument before the address specification inverts the sense of the address. The flag--src is an alias
for this option.

-d, --destination [!] address[/mask]

Destination specification. See the description of the -s (source) flag for a detailed description of the
syntax. The flag --dst is an alias for this option.

netstat

Shows network status.

Syntax

netstat [-a] [-n] [-v]

netstat [-g | -m | -p | -s | -f address_family ] [-n] [-P protocol]

netstat [ -i ] [ -I interface ] [ interval ]

netstat -r [-a] [-n] [-v ]

netstat -M [-n] [-s ]

netstat -D [ -I interface ]

-a Show the state of all sockets and all routing table entries; normally,
sockets used by server processes are not shown and only interface,
host, network, and default routes are shown.
-n Show network addresses as numbers. netstat normally displays
 addresses as symbols. This option may be used with any of the display
formats.
-v Verbose. Show additional information for the sockets and the routing
table.
-g Show the multicast group memberships for all interfaces.
-m Show the STREAMS statistics.
-p Show the address resolution (ARP) tables.
-s Show per-protocol statistics. When used with the -M option, show
multicast routing statistics instead.
-i Show the state of the interfaces that are used for TCP/IP traffic.
-r Show the routing tables.
-M Show the multicast routing tables. When used with the -s option, show
multicast routing statistics instead.
-d Show the state of all interfaces that are under Dynamic Host
Configuration Protocol (DHCP) control.
-D Show the status of DHCP configured interfaces.
-f imit statistics or address control block reports to those of the specified
address_family address_family, which can be one of:

inet For the AF_INET address family

unix For the AF_Unix address family
-P protocol Limit display of statistics or state of all sockets to those applicable to
protocol.
- I interface Show the state of a particular interface. interface can be any valid
interface such as ie0 or
le0.

Examples

netstat

Displays generic net statistics of the host you are currently connected to.

netstat -an

Shows all connections to the server including the source and destination ips and ports if you have proper
permissions.

netstat -rn

Displays routing table for all ips bound to the server.

netstat -an |grep :80 |wc -l

 Display the amount of active connections on port 80. Removing the pipe andwc command would display
each connection.

netstat -natp

Display active Internet connections. See document CH001079 for an example of output.

"Security through obscurity" may be a catchy phrase, but it's not the only thing that's catching among Windows
users.

The expression is intended to suggest that proprietary software is more secure by virtue of its closed nature. If
hackers can't see the code, then it's harder for them to create exploits for it--or so the thinking goes.

Unfortunately for Windows users, that's just not true--as evidenced by the never-ending parade
of patches coming out of Redmond. In fact, one ofLinux's many advantages over Windows is that it is more
secure--much more. For small businesses and other organizations without a dedicated staff of security experts,
that benefit can be particularly critical.

Five key factors underlie Linux's superior security:

1. Privileges

Linux systems are by no means infallible, but one of their key advantages lies in the way account privileges are
assigned. In Windows, users are generally given administrator access by default, which means they pretty much
have access to everything on the system, even its most crucial parts. So, then, do viruses. It's like giving
terrorists high-level government positions.

With Linux, on the other hand, users do not usually have such "root" privileges; rather, they're typically given
lower-level accounts. What that means is that even if a Linux system is compromised, the virus won't have the
root access it would need to do damage systemwide; more likely, just the user's local files and programs would
be affected. That can make the difference between a minor annoyance and a major catastrophe in any business
setting.

2. Social Engineering

Viruses and worms often spread by convincing computer users to do something they shouldn't, like open
attachments that carry viruses and worms. This is called social engineering, and it's all too easy on Windows
systems. Just send out an e-mail with a malicious attachment and a subject line like, "Check out these adorable
puppies!"--or the porn equivalent--and some proportion of users is bound to click without thinking. The result?
An open door for the attached malware, with potentially disastrous consequences organizationwide.

Thanks to the fact that most Linux users don't have root access, however, it's much harder to accomplish any
real damage on a Linux system by getting them to do something foolish. Before any real damage could occur, a
Linux user would have to read the e-mail, save the attachment, give it executable permissions and then run the
executable. Not very likely, in other words.

3. The Monoculture Effect

However you want to argue the exact numbers, there's no doubt thatMicrosoft Windows still dominates most of
the computing world. In the realm of e-mail, so too do Outlook and Outlook Express. And therein lies a
problem: It's essentially a monoculture, which is no better in technology than it is in the natural world. Just as
genetic diversity is a good thing in the natural world because it minimizes the deleterious effects of a deadly
virus, so a diversity of computing environments helps protect users.

Fortunately, a diversity of environments is yet another benefit that Linux offers. There's Ubuntu, there's Debian,
there's Gentoo, and there are many other distributions. There are also many shells, many packaging systems,
and many mail clients; Linux even runs on many architectures beyond just Intel. So, whereas a virus can be
targeted squarely at Windows users, since they all use pretty much the same technology, reaching more than a
small faction of Linux users is much more difficult. Who wouldn't want to give their company that extra layer
of assurance?

4. Audience Size

Hand-in-hand with this monoculture effect comes the not particularly surprising fact that the majority of viruses
target Windows, and the desktops in your organization are no exception. Millions of people all using the same
software make an attractive target for malicious attacks.

5. How Many Eyeballs

"Linus' Law"--named for Linus Torvalds, the creator of Linux--holds that, "given enough eyeballs, all bugs are
shallow." What that means is that the larger the group of developers and testers working on a set of code, the
more likely any flaws will be caught and fixed quickly. This, in other words, is essentially the polar opposite of
the "security through obscurity" argument.

With Windows, it's a limited set of paid developers who are trying to find problems in the code. They adhere to
their own set timetables, and they don't generally tell anyone about the problems until they've already created a
solution, leaving the door open to exploits until that happens. Not a very comforting thought for the businesses
that depend on that technology.

In the Linux world, on the other hand, countless users can see the code at any time, making it more likely that
someone will find a flaw sooner rather than later. Not only that, but users can even fix problems themselves.
Microsoft may tout its large team of paid developers, but it's unlikely that team can compare with a global base
of Linux user-developers around the globe. Security can only benefit through all those extra "eyeballs."

Once again, none of this is to say that Linux is impervious; no operating system is. And there are definitely
steps Linux users should take to make their systems as secure as possible, such as enabling a firewall,
minimizing the use of root privileges, and keeping the system up to date. For extra peace of mind there are also
virus scanners available for Linux, including ClamAV. These are particularly good measures for small
businesses, which likely have more at stake than individual users do.

It's also worth noting that security firm Secunia recently declared that Apple products have more security
vulnerabilities than any others--including Microsoft's.

Either way, however, when it comes to security, there's no doubt that Linux users have a lot less to worry about.

Why shell programming is required in linux?

A working knowledge of shell scripting is essential to anyone wishing to become reasonably proficient at
system administration, even if they do not anticipate ever having to actually write a script. Consider that as a
Linux machine boots up, it executes the shell scripts in /etc/rc.d to restore the system configuration and set up
services. A detailed understanding of these startup scripts is important for analyzing the behavior of a system,
and possibly modifying it.

The craft of scripting is not hard to master, since the scripts can be built in bite-sized sections and there is only a
fairly small set of shell-specific operators and options[1] to learn. The syntax is simple and straightforward,
similar to that of invoking and chaining together utilities at the command line, and there are only a
few "rules"governing their use. Most short scripts work right the first time, and debugging even the longer ones
is straightforwar

A shell script is a quick-and-dirty method of prototyping a complex application. Getting even a limited subset of
the functionality to work in a script is often a useful first stage in project development. This way, the structure
of the application can be tested and played with, and the major pitfalls found before proceeding to the final
coding in C, C++, Java, Perl, or Python.

Shell scripting hearkens back to the classic UNIX philosophy of breaking complex projects into simpler
subtasks, of chaining together components and utilities. Many consider this a better, or at least more esthetically
pleasing approach to problem solving than using one of the new generation of high powered all-in-one
languages, such as Perl, which attempt to be all things to all people, but at the cost of forcing you to alter your
thinking processes to fit the tool.

What socket? What do mean by binding to a socket?

A socket is a communication mechanism that allows client/server systems to be developed either locally, on a
single machine, or across networks. Linux functions such as printing, connecting to databases, and serving web
pages as well as network utilities such as rlogin for remote login and ftp for file transfer usually use sockets to
communicate.
Sockets are created and used differently from pipes because they make a clear distinction between client and
server. The socket mechanism can implement multiple clients attached to a single server.

Sockets are ports that the system allocates on the user’s behalfwhen executing network applications or other
services. Because the operating system generates a unique socket number, no two simultaneously running
applications on the same system will have the same socket number. On some UNIX systems, the allocation of
sockets begins above 1024.

Socket API functions

This list is a summary of functions or methods provided by the Berkeley sockets API library:

 socket() creates a new socket of a certain socket type, identified by an integer number, and allocates system
resources to it.
 bind() is typically used on the server side, and associates a socket with a socket address structure, i.e. a
specified local port number and IP address.
 listen() is used on the server side, and causes a bound TCP socket to enter listening state.
 connect() is used on the client side, and assigns a free local port number to a socket. In case of a TCP
socket, it causes an attempt to establish a new TCP connection.
 accept() is used on the server side. It accepts a received incoming attempt to create a new TCP connection
from the remote client, and creates a new socket associated with the socket address pair of this connection.
 send() and recv(), or write() and read(), or sendto() and recvfrom(), are used for sending and receiving data
to/from a remote socket.
 close() causes the system to release resources allocated to a socket. In case of TCP, the connection is
terminated.
 gethostbyname() and gethostbyaddr() are used to resolve host names and addresses. IPv4 only.
 select() is used to prune a provided list of sockets for those that are ready to read, ready to write, or that have
errors.
 poll() is used to check on the state of a socket in a set of sockets. The set can be tested to see if any socket
can be written to, read from or if an error occurred.
 getsockopt() is used to retrieve the current value of a particular socket option for the specified socket.
 setsockopt() is used to set a particular socket option for the specified socket.
Further details are given below.
socket()
socket() creates an endpoint for communication and returns a file descriptor for the socket. socket() takes three
arguments:

 domain, which specifies the protocol family of the created socket. For example:
 PF_INET for network protocol IPv4 or
 PF_INET6 for IPv6.
 PF_UNIX for local socket (using a file).
 type, one of:
 SOCK_STREAM (reliable stream-oriented service or Stream Sockets)
 SOCK_DGRAM (datagram service or Datagram Sockets)
 SOCK_SEQPACKET (reliable sequenced packet service), or
 SOCK_RAW (raw protocols atop the network layer).
 protocol specifying the actual transport protocol to use. The most common
are IPPROTO_TCP, IPPROTO_SCTP, IPPROTO_UDP,IPPROTO_DCCP. These protocols are specified in
<netinet/in.h>. The value “0” may be used to select a default protocol from the selecteddomain and type.
The function returns -1 if an error occurred. Otherwise, it returns an integer representing the newly-assigned
descriptor.
Prototype
int socket(int domain, int type, int protocol);
bind()
bind() assigns a socket to an address. When a socket is created using socket(), it is only given a protocol family,
but not assigned an address. This association with an address must be performed with the bind() system call
before the socket can accept connections to other hosts. bind() takes three arguments:
 sockfd, a descriptor representing the socket to perform the bind on.
 my_addr, a pointer to a sockaddr structure representing the address to bind to.
 addrlen, a socklen_t field specifying the size of the sockaddr structure.
Bind() returns 0 on success and -1 if an error occurs.
Prototype
int bind(int sockfd, const struct sockaddr *my_addr, socklen_t addrlen);