Bug#458518: ejabberd: Bind to ports < 1024 not possible, no error generated
Daniel Pocock
Version: 1.1.2-6
Severity: important
If you try to configure ejabberd to bind to port 80 or 443, by modifying
ejabberd.cfg, the following behaviour is observed:
- you can successfully start the process
- ejabberd binds to configured ports above 1023
- ejabberd is not bound to configured ports below 1024
The bug: no error is generated to say why the ports below 1024 are not
bound
Ultimately, it is failing to bind to ports below 1024 because it is
started as the user ejabberd instead of the user root.
Corrections:
- documentation (README.Debian) should inform the user that it is not
possible to bind on port 80 or 443 because the process is not running as
root
- ejabberd should log an error and possibly refuse to start if any of
the configured ports can not be bound successfully
- there should be a feature that allows ejabberd to start as root, bind
to the required ports, and then change to the ejabberd user (similar to
the way the `named' process behaves)
Why this is important, documentation:
- for usage of Jabber to spread, we must make it easy to get through
firewalls
- many corporate firewalls, by default, will only allow the `HTTP
Connect' proxy method to connect to servers on port 443
- configuring ejabberd to listen on port 443 is a very effective way
to allow incoming connections from users who are behind firewalls
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.26
Locale: LANG=C, LC_CTYPE=C (charmap=ISO-8859-1) (ignored: LC_ALL set to en_US)
Versions of packages ejabberd depends on:
ii adduser 3.102 Add and remove users and groups
ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy
ii erlang-base 1:11.b.2-4 Concurrent, real-time, distributed
ii erlang-nox 1:11.b.2-4 Concurrent, real-time, distributed
ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries
ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li
ii libssl0.9.8 0.9.8c-4etch1 SSL shared libraries
ii openssl 0.9.8c-4etch1 Secure Socket Layer (SSL) binary a
ii ucf 2.0020 Update Configuration File: preserv
ii zlib1g 1:1.2.3-13 compression library - runtime
ejabberd recommends no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sergei Golovan
> ejabberd.cfg, the following behaviour is observed:
> - you can successfully start the process
> - ejabberd binds to configured ports above 1023
> - ejabberd is not bound to configured ports below 1024
>
> The bug: no error is generated to say why the ports below 1024 are not
> bound
It's true. I'll try to fix it (I think that generating an error
message to the log is enough.)
> Ultimately, it is failing to bind to ports below 1024 because it is
> started as the user ejabberd instead of the user root.
> Corrections:
> - documentation (README.Debian) should inform the user that it is not
> possible to bind on port 80 or 443 because the process is not running as
> root
It will be done in the next ejabberd upload.
> - ejabberd should log an error and possibly refuse to start if any of
> the configured ports can not be bound successfully
Logging an error is enough for me.
> - there should be a feature that allows ejabberd to start as root, bind
> to the required ports, and then change to the ejabberd user (similar to
> the way the `named' process behaves)
It's hard for erlang application, so I don't think that it worth doing
that. Erlang appplication can't drop privileges, and soket binding to
privileged port by a non-privileged user requires an external suid
program which isn't available in Debian.
> Why this is important, documentation:
> - for usage of Jabber to spread, we must make it easy to get through
> firewalls
> - many corporate firewalls, by default, will only allow the `HTTP
> Connect' proxy method to connect to servers on port 443
> - configuring ejabberd to listen on port 443 is a very effective way
> to allow incoming connections from users who are behind firewalls
I don't agree that it's important. I think that all services should be
bound to their assigned ports. Otherwise the system becomes a mess.
>From the other hand, do you really think that "corporate firewalls"
are set by evil people just to prevent XMPP to spread? BTW, if you
want Jabber server to listen at port 443 you can redirect it by a
firewall.
--
Sergei Golovan
Sergei Golovan
> >
> Just as long as it makes the problem obvious - I was a little confused
> when I changed the configuration and there was no obvious impact.
The actual problem was that the logging facility wasn't started yet,
so error messages didn't reach the log file. The message looks like
the following:
E(<0.242.0>:ejabberd_listener:80): Failed to open socket for {222,
ejabberd_c2s,
[{access,c2s},
{max_stanza_size,
65536},
starttls,
{certfile,
"/etc/ejabberd/ejabberd.pem"},
{shaper,
c2s_shaper}]}: eacces
which rooks reasonably understandable.
>
> >> Why this is important, documentation:
> >> - for usage of Jabber to spread, we must make it easy to get through
> >> firewalls
> >> - many corporate firewalls, by default, will only allow the `HTTP
> >> Connect' proxy method to connect to servers on port 443
> >> - configuring ejabberd to listen on port 443 is a very effective way
> >> to allow incoming connections from users who are behind firewalls
> >>
> >
> > I don't agree that it's important. I think that all services should be
> > bound to their assigned ports. Otherwise the system becomes a mess.
> > From the other hand, do you really think that "corporate firewalls"
> > are set by evil people just to prevent XMPP to spread? BTW, if you
> > want Jabber server to listen at port 443 you can redirect it by a
> > firewall.
> >
> >
> I agree - in a default configuration - we should only use assigned ports.
>
> In practice, we should give users the information to configure it for
> their needs:
> - Many companies have a policy permitting email and instant messaging,
> for productivity reasons.
> - Google Talk provides a way for people to do Jabber through a HTTP
> firewall (using a flash client). MSN and others also work through HTTP
> proxies.
> - If firewall administrators really want to be secure, they would not
> offer the `HTTP Connect' service. For example, security concious
> companies typically don't provide any Internet access from those LAN
> segments that need real security. Those machines are on separate
> networks with extra firewalls and modified routing tables.
> - When someone is at a hotel, an airport, or a friends house, they may
> otherwise be unable to use Jabber. They need to either pre-configure
> their Jabber server on port 443, or install a web based Jabber client on
> their web server (which may mean limited features).
> - Consequently, although it is non-standard, it is quite legitimate and
> often quite desirable for people installing this package to want to use
> port 443.
> - In my own case, I put an extra IP address on the server, just for
> Jabber. That way, I can have ejabberd listening on (jabber IP):443, and
> I have an Apache process listening on (another IP):443. Therefore,
> using the https port for ejabberd client connections doesn't
> inconvenience me at all.
I think that it's faily easy to redirect TCP connections using
iptables, so I isn't so important to be able to bind privileged ports.
A simple example will be included into README.Debian.
Daniel Pocock
> I think that it's faily easy to redirect TCP connections using
> iptables, so I isn't so important to be able to bind privileged ports.
> A simple example will be included into README.Debian.
>
>
In a large installation, the state table for port mapping may be
undesirable. It is up to the system administrator to decide which
solution they prefer - although both solutions (port mapping and
listening on an extra port) are equally legitimate. Can we make setuid
operation a wishlist item for Erlang perhaps?
Here is the code I added to /etc/ejabberd/ejabberd.cfg for binding to a
specific IP address and both ports - 5222 (the default) and 443. In
this case, I also tell ejabberd to bind to a specific IP address,
because there is a genuine https service running on the same host:
% Listened ports:
{listen,
% Ordinary client-2-server service
[{5222, ejabberd_c2s, [{access, c2s},
{ip, {192, 168, 1, 100}},
{max_stanza_size, 65536},
starttls, {certfile,
"/etc/ejabberd/ejabberd.pem"},
{shaper, c2s_shaper}]},
{443, ejabberd_c2s, [{access, c2s},
{ip, {192, 168, 1, 100}},
{max_stanza_size, 65536},
starttls, {certfile,
"/etc/ejabberd/ejabberd.pem"},
{shaper, c2s_shaper}]},
Also, do you think it is safe for ejabberd to accept new registrations
by default? Has the issue been discussed already? I think all the
Jabber server packages should disable this feature by default, with a
debconf option to enable it. A note on this issue might also be useful
in README.Debian
Regards,
Daniel
Sergei Golovan
>
> In a large installation, the state table for port mapping may be
> undesirable. It is up to the system administrator to decide which
> solution they prefer - although both solutions (port mapping and
> listening on an extra port) are equally legitimate. Can we make setuid
> operation a wishlist item for Erlang perhaps?
1) It's a separate program which isn't shipped with erlang, so it'd
require a separate package;
2) It isn't a drop-in replacement for usual erlang sockets, so
ejabberd must be partially rewritten to use it.
I think it's infeasible for package maintainer to do that. But you may
go directly to upstream bug tracker and file a bug about privileged
ports.
>
> Here is the code I added to /etc/ejabberd/ejabberd.cfg for binding to a
> specific IP address and both ports - 5222 (the default) and 443. In
> this case, I also tell ejabberd to bind to a specific IP address,
> because there is a genuine https service running on the same host:
It's easy to redirect only packets that come to a specific IP.
>
> Also, do you think it is safe for ejabberd to accept new registrations
> by default? Has the issue been discussed already? I think all the
You're right. Usually this issue with free registration comes to my
mind just after uploading a new package. Could you file a bug to make
me not to forget it again?
--
Sergei Golovan