[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

OpenDev firewalls and MM2 insecurity (was: How to build circular dependant packages in debian)

On 2021-09-20 02:11:06 +0000 (+0000), Paul Wise wrote:
> Normally one would get "Connection refused" when connecting to a port
> that isn't open, but at this site one gets "No route to host", as if
> there is no network path to reach the host, which is clearly not true
> since the HTTP port works. I wasn't aware it is even possible to have
> different routing for each TCP port, I guess this is a feature of
> OpenStack?

No need to reach for OpenStack behaviors on this. All our servers
have IPTables rulesets using reject-with icmp6-adm-prohibited in
their default deny rules in order to avoid the complexity of
protocol-specific rejection rules. I noticed we're still using
icmp-host-prohibited in our v4 rules because long ago kernels lacked
support for sending icmp-admin-prohibited (also noted in the
iptables-extensions(8) manpage), but at this point we
should be quite safe to switch that so I've pushed up a change for
it just now.

That said, for IPv4 it's still an ICMP "host unreachable" error,
merely with the "admin prohibited filter" flag set, which many
clients don't do a great job of differentiating. Thankfully for
folks with working IPv6 an ICMP6 "destination unreachable" error
with "unreachable prohibited" set is often interpreted by clients as
"permission denied" which is a little more obvious, but when clients
automatically fall back from v6 to v4 on errors the end result isn't
much better.

> > If there's a reason we should prioritize an HTTPS
> > implementation there over other [Mailman 2] work,
> User subscription passwords are transferred to the Mailman
> subscription/options web interface, which is on the same site as
> the web mailman archives.

Yes, they are. They're also transferred unencrypted over SMTP and
MM2 can be triggered anonymously to do so at any time via a
"password recovery" form in its WebUI so long as you can guess the
E-mail address of a subscriber (trivial to do when there are also
public list archives). We debated that adding HTTPS for that
interface could actually do more harm than good by giving a false
sense of security to users who did not consider that aspect. Users
*should* be wary of the security of that service, full stop.

Thankfully, MM3 provides a modern password reset solution which
won't leak plaintext passwords to people sniffing SMTP
communications, so we do intend to add HTTPS when upgrading to that,
which ought to be fairly soon.
Jeremy Stanley

Attachment: signature.asc
Description: PGP signature

Reply to: