david.rabine

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Checking Open Ports ======

This [[http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/s1-server-ports.html|Red Hat Security Page]] had a great list of things you can check.

Here are some quick things (lifted directly from the link above):

Once you have configured services on the network, it is important to keep tabs on which ports are actually listening on the system's network interfaces. Any open ports can be evidence of an intrusion.

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 by typing 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. In this way, crackers attempt to cover their tracks if they open unauthorized network ports.

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:

<code>
nmap -sT -O localhost
</code>

The output of this command looks like the following:

<code>
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1596 ports scanned but not shown below are in state: closed)
Port       State       Service
22/tcp     open        ssh
111/tcp    open        sunrpc
515/tcp    open        printer
834/tcp    open        unknown
6000/tcp   open        X11
Remote OS guesses: Linux Kernel 2.4.0 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds
</code>

This output shows the system is running //portmap// due to the presence of the sunrpc service. However, there is also a mystery service on port 834. To check if the port is associated with the official list of known services, type:

<code>
cat /etc/services | grep 834
</code>

This command returns no output. This indicates that while the port is in the reserved range (meaning 0 through 1023) and requires root access to open, it is not associated with a known service.

Next, you can check for information about the port using //netstat// or //lsof//. To check for port 834 using //netstat//, use the following command:

<code>
netstat -anp | grep 834
</code>

The command returns the following output:

<code>
tcp   0    0 0.0.0.0:834    0.0.0.0:*   LISTEN   653/ypbind
</code>

The presence of the open port in //netstat// is reassuring because a cracker opening a port surreptitiously on a hacked system would likely not allow it to be revealed through this command. Also, the [p] option reveals the process id (PID) of the service which opened the port. In this case the open port belongs to //ypbind// (NIS), which is an RPC service handled in conjunction with the //portmap// service.

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

<code>
lsof -i | grep 834
</code>

Below is the relevant portion of the output for this command:

<code>
ypbind      653        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      655        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      656        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
ypbind      657        0    7u  IPv4       1319                 TCP *:834 (LISTEN)
</code>

As you can see, these tools can reveal a great about the status of the services running on a machine. These tools are flexible and can provide a wealth of information about network services and configuration. Consulting the man pages for //lsof//, //netstat//, //nmap//, and services is therefore highly recommended. 

====== Dropping Unwanted Packets ======

Some dude/dudette was flooding the apache server with requests, so I added an iptables rule to drop packets from his/her IP.

<code>
# drop all incoming packets from 88.241.152.169
iptables -I INPUT -s 88.241.152.169 -j DROP
# list your iptables rules
iptables -L -n
</code>