Security World: firewall-wizards Digest, Vol 44, Issue 2

Send firewall-wizards mailing list submissions to
firewall-wizards@listserv.icsalabs.com

To subscribe or unsubscribe via the World Wide Web, visit
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards
or, via email, send a message with subject or body 'help' to
firewall-wizards-request@listserv.icsalabs.com

You can reach the person managing the list at
firewall-wizards-owner@listserv.icsalabs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of firewall-wizards digest..."

Today's Topics:

1. Related established connections, and hosts that utilize TCP
syn cookies (FW WIZ)
2. Analyzing a Cisco firewalls connection table (Tim Eberhard)
3. Re: Analyzing a Cisco firewalls connection table
(Paul D. Robertson)

----------------------------------------------------------------------

Message: 1
Date: Fri, 11 Dec 2009 10:14:18 -0800
From: FW WIZ <netfilterwiz@gmail.com>
Subject: [fw-wiz] Related established connections, and hosts that
utilize TCP syn cookies
To: firewall-wizards@listserv.icsalabs.com
Message-ID:
<47ec7ea40912111014k157a8637u584c95a89c89474b@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"

My question is about tracking related, established connections, and how they
relate to client-server connections when the server utilizes TCP SYN cookies

When a remote server is utilizing TCP syncookies in its stack and a client
makes the initial TCP connection, supplies the working secret function, and
receives the rebuilt SYN, where does the connection originate from? Does
this connection originate from the server that replied to the initial
connection request, or from the host that sent the initial TCP SYN?

How is this interpreted by Netfilter when allowing, all outbound traffic by
default and when filtering outbound traffic by default but allowing ingress
and egress related established connections.

Is this treated as a related or an established connection? Will the packet
be allowed to traverse the filter if the server is attempting to establish
the connection with the originating workstation?

If the connection is seen as having originated from the server, will
Netfilter determine that the connection did not originate from a trusted
interface, address, port, etc, and filter it?

Would it be better to create a rule with iptables to track the connection,
perform criteria checking, and match the outbound packet with the incoming
rebuilt connection from the server when it replies?

The results that I?m finding suggests that the connection is considered to
have originated from the workstation that sent the original TCP SYN, making
most of my other questions not applicable, but I wanted to get insight from
others here.

What are your thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.icsalabs.com/pipermail/firewall-wizards/attachments/20091211/1662ea88/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 10 Dec 2009 18:50:39 -0600
From: Tim Eberhard <xmin0s@gmail.com>
Subject: [fw-wiz] Analyzing a Cisco firewalls connection table
To: Firewall Wizards Security Mailing List
<firewall-wizards@listserv.icsalabs.com>
Message-ID:
<2c52b84e0912101650p261e43c8oe128dad86620d743@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

All,

After searching around for something to do this for me I ended up coming up
short (I found one proof of concept that was old and I couldn't get to work)
so I ended up writing one on my own.

Several years ago I did the same for Netscreen firewalls and I wrote a
program called NSSA - Netscreen Session Analyzer. It's been used by people
all over the world and people seem to get a lot of use out of it.

Given the success I had releasing NSSA I am also going to go ahead and
release CCA - Cisco Connection Analyzer. This is a *very* beta release that
I've honestly only tested on a single 5540 ASA running 7.2 code. Other
hardware (Pix, FWSM..etc) and other versions of software MAY not work.. but
I would love to hear if it doesn't so I can get it working.

I encourage you Cisco guys to check it out. There are some useful reports
you can generate and better help you understand whats going through the
firewall real time. We often use this to troubleshoot abnormal connection
levels or high CPU.

It is in .exe format and is completely virus free. It requires no internet
connection. Please give it a try and give me some feedback good/bad/ugly.
You can download a copy here: performanceclassifieds.net/CCA.rar

Thanks all,
-Tim Eberhard

Here is an example of the output:

Top 10 Source IP addresses:
Number of Connections - IP Address
4 - 192.141.224.77 (21.05 Percent)
1 - 192.236.83.33 (5.26 Percent)
1 - 192.234.184.23 (5.26 Percent)
1 - 192.231.21.53 (5.26 Percent)
1 - 192.230.242.122 (5.26 Percent)
1 - 192.216.159.103 (5.26 Percent)
1 - 192.211.159.77 (5.26 Percent)
1 - 192.196.151.143 (5.26 Percent)
1 - 192.174.95.192 (5.26 Percent)
1 - 192.151.229.169 (5.26 Percent)

Top 10 Destination IP addresses:
Number of Connections - IP Address
5 - 90.80.240.218 (26.32 Percent)
5 - 90.80.225.61 (26.32 Percent)
2 - 90.80.246.64 (10.53 Percent)
2 - 90.80.240.217 (10.53 Percent)
1 - 90.80.246.96 (5.26 Percent)
1 - 90.80.246.35 (5.26 Percent)
1 - 90.80.246.155 (5.26 Percent)
1 - 90.80.246.125 (5.26 Percent)
1 - 90.80.225.39 (5.26 Percent)

Top 10 Source Ports::
Number of Connections - Port - Possible Service
6 - 8502 (Not listed) (31.58 Percent)
1 - 50001 (Not listed) (5.26 Percent)
1 - 3085 (pcihreq PCIHReq) (5.26 Percent)
1 - 3084 (itm-mccs ITM-MCCS) (5.26 Percent)
1 - 3080 (stm_pproc stm_pproc) (5.26 Percent)
1 - 3062 (ncacn-ip-tcp ncacn-ip-tcp) (5.26 Percent)
1 - 25821 (Not listed) (5.26 Percent)
1 - 20595 (Not listed) (5.26 Percent)
1 - 1188 (hp-webadmin HP Web Admin) (5.26 Percent)
1 - 1069 (cognex-insight COGNEX-INSIGHT) (5.26 Percent)

Top 10 Destination Ports:
Number of Connections - Port - Possible Service
7 - 80 (World Wide Web HTTP) (36.84 Percent)
5 - 4035 (wap-push-http WAP Push OTA-HTTP port) (26.32 Percent)
2 - 49252 (Not listed) (10.53 Percent)
1 - 50000 (Not listed) (5.26 Percent)
1 - 49259 (Not listed) (5.26 Percent)
1 - 49258 (Not listed) (5.26 Percent)
1 - 49254 (Not listed) (5.26 Percent)
1 - 49253 (Not listed) (5.26 Percent)

Top 10 Protocols Used:
Number of Connections - Protocols
12 - TCP (63.16 Percent)
7 - UDP (36.84 Percent)

Top 10 TCP Flag State:
Number of connections - TCP Flag
12 - (Up) U (28.57 Percent)
12 - ( initial SYN from outside ) B (28.57 Percent)
5 - ( Outbound Data ) O (11.9 Percent)
5 - ( inbound data ) I (11.9 Percent)
4 - ( inside FIN ) f (9.52 Percent)
2 - ( outside FIN ) F (4.76 Percent)
1 - ( inside acknowledged FIN ) r (2.38 Percent)
1 - ( outside acknowledged FIN ) R (2.38 Percent)

7 - UB
7 - -
1 - UfrIOB
1 - UfIOB
1 - UfFRIOB
1 - UfFIOB
1 - UIOB

Top 10 Talkers by total bandwidth:

Source IP: 192.234.184.23 -- Destination IP: 90.80.240.218
Bytes Transfered: 113952 Uptime: 20m19s -Bytes/sec: 93.48

Source IP: 11.181.137.65 -- Destination IP: 90.80.246.125
Bytes Transfered: 38609 Uptime: 10m19s -Bytes/sec: 62.37

Source IP: 192.148.19.11 -- Destination IP: 90.80.246.64
Bytes Transfered: 10994 Uptime: 46s -Bytes/sec: 239.0

Source IP: 192.141.224.77 -- Destination IP: 90.80.240.217
Bytes Transfered: 6925 Uptime: 14m18s -Bytes/sec: 8.07

Source IP: 11.44.153.246 -- Destination IP: 90.80.240.218
Bytes Transfered: 4590 Uptime: 1m5s -Bytes/sec: 70.62

Source IP: 192.151.229.169 -- Destination IP: 90.80.240.218
Bytes Transfered: 3707 Uptime: 19s -Bytes/sec: 195.11

Source IP: 192.174.95.192 -- Destination IP: 90.80.246.96
Bytes Transfered: 941 Uptime: 32s -Bytes/sec: 29.41

Source IP: 192.141.109.162 -- Destination IP: 90.80.246.35
Bytes Transfered: 941 Uptime: 1m0s -Bytes/sec: 15.68

Source IP: 192.236.83.33 -- Destination IP: 90.80.225.39
Bytes Transfered: 751 Uptime: 1m20s -Bytes/sec: 9.39

Source IP: 192.141.224.77 -- Destination IP: 90.80.225.61
Bytes Transfered: 595 Uptime: 2m44s -Bytes/sec: 3.63

Top 10 Talkers by bytes a second: