Firewall rules with predefined service groups for both source and destination?

Firewall rules with predefined service groups for both source and destination?

[Peter Müller]

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

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. :-)

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.

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).

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?

Thanks, and best regards,
Peter Müller

Re: Firewall rules with predefined service groups for both source and destination?

[Michael Tremer]

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

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.

> 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.

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.

-Michael

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

Re: Firewall rules with predefined service groups for both source and destination?

[Peter Müller]

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

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.

Thanks, and best regards,
Peter Müller

Re: Firewall rules with predefined service groups for both source and destination?

[Michael Tremer]

[-- 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

Re: Firewall rules with predefined service groups for both source and destination?

[Tapani Tarvainen]

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

On Jan 24 11:43, Michael Tremer (michael.tremer(a)ipfire.org) wrote:

> > On 21 Jan 2020, at 18:22, Peter Müller <peter.mueller(a)ipfire.org> wrote:

> > 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.

Not much, but it will prevent using you in certain type of bounceback
DDoS attack.

Let's say you are A, there's a blackhat B who wants to attack a third
party C who runs a web server. So B sends you a packet with source
port 80 and source address forged to point to C, and your reply goes
to port 80 at C. This is harder for C to handle than direct attacks or
similar attacks to non-privileged ports.

So yes, it does make sense to filter NEW packets sourced from
privileged ports.

Not that it matters all that much, it isn't actually all that hard for
C to deal with such attacks if they know what they're doing.

> 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.

I can think of one use case, although it is rather on the far side of
obscure: if you want to provide some service only to select few, or
even just one trusted user or your own other machine somewhere so know
where they're coming from, you could use source port filtering as an
additional protection mechanism.

Not that I'd recommend doing that, it's fragile and doesn't really buy
much additional security, and certainly not worth worrying about in
IpFire.

> 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.

Probably not. And those who worry about this can do it by themselves.

-- 
Tapani Tarvainen

Re: Firewall rules with predefined service groups for both source and destination?

[Michael Tremer]

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

Hi,

> On 27 Jan 2020, at 07:53, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> On Jan 24 11:43, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 
>>> On 21 Jan 2020, at 18:22, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
>>> 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.
> 
> Not much, but it will prevent using you in certain type of bounceback
> DDoS attack.
> 
> Let's say you are A, there's a blackhat B who wants to attack a third
> party C who runs a web server. So B sends you a packet with source
> port 80 and source address forged to point to C, and your reply goes
> to port 80 at C. This is harder for C to handle than direct attacks or
> similar attacks to non-privileged ports.
> 
> So yes, it does make sense to filter NEW packets sourced from
> privileged ports.
> 
> Not that it matters all that much, it isn't actually all that hard for
> C to deal with such attacks if they know what they're doing.

Yeah, I think this is a good point: Avoid accpeting connections from broken IP stacks.

It would be RFC-compliant, but I am not sure after what time we will see people who are using some rubbish embedded OS or something somewhere running into it.

>> 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.
> 
> I can think of one use case, although it is rather on the far side of
> obscure: if you want to provide some service only to select few, or
> even just one trusted user or your own other machine somewhere so know
> where they're coming from, you could use source port filtering as an
> additional protection mechanism.
> 
> Not that I'd recommend doing that, it's fragile and doesn't really buy
> much additional security, and certainly not worth worrying about in
> IpFire.

This is more security by obscurity because you would make a port scan just take longer when every possible source port has to be tried, too.

> 
>> 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.
> 
> Probably not. And those who worry about this can do it by themselves.

Actually not. That is why Peter started this conversation.

-Michael

> 
> -- 
> Tapani Tarvainen