Monthly Archives: October 2007

Sguil 0.7-CVS client on Ubuntu Gutsy

Posted on by

Last week I installed Ubuntu Gutsy on my laptop. I did a clean install, which went fine. Of course, I needed the Sguil client on it as well. Gutsy has all the required libraries in it’s repositories. Install the following packages:

tcl8.4
tclx8.4
tcllib
tk8.4
iwidgets4

Checking out the Sguil client is easy (make sure you have ‘cvs’ installed):

cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil login
cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil co sguil

After this the client runs fine on my system.

Libnet 1.1 IPv6 fixes and additions

Posted on by

Libnet is a cool packet crafting tool, used by Snort to send TCP reset packets and ICMP unreachable packets as part of active responses. Libnet 1.1 supports IPv6 which is what I needed for my work. After some reading and testing there were a few problems. First, while possible to send TCP reset packets, the packets didn’t have a correct checksum and debugging this with valgrind showed lots of memory errors. Second, ICMPv6 was only partly implemented. The libnet_build_* functions for it are missing. This is, by the way, quite a common picture. Many libraries and projects have some support for IPv6, but generally incomplete and less well tested.

For my work on a IPv6 enabled Snort_inline I’ve only fixed the checksum issue and added a libnet_build_icmpv6_unreach() function. The patch against libnet 1.1.3-RC-01 can be found here. It’s development was funded by the great people of NitroSecurity Inc., who are funding my work to bring IPv6 to Snort_inline. The work is not based on Sourcefire‘s recent IPv6 implementation, so it will be interesting to see if and how those codebases can be used to improve each other. The changes to Snort_inline will be made available as well later, WhenItsDone(tm) 🙂 Like with the support for NFQueue, NitroSecurity gives back to the community, which I really appreciate!

The patch: http://www.inliniac.net/files/libnet-1.1.3-RC-01-ipv6.diff.gz

ModSecurity rules for Tikiwiki 1.x tiki-graph_formula.php Function Injection Vulnerability

Posted on by

A new vulnerability has been found in Tikiwiki. Read more about it here.

I’ve created the following ModSecurity rule to block it.

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:’TIKIWIKI tiki-graph_formula.php link inclusion attempt’,severity:2”
SecRule ARGS:/^s*[a-z]+$/ “^(ht|f)tps?://”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:’TIKIWIKI tiki-graph_formula.php f parameter Function Injection Vulnerability’,severity:2”
SecRule ARGS_NAMES “^s*f[.*]$”

Ivan, I hope these rules survive your scrutiny 😉

Updated at 13:50: The first rule only covered the file inclusion in the title parameter which was what I was seeing in my logs. These rules should cover both the inclusion and the injection.

Vuurmuur gets traffic shaping

Posted on by

The last weeks I’ve been working on adding traffic shaping support to Vuurmuur. The work is largely done, only the GUI part is still missing. But using vuurmuur_script it is already usable in the current SVN trunk. I’ve written before about my shaping ideas here.

The support currently focuses on three different options:

1. Limiting bandwidth usage by rules.

Per rule a limit can be set for the maximum amount of bandwidth all traffic from this rule uses. Both directions of a connection have different limits. The in_max and out_max options can be added to existing rules for this. The syntax of the in_max and out_max is simple: out_max=15kbps means that traffic in the source to destination direction of a rule can at max use 15 kb/s.

2. Guaranteeing bandwidth to rules.

Again per rule a guaranteed minimum of available bandwidth can be configured. This way you can for example make sure your VoIP calls get enough. It’s important to not over commit the bandwidth. If you do that Vuurmuur will issue a warning but will still work because HTB, the used scheduler, accepts it as well. In this case the minimal bandwidth can not be guaranteed. To use this option add the in_min and out_min options. The syntax is the same as with in_max/out_max.

3. Prioritizing rules.

Like the first two options the priority can be set per rule. It’s a number where 1 is the highest prio. The default prio is 3. The syntax is prio=1. The lowest prio possible is 255.

For each interface, Vuurmuur needs to know the maximal bandwidth. Also, the shaping can be enabled and disabled on a per interface basis. Because shaping is attached to interfaces, rules using source and/or destination ‘any’ or ‘firewall(any)’ won’t be able to shape. Also, only outgoing shaping is supported, which is no problem in a gateway setup because then all traffic is outgoing on one of the interfaces, but on traffic from and to the firewall, this can be a limitation.

For example, to set the bandwidth in the interface ‘inet-nic’ which has a bandwidth of 3072kbit/512kbit, use the following vuurmuur_script commands:

vuurmuur_script -M -i inet-nic -V SHAPE -S Yes
vuurmuur_script -M -i inet-nic -V BW_IN -S 3
vuurmuur_script -M -i inet-nic -V BW_IN_UNIT -S mbit
vuurmuur_script -M -i inet-nic -V BW_OUT -S 512
vuurmuur_script -M -i inet-nic -V BW_OUT_UNIT -S kbit

Using vuurmuur_conf, it’s already possible to set the location of the tc binary. Look at ‘Vuurmuur Config -> General’.

An example of what a full rule using shaping can look like:

accept service ftp from local.lan to world.inet options prio=2, in_max=200kbps, out_max=15kbps

This example limits HTTP downloading to a speed of 200kb/s and uploading to 15kb/s.

The coming days and weeks I’ll finish the GUI support and release a test version.