User deny rules should override connection tracking

Bug #507469 reported by Alan Jenkins
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ufw
Won't Fix
Wishlist
Unassigned
ufw (Ubuntu)
Won't Fix
Wishlist
Unassigned

Bug Description

Binary package hint: ufw

AIUI, netfilter matching stops at the first ACCEPT rule. Ufw accepts "established" connections in the before-input ruies:

# quickly process packets for which we already have a connection
-A ufw-before-input -m state --state RELATED,ESTABLISHED -j ACCEPT

so this happens before any user rules. But I want to be able to do this:

ufw deny default
ufw allow in from 192.168.0.0/24 # allow ssh etc. from computers on the home network
ufw deny proto tcp in to any 1:1023

and have it deny incoming connections to the priveleged ports _even if the connection tracker thinks they should be allowed_. I believe this could be achieved by moving the ESTABLISHED rule to after-input.

I want to be able to override connection tracking because there's always going to be the possibility that it will get things wrong. In particular, there has been a recent claim that linux-based firewalls can be penetrated simply by visiting a malicious web page. I don't know whether this specific claim applies to Ubuntu, but I shouldn't have to worry about this class of attacks.

<http://www.theregister.co.uk/2010/01/06/web_based_firewall_attack/>
<http://samy.pl/natpin/>

[I've not marked this bug as a security vulnerability, since fixing it won't improve the default security. Unless of course you decide to provide my rules as a default, but I don't suppose that's very likely].

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thank you for using Ubuntu and taking the time to report a bug. I'll need to look at this more before considering making changes, but I did want to say in the meantime that /etc/ufw/*.rules are there for you as an administrator to adjust as necessary for your site requirements. Feel from to remove those lines from before.rules and adjust after.rules to have:
-A ufw-after-input -m state --state RELATED,ESTABLISHED -j ACCEPT
-A ufw-after-output -m state --state RELATED,ESTABLISHED -j ACCEPT

For large rulesets, this may affect performance, but I imagine in most ufw setups it won't make any appreciable difference. Thanks again and report back how this works out for you.

Changed in ufw (Ubuntu):
importance: Undecided → Wishlist
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I might also mention that ufw in Ubuntu 9.10 also has egress (outgoing) filtering support, which can also probably help here.

Revision history for this message
Alan Jenkins (aj504) wrote :

Thanks for the quick response! I tried changing the rules files and it did what I wanted.

I'm already running 9.10, but I'm not sure how I could use egress filtering to protect against this.

Revision history for this message
Alan Jenkins (aj504) wrote :

The other possible disadvantage of this configuration is that you might be running services which are private, but which try to make outgoing connections to the internet *from* a privileged port. I can't think of any example off the top of my head, but it's something to consider.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I am going to mark this "Won't Fix" for now, since this seems a specialized case and ufw allows for it via it rules files. I'll reopen if there is something that I think could be added without adding confusion to users.

Changed in ufw:
importance: Undecided → Wishlist
status: New → Won't Fix
Changed in ufw (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.