- I am working on this. But firewall rules are the best place to have DoS prevention
that takes least resources and works best. As for the gatekeeper it means
to create a new socket, handle the Setup and send back Release Complete.
Fine for a soft limit, but almost does not prevent from DoS.
----- Original Message ----- From: "Freddy Parra" <fparra@xxxxxxxxxx>
Sent: Monday, February 28, 2005 9:16 PM
Jan,
I will try to pin point the code as to where this is happening since I did get the core dump file for it. My concern now is as Michal pointed out that this can easily be exploited via DOS. The only thing someone would need is some form of generating calls like the call generator avail. to crash anyone's gatekeeper. I guess currently there is no other way to prevent this aside from creating firewall rules as Michal and Teodor stated or a patch solution like you described below. In the mean time, firewall rules seem to be the only fix. Most Linux distributions come with a default socket limit of 1024, which wouldn't take much calls to take someone's gatekeeper off line. Thanks.
Freddy
-----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jan Willamowius Sent: Thursday, February 24, 2005 4:05 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Non-Responsive
Freddy, that is very good testing!
I'm currently busy with non-GnuGk projects, but it would be great if you could pinpoint the place in the code where we are still missing a check for a failed socket open based on your current test setup. We fixed a lot of those moving from 2.2.0 to 2.2.1 but obviously not all and you should be able to get a backtrace from your segfault.
After that we need a strategy how to deal with an out-of-socket situation best. If we have only reached the limit per thread we might actually be able to dynamically start another handler thread and be fine. But it could also be a system limit we are reaching and then we'd need a strategy to handle current calls and registrations and avoid new calls. Quite a bit of work, but doable.
So short, Jan
Freddy Parra wrote:
Test on generating calls for Gnugk Version 2.2.2:
The following test was performed:
1.) I used screens to create a separate session on Linux and set ulimit to be 65 sockets for gnugk to run with.
2.) I had signaling handlers set to 15 and with h225 routed and h245 being tunneled. No media proxying.
3.) Generated 3 sets of 10 calls each to Gnugk.
4.) During the second set of initiated calls Gnugk displayed the following error:
Assertion fail: Operating System error, file tlibthrd.cxx, line 730, Error=24
<A>bort, <C>ore dump, <I>gnore?
5.) Once this error appear one could continue to send calls to the system, but no more Sockets were being created and released when
Checking the total sockets with lsof - p 29621 | wc -l.
6.) I repeated this same test a few more times and the same error appeared.
I then decided to perform the test on an old version of 2.2b5 that I had been using for many months before moving to 2.2.2
The same errors occur as in 2.2.2. I also did not see any new sockets being created or released when issuing lsof - p 29621 | wc -l.
The status port was blank with _ characters appearing.
I used the following Call Generator command.
callgen323 -m 10 -r 10 --tmaxest 5 --tmincall 3 --tmaxcall 3 --tminwait 1 --tmaxwait 1 -u gen2 -g xxx.xxx.xxx.xxx CISCO5850E
________________________________
From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Freddy Parra Sent: Wednesday, February 23, 2005 11:04 AM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: Non-Responsive
Here are some current results:
When max sockets are reached the following behavior was noted:
For this test I had the following conditions set:
1.) I used screens to create a separate session window on Linux and set ulimit to be 60 sockets for gnugk to run with.
2.) I had signaling handlers set to 15 and with h225 routed and h245 being tunneled. No media proxying.
3.) I was able to create 3 telnet instances to the status port and on the 4th instance I got a blank telnet response. This meant I ran out of sockets
which is the state I wanted gnugk to be in.
4.) When I issued a reload on one of the telnet sessions all endpoints that were registered suddenly unregistered.
5.) I retested the same case scenario and this time had a segmentation fault (core dump).
6.) I performed the following test a few times over and the same scenarios played out, with endpoints un-registering and segmentation fault happening.
I'm in the process of creating some test with the call generator and see what the behavior is when calls are being sent to the system when max sockets are reached.
Freddy
-----Original Message----- From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Freddy Parra Sent: Tuesday, February 22, 2005 6:53 PM To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: Non-Responsive
Hi Todd,
That's interesting. I was thinking of maybe running the call generator
program that comes with openh323 and setting the ulimit for total
sockets on gnugk to a very small number like 20, then generating like 50
or more calls at the same time using the call generator. Maybe like this
we can duplicate this behavior and see if this is the actual problem. I
will try later on today if I find something and post my findings.
Freddy
-----Original Message-----
From: openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx
[mailto:openh323gk-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of R.
Todd Wallace
Sent: Tuesday, February 22, 2005 5:55 PM
To: openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Subject: RE: Non-Responsive
Something that was noticed was that the GNU had a ton of sockets in wait
state. It looks like there was a blip in IP and these sockets did not
get
released and the GNU had them in wait state.
------------------------------------------------------- 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
_______________________________________________________
List: Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Homepage: http://www.gnugk.org/
