yurisk.info » Linux

MAC finder script

Yuri — Fri, 02 Jul 2010 05:35:37 +0000

While I don’t like going down to Layer 2 , recently I had to do it – I didn’t know IP address of the Cisco router I wanted to connect to but I had access to the Cisco router sitting in the same network. That would be pretty easy to do #show arp on this router and then search on Google to whom belongs each MAC if it wasn’t the subnet mask of /26. Copy pasting each entry of the ARP table into Google didn’t look like a lot of fun. So I wrote a python script that reads MAC addresses in bulk from command line and using downloaded beforehand database of MAC-vendor translations prints vendor for each MAC address. It works for #show arp on CIsco,#show mac-address-table on CIsco switches, #arp -en on Linux (means including Checkpoint), #arp -a on Freebsd ,#show arp of Junos from Juniper, #get sys arp on Fortigate.
Below is the script.
Here:
mac-database.txt – file containing MAC-vendor translation in format , I used standards.ieee.org/regauth/oui/oui.txt as the source with a bit of sed, but if you want ready to use file I recommend nmap-mac-prefixes from nmap source-code distribution http://nmap.org/svn/nmap-mac-prefixes
Download script (to make sure formatting is preserved, an important thing for Python)
http://yurisk.info/scripts/mac-finder.py
Script AND mac database from nmap project – http://yurisk.info/scripts/mac.tar.gz

#!/usr/bin/python
#This script accepts MAC addresses from the command line and
#prints vendor for each mac address
# Author:Yuri, yurisk@yurisk.info,06.2010
import sys
import re
#This function removes from MACs colon or dot and returns MAC as a sequence of HEX chars
def dotreplace(matchobj):
         if matchobj.group(0) == '.':
                return ''
         elif  matchobj.group(0) == ':':
                return ''
#open file with MAC addresses and vendors database,it has form xxxx 
macs=open('mac-database.txt','r')
macs_lines=macs.readlines()
#Read from stdinput
data = sys.stdin.readlines()
for ppp in data:
       popa=re.search('.*([a-f0-9]{4}\.[a-f0-9]{4}\.[a-f0-9]{4}).*',ppp,re.IGNORECASE)
       if popa:
             newpopa=re.sub('\.', dotreplace,popa.group(1))[0:6]
             newpopa_re=re.compile(newpopa,re.IGNORECASE)
             for mac_db in macs_lines:
                 vendor=re.search(newpopa_re,mac_db)
                 if vendor:
                    print ppp.strip(),mac_db[7:]
       popalinux = re.search('.*([a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}:[a-f0-9]{2}).*',ppp,re.IGNORECASE)
       if popalinux:
             newpopalinux=re.sub(':',dotreplace,popalinux.group(1))[0:6]
             newpopalinux_re=re.compile(newpopalinux,re.IGNORECASE)
             for mac_db in macs_lines:
                 vendor=re.search(newpopalinux_re,mac_db)
                 if vendor:
                    print ppp.strip(),mac_db[7:]

       popadash = re.search('.*([a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}-[a-f0-9]{2}).*',ppp,re.IGNORECASE)
       if popadash:
             newpopadash=re.sub('-',dotreplace,popadash.group(1))[0:6]
             newpopadash_re=re.compile(newpopadash,re.IGNORECASE)
             for mac_db in macs_lines:
                 vendor=re.search(newpopadash_re,mac_db)
                 if vendor:
                    print ppp.strip(),mac_db[7:]

Running it:

[root@darkstar ]# ./mac-finder.py

$ arp -a
(10.99.99.150) at 00:50:56:95:74:72 on em0 [ethernet]
(10.99.99.254) at 00:09:0f:31:c8:24 on em0 [ethernet]

(10.99.99.150) at 00:50:56:95:74:72 on em0 [ethernet] VMware, Inc.
(10.99.99.254) at 00:09:0f:31:c8:24 on em0 [ethernet] Fortinet Inc.

How to choose the password that noone can guess and you cant remember

Yuri — Wed, 09 Jun 2010 10:29:21 +0000

How to choose the password that noone can guess and you cant remember Of course you know what the good password should be – random letters including capitals, peppered with numbers and enhanced with printable control characters.
The only small but important detail these recommendations seem to forget is that there are may be few hundreds in the world that can memorize such incomprehensible sequence of chars. So if someone does decide to follow it such passwords end up being written on the paper and stuck to the monitor (on its back).
I never followed such recommendations but nevertheless found the way to come up with hard to break passwords. Here it is – I just take easily memorizeable sentence from some verse/prose , take first letters of each word, capitalize first letter and then add some predefined number that doesn’t chnage from password to password .Example follows.
This is how the 1st sentence from e.e. cummings turns into password:
Anyone lived in a pretty how town -> Aliapht7722
As I said previously these are passwords I use also for SSH user access and for the last year brute force efforts went down the drains (so far).
The topic of passwords is actually a big one , and more of human psychology kind rather than crypto-randomness sort of things.
For more about that look for example here:
www.schneier.com
Another way to come up with random but easy to pronounce words for passwords can be done with scientific approach:
www.multicians.org

Top 10 usernames used in SSH brute force

Yuri — Fri, 04 Jun 2010 09:08:23 +0000

In continuation to yesterday’s post I thought it would be interesting to know statistics of the usernames used in those bruteforce probes. I thought and I did . Find below awk/sed script to get usernames for failed ssh login attempts and sort it for statistics and also list of the usernames I got from my server. The full list of usernames can be found at the end.
The script:

awk '/Failed password for/ ' /var/log/secure* | sed 's/.* $[[:print:]]\+$ from .*/ \1 /g ' | sort | uniq -c | sort -n -k1

And the winners are:

The table listing top 10 usernames used in real cracking attampts on SSH service
Username	Number of times seen
mysql	232
info	252
postgres	317
guest	435
nagios	452
user	459
oracle	598
admin	884
test	1017
root	22058

Full list of the usernames Usernames.log

SSH brute force is on the rise

Yuri — Thu, 03 Jun 2010 19:31:43 +0000

SSH brute forcing is still in high demand. I have , for my own testing and pleasure, virtual servers scattered around the world. All of them being of the Linux/BSD family I manage by SSH. The other quirk of mine is that I have on purpose no static IP at home for various reasons (saving me money being one of them). And to manage those servers by SSH I implement a very simple security rule – from Any to SSH port allow. Port is left to be standard one – 22. After all that time my server was broken into just once , when I gave access by SSH to the colleague of mine and later he changed the password to something crackable in 5 secs. Since then I – first don’t give ssh access to colleagues , and second – look from time to time at ssh failed attempts logs for amusement.

My observations so far are :
– ssh brute forcing is still/yet/again extremely popular and increasing . On average after unfirewalled access to port 22 is discovered it goes to ~ 5000-6000 attempts per day .
– crackers do have some means of communicating between them (market economy ?) – my servers have static IPs and first days after its set up brute force login attempts are as low as 2-10 a day. But once the server IP has been discovered by determined crackers it goes up in numbers very quickly.
– origins of the attacks correlate pretty well with the known sources of Spam/Malware : Brazil, China, US etc.
If you’d like to look at your SSH logs and do some stats on failed attempts here is the awk one-liner I use. Enjoy.

awk --re-interval '/authentication failure/ {}
/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]/ {match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]/,IP); IPS[IP[0]]++ } END { for (cracker_ips in IPS) print cracker_ips " " IPS[cracker_ips]}' /var/log/secure.1 | sort -n -k2

190.202.85.3 1
194.192.14.7 1
212.111.199.3 1
222.124.195.1 1
210.71.71.1 2
89.138.195.1 5
212.156.65.7 25
202.117.51.2 32
210.51.48.7 32
115.146.138.5 47
60.191.98.5 88
174.120.208.5 107
61.129.60.2 165
202.103.180.4 175
213.251.192.2 239
91.82.101.4 242
220.173.60.6 264
12.11.210.3 271
144.16.72.1 291
212.118.5.1 360
66.11.122.1 384
211.160.160.1 703
190.12.66.1 999
83.19.184.3 1176
67.213.8.2 4955
199.187.120.2 5312
95.0.180.2 6680
85.131.163.5 7685

NB Crackers IPs are not sanitized

IP Options are evil – drop them , drop them on Cisco Asa/IOS Microsoft ISA Juniper or Checkpoint

Yuri — Sat, 23 Jan 2010 19:51:22 +0000

As you probably noticed IP header has variable length placeholder for the IP Options field. It has been there since the beginning , once a good idea for debug now turned into trouble. RFC 791 states that hosts/routers supporting IP protocol must implement Ip Options filed . It is up to the vendor to decide what to do with this optional field, but it must understand it. Still, wouldn’t be a problem if not modern architecture of the routing equipment that was designed to do most efficiently Routing , i.e. pass from interface to interface gigabytes of traffic. Therefore routing functions are highly optimized and most of the time are implemented in hardware . All other types of traffic unfortunately are not, and in most of the cases processing , lets call it Control traffic, is being left to poor router CPU and done in software. That brought the troubles into the IP world – relatively small amounts of control traffic (including Ip Options packets) may bring down otherwise
powerful router in just minutes.
To prevent this attack vendors implemented protection measures to drop entirely or selectively IP packets that has Ip Options filed set. Below is quick cheat sheet how to do it in some gear :

Checkpoint firewall NG/NGX – packets with Ip Options are dropped by default except for the “Router Alert” option (0×94) for the IGMPv2 and PIM protocols [or so CP claim, will have to verify later] and not even logged. To start logging dropped packets go to Policy -> Global Properties -> Log and Alerts -> check Ip dropped packets : Log

There is a value related to it that is on by default : Global Properties -> SmartDashboard customization -> Advanced Configuration -> Configure -> Firewall 1 -> Stateful inspection -> enable_ip_options (check/uncheck) but unchecking it removes from firewall VM chain module that inspects these Options at all and all Ip Options packets are dropped . So all packets bearing Ip Options are happily dropped even before security rules , here:

[Expert@splat60]# fw ctl chain
in chain (9):
0: -7f800000 (9095dd60) (ffffffff) IP Options Strip (ipopt_strip)
1: – 1fffff6 (9095ee80) (00000001) Stateless verifications (asm)

Also Checkpoint say you can decide which Ip Options will be allowed later BUT only when installing the firewall: “The set of permitted options must be configured during installation … the enable_ip_options setting in SmartDashboard is then used to enable or disable this functionality. Contact Check Point support for instructions on configuring the set of allowed IP options.”

Microsoft ISA 2000 server:
– If Enable Packet Filtering is not checked then do it in IP Packet Filters -> Properties – > General tab. On the Packet Filters tab check Enable Filtering IP Options .
Microsoft ISA 2004 Server:
- IP options filtering is enabled by default
- Go to Configuration node of the server in question in Management console -> General -> Additional Security Policy
Define IP Preferences . Here you will have 3 options to deal with Ip Options packets:
a) Deny packets with any IP options;
b) Deny packets with selected IP options;
c) Deny packets with all except selected IP options
The same options are available in ISA 2006 , click on Configure IP Protection link – > IP Preference settings

IOS Cisco router :
see my other blog – to be filled later
Cisco ASA :
see my other blog – to be filled later

Juniper router:
You just add ip-options term to the filter and apply it to the interface of interest. In the example below I block only Route Record type of Ip Options, if you use any then it will block any type:

[edit firewall family inet filter NOICMP term 3]

firewall {
    family inet {
        filter NOICMP {
            term 1 {
                from {
                    address {
                        192.168.2.100/32;
                    }
                }
                then {
                    reject;
                }
            }
            term 2 {
                from {
                    ip-options route-record;
                }
                then {
                    reject;
                }
            }
            term 3 {
                from {
                    address {
                        192.168.2.0/24;
                    }
                }
                then accept;
            }
        }
    }
}

Apply to the interface:

interfaces {
    em0 {
        unit 0 {
            enable;
            family inet {
                filter {
                    input NOICMP;
                }
                address 192.168.2.133/24;
            }
        }
    }

Other possible arguments to ip-options clause:

set term 3 from ip-options ?

Possible completions:

              Range of values
  [                    Open a set of values
  any                  Any IP option
  loose-source-route   Loose source route
  route-record         Route record
  router-alert         Router alert
  security             Security
  stream-id            Stream ID
  strict-source-route  Strict source route
  timestamp            Timestamp

Windows 2008.
By default it doesnt allow/forward packets with Source Routing set, and that's good. For completeness
here is how to enable (or check whether it is enabled) source-routed forwarding:
BillG> netsh interface ipv4 set global sourceroutingbehavior=drop| forward| dontforward
- or-
Registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
Key: DisableIPSourceRouting
DWORD value: 0

Verify:
In Security any measure/protection/method is as good as the proof you can present that it actually works.
Windows:
- Ping with Record Route field set:
BillG> ping –r 9 192.2.2.1
- Ping with Strict Routing field set:
BillG> ping –k <1st_hop_router_IP> <2nd_hop_router_IP…>
- Ping with Loose Routing field set:
BillG> ping -j <1st_hop_router_IP> <2nd_hop_router_IP…>
- Ping with Timestamp option set:
BillG> ping –s 3 8.8.8.8
Linux:
- Ping with Record Route field set:
root@darktstar:~/nmap# ping -R 8.8.8.8
- Ping with Timestamp option set:
root@darkstar:~/nmap# ping -T tsonly 8.8.8.8
Linux,BSD,Unix :
This handy utility sends bunch of packets to the target to test what Ip Options the target supports:
freebsd# fragtest ip-opt 192.168.2.133
ip-opt: sec lsrr ts esec cipso satid ssrr
I run fragroute above against Juniper (8.3) that was configured in the example earlier to block only Record Route option, as you can see it is indeed missing in the output list that enumerates what Ip Options the target supports [ see Reference for fragroute details]

References for further details:
Juniper: JUNOS Enterprise Routing, 1st Edition, By Doug Marschke; Harry Reynolds, 2008
Microsoft ISA : Microsoft® ISA Server 2006 Unleashed ,By Michael Noel, 2007
Fragroute http://monkey.org/~dugsong/fragroute/
Windows 2008: Windows® Server 2008 TCP/IP Protocols and Services,By Joseph Davies, 2008

ARP table overflow in Checkpoint and Linux in general

Yuri — Tue, 15 Dec 2009 13:40:56 +0000

Not specific to the Checkpoint but rather any Linux-based system issue, still people often
forget about that and look for the Checkpoint-specific solutions to that , so to help with this search I wrote the note
how to fix it below:
Problem usually shows itself in randomly distributed inability of stations to pass the firewall, slowness and other network problems follow.
In /var/log/message you see the following record:

kernel: Neighbour table overflow.
That means ARP table has reached its maximum allowed limit and no new ARP entries are being learnt.

You can either find reason for sudden ARP requests influx or adjust ARP table limts accordingly.
You adjust ARP table limits either editing this file (then change survives reboot):

/etc/sysctl.conf
If not present add these lines at the end, and try not to delete by mistake anything:
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 16384

- Then issue command:
# sysctl -p
- Or if you want to increase it temporarily until reboot:
#echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh1
#echo 4096 > /proc/sys/net/ipv4/neigh/default/gc_thresh2
#echo 16384 > /proc/sys/net/ipv4/neigh/default/gc_thresh3

And the short explanation follows.
gc in the above means Garbage Collector (GC).
net.ipv4.neigh.default.gc_thresh1 – sets minimum number of ARP entries in the cache.
Until this value is reached GC doesnt run at all.
net.ipv4.neigh.default.gc_thresh2 – sets soft maximum number of ARP entries in the cache.
GC allows ARP cache to pass this limit for 5 seconds and then starts cleaning.
net.ipv4.neigh.default.gc_thresh3 - sets hard limit of ARP entries in the cache.
After it is reached no more ARP entries are being added.

SSH login alert by mail Linux or Unix based systems

Yuri — Fri, 18 Sep 2009 10:24:40 +0000

As you may have noticed many security-related software/appliances are based on Linux or Unix operating
systems in their variety. And as the logical consequence of that remote managing of such devices is done with OpenSSH
package . What is lacking in these applications built on Linux/Unix platforms is alerting in real–time on successful
SSH login to the system . e.g eSafe can alert only on login to the software itself (i.e. econsole), the same goes for the Checkpoint firewall
. On the other hand SSH login to the system ultimately means superuser/root access that gives control over the whole
system. To fix it I wrote the following script. This script sends mail to predefined email address each time someone
successfully logs in by SSH to the machine.
I take advantage here of the built-in feature of the OpenSSH daemon – if you create text file containing commands (as if you typed
them on the command line), and name it either /etc./ssh/sshrc or /.ssh/rc , these commands in file will be run each time user logs in through SSH daemon to the system.
The file has to be readable by the user logging in through SSH.
Note 1:
file /etc/ssh/sshrc is applied globally to any user logging in, unless:
Note 2:
file /.ssh/rc overrides action of /etc/ssh/sshrc . Caveat here – it is enough for a user to put in his home .ssh directory
empty file named rc and it will disable /etc/ssh/sshrc including mail alerts sent from it. Actually it is not that big of an issue as you may
create rc file in the home directory of the user yourself, give it 644 permissions and while user will know what is going on when doing ssh login he/she won’t be able to do anything about that.

So to script itself.
Here:
yurisk@yurisk.info   – mail to which I get mail alert
mail.yurisk.info   -   mail server that accepts mails destined for yurisk.info domain (its MX record)
SENDING_HOST   - hostname of sending host, will be included in the subject so later I can create mail inbox rule to pay appropriate attention   to such mails
USER_ID     – output of the #id command so I will also be able to filter incoming messages on the user logged in

freeBSD# cat /etc/ssh/mail_alert.awk
BEGIN {
# Set up some info to be included in the mail
# As you see I prefer to use absolute pathnames , but you don’t have to
# Find the hostname to which SSH login happened , to be included in the Subject
”/bin/hostname” | getline SENDING_HOST
# FInd ID of logged
”/usr/bin/id” | getline
USER_ID = $1
SMTP = “/inet/tcp/0/mail.yurisk.info/25″
RS = ORS = “\r\n”
print “helo yurisk.info”     |& SMTP
SMTP                       |& getline
print “mail from: <yurisk@yurisk.info>” |& SMTP
SMTP                       |& getline
print “rcpt to: <yurisk@yurisk.info>” |& SMTP
SMTP                       |& getline
print   “data”             |& SMTP
SMTP                       |& getline
print “Subject:SSH login alert – user ” USER_ID “logged in ” SENDING_HOST |& SMTP
print                       |& SMTP
”/usr/bin/w” | getline
print $0                  |& SMTP
  print   ” He is most free from danger, who, even when safe, is on his guard “               |& SMTP

print   “ “               |& SMTP
print “.”                 |& SMTP
print                      |& SMTP

print “quit” |& SMTP

}
- Now the file that is checked on each login for commands ( I put both files in /etc/ssh/) :
freeBSD# cat /etc/ssh/sshrc
awk -f /etc/ssh/mail_alert.awk > /dev/null
Note for FreeBSD (I guess any *BSD) users: in *rc file above you will have to replace awk with gawk, as in *BSD systems awk behaves as the old-style Unix awk that has no bidirectional pipe to connect to mail server.

PS. You might be asking why awk here ? True, Linux/Unix have perfect tool for sending mails called #mail, but I did it with awk
for a reason – not on every (especially if hardened) system you will find mail/telnet/etc utilities with which sending mails is more simple and more reliable. The biggest one is Checkpoint firewall – it has NO mail or telnet clients, neither scripting language beyond AWK and Bash.

The downside of awk is that it is not perfect for more or less complex protocols. So script may stuck / send commands too fast/ etc and therefore be disconnected by the server.

Also if mail server uses greylisting – this script won’t understand it. So check it in interactive session before using. If time permits later I will polish it a bit to count for such cases.

BTW If you haven’t noticed eSafe has full-blown scripting languages installed – Perl and Python . With these you are limited by your imagination only.

Ping – setting don't fragment bit in Linux/FreeBSD/Solaris/Cisco/Juniper

Yuri — Tue, 01 Sep 2009 08:42:46 +0000

Ping.

Many times while debugging network problems of various kinds you need to send some packets
of desirable size and don’t fragment bit being set. Below I list how to do it for the different
equipment/OSes.
Let’s start with the most popular operating system among network folks – Linux:

Linux

By default ping in any Linux-based system (It also means any distribution – Slackware, Ubuntu, CentOS etc) is sent with
Don’t fragment (df) bit set . You don’t need to add any command line switches for that.
Here is what you get by default ping in Linux:
Defaults:
Don’t fragment bit (in echo request) – set
Ip packet size – 84 bytes
Sending interval – 1 second

Some examples.
- sending pings station:
[root@lonestar ~]# ping 191.91.21.41
- receiving station:
[root@darkstar ~]# tcpdump -s 1500 -n -vv icmp
21:23:51.598641 IP (tos 0×0, ttl 61, id 20, offset 0, flags [DF], proto: ICMP (1), length: 84) 112.225.125.100 > 10.99.99.150: ICMP echo request, id 5392, seq 20, length 64
21:23:51.598817 IP (tos 0×0, ttl 64, id 7135, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.150 > 112.225.125.100: ICMP echo reply, id 5392, seq 20, length 64
To change sent packet size:
-s , bytes (8 bytes of ICMP header will be added automatically).

Sending host:
[root@darkstar ~]# ping 10.99.99.158 -s 1300
PING 10.99.99.158 (10.99.99.158) 1300(1328) bytes of data.
1308 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=1.65 ms

Receiving host:
freeBSD# tcpdump -n -v -s 1500 icmp
16:15:11.901787 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 44399, seq 63, length 1308
To change sending interval (mostly used together with large packet size) :
-i

Sending host:
[root@darkstar ~]# ping -s 1300 -i 0.2 10.99.99.158

Receiving host:
freeBSD# tcpdump -n -v -s 1500 icmp
16:20:11.223481 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 1136, seq 396, length 1308
16:20:11.223496 IP (tos 0×0, ttl 64, id 805, offset 0, flags [DF], proto ICMP (1), length 1328) 10.99.99.158 > 10.99.99.150: ICMP echo reply, id 1136, seq 396, length 1308

To force Linux to send pings with DF bit cleared (i.e. not set):
ping –M don’t

Sending host:

[root@darkstar ~]# ping -s 1300 -M dont 10.99.99.158
PING 10.99.99.158 (10.99.99.158) 1300(1328) bytes of data.
1308 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.560 ms

Receiving host:

freeBSD# tcpdump -n -v -s 1500 icmp
16:28:33.111903 IP (tos 0×0, ttl 64, id 41857, offset 0, flags [none], proto ICMP (1), length 1328) 10.99.99.150 > 10.99.99.158: ICMP echo request, id 33136, seq 6, length 1308
16:28:33.111920 IP (tos 0×0, ttl 64, id 9425, offset 0, flags [none], proto ICMP (1), length 1328) 10.99.99.158 > 10.99.99.150: ICMP echo reply, id 33136, seq 6, length 1308

SideNote: FreeBSD ping has a nice add-on (see below) – sweeping size of the packets, while Linux doesn’t have such extra feature,
Below is script to emulate it on Linux:
awk ‘ BEGIN {for (size=100;size<1470;size++) {
cmd = (”ping –c 3 –I 0.5 –s ” size “ “ “10.99.99.158″)
print cmd | “/bin/bash”
close(”/bin/bash”) } } ‘

Here:
size – size of data in ICMP packet (bytes);
-I 0.5 – interval of 5 seconds (optional);
-c 3 – number of pings in each size session (NOT optional – or you will enter an endless loop which even Ctrl-C won’t be able
to stop )

See it in action:
[root@darkstar ~]# awk ‘ BEGIN {for (size=100;size<1470;size++) {
cmd = (”ping -c 3 -i 0.5 -s ” size “ “ “10.99.99.158″)
print cmd | “/bin/bash”
close(”/bin/bash”) } } ‘
PING 10.99.99.158 (10.99.99.158) 100(128) bytes of data.
108 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=1.75 ms
108 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.276 ms
108 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.201 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.201/0.742/1.750/0.713 ms
PING 10.99.99.158 (10.99.99.158) 101(129) bytes of data.
109 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.185 ms
109 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.253 ms
109 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.230 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.185/0.222/0.253/0.033 ms
PING 10.99.99.158 (10.99.99.158) 102(130) bytes of data.
110 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.118 ms
110 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.201 ms
110 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.343 ms

— 10.99.99.158 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.118/0.220/0.343/0.094 ms
PING 10.99.99.158 (10.99.99.158) 103(131) bytes of data.
111 bytes from 10.99.99.158: icmp_seq=1 ttl=64 time=0.565 ms
111 bytes from 10.99.99.158: icmp_seq=2 ttl=64 time=0.182 ms
111 bytes from 10.99.99.158: icmp_seq=3 ttl=64 time=0.329 ms
FreeBSD

Defaults:
Don’t fragment bit – not set ; use –D option to set
IP Packet size: 84 bytes ; use –s option to change
Sending interval: 1 sec ; use –I to change
e.g. Sending pings of data size 1300 bytes with interval 0.2 seconds with df bit set:

Sending host[10.99.99.158]:
freeBSD# ping -D -s 1300 -i 0.2 10.99.99.150

Receiving host[10.99.99.150]:
[root@darkstar ~]# tcpdump -n -v -s 1500 host 10.99.99.158
20:42:57.816697 IP (tos 0×0, ttl 64, id 11630, offset 0, flags [DF], proto: ICMP (1), length: 1328) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 10770, seq 23, length 1308
20:42:57.816914 IP (tos 0×0, ttl 64, id 33327, offset 0, flags [none], proto: ICMP (1), length: 1328) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 10770, seq 23, length 1308

SideNote: *BSD family has a nice additional option not found in most other systems – you can order ping to sweep size of sent packets .
Example follows:

Here sweep range is from 20 bytes up to 1400 bytes, increase step is 300 bytes.

Sending host[10.99.99.158]:
freeBSD# ping -D -g 20 -G 1400 -h 300 10.99.99.150
PING 10.99.99.150 (10.99.99.150): (20 … 1400) data bytes
28 bytes from 10.99.99.150: icmp_seq=0 ttl=64 time=1.313 ms
328 bytes from 10.99.99.150: icmp_seq=1 ttl=64 time=0.531 ms
628 bytes from 10.99.99.150: icmp_seq=2 ttl=64 time=0.581 ms
928 bytes from 10.99.99.150: icmp_seq=3 ttl=64 time=0.362 ms
1228 bytes from 10.99.99.150: icmp_seq=4 ttl=64 time=0.223 ms

— 10.99.99.150 ping statistics —
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.223/0.602/1.313/0.377 ms
Receiving host[10.99.99.150]:
[root@darkstar ~]# tcpdump -n -v -s 1500 host 10.99.99.158
21:50:06.942165 IP (tos 0×0, ttl 10.99.99.150 64, id 12828, offset 0, flags [DF], proto: ICMP (1), length: 48) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 0, length 28
21:50:06.944098 IP (tos 0×0, ttl 64, id 43255, offset 0, flags [none], proto: ICMP (1), length: 48) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 0, length 28
21:50:07.944761 IP (tos 0×0, ttl 64, id 12831, offset 0, flags [DF], proto: ICMP (1), length: 348) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 1, length 328
21:50:07.944826 IP (tos 0×0, ttl 64, id 43256, offset 0, flags [none], proto: ICMP (1), length: 348) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 1, length 328
21:50:08.945815 IP (tos 0×0, ttl 64, id 12833, offset 0, flags [DF], proto: ICMP (1), length: 648) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 2, length 628
21:50:08.945890 IP (tos 0×0, ttl 64, id 43257, offset 0, flags [none], proto: ICMP (1), length: 648) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 2, length 628
21:50:09.946724 IP (tos 0×0, ttl 64, id 12835, offset 0, flags [DF], proto: ICMP (1), length: 948) 10.99.99.158 > 10.99.99.150: ICMP echo request, id 50962, seq 3, length 928
21:50:09.946819 IP (tos 0×0, ttl 64, id 43258, offset 0, flags [none], proto: ICMP (1), length: 948) 10.99.99.150 > 10.99.99.158: ICMP echo reply, id 50962, seq 3, length 928

SOLARIS
Defaults:
Don’t fragment bit - not set , and not changeable , yes , it sounds strange but Solaris doesn’t
support df bit in its ping utility. You may set df bit in their traceroute program , but it has no provision for changing size of the packet and therefore is of no value for our case.

Non-verbose ; use –s to override
IP packet size: 84 bytes

Pinging with defaults:
root@solaris:~# ping -s 10.99.99.150
PING 10.99.99.150: 56 data bytes
64 bytes from 10.99.99.150: icmp_seq=0. time=0.759 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v -s 1500 host 10.99.99.159
20:50:08.084364 IP (tos 0×0, ttl 255, id 8020, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.159 > 10.99.99.150: ICMP echo request, id 9096, seq 7, length 64
20:50:08.084538 IP (tos 0×0, ttl 64, id 52389, offset 0, flags [none], proto: ICMP (1), length: 84) 10.99.99.150 > 10.99.99.159: ICMP echo reply, id 9096, seq 7, length 64

To change size of sent packet, to say 1300 bytes of data:

root@solaris:~# ping -s 10.99.99.150 1320
PING 10.99.99.150: 1320 data bytes
1328 bytes from 10.99.99.150: icmp_seq=0. time=1.610 ms
1328 bytes from 10.99.99.150: icmp_seq=1. time=0.335 ms
SideNote: There is no size sweeping capability built-in , so I wrote this script to emulate this feature in Solaris as well:
root@solaris:~# awk ‘ BEGIN {for (size=100;size<1470;size=size+10) {
cmd = (”ping -s “ “10.99.99.158 ” size ” 3″)
print cmd | “/bin/bash”
close(”/bin/bash”) } } ‘

Here :
size - size of date in ICMP packet , starts at 10 bytes ends at 170 bytes
size+10 – size incrementing by 10 bytes each series of pings
3 - number of pings in each size set.

Results:
root@solaris:~# awk ‘ BEGIN {for (size=100;size<1470;size=size+10) {
cmd = (”ping -s “ “10.99.99.158 ” size ” 3″)
print cmd | “/bin/bash”
close(”/bin/bash”) } } ‘
PING 10.99.99.158: 100 data bytes
108 bytes from 10.99.99.158: icmp_seq=0. time=0.319 ms
108 bytes from 10.99.99.158: icmp_seq=1. time=0.460 ms
108 bytes from 10.99.99.158: icmp_seq=2. time=0.328 ms

—-10.99.99.158 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 0.319/0.369/0.460/0.079
PING 10.99.99.158: 110 data bytes
118 bytes from 10.99.99.158: icmp_seq=0. time=0.371 ms
118 bytes from 10.99.99.158: icmp_seq=1. time=0.370 ms
118 bytes from 10.99.99.158: icmp_seq=2. time=0.477 ms

—-10.99.99.158 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip (ms) min/avg/max/stddev = 0.370/0.406/0.477/0.061
PING 10.99.99.158: 120 data bytes
128 bytes from 10.99.99.158: icmp_seq=0. time=0.395 ms
128 bytes from 10.99.99.158: icmp_seq=1. time=0.361 ms
128 bytes from 10.99.99.158: icmp_seq=2. time=0.264 ms

CISCO routers (IOS)

Defaults:
IP packet size : 100 bytes ; use size to change
Don’t fragment bit – not set ; use df-bit to set

Running with defaults:
Tokyo#ping 191.91.21.41
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v -s 1500 icmp
22:16:53.758056 IP (tos 0×0, ttl 253, id 11, offset 0, flags [none], proto: ICMP (1), length: 100) 174.93.31.134 > 10.99.99.150: ICMP echo request, id 4, seq 0, length 80
22:16:53.758246 IP (tos 0×0, ttl 64, id 10923, offset 0, flags [none], proto: ICMP (1), length: 100) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 4, seq 0, length 80
< — Cut for brevity –>
Setting df bit and size of the packet size (Note – here when you set size of the ping you set IP packet size and not ICMP data size as in *Nix systems).
Repeat count is set to 3 .
Tokyo#ping 191.91.21.41 size 1300 df-bit rep 3
Type escape sequence to abort.
Sending 3, 1300-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
Packet sent with the DF bit set
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 4/4/4 ms

Receiving host:
[root@darkstar ~]# tcpdump -n -v -s 1500 icmp
22:18:16.657849 IP (tos 0×0, ttl 253, id 21, offset 0, flags [DF], proto: ICMP (1), length: 1300) 174.93.31.134 > 10.99.99.150: ICMP echo request, id 6, seq 0, length 1280
22:18:16.658028 IP (tos 0×0, ttl 64, id 10933, offset 0, flags [none], proto: ICMP (1), length: 1300) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 6, seq 0, length 1280
Sweeping ping size.
This feature is available from extended ping menu:
Rio#ping
Protocol [ip]:
Target IP address: 191.91.21.41
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]:
Sweep max size [18024]: 1700
Sweep interval [1]: 100
Type escape sequence to abort.
Sending 85, [36..1700]-byte ICMP Echos to 191.91.21.41, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!
Receiving host:
10:35:22.563851 IP (tos 0×0, ttl 253, id 179, offset 0, flags [DF], proto: ICMP (1), length: 36) 174.93.31.134 > 10.99.99.150: ICMP echo request, id 9, seq 0, length 16
10:35:22.563891 IP (tos 0×0, ttl 64, id 46861, offset 0, flags [none], proto: ICMP (1), length: 36) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 9, seq 0, length 16
10:35:22.566205 IP (tos 0×0, ttl 253, id 180, offset 0, flags [DF], proto: ICMP (1), length: 136) 174.93.31.134 > 10.99.99.150: ICMP echo request, id 9, seq 1, length 116
10:35:22.566223 IP (tos 0×0, ttl 64, id 46862, offset 0, flags [none], proto: ICMP (1), length: 136) 10.99.99.150 > 174.93.31.134 : ICMP echo reply, id 9, seq 1, length 116

Juniper routers (JunOS):
Defaults:
Ip packet size : 84 bytes
Don’t fragment bit – not set; use do-not-fragment to set
Interval – 1 sec; use interval to change
Sending pings with df bit set and size 1470 bytes
root@Juniper> ping 192.168.37.29 do-not-fragment size 1470
ping 192.168.37.29 do-not-fragment size 1470
PING 192.168.37.29 (192.168.37.29): 1470 data bytes
1478 bytes from 192.168.37.29: icmp_seq=0 ttl=64 time=1.434 ms
1478 bytes from 192.168.37.29: icmp_seq=1 ttl=64 time=0.210 ms

— 192.168.37.29 ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.203/0.513/1.434/0.532 ms

IF packet size too large and df is set you get this:

root@Juniper> ping 192.168.37.29 do-not-fragment size 13000
ping 192.168.37.29 do-not-fragment size 13000
PING 192.168.37.29 (192.168.37.29): 13000 data bytes
ping: sendto: Message too long

Clear ARP table in Checkpoint

Yuri — Sat, 25 Oct 2008 10:36:25 +0000

Yesterday my colleague asked how to clear all entries in the ARP table of the
NGX in question (Splat). I thought the arp command of the Linux would include some switch for that case too – but it didn’t. To delete ARP entry from the ARP cache you use #arp -d , and it has no provision for deleting multiple entries in one go. So here is the one-liner
that does just that – clears all entries in ARP cache. I found it in Google and
slightly rearranged for brevity (note- it is one line of text) :

for ip in $(awk '/([[:digit:]]\.)+/ {print $1}' /proc/net/arp) ; do arp -d $ip ; done

Autologin Expect scripts for telnet/ssh

Yuri — Sun, 21 Sep 2008 17:28:02 +0000

Tired of typing over and over your username/password when using
telnet/ssh ? Here are Expect http://expect.nist.gov/ scripts to autologin by Telnet and ssh
Notes:
- Yes, it is not secure to keep you username/password saved somewhere, so know
what you do . In my opinion as long as this
is a dedicated for remote logins server, that has no access from outside, and hardened accordingly
(pertinent to the scripts – only owner/root can read user’s home folder, etc.,) the risk is acceptable.

Note 2: password is saved in a file named “sword”

cat tel
#!/usr/local/bin/expect Change to the location of your Expect package

proc Usage {} {
puts “\n tel \n”
return
}

set argnumber [llength $argv]

if {$argnumber==0} {
      puts “You need to specify at least one piece of equipment to log into\n”
      Usage
      exit

   } elseif {$argnumber>1} {
       puts “You specified too many arguments, only one please\n”

      Usage
       exit
                  }

set hostName [lindex $argv 0]

puts “Entering $hostName”
set username “myusername”
set HANDL [open "sword"]
set password [gets $HANDL]
close $HANDL
spawn telnet $hostName
expect {[Uu]sername*} {
send “$username\r”
}

expect {[Pp]assword:} {
send “$password\r”
}

#Cisco specific block – to enter enable level, you may remove this block if not needed
expect {*#} {
send “enable\r” }

expect {[Pp]assword:} {
send “$password\r”
}
#End of Cisco specific block

interact

Now SSH login script
> cat essh
#!/usr/local/bin/expect Change to the location of your Expect package

proc Usage {} {
puts “\n essh \n”
return
}

set argnumber [llength $argv]

if {$argnumber==0} {
      puts “You need to specify at least one piece of equipment to log into\n”
      Usage
      exit

   } elseif {$argnumber>1} {
       puts “You specified too many arguments, only one please\n”

      Usage
       exit
                  }

set hostName [lindex $argv 0]

puts “Entering $hostName”
set username “myusername”
set HANDL [open "sword"]
set password [gets $HANDL]
spawn ssh $hostName

expect {[Pp]assword:} {
send “$password\r”
}

#Again goes Cisco – specific block , remove if not needed
expect {*#} {
send “enable\r” }

expect {[Pp]assword:} {
send “$password\r”
}
#End of Cisco – specific block

interact