> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > Sent: Friday, May 27, 2005 10:56 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Uniobjects hack > > > The ability to bypass application security using UniObjects has really got > me thinking. In the absence of any suitable remedies and perhaps as a > stop gap solution whilst a better solution is written, I would recommend > the following: > > 1. As Martin said, make sure that you do not let UniObjects traffic > through your firewall. This cuts down the threat from outside but many > hacks come from employees who are disgruntled or just plain nosey. > > 2. If you don't require UniObjects on all PCs then don't install it. If > you do require it, don't install the documentation that gives the user a > sample application to copy. Change the standard port used by UniObjects > and don't advertise it. >
You can still sniff out open ports easily. Your best bet is to map port access by IP class range and exclude departments that don't need access. Of course, if the network is all over the place then you'll need to specify filtering by IP. > 3. Consider an architecture where the UniObjects client is a separate > server (e.g. web server or Citrix server) and users don't require the > UniObjects DLLs on their own client. This is also easier to maintain when > you upgrade. > DMZ setup is still a big part of the equation if you use a remote machine to host a connectivity portal. The only problem there is traceability, if someone where to hack into that box and gain root/admin privs. The same can be said for any box on the LAN, except you won't be looking for oddball IP-based activity if it's all coming from one machine. :P > 4. In addition to application security, make use of OS security. For > example, if your HR system is only used by a handful of people, don't give > all your users access to the data files and rely on the application > security to keep them away. If they have to steal a password as well as > write a VBA program, it is harder than just writing a VBA program. > > 5. Don't hard code usernames and passwords into your source code! They > can be seen in the object code of any application. You can concatenate raw characters together to form a username or password, and you won't be able to easily pull the object code up in hexedit and look for stored strings. You can also use an internal character shifting algorithm to make it harder to dechiper what's what in the object code. > > 6. Keep an eye on logs and look out for unusual behaviour. Can anyone > help me with this? What logs are written to when someone logs in and can > you distinguish between a telnet login and a UniObjects login? > If you are firewalling the box, then you should be able to log incoming traffic regardless of destination port. If not, then setup a firewall router that can log and report activity. A 586 with 32MB of RAM will run a Linux firewall just fine. Glen http://mvdevcentral.com ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
