public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Firewall rules with predefined service groups for both source and destination?
Date: Sun, 26 Jan 2020 20:43:39 +0000	[thread overview]
Message-ID: <C7287DB8-4F7E-45E2-AED6-A2E79D6799E8@ipfire.org> (raw)
In-Reply-To: <6d8b7439-f584-eb4a-9b87-078d0b1af0c1@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

Hi,

> On 25 Jan 2020, at 16:41, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
>> Hi,
>> 
>>> On 21 Jan 2020, at 18:22, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>> 
>>> Hello *,
>>> 
>>> since I am not sure whether I am dealing with a bug, a missing feature
>>> or my very own personal incompetence, asking the mailing list seemed
>>> reasonable for this. :-)
>> 
>> Yes, because we are only experts here :)
>> 
>>> For security purposes, dropping packets from source ports < 1024 is a good
>>> idea as the latter indicates successful compromise of services running on
>>> privileged ports. New connections are usually established from ports > 1023,
>>> so there is little legitimate scope for this if in doubt.
>> 
>> Hmm, okay. I get your point. However I am not sure if this will improve security too much.
> 
> Probably not as an attacker could always open a new connection using some port
>> 1023 if he/she/it already controls a machine. However, it raises the bar -
> and some Emerging Threat signatures cover the same anomaly ("GPL MISC source port 53 to <1024"
> and "GPL MISC Source Port 20 to <1024").
> 
> But yes, this certainly is not a silver bullet.
> 
>> 
>>> When creating a firewall rule via the WebIF, it does not seem to be possible
>>> to limit source _and_ destination ports if a predefined service (group) is
>>> used - the latter one always refers to the destination port(s).
>> 
>> Yes, because technically that is how those services work.
>> 
>> A browser will always connect from a random port to port 80. There is literally no use-case to limit this to a pre-defined port. You never even know if you are having any NAT routers on the ways that will change your source port.
>> 
>>> As soon as a single protocol such as TCP or UDP is selected, however, a field
>>> "source port" is available.
>>> 
>>> Is this behaviour intentional? If yes, how do I limit firewall rules to
>>> certain source ports then? Aren't the descriptions "service" and "service group"
>>> misleading?
>> 
>> Those are only for destinations.
> 
> Glad to have this clarified.
> 
>> 
>> What we could do is limiting source ports to > 1024 by default, but I am not sure if that will make a noticeable difference for anyone.
> 
> Good idea. I guess some services may need source ports < 1024 (e.g. IPsec), but adding
> some switch saying "accept connections from high ports only" might be suitable for this.

IKEv1 does this, but you are not guaranteed that you will reach the other end without passing through a NAT gateway which randomises the source port.

I think it might be worth a try, but we will make the firewall less efficient by making it check the source as well.

> Thanks, and best regards,
> Peter Müller


  reply	other threads:[~2020-01-26 20:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 18:22 Peter Müller
2020-01-24 11:43 ` Michael Tremer
2020-01-25 16:41   ` Peter Müller
2020-01-26 20:43     ` Michael Tremer [this message]
2020-01-27  7:53   ` Tapani Tarvainen
2020-01-27 10:01     ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C7287DB8-4F7E-45E2-AED6-A2E79D6799E8@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox