Simple Network Troubleshooting

In This Chapter

Chapter 9

Simple Network Troubleshooting

How To See MAC Addresses

How To Use “Ping” To Test Network Connectivity

Using “traceroute” To Test Connectivity

Viewing Packet Flow With TCPdump

Using Telnet

Using NMAP

Who Has Used My System?

© Peter Harrison, http://www.linuxhomenetworking.com

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

You will eventually find yourself trying to fix a network related problem. Here are some troubleshooting tips to help you discover what the problem could be.

How To See MAC Addresses

There are times when you lose connectivity with another server that is directly connected to your local network. Taking a look at the ARP table of the server from which you are troubleshooting will help determine whether or not the remote server’s NIC is responding to any type of traffic from your Linux box. Lack of communication at this level may mean:

·     Either server may be disconnected from the network

·     There may be bad network cabling

·     A NIC may be disabled or the remote server may be shut down

Here is a description of the commands you may use to determine ARP values

·     The “ifconfig -a” command will show you both the NIC’s MAC address and the associated IP addresses of the server which you are currently logged in to.

[root@bigboy tmp]# ifconfig -a

wlan0 Link encap:Ethernet HWaddr 00:06:25:09:6A:B5
inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:47379 errors:0 dropped:0 overruns:0 frame:0
TX packets:107900 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4676853 (4.4 Mb) TX bytes:43209032 (41.2 Mb)
Interrupt:11 Memory:c887a000-c887b000

wlan0:0 Link encap:Ethernet HWaddr 00:06:25:09:6A:B5
inet addr:192.168.1.99 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Memory:c887a000-c887b000

[root@bigboy tmp]#

 

Here you can see the wlan0 interface has two IP addresses 192.168.1.100 and 192.168.1.99 tied to the NIC hardware MAC address of 00:06:25:09:6A:B5

 

·     The “arp -a” command will show you the MAC addresses in your server’s ARP table. Here we see we have some form of connectivity with the router at address 192.168.1.1

 

[root@bigboy root]# arp -a
bigboypix (192.168.1.1) at 00:09:E8:9C:FD:AB [ether] on wlan0
? (192.168.1.101) at 00:06:25:09:6A:D7 [ether] on wlan0
[root@bigboy root]#

·     You should also check the ARP table of the remote server to see whether it is populated with acceptable values too.

How To Use “Ping” To Test Network Connectivity 

Whether or not your troublesome server is connected to your local network it is always a good practice to force a response from it.

One of the most common methods used to test connectivity across multiple networks is the “ping” command. Ping sends ICMP “echo” type packets that request a corresponding ICMP “echo-reply” response from the device at the target address. As most servers will respond to a ping query it becomes a very handy tool. A lack of response could be due to:

·     A server with that IP address doesn’t exist

·     The server has been configured not to respond to pings

·     A firewall or router along the network path is blocking ICMP traffic

·     You have incorrect routing. Check routes on the local, remote servers and all routers in between. A classic symptom of bad routes on a server is the ability to only ping servers on your local network and nowhere else. 

There are a variety of ICMP response codes which can help in further troubleshooting. See the appendix for a full listing of them.

 

The Linux ping command will send continuous pings, once a second, until stopped with a <Ctrl-C>. Here is an example of a successful ping to the server bigboy at 192.168.1.100

 

[root@smallfry tmp]# ping 192.168.1.101
PING 192.168.1.101 (192.168.1.101) from 192.168.1.100 : 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=1 ttl=128 time=3.95 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=128 time=7.07 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=128 time=4.46 ms
64 bytes from 192.168.1.101: icmp_seq=4 ttl=128 time=4.31 ms

— 192.168.1.101 ping statistics —
4 packets transmitted, 4 received, 0% loss, time 3026ms
rtt min/avg/max/mdev = 3.950/4.948/7.072/1.242 ms

[root@smallfry tmp]#
 

You may get a “Destination Host Unreachable” message if your router or server knows that the target IP address is part of a valid network, but is getting no response from the target server. The network device sends an ICMP reply type 3 which triggers the message.

[root@smallfry tmp]# ping 192.168.1.105
PING 192.168.1.105 (192.168.1.105) from 192.168.1.100 : 56(84) bytes of data.
From 192.168.1.100 icmp_seq=1 Destination Host Unreachable
From 192.168.1.100 icmp_seq=2 Destination Host Unreachable
From 192.168.1.100 icmp_seq=3 Destination Host Unreachable
From 192.168.1.100 icmp_seq=4 Destination Host Unreachable
From 192.168.1.100 icmp_seq=5 Destination Host Unreachable
From 192.168.1.100 icmp_seq=6 Destination Host Unreachable

— 192.168.1.105 ping statistics —
8 packets transmitted, 0 received, +6 errors, 100% loss, time 7021ms, pipe 3
[root@smallfry tmp]#

 

Using “traceroute” To Test Connectivity 

Another tool for network troubleshooting is the traceroute command. It gives a listing of all the router hops between your server and the target server. This helps you verify that routing over the networks in between is correct.

Traceroute works by sending a UDP packet destined to the target with a TTL of “0”. The first router on the route recognizes that the TTL has already been exceeded and discards or “drops” the packet, but also sends an ICMP “time exceeded” message back to the source. The traceroute program records the IP address of the router that sent the message and knows that that is the first hop on the path to the final destination. The traceroute program tries again, with a TTL of “1”. The first hop, sees nothing wrong with the packet, decrements the TTL to 0 as expected, and forwards the packet to the second hop on the path. Router 2, sees the TTL of “0”, drops the packet and replies with an ICMP time exceeded message. Traceroute now knows the IP address of the second router. This continues around and around until the final destination is reached.


Here is a sample output for a query to 144.232.20.158:

 

[root@bigboy root]# traceroute 144.232.20.158
traceroute to 144.232.20.158 (144.232.20.158), 30 hops max, 38 byte packets
1 adsl-67-120-221-110.dsl.sntc01.pacbell.net (67.120.221.110) 14.304 ms 14.019 ms 16.120 ms
2 dist3-vlan50.sntc01.pbi.net (63.203.35.67) 12.971 ms 14.000 ms 14.627 ms
3 bb1-g1-0.sntc01.pbi.net (63.203.35.17) 15.521 ms 12.860 ms 13.179 ms
4 bb2-p11-0.snfc21.pbi.net (64.161.124.246) 13.991 ms 15.842 ms 15.728 ms
5 bb1-p14-0.snfc21.pbi.net (64.161.124.53) 16.133 ms 15.510 ms 15.909 ms
6 sl-gw11-sj-3-0.sprintlink.net (144.228.44.49) 16.510 ms 17.469 ms 18.116 ms
7 sl-bb25-sj-6-1.sprintlink.net (144.232.3.133) 16.212 ms 14.274 ms 15.926 ms
8 * * *
9 * *
[root@bigboy root]#

 

If there is no response within a 5 second timeout interval a “*” is printed for that probe. Possible causes of this and other traceroute status messages are listed below:

Possible Traceroute Messages

Traceroute

Symbol

Description

* * *

Time exceeded. Could be caused by:

·    A router on the path not sending back the ICMP “time exceeded” messages

·    A router or firewall in the path blocking the ICMP “time exceeded” messages

·    The target IP address not responding

!H, !N, or !P

Host, network or protocol unreachable

 !X or !A

Communication administratively prohibited. A router Access Control List (ACL) or firewall is in the way

!S

Source route failed. Source routing attempts to force

traceroute to use a certain path. Failure may be

due to a router security setting

 

Some devices will prevent traceroute packets directed at their interfaces, but will allow ICMP packets. Using traceroute with a “-I” flag forces traceroute to use ICMP packets that may go through. In this case the “* * *”, status messages disappear.

 

