public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Tapani Tarvainen <ipfire@tapanitarvainen.fi>
To: development@lists.ipfire.org
Subject: Re: Firewall rules with predefined service groups for both source and destination?
Date: Mon, 27 Jan 2020 09:53:50 +0200	[thread overview]
Message-ID: <20200127075349.GA25405@tehanu.it.jyu.fi> (raw)
In-Reply-To: <B4560934-15F2-4E00-8D4A-3FE9A60B3A08@ipfire.org>

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

  parent reply	other threads:[~2020-01-27  7:53 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
2020-01-27  7:53   ` Tapani Tarvainen [this message]
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=20200127075349.GA25405@tehanu.it.jyu.fi \
    --to=ipfire@tapanitarvainen.fi \
    --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