Re: [U2] Denial Of Service in UVRPC Universe
Thanks a lot, Herve.
This parameter has been the sollution to my customer issues.
Maybe, the virus or worm that was blocking unirpcd still exists, but now,
with a timeout of 15 seconds, my customer works without a problem.
I consider that is not really a Universe "bug", but a collateral effect of
the Universe way of licences control.
Could it be related with other issues we have?:
Only happens with uvcs remote sessions over internet or VPNs.
Telnet sessions and Terminal Server sessions does'nt drop, but uvcs sessions
drops on client side, meanwhile the server think that the session is still
active.
Regards,
__
Augusto Alonso Alonso
IT Manager
Quiter Servicios Informaticos S.L.
Tel: +34 902 23 33 23
Fax: +34 902 23 42 80
[EMAIL PROTECTED]
www.quiter.com
__
- Original Message -
From: "Herve Balestrieri" <[EMAIL PROTECTED]>
To:
Sent: Thursday, September 20, 2007 11:46 AM
Subject: Re: [U2] Denial Of Service in UVRPC Universe
Augusto,
The UniRPC protocol hanging when contacted by other network protocols
working on the same TCP port is not exactly what we could name a "bug".
But, for the very true reasons you exposed, enhancements have been made in
UniRPC daemon ("unirpcd" executable) to handle smoothly the case of
unexpected packets causing the daemon to hang, as the UniRPC "applicative"
protocol doesn't know about any of the others high-level protocols such as
"telnet", "ftp", and so on.
A new "unirpcd" parameter = -timeout tt, with "tt" in seconds allows the
UniRPC daemon to handle smoothly this situation.
We recommend the timeout value to be the smallest as your network can
support, because for the duration of the timeout, the UniRPC daemon is
actually hanging, but in a controlled manner, and no more UniRPC
connections can be accepted.
A value of 15 seconds seems generally the largest acceptable value on most
sites, so it could be reduced on purpose.
Note that this parameter exists for UniVerse on Windows platform starting
at release 10.1.23 for releases 10.1.x and 10.2.3 for releases 10.2.x.
The procedure to get it enabled through Windows Services Manager is
documented in the "patchlist" file accessible on :
https://www-927.ibm.com/software/data/u2/support/u2techconnect/downloads/readme/UV-10.1.23.zip
Have to look at "Issue # 9074".
On UNIX platforms, the "-timeout" parameter was altready existing in the
early releases 10.0.x (and UniData 6.0.x), (and it's much easier to have
it
enabled at system command line !).
Hope this will help.
P.S: The answer here is one more reason to attend to U2U in IBM Bedfont
Lakes (Feltham) as my manager suggested !...
Regards,
Herve' Balestrieri
Hi all.
If you do a telnet against any Universe server on port 31438 (I have
tested
it on Universe 10.0.10 in Windows, Universe 10.0.20 in Linux and Universe
10.0.6 in HP-UX), you will have something very similar to a Denial Of
Service on this port 31438:
-all previous UVRPC established sessions keep on working without
problem, but
-any subsequent tries to start new UVRPC sessions, will timeout with
"Error returned from connect = 81015".
The problem desappears when the PC client closes the telnet session. (Or
you
can restart UniVerse or the whole server...)
Could someone tell me if is it a normal behaviour or is it a unirpcd bug?
Is there any way of detect or avoid this kind of sessions?
Could it be the same problem that some viruses (like Blaster) causes on
UVRPC of Universe Servers?
Any help will be apreciated.
Regards,
__
Augusto Alonso Alonso
IT Manager
Quiter Servicios Informaticos S.L.
[EMAIL PROTECTED]
www.quiter.com
__
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Denial Of Service in UVRPC Universe
Augusto,
The UniRPC protocol hanging when contacted by other network protocols
working on the same TCP port is not exactly what we could name a "bug".
But, for the very true reasons you exposed, enhancements have been made in
UniRPC daemon ("unirpcd" executable) to handle smoothly the case of
unexpected packets causing the daemon to hang, as the UniRPC "applicative"
protocol doesn't know about any of the others high-level protocols such as
"telnet", "ftp", and so on.
A new "unirpcd" parameter = -timeout tt, with "tt" in seconds allows the
UniRPC daemon to handle smoothly this situation.
We recommend the timeout value to be the smallest as your network can
support, because for the duration of the timeout, the UniRPC daemon is
actually hanging, but in a controlled manner, and no more UniRPC
connections can be accepted.
A value of 15 seconds seems generally the largest acceptable value on most
sites, so it could be reduced on purpose.
Note that this parameter exists for UniVerse on Windows platform starting
at release 10.1.23 for releases 10.1.x and 10.2.3 for releases 10.2.x.
The procedure to get it enabled through Windows Services Manager is
documented in the "patchlist" file accessible on :
https://www-927.ibm.com/software/data/u2/support/u2techconnect/downloads/readme/UV-10.1.23.zip
Have to look at "Issue # 9074".
On UNIX platforms, the "-timeout" parameter was altready existing in the
early releases 10.0.x (and UniData 6.0.x), (and it's much easier to have it
enabled at system command line !).
Hope this will help.
P.S: The answer here is one more reason to attend to U2U in IBM Bedfont
Lakes (Feltham) as my manager suggested !...
Regards,
Herve' Balestrieri
> Hi all.
>
> If you do a telnet against any Universe server on port 31438 (I have
tested
> it on Universe 10.0.10 in Windows, Universe 10.0.20 in Linux and Universe
> 10.0.6 in HP-UX), you will have something very similar to a Denial Of
> Service on this port 31438:
> -all previous UVRPC established sessions keep on working without
> problem, but
> -any subsequent tries to start new UVRPC sessions, will timeout with
> "Error returned from connect = 81015".
>
> The problem desappears when the PC client closes the telnet session. (Or
you
> can restart UniVerse or the whole server...)
>
> Could someone tell me if is it a normal behaviour or is it a unirpcd bug?
> Is there any way of detect or avoid this kind of sessions?
> Could it be the same problem that some viruses (like Blaster) causes on
> UVRPC of Universe Servers?
>
> Any help will be apreciated.
>
> Regards,
> __
> Augusto Alonso Alonso
> IT Manager
> Quiter Servicios Informaticos S.L.
> [EMAIL PROTECTED]
> www.quiter.com
> __
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Denial Of Service in UVRPC Universe (shameless plug)
There will be opportunities to meet / greet / brain-pick at U2U of course - IBM Feltham in early October: http://www-306.ibm.com/software/info/u2/university/index.jsp If you have any questions about n-Tier architectures, DMZ's or firewall configuration there will be plenty of chances and some real-world experiences to exchange. Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Denial Of Service in UVRPC Universe
If you are using a Workstation version of Windows as your server there are built in limitations to the number of TCP connections you can make from external IP addresses. I believe the figure is 10 - but someone else may be able to clarify the details. The Windows "Server" editions do not have this limitation. Otherwise: 1. Did you run out of UniVerse licenses? Each session takes a license slot. 2. Are you running with Device Licensing and using incorrect session keys? (> 10 sessions with the same key) 3. Does this only happen if you telnet to 31438 regardless of the number of sessions? The answer to that one is don't telnet - you may be locking the port down by violating the protocol used for sessions. In which case it will wait and wait until it detects a fatal protocol violation and time out (timeout settings are configurable - you can reduce them down). Worth noting there have been at least three major generations of the client and server components since 10.0: 10.1.20+ server and 10.1a/10.1b clients. If you order the LATEST 10.1 you will automatically get the latest clients. 10.2.6 server and 10.2 clients. Whatever the case - upgrading may change this for you and is worthy of a check. The timing on initial handshake may have been tightened up. If not it's always worth asking. I can see why the timeout on an initial handshake failure might be different to an inactivity timeout. Hope this helps if your problem is (3) then the timeout and "don't do it" is probably the best I can offer if using the current generation of client and server components don't change the situation. If a hostile application tried to connect there would be authentication violations and protocol violations everywhere and it should disconnect pretty quickly. I suspect a Telnet just sits there as a "dead keyboard" until a timeout or you key something it objects to. In real life of course you would use firewalls to prevent a Denial of Service attack and you would have a rather pointed talk (at least) to anyone in-house trying to hack your systems with a DoS attack. Your server ports (all of them - not just 31438) would have firewall protection and would only be exposed in a limited fashion on an in-house intranet. If someone gets a virus or tries something detectable by your firewall then they would get shut down pretty quickly. If you are using UniObjects on an Internet connection then I am sure you would be behind an n-Tier architected DMZ so would not be exposed to a DoS attack from the outside. Any PC in-house tries it? Then take appropriate action. *** This is key - no server port in a "green zone" (your data and application residency) should ever be exposed to the "red zone" (potentially hostile users) without going through an "amber zone" (a middle-tier firewall and server). This applies to ALL ports and services - not just those used by UniVerse. To expose any host ports to the red zone is a very large security risk *** Background reading on n-Tier deployment is strongly recommended. Hope this helps Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Augusto Alonso Sent: 19 September 2007 12:42 To: u2-users@listserver.u2ug.org Subject: [U2] Denial Of Service in UVRPC Universe Hi all. If you do a telnet against any Universe server on port 31438 (I have tested it on Universe 10.0.10 in Windows, Universe 10.0.20 in Linux and Universe 10.0.6 in HP-UX), you will have something very similar to a Denial Of Service on this port 31438: -all previous UVRPC established sessions keep on working without problem, but -any subsequent tries to start new UVRPC sessions, will timeout with "Error returned from connect = 81015". The problem desappears when the PC client closes the telnet session. (Or you can restart UniVerse or the whole server...) Could someone tell me if is it a normal behaviour or is it a unirpcd bug? Is there any way of detect or avoid this kind of sessions? Could it be the same problem that some viruses (like Blaster) causes on UVRPC of Universe Servers? Any help will be apreciated. Regards, __ Augusto Alonso Alonso IT Manager Quiter Servicios Informaticos S.L. [EMAIL PROTECTED] www.quiter.com __ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