[root@bigboy root]# traceroute -I 144.232.20.158
traceroute to 144.232.20.158 (144.232.20.158), 30 hops max, 38 byte packets
1 adsl-67-120-221-110.dsl.sntc01.pacbell.net (67.120.221.110) 14.408 ms 14.064 ms 13.111 ms
2 dist3-vlan50.sntc01.pbi.net (63.203.35.67) 13.018 ms 12.887 ms 13.146 ms
3 bb1-g1-0.sntc01.pbi.net (63.203.35.17) 12.854 ms 13.035 ms 13.745 ms
4 bb2-p11-0.snfc21.pbi.net (64.161.124.246) 16.260 ms 15.618 ms 15.663 ms
5 bb1-p14-0.snfc21.pbi.net (64.161.124.53) 15.897 ms 15.785 ms 17.164 ms
6 sl-gw11-sj-3-0.sprintlink.net (144.228.44.49) 14.443 ms 16.279 ms 15.189 ms
7 sl-bb25-sj-6-1.sprintlink.net (144.232.3.133) 16.185 ms 15.857 ms 15.423 ms
8 sl-bb23-ana-6-0.sprintlink.net (144.232.20.158) 27.482 ms 26.306 ms 26.487 ms
[root@bigboy root]#

 

Always Get A Bidirectional Traceroute

It is always best to get traceroutes from the source IP to the target IP and also from the target IP to the source IP. This is because the packet’s return path from the target is sometimes not the same as the path taken to get there. A high traceroute time equates to the round trip time for both the initial traceroute query to each “hop” and the response of each “hop”.

Here is an example of one such case, using disguised IP addresses and provider names. There was once a routing issue between telecommunications carriers FastNet and SlowNet. When a user at IP address 40.16.106.32 did a traceroute to 64.25.175.200, a problem seemed to appear at the 10th. hop with OtherNet. However, when a user at 64.25.175.200 did a traceroute to 40.16.106.32, latency showed up at hop 7 with the return path being very different.  

In this case, the real traffic congestion was occurring where FastNet handed traffic off to SlowNet in the second trace. The latency appeared to be caused at hop 10 on the first trace not because that hop was slow, but because that was the first hop at which the return packet traveled back to the source via the congested route. Remember, traceroute gives the packet round trip time.

 

Trace route to 40.16.106.32 from 64.25.175.200

 

1  0    ms 0    ms 0    [64.25.175.200]
2  0    ms 0    ms 0    [64.25.175.253]
3  0    ms 0    ms 0    border-from-40-tesser.boulder.co.coop.net [207.174.144.169]
4  0    ms 0    ms 0    [64.25.128.126]
5  0    ms 0    ms 0    p3-0.dnvtco1-cr3.othernet.net [4.25.26.53]
6  0    ms 0    ms 0    p2-1.dnvtco1-br1.othernet.net [4.24.11.25]
7  0    ms 0    ms 0    p15-0.dnvtco1-br2.othernet.net [4.24.11.38]
8  30   ms 30   ms 30   p15-0.snjpca1-br2.othernet.net [4.0.6.225]
9  30   ms 30   ms 30   p1-0.snjpca1-cr4.othernet.net [4.24.9.150]
10 1252 ms 1212 ms 1202 h0.webhostinc2.othernet.net [4.24.236.38]
11 1252 ms 1212 ms 1192 [40.16.96.11]
12 1262 ms 1212 ms 1192 [40.16.96.162]
13 1102 ms 1091 ms 1092 [40.16.106.32]

Trace route to 64.25.175.200 from 40.16.106.32

 

1  1    ms 1    ms 1    ms [40.16.106.3]

2  1    ms 1    ms 1    ms [40.16.96.161]

3  2    ms 1    ms 1    ms [40.16.96.2]
4  1    ms 1    ms 1    ms [40.16.96.65]
5  2    ms 2    ms 1    ms border8.p4-2.webh02-1.sfj.fastnet.net [216.52.19.77]
6  2    ms 1    ms 1    ms core1.ge0-1-net2.sfj.fastnet.net [216.52.0.65]
7  993  ms 961  ms 999  ms sjo-edge-03.inet.slownet.net [208.46.223.33]
8  1009 ms 1008 ms 971  ms sjo-core-01.inet.slownet.net [205.171.22.29]
9  985  ms 947  ms 983  ms svl-core-03.inet.slownet.net [205.171.5.97]
10 1028 ms 1010 ms 953  ms [205.171.205.30]
11 989  ms 988  ms 985  ms p4-3.paix-bi1.othernet.net [4.2.49.13]
12 1002 ms 1001 ms 973  ms p6-0.snjpca1-br1.othernet.net [4.24.7.61]
13 1031 ms 989  ms 978  ms p9-0.snjpca1-br2.othernet.net [4.24.9.130]
14 1031 ms 1017 ms 1017 ms p3-0.dnvtco1-br2.othernet.net [4.0.6.226]
15 1027 ms 1025 ms 1023 ms p15-0.dnvtco1-br1.othernet.net [4.24.11.37]
16 1045 ms 1037 ms 1050 ms p1-0.dnvtco1-cr3.othernet.net [4.24.11.26]
17 1030 ms 1020 ms 1045 ms p0-0.cointcorp.othernet.net [4.25.26.54]
18 1038 ms 1031 ms 1045 ms gw234.boulder.co.coop.net [64.25.128.99]
19 1050 ms 1094 ms 1034 ms [64.25.175.253]
20 1050 ms 1094 ms 1034 ms [64.25.175.200]

Ping & Traceroute Troubleshooting Example

In this example, a ping to 186.9.17.153 gave a “TTL timeout” message. Ping TTLs will usually only timeout if there is a routing loop in which the packet bounces between two routers on the way to the target. Each “bounce” causes the TTL to decrease by a count of one until the TTL reaches zero at which point you get the timeout.

The routing loop was confirmed by the traceroute in which the packet was proven to be bouncing between routers at 186.40.64.94 and 186.40.64.93.

 

G:\>ping 186.9.17.153

 

Pinging 186.9.17.153 with 32 bytes of data:

 

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

Reply from 186.40.64.94: TTL expired in transit.

 

Ping statistics for 186.9.17.153:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum =  0ms, Average =  0ms

 

 

G:\>tracert 186.9.17.153

 

Tracing route to lostserver.confusion.net [186.9.17.153]

over a maximum of 30 hops:

 

  1   <10 ms   <10 ms   <10 ms  186.217.33.1

  2    60 ms    70 ms    60 ms  rtr-2.confusion.net [186.40.64.94]

  3    70 ms    71 ms    70 ms  rtr-1.confusion.net [186.40.64.93]

  4    60 ms    70 ms    60 ms  rtr-2.confusion.net [186.40.64.94]

  5    70 ms    70 ms    70 ms  rtr-1.confusion.net [186.40.64.93]

  6    60 ms    70 ms    61 ms  rtr-2.confusion.net [186.40.64.94]

  7    70 ms    70 ms    70 ms  rtr-1.confusion.net [186.40.64.93]

  8    60 ms    70 ms    60 ms  rtr-2.confusion.net [186.40.64.94]

  9    70 ms    70 ms    70 ms  rtr-1.confusion.net [186.40.64.93]

Trace complete.

 

This problem was solved by resetting the routing process on both routers. The problem was initially triggered by an unstable network link that caused frequent routing recalculations. The constant activity eventually corrupted the routing tables of one of the routers.

 

Possible Reasons For Failed Traceroutes

Traceroutes can fail to reach their intended destination for a number of reasons, these include:

