From mboxrd@z Thu Jan  1 00:00:00 1970
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: Mon, 27 Jan 2020 10:01:25 +0000
Message-ID: <9C17119F-01ED-4492-9CD9-E938A1A21BC5@ipfire.org>
In-Reply-To: <20200127075349.GA25405@tehanu.it.jyu.fi>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4483982825555285277=="
List-Id: <development.lists.ipfire.org>

--===============4483982825555285277==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

> On 27 Jan 2020, at 07:53, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wr=
ote:
>=20
> On Jan 24 11:43, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
>=20
>>> On 21 Jan 2020, at 18:22, Peter M=C3=BCller <peter.mueller(a)ipfire.org> =
wrote:
>=20
>>> 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 > 10=
23,
>>> so there is little legitimate scope for this if in doubt.
>=20
>> Hmm, okay. I get your point. However I am not sure if this will
>> improve security too much.
>=20
> Not much, but it will prevent using you in certain type of bounceback
> DDoS attack.
>=20
> 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.
>=20
> So yes, it does make sense to filter NEW packets sourced from
> privileged ports.
>=20
> 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 I=
P stacks.

It would be RFC-compliant, but I am not sure after what time we will see peop=
le 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.
>=20
> 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.
>=20
> 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 ta=
ke longer when every possible source port has to be tried, too.

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

Actually not. That is why Peter started this conversation.

-Michael

>=20
> --=20
> Tapani Tarvainen


--===============4483982825555285277==--