Category Archives: packet-sniffing

How to test CAS’ SAML using soapUI

Posted on by

Overview
Recent versions (I believe 3.2 or older) of Central Authentication System (a.k.a. CAS) include Security Assertion Markup Language (a.k.a. SAML) support, out of the box. The beauty if it is that it is already “there” accessible through the URL ‘/cas/samlValidate’ instead of the usual ‘/cas/serviceValidate’.

One thing to be noted is that it is not so easy to communicate with your CAS instance using SAML protocol since the requests need to be HTTP POST (which put browsers out of the picture) using a properly formed SAML payload.

Here is when soapUI comes in, which is an excellent tool for web services testing using SOAP requests (there should not be any problem/limitation by using the open source version of the tool) since it can be used to complete the SAML communication and see what the CAS server is actually returning back.

Steps
So, in order to complete that, you would need to connect to your CAS server, login by providing valid credentials and then get a CAS ticket. This can be done by opening the following URL on a browser:

https://CAS_DOMAIN:PORT/cas/login?service=http://localhost/foo



The browser should be now displaying an error because it should have been redirected back to the URL http://localhost/foo which probably does not exist. No problem. What is important though is that you would be able to retrieve the ticket from the URL. Example:


# URL
http://localhost/foo?ticket=ST-3-j6RIZfeaNTxilsFYr3xe-cas

# TICKET
ST-3-j6RIZfeaNTxilsFYr3xe-cas



Now using SoapUI you need to send CAS a proper SAML request. You may do that using the “submit a request to a specified end point” action. The URL where to send the request should be:


https://CAS_DOMAIN:PORT/cas/samlValidate? ->
     TARGET=http://localhost/foo&ticket=ST-3-j6RIZfeaNTxilsFYr3xe-cas



the request body should be:



								ST-3-j6RIZfeaNTxilsFYr3xe-cas




CAS’ response should be similar to this:



                  http://localhost/foo

                  juan.huerta

                     urn:oasis:names:tc:SAML:1.0:cm:artifact




The returned username can be found in the ‘NameIdentifier’ tag.


See Also



Note.- special thanks to Juan Huerta, Julien Gribonvald and Marvin Addison for their tips which inspired me to write this post.

How to define shorewall rules to allow VRRP traffic

Posted on by

It is essential for routers that implement the Virtual Router Redundancy Protocol to be able to communicate with each other.

As the protocol defines, the master router needs to send multicast packets to the whole subnet and of course, the rest of the backup routers need to receive this announcements otherwise they will think that the master router is dead and will initiate an election of a master router.

If no router is able to receive this “multicasted” announcements they all will eventually think that they are the only ones alive and thus become master. All of them master. That brings networking issues.

This page covers how to define the rule(s) under shorewall firewall in order to allow this VRRP announcements pass-through.

Rule definition

VRRP’s announcement multicast packets have the following characteristics:

  1. They are sent to the following multicast IP address: 224.0.0.18
  2. They use the protocol vrrp
  3. They source IP address is a virtual router

Thus, a rule that allows all the incoming VRRP traffic would look like this:

ACCEPT  net fw:224.0.0.18 vrrp

A rule that allows VRRP packets from a specific router would look like this:

ACCEPT  net:OTHER_VIRTUAL_ROUTER_IP fw:224.0.0.18 vrrp

Example

Let’s imagine we have two routers implementing VRRP (using keepalived, for example). Their IPs are: 10.20.30.40 and 10.20.30.41. Their shorewall rules should include the following:

on 10.20.30.40:

ACCEPT  net:10.20.30.41 fw:224.0.0.18 vrrp

on 10.20.30.41:

ACCEPT  net:10.20.30.40 fw:224.0.0.18 vrrp

References

Opening Large Capture Files with WireShark (aka Ethereal)

Posted on by

Sometimes it might be needed to open ”’big”’ network traffic capture files (a.k.a. .cap) . This challenge is commonly encountered since this sort of logging it is usually very verbose. Leaving a packet sniffer (such as tcpdump) overnight logging all the packets that go through a network interface card might generate several gigs of data.

WireShark (formerly known as Ethereal) is an excellent open source packet sniffer with a nice user interface (GUI) and available for many different platforms.

According to WireShark’s documentation:

Wireshark uses memory to store packet meta data (e.g. conversation and fragmentation related data) and to display this info on the screen.

How much memory actually used is depending on:

  • the number of packets captured (well, depending on the capture duration and the network load on the line)
  • the kind of packets captured (small/large packets, some packet types will lead to much more memory usage than others)
  • the preference settings, e.g. the “TCP desegmentation” setting

In my experience (and with the capture files and Preference settings I’m usually working with), I need about ten times of memory than the actual capture file size. But again, this will largely depend on the things noted above.

Fortunately, WireShark includes a easy-to-use tool to manipulate capture files: editcap.

Editcap is able to do things like processing a huge capture file and extract the packet information that correspond to a certain period of time. This functionality is perfect if, let’s say, you have a 24 hours capture file and you know that problems were reported at a certain time. You could then extract a bunch of packets around that time, export this into a new file and open it using WireShark.

Editcap Usage

Usage: editcap [options] ...   [ [-] ... ]

A single packet or a range of packets can be selected.

Packet selection:
  -r                     keep the selected packets, default is to delete them
  -A         don't output packets whose timestamp is before the
                         given time (format as YYYY-MM-DD hh:mm:ss)
  -B          don't output packets whose timestamp is after the
                         given time (format as YYYY-MM-DD hh:mm:ss)
  -d                     remove duplicate packets

Packet manipulation:
  -s            truncate each packet to max.  bytes of data
  -C            chop each packet at the end by  bytes
  -t    adjust the timestamp of each packet,
                          is in relative seconds (e.g. -0.5)
  -E  set the probability (between 0.0 and 1.0 incl.)
                         that a particular packet byte will be randomly changed

Output File(s):
  -c   split the packet output to different files,
                         with a maximum of  each
  -F       set the output file type, default is libpcap
                         an empty "-F" option will list the file types
  -T         set the output file encapsulation type,
                         default is the same as the input file
                         an empty "-T" option will list the encapsulation types

Miscellaneous:
  -h                     display this help and exit
  -v                     verbose output

Editcap Example
This example extracts all the packet information corresponding to 4th July 2008, 6am to 7am and writes it into a new file, i.e.:

  • Source file: 2008-07-04_capture.cap (813 MB)
  • Destination file: 6to7.cap (48.5 MB)
editcap -A "2008-07-04 06:00:00" -B "2008-07-04 07:00:00" 2008-07-03_capture.cap 6to7.cap