Potential issue while clients are using XLXooo as the DExtra callsign to connect a XLX refector about xlxd HOT 2 CLOSED

Hi Yngwie,

Thank you for your interesting findings..

The way it actually works, is that peer/client detection is not callsign based, but protocol (UDP port) based.
So, once ircddbgateway client connected successfully on Dextra socket using a XLXooo callsign, the following keepalive are failing
as the XLX server sends it’s Dextra identity (ie XRFooo) is the keepalive packet which irccddbgateway don’t
like as it’s expecting the XLXooo it thought it connected with.

So, from the security point of view, this behavior should be safe.
One extra level of protocol-checking could however be added, as the XLX should have not accepted in a first instance a Dextra
connection with a XLXooo callsign parameter.

73
Jean-Luc

Le 17 juil. 2016 à 05:05, yngwiechou [email protected] a écrit :

Here's scenario:

For DExtra Protocol, clients are usually using callsign XRFooo for reflector connection.
However, iif a G4KLX client is using XLXooo callsign instead of XRFooo in DExtra_Hosts.txt and connecting to XLX reflector, then client will be dropped due to lack of keepalive.

Here's the log when a client is using XLXooo callsign in DExtra_Hosts.txt for reflector connection.

/opt/XLX# tail -f /var/log/messages
Jul 17 10:50:21 localhost xlxd: DExtra client BV5OO C keepalive timeout
Jul 17 10:50:21 localhost xlxd: Client BV5OO C at 10.100.1.100 removed
Jul 17 10:51:10 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:51:10 localhost xlxd: New client BV5OO C at 10.100.1.100 added with protocol 1
Jul 17 10:51:10 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:55:04 localhost xlxd: DExtra client BV5OO C keepalive timeout
Jul 17 10:55:04 localhost xlxd: Client BV5OO C at 10.100.1.100 removed
Jul 17 10:55:57 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:55:57 localhost xlxd: New client BV5OO C at 10.100.1.100 added with protocol 1
Jul 17 10:55:57 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:56:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:56:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:57:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:57:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:58:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:58:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:59:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 10:59:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 11:00:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 11:00:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 11:01:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
Jul 17 11:01:58 localhost xlxd: DExtra connect packet for module C from BV5OO C at 10.100.1.100 rev 0
To me, it seems the xlxd is using callsign to tell if the incoming connection is a peer or a client.
Not sure if this will be a security concern.

73,
Hi Yngwie

BX2AFC

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #8, or mute the thread https://github.com/notifications/unsubscribe-auth/AOfZMIgo6kvpxr_bBVHyMyUoJ_rqzzLAks5qWZwOgaJpZM4JOJDp.

from xlxd.

Understood, Luc.

Much appreciated for your kindly explanation!

Cheers,
Yngwie

from xlxd.