Stop and smell the roses!

[GuruLounge]

Okay, I spent an entire weekend and part of Friday (that's right, no movies and beer for me) working on setting up UltraVNC on our servers around the country. By the time I got to the end of it I had set up Version 1.00 RC15 on the servers using Zebedee to encrypt the traffic. Nice and stable (admittedly a bit slow since no hooks are used) but it does the job and allows the employees to log into the servers, access the desktop and sync their files.

This is a much better scenario over the previous regular VNC with FTP on an open connection.

Don't think I don't appreciate what folx do for opensource -- I'm glad stuff like this is created but this is something I simply MUST rant about...

NOW:

When I first discovered UltraVNC I was shocked amazed and soooo happy I could handle all my RAS problems with one program.... Now the fun part:

I went thru every available version and as you can see I eventually settled on RC15 because it didn't break -- well not after I applied a few registry tweaks

For starters I'll say what I did to make 15 work well:

I discovered that it didn't properly save the default settings to the registry (HKLM) but put them in the HKCU section. Apparently it doesn't load these settings when it starts again. So after I saved the settings I wanted I had to go into the registry and copy the user settings (HKCU) to the default (HKLM). I did this by exporting the whole section, editing the first entry, then re-importing it. --- OKay, UVNC loads the settings I want on startup -- great.

NOW (again):

I log in remotely and try to change properties and the server dies. After a bit of futzing around with it I just add the key "AllowProperties" to DEFAULT and set it to DWORD:0. No chance of a user attempting to edit properties and killing the server. Albiet I have to edit properties via the registry but that part is over for now and the properties are fine the way they are.

Now (again):

I discover I get occasional server crashes when I'm using a port other than the default 5900 (actually I was using ports 6000-6005 because that's what was allocated to us by the network admin). I discover that I'm better off using "display" over "port". I haven't checked for stability with displays other than 0 but since I'm using Zebedee to port forward I don't care or have the time.

Now (at last):

One of the things that enticed me to UltraVNC was the DSM plugins. Unfortunately they work for the first connection but not for any following connections. I tried all versions I could find of the plugin (112,114 and 115). Hence I opted for Zebedee to handle encryption. It slows the connection down a bit but the security is worth it. I know DSM is fixed in later versions of UVNC as I've tried them - but filetransfer is broken, and perhaps another item or two that I need.

MY POINT:

In all the subsequent releases of UVNC I tried it seems features where usually added but the previous bugs were not fixed or they were broken again by new features.

It seems like the development team needs a bit of leadership and organization. Just stop and fix what you have. Add the extra features later. That way folx will have a version to use while you're hacking away at the new and improved version of what already works.

Quite frankly I'd be willing to BUY a copy of a program that had the basics of what people are looking for (remote access and file transfer - encryption is a plus). Honestly -- I would only buy one copy and put it on all my servers. I'm not impressed with the "per seat" concept. My point here is if you make a good product people are willing to exchange with you for it. -- Just something to keep in mind here.

UltraVNC is the best version of VNC with filetransfer that I've found. Keep up the good work.

Hope I didn't offend
Lounge

[Guest]

I agree with this need to dedicate time to a release which solves all the little small bugs here and there.

I would even go as far as going back to RC18 (really very stable) and recompiling that as 1.0 to help having a solid release 1. And then continue with the bug search and fix in RC19.

RC19 has seen maybe too many additions all at once,. They are certainly very valuable but the development seems unstoppable, so debugging is not easy to do and the full release gets postponed.

[Rudi De Vos]

Thanks for the detailed report.

The problem with bug fixing is that most people just tell
"It does not work".
From RC18 to know we had more then 25 test releases, possible the registry bug was already in from the beginning.

Spend 20 hours on registry bug fixing. Found a fix, but no cause of the bug. Executing 2 times the same function give
2 different registry locations, "impersonation service stuff".
Open/Close reg keys before actual opening and read seems to fix it....still wondering way?

DSMplugin missed the reset option. Server/viewer/plugin needed to change to fix this issue....3 spots to introduce errors.

Current we are spending a lot of time on bug tracing and getting RC19 stable as fast as possible.

For Future releases we should realy need some dedicated beta testers. Changes need to be test one by one, so at least you know where to look when something goes wrong. To many time is lost by bug tracing....

Rudi

[scovel]

Sorry about the plugin. Before RC19-5/1.1.2 the encryption wasn't really doing a "correct" job. It was very important to fix it, but it required a change to the server (winvnc.exe).

Zebedee. I still use this for Windows-->Linux connections. Turn off all compression done by Zebedee. Let it do the encryption, but let UltraVNC handle the compression. You may notice its much faster that way.

Sean

[GuruLounge]

Thanx for the info on Zebedee. I'll make sure to turn off compression.

Now I just need to find a way to make sure nobody can tunnel through ZBD to port 445 and access the fileshares (like they did recently!!). Yes, I joined the ZBD mailing list awaiting instructions on this scenario.

Currently using UVNC RC19.5 w/patches. Everything seems to work pretty well excluding the Server-to-Viewer File Transfers -- which tends to leave some bytes off the end of the file.

I'd rather see this bug fixed and be happy with a stable new release than drop back to RC15. If the Devs do get this one fixed I'm packing it up and putting it away in my archives

Lounge

[scovel]

Wow! How is that possible? Are you only forwarding port 5900?

Was it an internal user that went though the tunnel, or was it an external hacker?

Do you have authentication on in Zebedee? I think I'll go set up authentication on my tunnel! The endpoint is a Linux box, but better be safe than sorry!

Sean

[GuruLounge]

I'm not sure what happened. Kinda like being at a bar then finding yourself sprawled out in the parking lot the next day.

I know this:

1) I'm a ZBD newbie - first time I even managed to get the tunnels installed and actually working.

2) I had the PC on the DMZ so FTP would work from behind another router.

3) My log shows the trouble didn't start until AFTER I started the ZBD server.

4) I had also assigned a domain name to the server about the same time (this system is on DSL and the IP changes often). I used a DynDNS client to keep the hostname->IP fixed. This allowed for persistant connections from clients.

5) About 4-5 days later I'm just browsing the firewall port status and see multiple connections to port 445 from external WAN sources. About the same time I notice these viruses kept getting dropped in my root directory somehow. "stoner.exe" was one of them - I don't remember the others.


At first I started configuring the software firewall to block access to port 445. It took a while for the status entries to drop off then I realized it wasn't actually blocking access until attempts were made to transfer data. I set up warning messages for port 445 and noticed that as connections were being cut - connection attempts were frantically poping up again.

What really bugged me was that I had configured the router to specifically block incomming and outgoing access on all filesharing ports. This didn't seem to be working. Then I made the biggest discovery of my life -- I didn't realize I had the server on the DMZ for FTP access. When I took it off the DMZ most of the problems went away.


When I did this I noticed that 445 connections were starting to come thru ZBD to Localhost. This is what freaked me out. I thought I had created tunnels only to port 5900 -- and from the looks of it that's what I did. Even so, I still need to set up private keys and make certain that ZBD only uses specific ports and allows only private key connections.

So, I've taken ZBD offline and I'm sittin' waitin' until I get a reply from the ZBD mailing list on how to configure the ZBD server for specific ports only. I'm suspecting "redirect none" might have something to do with it but I thought that would prevent other ports from being accessed.


I'd be happy to get input here as well.

Lounge

[scovel]

I'm no zebedee expert....

The client-side config file is actually pretty open. I guess it has to be to allow multiple viewer connections coming from unknown high ports.

The server side can be pretty specific. You should be able to restrict to host and port. What does your server config look like? In particular the TARGET statements.

Can you tell WHERE (what IP) the 445 connections were coming from?

I also have my firewall restrict zebedee connections to a short list of places I connect from. Not always an option, I know.

Sean

P.S. Feel free to Email me at msrc4plugin at comcast dot net.

[UltraSam]

Thanks for the overall positive feedback

Be sure that we don't implement new stuff anymore until v1 release. We've been spending a lot of time debugging-only since a few weeks. We're hopefully seeing the light at the end of the tunnel.
Still a few details to fix, though, like broken file reception

I don't think we need more project leadership. We are already 2 project managers and we usually agree on the goals and ideas for the project: for now, debug and release the V1 !

If it takes so long it's because we all have a lot of things to work on. Fortunatly, more and more cool and skilled people are joining us.
We're only missing more beta testers.

[GuruLounge]

Well, this tells me this forum isn't slow. And I see a lot of people do contribute.

Lounge