o        Traceroute packets are being blocked or rejected by a router in the path. The router immediately after the last visible one is usually the culprit. It’s usually good to check the routing table and/or other status of this next hop device.

o        The target server doesn’t exist on the network. It could be disconnected, or turned off. (!H or !N messages may be produced.)

o        The network on which you expect the target host to reside doesn’t exist in the routing table of one of the routers in the path (!H or !N messages may be produced.)

o        You may have a typographical error in the IP address of the target server

o        You may have a routing loop in which packets bounce between two routers and never get to the intended destination.

o        The packets don’t have a proper return path to your server. The last visible hop being the last hop in which the packets return correctly. The router immediately after the last visible one is the one at which the routing changes. It’s usually good to:

v      log on to the last visible router.

v      Look at the routing table to determine what the next hop is to your intended traceroute target.

v      Log on to this next hop router.

v      Do a traceroute from this router to your intended target server.

v      If this works: Routing to the target server is OK. Do a traceroute back to your source server. The traceroute will probably fail at the bad router on the return path.

v      If it doesn’t work: Test the routing table and/or other status of all the hops between it and your intended target.

Note: If there is nothing blocking your traceroute traffic, then the last visible router of an incomplete trace is either the last good router on the path, or the last router that has a valid return path to the server issuing the traceroute. 

 

 


 

Viewing Packet Flow With TCPdump

Tcpdump is one of the most popular packages for viewing the flow of packets through your Linux box’s NIC card. It is installed by default on RedHat linux and has very simple syntax, especially if you are doing simpler types of troubleshooting. 

One of the most common uses of tcpdump is to determine whether you are getting basic two way communication. Lack of communication could be due to:

·     Bad routing

·     Faulty cables, interfaces of devices in the packet flow

·     The server not listening on the port because the software isn’t installed or started

Analyzing tcpdump in much greater detail is beyond the scope of this section.

 

Like most Linux commands, tcpdump uses command line switches to modify the output. Some of the more useful command line switches would include:

Possible TCPdump Messages 

tcpdump

command

switch

Description

-c

Stop after viewing count packets.

-i

Listen on interface. If this is not specified, then tcpdump will use the lowest numbered interface that is UP

-t

Don’t print a timestamp at the beginning of each line

 

 

You can also add expressions after all the command line switches. These act as filters to limit the volume of data presented on the screen. You can also use keywords such as “and” or “or” between expressions to further fine tune your selection criteria. Some useful expressions include:


 

Useful TCPdump Expressions 

tcpdump

command

expression

Description

host host-address

View packets from the IP address host-address

icmp

View icmp packets

tcp port port-number

View TCP packets with packets with either a  source or destination TCP port of port-number

udp port port-number

View UDP packets with either a  source or destination UDP port of port-number

 

Example: tcpdump used to view ICMP “ping” packets going through interface wlan0

 

[root@bigboy tmp]# tcpdump -i wlan0 icmp

tcpdump: listening on wlan0
21:48:58.927091 smallfry > bigboy.my-site.com: icmp: echo request (DF)
21:48:58.927510 bigboy.my-site.com > smallfry: icmp: echo reply
21:48:58.928257 smallfry > bigboy.my-site.com: icmp: echo request (DF)
21:48:58.928365 bigboy.my-site.com > smallfry: icmp: echo reply
21:48:58.943926 smallfry > bigboy.my-site.com: icmp: echo request (DF)
21:48:58.944034 bigboy.my-site.com > smallfry: icmp: echo reply
21:48:58.962244 bigboy.my-site.com > smallfry: icmp: echo reply
21:48:58.963966 bigboy.my-site.com > smallfry: icmp: echo reply
21:48:58.968556 bigboy.my-site.com > smallfry: icmp: echo reply

9 packets received by filter
0 packets dropped by kernel
[root@bigboy tmp]#
 

Explanation

o        The first column of data is a packet time stamp.

o        The second column of data shows the packet source then destination IP address or server name of the packet

o        The third column shows the packet type

o        Two way communication is occurring as each echo gets an echo reply


 

 

Example: tcpdump used to view packets on interface wlan0 to/from host 192.168.1.102 on TCP port 22 with no timestamps in the output

 

[root@bigboy root]# tcpdump -i wlan0 -t host 192.168.1.102 and tcp port 22

tcpdump: listening on wlan0
smallfry.32938 > bigboy.my-site.com.ssh: S 2013297020:2013297020(0) win 5840 <mss 1460,sackOK,timestamp 75227931 0,nop,wscale 0> (DF) [tos 0x10]
bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 2013297021 win 0 (DF) [tos 0x10]
smallfry.32938 > bigboy.my-site.com.ssh: S 2013297020:2013297020(0) win 5840 <mss 1460,sackOK,timestamp 75227931 0,nop,wscale 0> (DF) [tos 0x10]
bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]
smallfry.32938 > bigboy.my-site.com.ssh: S 2013297020:2013297020(0) win 5840 <mss 1460,sackOK,timestamp 75227931 0,nop,wscale 0> (DF) [tos 0x10]
bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]
bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]

bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]
bigboy.my-site.com.ssh > smallfry.32938: R 0:0(0) ack 1 win 0 (DF) [tos 0x10]

9 packets received by filter
0 packets dropped by kernel
[root@bigboy root]#

Explanation

o        The first column of data shows the packet source then destination IP address or server name of the packet

o        The second column shows the TCP flags within the packet

o        The client named “bigboy” is using port 32938 to communicate with the server named “smallfry” on the TCP SSH port 22.

o        Two way communication is occurring

 

Using Telnet

An easy way for you to tell if a remote server is listening on a specific TCP port is to use the telnet command. By default, telnet will try to connect on TCP port 23, but you can specify other TCP ports by typing them in after the target IP address. In this case we’re testing to see if the remote server is listening on port 22 (SSH)

 

[root@bigboy tmp]# telnet 192.168.1.102 22

Trying 192.168.1.102…

Connected to 192.168.1.102.

Escape character is ‘^]’.

SSH-1.99-OpenSSH_3.4p1

^]

telnet> quit

Connection closed.

[root@ bigboy tmp]#

 

To break out of the connection you have to use <ctrl>], not the usual <crtl>C. You will geta “connection refused” message if the remote server isn’t listening on the specified target port as shown in the example below.

 

[root@bigboy tmp]# telnet 192.168.1.102 22

Trying 192.168.1.100…

telnet: connect to address 192.168.1.100: Connection refused

[root@ bigboy tmp]#

 

I have used this technique often to troubleshoot remote webservers that aren’t serving web pages. If it is listening on port 80, and no pages are being served, then the problem is usually due to a bad web application, not the web server software itself. If it isn’t listening to port 80 at all, then it could be an Apache / IIS problem, or the server could be down, or there could be a network related problem that prevents connectivity from being established.

 

Using NMAP

NMAP is program that you can use to determine all the TCP ports on which a remote server is listening. It isn’t usually an important tool in the home environment but in a corporate environment it can be helpful in getting a better idea of the function of undocumented servers that have been found by your boss. You can also use it to run a vulnerability scan against your site as NMAP is one of the tools used by malicious surfers.

Here is a sample output:

·     First we see all the available options by just typing the “nmap” command

 

[root@bigboy tmp]# nmap

Nmap V. 3.00 Usage: nmap [Scan Type(s)] [Options] <host or net list>

Some Common Scan Types (‘*’ options require root privileges)

* -sS TCP SYN stealth port scan (default if privileged (root))

  -sT TCP connect() port scan (default for unprivileged users)

* -sU UDP port scan

  -sP ping scan (Find any reachable machines)

* -sF,-sX,-sN Stealth FIN, Xmas, or Null scan (experts only)

  -sR/-I RPC/Identd scan (use with other scan types)

