Technical Blog about IT Security and Networking

October 20, 2009

copy http flash – download from HTTP server to the Cisco router

Filed under: Uncategorized — yurisk @ 7:06 pm

 The feature to download anything (mostly used to download IOS images) from remote HTTP server to the cisco router has
been with us for years, yet there are few caveats to be aware of before using it.
The command itself is pretty simple:
Router# copy http[:full URI specification]  flash[: local path to save the file]

The facts you should know:

- router is first doing resolving of the domain name to the IP, then uses this IP as Host header in the  communication with
the remote HTTP server. This is important when you try to download something from the webserver already configured
for the Virtual hosts. Because then webserver looks at this header and searches for the matching local file according to
its internal logic.
For example if using Apache configured for named Virtual hosting you should put the file to be downloaded in
the default Virtual host, i.e. first virtual host in the Apache configuration file. Let’s look at the example.
Here we have  the partial Apache config file :
#The file we want to download is in /usr/local/apache2/htdocs/mrtg/test.bin

#Here comes the 1st VirtualHost entry
<VirtualHost *:80>
   ServerAdmin  admin@yurisk.net
   DocumentRoot “/usr/local/apache2/htdocs/mrtg”
# as this this the 1st Virtual Host entry server names below are irrelevant for our case
   ServerName mrtg.yurisk.info
   ServerAlias mrtg. yurisk.net
   ErrorLog “logs/mrtg.yurisk.info-error_log”
   CustomLog “logs/mrtg.yurisk.info-custom_log” common
<Directory />
   Options FollowSymLinks
   AllowOverride None
#Here I set up a basic authentication with local user/pass file, you may omit this
       AuthType  Basic
       AuthName  “By My Invitation only :) “
       AuthUserFile /usr/local/apache2/passwords
       Require valid-user
       Options None
#Uncomment below if not using the authentication
#    Order allow,deny
#    Allow from any

</Directory>

<VirtualHost *:80>
——-Cut here – many more virtual hosts ——

- while using TCP with built-in packet verification generally prevents damaged downloads , it is always a good idea to verify with md5
sum the downloaded file. The command:

#verify /md5 flash:<downloaded file name>
- This command also supports copying from HTTPs, but it would add unwanted SSL encrypt/decrypt overload
so I haven’t tested it , yet.

Now the real life example:

  Tair#copy http://qwerty:12345@ 214.90.51.41/test.bin flash
Destination filename [test.bin]?
Loading http:// qwerty:12345@ 214.90.51.41/test.bin
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
5120000 bytes copied in 17.924 secs (285651 bytes/sec)
Tair # verify /md5 flash:test.bin
…………………………………………………………………………………………………………………………………………………………………….

……………………………………………………………………………………………………………………………………………………………………..

……………………………………………………………………………………………………………………………………………………………………..

……………………………………………………………………………………………………………………………………………………………………..

……………………………………………………………………………………………………………………………………………………………………..

………………………………………………………………………………………………………………………………………………………………………

…………………………………………………………………………………………………………..Done!
verify /md5 (flash:test.bin) = e8c39d44aafc82b035dfc7ad16fc2183

September 18, 2009

SSH login alert by mail Linux or Unix based systems

Filed under: Linux — yurisk @ 10:24 am

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 <user home dir>/.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 <user home dir>/.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.

September 13, 2009

Reinstall Checkpoint UTM firewall, the hard way…

Filed under: Checkpoint NG/NGX, Firewall — yurisk @ 5:20 pm
Tags:

 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 Power (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.

September 8, 2009

eSafe has iptables too ….

Filed under: Esafe — yurisk @ 5:58 pm

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 /stc/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

September 1, 2009

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

Filed under: Linux, Networking — yurisk @ 8:42 am

 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  <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 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  <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 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  <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 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 <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 <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

June 20, 2009

Don’t rely on SmartViewTracker only – it may lie

Filed under: Checkpoint NG/NGX, Firewall — yurisk @ 2:11 pm
Tags: ,

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.

June 19, 2009

Failed to connect to Fortiguard servers

Filed under: Firewall, Fortigate — yurisk @ 1:44 pm
Tags:

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.

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”

June 12, 2009

Website/malware categorization in eSafe

Filed under: Esafe — yurisk @ 8:41 am
Tags:

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

June 10, 2009

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

Filed under: Firewall, Fortigate — yurisk @ 6:24 pm
Tags:

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

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 :

# 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 only 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 0×1106
PCI_Device_ID 0×3065
PCI_Subsystem_Vendor 0×3065
PCI_Subsystem_ID 0×1106
PCI_Revision_ID 0×74
PCI_Address 0:12.0
PCI_Bus_Type
Memory 0×0000f400
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(0×00001103)
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

May 28, 2009

Tracking the source of DOS attack with Cisco IOS

Filed under: Cisco, IOS Cisco — yurisk @ 11:23 am
Tags:

Problem: Enterprise is under Denial Of Service Attack that brings down key elements of the business or the whole network at all.
To track the attacker is the first step in handling the attack and unless the flood is coming from inside (most probably not in a well managed LAN) you will need help of your Service Provider to find out the origin. Unfortunately Service Provider’s (SP) backbone is not well suited for such forensics, as its business role is
to provide uninterrupted connectivity to ALL the clients , not only you, so SP will not enable ACLs/ip accounting/Netflow on their backbone to identify where the attack is coming from . And if source Ip of the attack is spoofed you can’t do much .

For such cases Cisco came with the nice feature called
ip source tracking that will gather flow statistics for specific destination
IPs (of victim) and periodically will export them for viewing, and will do all this without overloading the backbone router it is enabled on (Of course relevant if your SP is using Cisco gear) . Here are details:

– Enable it globally for the victim IP , here IP being attacked is 63.45.33.22

Edge(config)#ip source-track 63.45.33.22

- If you want (and if this is being done by SP they will not) you may create log entries:
Edge1(config)#ip source-track syslog-interval 2
Then you will see in logs (good for reminding to disable this afterwards) :
May 28 10:55:47.105: %DOS_TRACK-5-CFG: IP Source Tracker configured for 1 hosts

- Also you may define how often to export gathered info to be viewed (seems to depend on the platform ) :

Edge(config)#ip source-track export-interval 60

- And finally , you see the data accumulated so far :

Edge#sh ip source-track
Address SrcIF Bytes Pkts Bytes/s Pkts/s
63.45.33.22 Fa0/0 141G 485M 8244 141

Most important here will be the Source interface (in this router there is only 1 ingress interface , in real backbone you will have few feeds) where you see most of the incoming traffic for this destination IP. Then you (SP) would go to the upstream router connected to this local interface, enable the same source tracking and so on. Up to the last point in the backbone where the attacking traffic enters
the backbone of SP out of some upstream SP . Then SP would have option to contact the abuse of this upstream provider for them to investigate the issue further, or at least divert the attack to the black hole at the entry point, so end client would not be affected at all.

Next Page »

Blog at WordPress.com.