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