Looks like the first query has found some results in the database (as no log output is generated). It's a bit unclear for me, why the other queries are executed. Without ARQ details it's hard to say something precise.
Regarding caller lookup - there are many configuration, some people want to authenticate based on h323id, others on caller id, yet others on all aliases. We don't want to restrict this. As the attacker would have to know clear text password to authorize with another alias, this does not introduce any security implications.
----- Original Message ----- From: "Frank Fischer" <frank.fischer@xxxxxxxxxxxxxxxx>
Sent: Sunday, April 17, 2005 6:07 PM
I found some 'unexpected' behaviour with SQLPasswordAuth in 2.0.9 - maybe someone knows if i did some misconfiguration or if it's a bug?
Here's what i did: I have (parent) gatekeeper (2.0.9) (signaling mode)
(routing done by an external application) that works fine so far. Now i set
up another gatekeeper (2.0.9) (full proxy mode) and registered it to the
parent as endpoint typ terminal.
[Endpoint] Gatekeeper= xxx.xxx.xxx.xxx Type=Terminal H323ID=abcdefg Password=aaa TimeToLive=900 RRQRetryInterval=30 ARQTimeout=10 UnregisterOnReload=1
Registration works fine and call routing from parent to child gk works too. But when i try to set up a call from the child to the parent the ARQ gets
rejected on the parent with reason security denial. A debug trc 5 shows the
following:
2005/04/17 17:22:22.332 1 RasSrv.cxx(1653) GK ARQ Received
2005/04/17 17:22:22.332 5 gksql.cxx(326) SQLPasswordAuth
Executing query: SELECT H235Password FROM subscribers WHERE H323ID =
'abcdefg'
2005/04/17 17:22:22.332 5 gksql.cxx(326) SQLPasswordAuth
Executing query: SELECT H235Password FROM subscribers WHERE H323ID =
'2527_gkfi'
2005/04/17 17:22:22.332 4 sqlauth.cxx(482) SQLPasswordAuth
Password not found for alias '2527_gkfi'
2005/04/17 17:22:22.332 5 gksql.cxx(326) SQLPasswordAuth
Executing query: SELECT H235Password FROM subscribers WHERE H323ID =
'123456789'
2005/04/17 17:22:22.332 4 sqlauth.cxx(482) SQLPasswordAuth
Password not found for alias '123456789'
2005/04/17 17:22:22.332 3 gkauth.cxx(1710) GKAUTH
SQLPasswordAuth password not found for '123456789'
2005/04/17 17:22:22.332 3 gkauth.cxx(1243) GKAUTH
SQLPasswordAuth ARQ check failed
2005/04/17 17:22:22.332 2 RasSrv.cxx(1924)
ARJ|62.167.xxx.xxx:1720|99999999:dialedDigits|123456789:dialedDigits|false|s
ecurityDenial;
The parent gk first looks up the H323ID (alias) in the DB. There is no
"result"; could the gk find a password or not? If you look at the two
following lookups for the EndpointId and the E164Number which both fails. What happend to the first lookup? It should have passed the password test,
since I'm sure the H323ID and password are correct and this is already
proven by the fact that the child gk could actually register with the parent
using the same username/password.
So this check should succeed and there is no need to lookup with the
EndpointId or caller phonenumber (which is IMHO a security issue - caller
phonenumbers should only be used for authentication in a RRQ but not in an
ARQ).
This only happens in that specific situation with child gk/parent gk. If an
ARQ from an Endpoint that is directly registered with the parent gk is
received, only H323Id/password is checked and the check succeeds, so an ACF
is issued.
Anyone has an idea what happend here? Bug or configuration issue?
Thanks a lot for your help in advance!
Greetings Frank
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/