network analysis tools hostname traceroute | dig domain| dig -x host

hostname - check your own hostname
ping - test connectivity
traceroute - get routing info
dig - get DNS info
nmap - advanced tool to get info about remote service availability

packet informatio for network cards
[root@localhost ~]# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
ens33 1500 55447 0 0 0 32570 0 0 0 BMRU
lo 65536 211 0 0 0 211 0 0 0 LRU

listening ports
[root@localhost ~]# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 15358 1/systemd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 20873 1120/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 20907

way to troubleshoot connection
1) ip a show

make sure there is default route in the same network as IP ADDRESS
2) ip route show, check default route
[root@localhost ~]# ip route show
default via 192.168.174.2 dev ens33 proto static metric 100
192.168.174.0/24 dev ens33 proto kernel scope link src 192.168.174.131 metric 100

check DNS config,still good to use resolve.conf
3)[root@localhost ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search localdomain
nameserver 192.168.174.2
nameserver 8.8.8.8
nameserver 8.8.8.4

4)ping default route
root@localhost ~]# ping 192.168.174.2
PING 192.168.174.2 (192.168.174.2) 56(84) bytes of data.
64 bytes from 192.168.174.2: icmp_seq=1 ttl=128 time=0.179 ms

bandwidth test - use ping -f
[root@localhost ~]# ping -f google.com
PING google.com (172.217.20.174) 56(84) bytes of data.
.....^C
--- google.com ping statistics ---
1378 packets transmitted, 1373 received, 0% packet loss, time 18393ms
rtt min/avg/max/mdev = 40.777/46.719/112.560/11.311 ms, pipe 9, ipg/ewma 13.357/43.889 ms

[root@localhost ~]#

5)traceroute

6)DNS name resolution works

[root@localhost ~]# host google.com

google.com has address 216.58.209.46

google.com has IPv6 address 2a00:1450:401b:803::200e

google.com mail is handled by 50 alt4.aspmx.l.google.com.

google.com mail is handled by 30 alt2.aspmx.l.google.com.

google.com mail is handled by 10 aspmx.l.google.com.

google.com mail is handled by 20 alt1.aspmx.l.google.com.

google.com mail is handled by 40 alt3.aspmx.l.google.com.

[root@localhost ~]# dig google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.1 <<>> google.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27595

;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; MBZ: 0005 , udp: 512

;; QUESTION SECTION:

;google.com. IN A

;; ANSWER SECTION:

google.com. 5 IN A 216.58.209.78

;; Query time: 55 msec

;; SERVER: 192.168.174.2#53(192.168.174.2)

;; WHEN: Sat Jun 03 16:20:23 EDT 2017

;; MSG SIZE rcvd: 87
===================

dig uses the OS resolver libraries. nslookup uses is own internal ones.

That is why Internet Systems Consortium (ISC) has been trying to get people to stop using nslookup for some time now. It causes confusion.

===================
[root@localhost ~]# ip -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
18178 211 0 0 0 0
TX: bytes packets errors dropped carrier collsns
18178 211 0 0 0 0
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 00:0c:29:17:b4:58 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
64942140 56913 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2953545 34082 0 0 0 0

[root@localhost ~]#

[root@localhost ~]# nmap -p 1-1000 google.com

Starting Nmap 6.40 ( http://nmap.org ) at 2017-06-03 16:33 EDT
Nmap scan report for google.com (172.217.20.206)
Host is up (0.044s latency).
Other addresses for google.com (not scanned): 172.217.20.206 172.217.20.206
rDNS record for 172.217.20.206: waw02s08-in-f14.1e100.net
Not shown: 998 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https

Nmap done: 1 IP address (1 host up) scanned in 55.84 seconds
[root@localhost ~]#

Digging deeper with NSE Scripts

Scan using default safe scripts	nmap -sV -sC 192.168.1.1
Get help for a script	nmap --script-help=ssl-heartbleed
Scan using a specific NSE script	nmap -sV -p 443 –script=ssl-heartbleed.nse 192.168.1.1
Scan with a set of scripts	nmap -sV --script=smb* 192.168.1.1

According to my Nmap install there are currently 471 NSE scripts. The scripts are able to perform a wide range of security related testing and discovery functions. If you are serious about your network scanning you really should take the time to get familiar with some of them.

The option --script-help=$scriptname will display help for the individual scripts. To get an easy list of the installed scripts try locate nse | grep script.

A scan to search for DDOS reflection UDP services

Scan for UDP DDOS reflectors

nmap –sU –A –PN –n –pU:19,53,123,161 –script=ntp-monlist,dns-recursion,snmp-sysdescr 192.168.1.0/24

UDP based DDOS reflection attacks are a common problem that network defenders come up against. This is a handy Nmap command that will scan a target list for systems with open UDP services that allow these attacks to take place. Full details of the command and the background can be found on the Sans Institute Blog where it was first posted.

Detect Heartbleed SSL Vulnerability

Heartbleed Testing

nmap -sV -p 443 --script=ssl-heartbleed 192.168.1.0/24

Heartbleed detection is one of the available SSL scripts. It will detect the presence of the well known Heartbleed vulnerability in SSL services. Specify alternative ports to test SSL on mail and other protocols (Requires Nmap 6.46).

Search This Blog

Linux, UNIX