Some Common Options (none are required, most can be combined):

* -O Use TCP/IP fingerprinting to guess remote operating system

  -p <range> ports to scan.  Example range: ‘1-1024,1080,6666,31337’

  -F Only scans ports listed in nmap-services

  -v Verbose. Its use is recommended.  Use twice for greater effect.

  -P0 Don’t ping hosts (needed to scan http://www.microsoft.com and others)

* -Ddecoy_host1,decoy2[,…] Hide scan using many decoys

  -T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> General timing policy

  -n/-R Never do DNS resolution/Always resolve [default: sometimes resolve]

  -oN/-oX/-oG <logfile> Output normal/XML/grepable scan logs to <logfile>

  -iL <inputfile> Get targets from file; Use ‘-‘ for stdin

* -S <your_IP>/-e <devicename> Specify source address or network interface

  –interactive Go into interactive mode (then press h for help)

Example: nmap -v -sS -O http://www.my.com 192.168.0.0/16 ‘192.88-90.*.*’

SEE THE MAN PAGE FOR MANY MORE OPTIONS, DESCRIPTIONS, AND EXAMPLES

[root@bigboy tmp]#

 

·     Then we scan by trying to make regular connections (-sT) in the extremely fast “insane” mode (–T 5) from ports 1 to 5000.

 

[root@bigboy tmp]# nmap -sT -T 5 -p 1-5000 192.168.1.153

 

Starting nmap V. 3.00 ( http://www.insecure.org/nmap/ )

Interesting ports on whoknows.my-site-int.com (192.168.1.153):

(The 4981 ports scanned but not shown below are in state: closed)

Port       State       Service

21/tcp     open        ftp                    

25/tcp     open        smtp                   

135/tcp    open        loc-srv                

139/tcp    open        netbios-ssn            

199/tcp    open        smux                   

465/tcp    open        smtps                   

507/tcp    open        crs                    

2103/tcp   open        unknown                

2105/tcp   open        eklogin                

2107/tcp   open        unknown                

2301/tcp   open        compaqdiag              

3300/tcp   open        unknown                

 

Nmap run completed — 1 IP address (1 host up) scanned in 8 seconds

[root@bigboy tmp]#

 

Who Has Used My System?

It is always important to know who has logged into your Linux box. This isn’t just to help track the activities of malicious users, but mostly to figure out who made the mistake that crashed the system or blew up Apache with a typographical error in the httpd.conf file.


 

The “Last” Command

The most common command to do this is “last” which will list the last users who logged into the system. Here are some examples:

[root@rahtid log]# last -100

root     pts/0        reggae.simiya.co Thu Jun 19 09:26   still logged in  

root     pts/0        reggae.simiya.co Wed Jun 18 01:07 – 09:26 (1+08:18)  

reboot   system boot  2.4.18-14        Wed Jun 18 01:07         (1+08:21)  

root     pts/0        reggae.simiya.co Tue Jun 17 21:57 – down   (03:07)   

root     pts/0        reggae.simiya.co Mon Jun 16 07:24 – 00:35  (17:10)   

root     pts/0        reggae.simiya.co Sun Jun 15 16:29 – 17:26  (00:56)   

wtmp begins Sun Jun 15 16:29:18 2003

[root@rahtid log]#

 

In the example above someone from reggare.simiya.com logged into bigboy as user root. I generally prefer not to give out the “root” password and let all the systems administrators log in with their own individual logins. They can then get “root” privileges by using sudo. This makes it easier to track down individuals versus groups of users.

The “who” Command

This command is used to see who is currently logged in. Here we see a user logged as root from server reggae.simiya.com .

 

[root@rahtid log]# who

root     pts/0        Jun 19 09:26 (reggae.simiya.com)

[root@rahtid log]#

Sumber : http://www.chinalinuxpub.com

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: