yurisk.info

Yuri Slobodyanyuk's blog on IT Security and Networking sharing experience and expertise

Page 21 of 24

Reinstall Checkpoint UTM firewall, the hard way…

September 13, 2009 / /

 Sometimes machines fail , in the end all machines fail some day anyway. When it happens to the firewall (Checkpoint ) it might be a very
frustrating event . By failing I mean machine turns on but doesn’t boot or boots into unusable state. The first thought that comes to
the sysadmin looking at such a miserable piece of expensive metal – format/fdisk/Factory Defaults/anything !!!???
If you have Checkpoint Open Server (i.e. Checkpoint VPN-1 software installed on 3rd party server) then most probably you have CD/DVD-drive in it and what  left is to find installation CD  of the Checkpoint – 30 minutes, some basic rules and your network partially but starts to work.
But if you have a Checkpoint UTM  appliance you have a problem. A big one. There is no magic button to restore to factory defaults nor CD/DVD drive to start formatting/reinstalling the firewall immediately.  Not that Checkpoint didn’t think about that situation, just reinstalling/reimaging  procedure is a bit involved.
I won’t say new things here as all is neatly documented in SecureKnowledgebase of checkpoint.com (sk37231) . But as I get questions about that more frequently than people bother to check at the Checkpoint website here is a short procedure:

– You download from checkpoint.com (with download speeds and image size patience is your friend) UTM image matching your UTM version ;
– You burn it to DVD disk (It is 1,5 Gigabyte in size) ;
– You connect USB DVD drive to USB port in UTM reboot from it and start install from scratch.

That is it.

PS If you happen to forget SSH password of the expert user you are also left with grim option to try to boot appliance from some bootable DVD and reset password, or just plain reinstall the whole firewall. So be very careful about SSH passwords for the UTM appliances.

eSafe has iptables too ….

September 8, 2009 / /

Did you know that eSafe  software is based on RedHat Enterprise  Linux (RHEL) ? Of course you did.
But what does it mean? It means that all (or almost all) tools/utilities/programming logic of the Linux is at your fingertips.
Let’s take for example software eSafe runs on the boot

 [root@esafe root]# chkconfig –list
rdisc                          0:off   1:off   2:off   3:off   4:off   5:off   6:off
anacron                   0:off   1:off   2:off   3:off   4:off   5:off   6:off
kudzu                        0:off   1:off   2:off   3:on    4:on    5:on    6:off
syslog                       0:off   1:off   2:on    3:on    4:on    5:on    6:off
network                   0:off   1:off   2:on    3:on    4:on    5:on    6:off
random                    0:off   1:off   2:on    3:on    4:on    5:on    6:off
saslauthd                 0:off   1:off   2:off   3:off   4:off   5:off   6:off
microcode_ctl      0:off   1:off   2:on    3:on    4:on    5:on    6:off
irqbalance              0:off   1:off   2:off   3:on    4:on    5:on    6:off
smartd                     0:off   1:off   2:off   3:off   4:off   5:off   6:off
atd                             0:off   1:off   2:off   3:on    4:on    5:on    6:off
log2trap                   0:off   1:off   2:off   3:off   4:off   5:off   6:off
sshd                          0:off   1:off   2:on    3:on    4:on    5:on    6:off
crond                       0:off   1:off   2:on    3:on    4:on    5:on    6:off
ntpd                         0:off   1:off   2:off   3:off   4:off   5:off   6:off
iptables                   0:off   1:off   2:on    3:on    4:on    5:on    6:off
webmin                   0:off   1:off   2:on    3:on    4:off   5:on    6:off
esafe                        0:off   1:off   2:off   3:on    4:on    5:on    6:off

Today I played with just one of them – iptables. First things first – eSafe is not a firewall . You don’t usually give
bunch of papers (called money) to use eSafe for the function that any Pentium 4 PC can do for the fraction of the price. So, it
is not supported and not to be used as the mainstream feature. Nevertheless it is here and may come handy in some situations.

In the output of chkconfig –list  chckconfig showed that whenever eSafe is on, iptables is on as well. The default iptables policy is ALLOW ANY ANY :
[root@esafe root]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Few observations:
– To block incoming connections destined for the eSafe itself you use INPUT chain, FORWARD chain has no meaning in bridged eSafe Gateway (in routing Gateway mode it  would be applicable I guess)
– I tried few basic rules on the eSafe Hellgate 200 while turning on High-Debug mode , and while machine was loaded by debug
mode , using iptables filtering did not add visible overhead to it.
In most of the deployment scenarios eSafe is installed between internal interface of the firewall and LAN. It means from outside it is protected quite well whereas from LAN it is wide open to any trouble coming in. eSafe has its own means of  limiting access to it from certain IPs.
To limit access to eConsole – you go in eConsole to Options -> Access and Permissions -> configure user (by default admin will be there)  and IP from which this user will be granted access.
To limit access to WebGUI (HTTPS) : in the WebGUI go to Settings -> Access Control ->  put IP to allow it access in “eSafe Appliance accepts connections from:”
To limit access by SSH use Linux means (there are few ways but I show just one of them) :
 vi /etc/ssh/sshd_config
# add at the end the following line to limit ssh access to 10.99.99.150 only:
AllowUsers   *@10.99.99.150
Or, using wildcards to the whole network only:
AllowUsers   *@10.*.*.*

All the above is correct and fine BUT – what if you need to temporarily limit access and not permanently ? All the above are permanent changes that will survive  reboot and  if you make a mistake you grant someone a visit to the appliance for  console connection. On the other hand you may use iptables to achieve the same access control and should something go wrong reboot will return all back to normal.

So, let’s go:

– I don’t like when debugging some complicated issue after logging off from eConsole I can’t access it again as someone from LAN already logged in :
1) Grant your IP the access to econsole:
[root@esafe root]# iptables -I INPUT    -p tcp -s 10.99.99.150 --dport 43969:43982 -j ACCEPT
2) Deny anyone else
[root@esafe root]# iptables -I INPUT 2 -p tcp --dport 43969:43982 -j DROP
– SSH in general isn’t something  a client should have access to :
1) First allow youself access:
 [root@esafe root]# iptables -I INPUT -p tcp --dport 22 -s 10.99.99.150  -j ACCEPT
2) Then deny anyone else:
[root@esafe root]# iptables -I  INPUT 2 -p tcp --dport 22   -j DROP

3) Restart ssh daemon (it won’t disconnect your current session):

[root@esafe root]# service sshd restart

[root@esafe root]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  —  10.99.99.150         anywhere           tcp dpt:ssh
DROP       tcp  —  anywhere             anywhere           tcp dpt:ssh

 
Those  addicted to iptables know that some spicy features come with modules and kernel options set at compile time.
To give you the taste of  what is included in eSafe iptables, the listing follows:

/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/arp_tables.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/arpt_mangle.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/arptable_filter.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_conntrack.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_conntrack_amanda.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_conntrack_irc.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_conntrack_tftp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_nat_amanda.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_nat_ftp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_nat_irc.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_nat_snmp_basic.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_nat_tftp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_queue.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ip_tables.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipchains.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipfwadm.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_DSCP.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_ECN.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_LOG.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_MARK.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_MASQUERADE.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_MIRROR.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_REDIRECT.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_REJECT.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_TCPMSS.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_TOS.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_ULOG.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_ah.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_conntrack.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_dscp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_ecn.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_esp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_helper.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_length.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_limit.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_mac.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_mark.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_multiport.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_owner.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_pkttype.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_recent.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_state.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_tcpmss.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_tos.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_ttl.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/ipt_unclean.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/iptable_filter.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/iptable_mangle.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv4/netfilter/iptable_nat.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/ah6.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/esp6.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/ip6_tunnel.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/ipcomp6.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/ipv6.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6_tables.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_LOG.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_MARK.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_ah.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_dst.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_esp.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_eui64.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_frag.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_hbh.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_hl.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_ipv6header.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_length.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_limit.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_mac.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_mark.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_multiport.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_owner.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6t_rt.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6table_filter.o
/lib/modules/2.4.21-47.ELsmp/kernel/net/ipv6/netfilter/ip6table_mangle.o

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

September 1, 2009 / /

Ping.
[showmyads]
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 0x0, 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 0x0, 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  <size> , 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 0x0, 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  <secs>

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 0x0, 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 0x0, 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 0x0, 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 0x0, 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  <secs> 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 <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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 0x0, 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 <secs> 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

Don’t rely on SmartViewTracker only – it may lie

June 20, 2009 / /

Funny case of WYSIWYG misleading the uninitiated. The case involved a seemingly normally functioning firewall Checkpoint which after a client created rule to allow FTP from any to his server in DMZ (no Nat involved) refused to allow connections though. The client being quite experienced himself entered SmartViewTracker did filter on the rule (here rule 77) and saw nothing (of course Log was enabled on the rule) . OK, he thought, he canceled the filter and also started looking on the clean up rule that said Any -> Any = Drop (log enabled) and … again saw no hits at all. And at this stage he approached us with
request to check Linkproof leading to this firewall as ” it doesnt pass traffic to my FTP server”.
I did a usual thing – ssh -> fw monitor on FTP server IP and , hurra, saw
me reaching FTP server IP but on input interface only – “Aha, dropped by a rule
for sure” , then it took me another minute to prove it (to me and to the client)
with this:

Here:
194.99.73.13 – FTP server in DMZ (IP sanitazed of course)
124.92.11.33 – my IP

[Expert@firewall2070]# fw ctl zdebug drop | grep 194.99.73.13
fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by fwhold_expires Reason: held chain expired
fw_log_drop: Packet proto=6 124.92.11.33:53408 -> 194.99.73.13:21 dropped by
fw_handle_first_packet Reason: Rulebase drop – rule 77

To remind – rule 77 was Any -> 194.99.73.13 (Service FTP) = Allow (log)

Why rule didn’t work is another question – but reason was messed up rulebase that cleint did, when further
down the rulebase was another rule to the same server partly overlapping this rule, the moment I disabled
second rule all started to work.

So conclusion – don’t rely on the SmartviewTracker only for debug , there can be too many
reasons why it is not logging/showing logs as should.

Failed to connect to Fortiguard servers

June 19, 2009 / / 6 Comments

Today encountered otherwise easy to diagnose misconfiguration only that Fortinet decided to ‘hide’ this parameter deep enough so that it got on my nerves until I fixed it.
[showmyads]

NOTE : Fortiguard is subscription based service when your Fortigate unit periodically
connects to the Fortinet servers (collectively named Fortiguard servers) to get info that enables advanced
feautures like filtering by category/rating.

Problem – suddenly Fortigate of the client refused to do web/spamfiltering service while having valid contract subscription. Not a big deal as in System -> Maintenance -> Fortiguard status was “Failed to connect ” (or something of a kind dont recall it now) . On the same page there is a nice button “Test Availability” pushing which would bring error “Connection failed Check firewall routing table” .
In most of the cases it is either reachability issue or Fortigate is trying to update against wrong server.
Doing pings successfuly from the firewall to service.fortiguard.net (FQDN to use for Fortiguard servers)
left 2nd option – wrong Fortiguard server hardcoded somewhere in the configs. Doing
FG100 # show system fortiguard Gave only this
config system fortiguard
set antispam-cache disable
set webfilter-cache disable
end

And only doing FG100 # get system fortiguard Gave the answer
hostname : 66.92.33.1
srv-ovrd : disable
port : 53
client-override-status: disable

To fix this you enter:
FG100 # config system fortiguard
FG100 (fortiguard) # set
*hostname hostname or IP of the FortiGuard server
FG100 (fortiguard) # set service.fortiguard.net
FG100 (fortiguard) #next

* FortiOS 3.x uses service.fortiguard.net , FortiOS 2.80 used guard.fortinet.net for Webfiltering and
antispam.fortigate.com for Antispam filtering and it is Fortinet recommendation to do so, nevertheless
setting guard.fortinet.net in Fortios 3 works as well (after all they are CNAME’d )

And while we are on it, here are few useful debug commands for the topic:

– To see real time list of servers to which the firewall tries to connect for Fortiguard service
FG200# diagnose debug rating
Locale : english
License : Contract
Expiration : Fri Jun 17 02:00:00 2010
Hostname : guard.fortinet.net

-=- Server List (Wed Jun 19 08:12:58 2009) -=-

IP Weight Round-time TZ Packets Curr Lost Total Lost
212.95.252.121 0 85 0 521863 0 113
212.95.252.120 0 89 0 4625 0 5
82.71.226.65 0 97 0 2140 0 34
62.209.40.73 10 105 1 2060 0 0
62.209.40.72 10 103 1 2060 0 0
66.117.56.37 50 158 -5 2060 0 0
69.20.236.180 50 191 -5 2060 0 0
69.20.236.179 50 185 -5 2060 0 0
66.117.56.42 50 164 -5 2061 0 1
72.52.72.243 80 245 -8 2063 0 3
116.58.208.39 80 371 -8 2081 0 21
208.91.112.194 80 233 -8 2075 0 12
216.156.209.26 80 239 -8 2068 0 7
121.111.236.179 90 354 9 2061 0 1
121.111.236.180 90 366 9 2064 0 4

– The same for Antispam service
FG200# diagnose spamfilter fortishield servers
Locale : english
License : Contract
Expiration :Fri Jun 17 02:00:00 2010
Hostname : guard.fortinet.net

-=- Server List (Wed Jun 19 08:13:39 2009) -=-

IP Weight Round-time TZ Packets Curr Lost Total Lost
212.95.252.121 0 94 0 2063 0 0
212.95.252.120 0 96 0 2061 0 0
82.71.226.65 0 104 0 2076 0 18
62.209.40.73 10 113 1 2061 0 0
62.209.40.72 10 111 1 2061 0 0
66.117.56.37 50 159 -5 2061 0 0
69.20.236.180 50 199 -5 2061 0 0
69.20.236.179 50 193 -5 2061 0 0
66.117.56.42 50 169 -5 2063 0 2
72.52.72.243 80 273 -8 2065 0 4
116.58.208.39 80 380 -8 2085 0 24
208.91.112.194 80 271 -8 2071 0 8
216.156.209.26 80 261 -8 2064 0 2
121.111.236.179 90 362 9 2061 0 0
121.111.236.180 90 370 9 2062 0 1

– To see on the console Webfiltering doing its work:
FG200# diagnose debug application urlfilter 1

FG200 # id=93000 pid=50 main-696 in main.c received pkt:count=197, a=/tmp/.thttp.socket/21
id=22009 received a request /tmp/.thttp.socket, addr_len=21: d=www.cnn.com:80, url=/a7Admin/SelectImage.aspx?end=document.f.largeimage.value&preview=document.getElementById(‘oImg2’)&w=319&h=215, id=913659, vfid=0, type=0, client=192.168.7.238
id=93000 msg=”found it in cache”
id=93003 user=”N/A” src=192.168.7.238 sport=4796 dst=157.166.224.25 dport=80 service=http cat=36 cat_desc=”News and Media” hostname=www.cnn.com url=/a7Admin/SelectImage.aspx?end=document.f.largeimage.value&preview=document.getElementById(‘oImg2’)&w=319&h=215 status=passthrough msg=”URL belongs to an allowed category in the policy”
id=93000 pid=50 main-696 in main.c received pkt:count=255, a=/tmp/.thttp.socket/21
id=22009 received a request /tmp/.thttp.socket, addr_len=21: d=b.mail.google.com:80, url=/mail/channel/bind?VER=6&it=460207&at=xn3j2v04hx65iz3ypmmyzptrbkimsf&RID=rpc&SID=57A1C77D6AAC35B0&CI=1&AID=347&TYPE=html&zx=8i5clc-olem8j&DOMAIN=mail.google.com&t=1, id=900542, vfid=0, type=0, client=192.168.7.56
id=93003 user=”N/A” src=192.168.7.56 sport=4280 dst=74.125.39.189 dport=80 service=http cat=23 cat_desc=”Web-based Email” hostname=b.mail.google.com url=/mail/channel/bind?VER=6&it=460207&at=xn3j2v04hx65iz3ypmmyzptrbkimsf&RID=rpc&SID=57A1C77D6AAC35B0&CI=1&AID=347&TYPE=html&zx=8i5clc-olem8j&DOMAIN=mail.google.com&t=1 status=passthrough msg=”URL belongs to an allowed category in the policy”

Website/malware categorization in eSafe

June 12, 2009 / / 1 Comment

If some website gets blocked by eSafe for being categorized wrongly you
may fix it actually very simple. You enter the link below and change the website category; this takes some time , usually from few hours up to a day,for the change to take effect. If website has no category already then update takes effect fast.

filterdb.iss.net/urlcheck/

To see what each category includes:
www-935.ibm.com/services/us/index.wss/detail/iss/a1029077?cntxt=a1027244

When you want to report an item that was falsely detected as virus/malware by
eSafe you should send your request to :

info

You can’t set duplex/speed settings of the Fortigate interfaces?

June 10, 2009 / /

You can’t set duplex/speed settings of the Fortigate interfaces.
Important FIX: depends on which interface you are trying to set! [ Thanks to Chen for pointing out ]
Upon careful reexamination turns out that you can’t set duplex/speed settings of 4-port switch interfaces only, i.e. Internal interface of Fortigate 60, 60M, 100A, 200A, and FortiWiFi-60 and also LAN interface of 500A .
Tried on FG100A FortiOS v4.0,build0178,090820 (MR1)
[showmyads]

FG100 (dmz2) # set speed
100full 100M full-duplex
100half 100M half-duplex
10full 10M full-duplex
10half 10M half-duplex
auto auto adjust speed

Working most of the time with Cisco gear I’m (and others) used to being able to set duplex/speed
parameters on the physical interfaces to my liking.
This comes as a necessity when connecting cisco to various equipment of differing quality. So it was a surprise to me when I encountered strange layer1/layer2 connectivity problem between some Fortigate 200A and cisco and tried to set manually duplex full/speed 100 on the Fortigate just to find out that it is impossible to do it on the Fortigate.
It was possible back in the days of FortiOS 2.80 (and early 3.0 – I guess up until MR5)  :

# conf sys int
(interface)# edit internal
(internal)# set speed

100full 100M full-duplex
100half 100M half-duplex
10full 10M full-duplex
10half 10M half-duplex

But then Fortinet dropped this option and the only (not direct) explanation
found on their site is this memo:
“Locked-down port policies (forcing speed, duplex, and link capabilities with auto-negotiation disabled) are
outdated. Legacy and historical reasons for forced setup with auto-negotiation disabled date
back many years when the technology was new…”

Now we can see what is the negotiated status of the links
(this command also shows errors/collisions/MTU on the interface) :

FG100 # diagnose hardware deviceinfo nic internal
Description VIA VT6102 Rhine-II
Part_Number N/A
Driver_Name via-rhine
Driver_Version 1.1.17
PCI_Vendor 0x1106
PCI_Device_ID 0x3065
PCI_Subsystem_Vendor 0x3065
PCI_Subsystem_ID 0x1106
PCI_Revision_ID 0x74
PCI_Address 0:12.0
PCI_Bus_Type
Memory 0x0000f400
IRQ 11
System_Device_Name internal
Current_HWaddr 00:09:0f:30:32:11 #In HA set up primary member would have different , virtual MAC address , for more see here FortiOS v3.0 HA Cluster virtual MAC addresses
Permanent_HWaddr 00:09:0f:30:32:11
Link up
Speed 100
Duplex forced full
FlowControl off
State up(0x00001103)
MTU_Size 1392
Rx_Packets 89944267
Tx_Packets 73437299
Rx_Bytes 370540924
Tx_Bytes 428118992
Rx_Errors 0
Tx_Errors 0
Rx_Dropped 0
Tx_Dropped 0
Multicast 8810
Collisions 0
Rx_Length_Errors 0
Rx_Over_Errors -0
Rx_CRC_Errors 0
Rx_Frame_Errors 0
Rx_FIFO_Errors 0
Rx_Missed_Errors 0
Tx_Aborted_Errors 0
Tx_Carrier_Errors 0
Tx_FIFO_Errors 0
Tx_Heartbeat_Errors 0
Tx_Window_Errors 0
Tx_Single_Collision_Frames 0
Tx_Multiple_Collision_Frames 0
Rx_Frame_Too_Longs 0
Rx_Symbol_Errors 0
Rx_Control_Unknown_Opcodes 0
Rx_Pause_Frames 0
Tx_Pause_Frames 0
Scatter_Gather OFF
poll_intr_switch 0
rx_tasklet_pkts 92505560
xmit queue 0
recv queue -64
phy_id= 1/1

« Older posts Newer posts »

© 2016 yurisk.info

Theme by Anders Noren — Up ↑