Posted by rodenjh
Tue, 23 Jun 2009 10:29:00 GMT
The desire to work at home can become a necessity, as currently discussed
reaction plans for the event of a serious influenza pandemic have shown. To
guaranty business continuity for the successful operation of external workplaces,
enterprises should deploy highly performant remote access solutions before
a crisis strikes.
The discussion of how enterprises can maintain business continuity in the event of an influenza pandemic is not new: Already in August 2007, the Swiss pharmaceutical giant Roche announced that their emergency business plan also foresees the need for employees to have secure remote access to the company's IT system, in order to ensure business operations continuity and protect the employees from exposure to health risks. "The most important service that we have defined is the remote access of our employees to the computer systems," said Jennifer Allerton, CIO of Roche Pharma.
However, a study carried out by the corporate consulting firm Mercer in 2007 showed that only 47 percent of major corporations had created an emergency plan and only 17 percent had planned a budget for pandemic contingency planning.
Even if the home country of an enterprise is not directly affected, problems may nonetheless arise, as was demonstrated this May in Hong Kong: Hundreds of travelers and hotel guests were placed under quarantine by the Chinese health authorities, as it was feared they may have come into contact with just one Mexican visitor who had tested positive for the swine flue virus.
Securing Business Continuity from Outside
Whereas one usually thought of business continuity assurance in terms of secure computer centers and databases, backups and restart times, when one considers the possibility of employees being unavailable, the topic gets a new dimension: In such a case, the enterprise must follow two goals:
The Solution: Secure Remote Access
Corporations that want to ensure smooth business continuity even in such times of crisis when only a skeleton staff may be available on location, require a readily available, performant and easy-to-use secure remote access solution. That this also increases the attractiveness of the workplace and thus the entire enterprise, is a welcome side effect. In many cases, the use of home offices or the use of freelancers can also lead to cost reductions.
The First Step: Needs Assessment
The first basic question in a remote access project is whether this access, and thus the ability to work at home, should be set up only for use in the event of a crisis or whether it should be implemented as part of standard business procedure.
When this has been decided, it must be decided which employees or home office workplaces are to be equipped with secure remote access. Depending on the employee's duties, the type and range of secure remote access is to be determined: From access to only their own desktop to comprehensive secure remote access to the entire enterprise network.
Finally there is the question of which technology to use. Decisive factors here are , availability, performance, cost and, of course, security. The Internet can make workstation PC's and systems available from all over the world, but this brings with it security risks.
Which Access for What Purpose?
The technical prerequisites for remote access from and to home offices are already available almost anywhere: Just about everyone has a PC or laptop and uses an economical DSL connection. Laptops and PDA's can be used during business trips and, in an emergency, one can read one's e-mail from an Internet Café or a PC in the hotel lobby.
HOB provides two proven solutions for secure remote access: HOB RD VPN, which uses the SSL protocol for encryption, and HOBLink VPN, which is an IPSec-based VPN.
Secure End-to-End Connection via SSL:
HOB RD VPN
In the opinion of IT experts, the SSL protocol is increasingly being deployed
for secure remote access solutions. HOB RD VPN uses SSL encryption to protect
its End-to-End connections tot the application level, which works in every
environment and in only a very few cases is blocked.
With HOB RD VPN, there is no need to install any HOB software on the client
side, neither are special drivers nor administrator rights needed; the client
machine only needs a Java-capable browser.
In addition to secure remote access to an Intranet, Web applications and file
servers, HOB RD VPN also has powerful Java clients for Windows Terminal Servers
and legacy host applications, which also require no installation on either the
client or target machine. HOB RD VPN can also provide full network access with
the HOB PPP Tunnel component. With this, the user can get secure remote access
to any network resource for which he or she is authorized.
Full Network Access Over IPSec:
HOBLink VPN
For secure remote access over IPSec, HOB has the product HOBLink VPN, which,
using its "Silent Installation" feature is easy to centrally implement and
administrate. Hereby the enterprise-wide rollout is carried out via a client CD,
which when started automatically installs all of the features, rules and ad-ons.
After entering user name and password, the user can logon to the enterprise
network and, depending on the authorization given, directly access his or her
applications and data.
HOB GmbH & Co. KG
Marketing/Public Relations
Petra
Körwer
Schwadermühlstraße 3
90556 Cadolzburg
Tel. 09103/715-284
Fax 09103/715-271
E-Mail:
marketing@hob.de
Posted in Performance tests | Tags Business, Contingency, Continuity, Pandemic, Plans | no comments | no trackbacks
Posted by Dietmar Schmidt
Mon, 09 Mar 2009 14:51:00 GMT
Before we put a new file server into production, we make a few
benchmarks for the CIFS and NFS performance. The new server was a
Solaris box with huge ZFS volumes. On the Solaris server an NFS
server and Samba (for CIFS) are running out of the box. Samba was
configured to use our MS Active Directory for Authentication.
As benchmarks we use the following:
A program that reads files of different sizes (5GB, 100MB, 10MB
1MB) from the server share.
Different copy jobs with a 5GB file and 1GB folders with
different file sizes.
If you are interested in the detailed environment, benchmark
description, values and charts you can download this pdf .
For all the benchmarks we measure the time for completion and
calculate the transfer rates.
To omit compression of the used
protocols we used files created with /dev/urandom.
We expected nearly the same values for reading a file and copying
to a local drive, since both tests do the same (copy additionally
writes to a local disk and might therefore be slower).
Reading from a server share is the most common task done in the
real world, so this performance has more effect in real environments.
The CIFS and NFS shares are in
the same shared folder on the server.
We discovered that NFS was very fast, but CIFS was very slow.
Especially when we read from the server or copied from the server.
With NFS we read a 5 GB file with over 80 MB/s (about one minute),
the same file has only 7 MB/s (about 12 minutes) with CIFS! All the
different copy jobs from the server share to the local drive are
under 10MB/s for CIFS; for NFS we are never under 40MB/s.
For the copy the files to the server jobs, NFS was also always
faster than CIFS, but only by about 10 MB/s. So sending files to the
server with CIFS has no such bad performance.
We were very surprised about the bad values for CIFS. To verify
the results, we decided to measure another system. A Windows Server
2008 with a faster CPU and a fast storage system. The results were in
the range of the Solaris NFS System. When copying to the server
share, the Windows system is always faster than the Solaris system.
So CIFS is not slow, but our Solaris system is slow; maybe Samba
is the problem?
To verify this we used a slower Linux box with Samba and NFS. On
the Linux server we have also nearly 80 MB/s for NFS for the 5 GB
file. If we use smaller files the transfer-rates are slower compared
to our Solaris NFS server. As expected, asynchronous NFS was a bit
faster than synchronous NFS. For the CIFS share we measured 37 MB/s.
For the most benchmarks CIFS and NFS have comparable results. With
some benchmarks CIFS wins, with others, NFS.
As expected Samba is not slow at all.
Back to our Solaris system, we discussed the next steps to find
out why we measure such bad values for CIFS. First we tried some
performance parameters in the Samba configuration. This gave us
minimally better results. This made us think, maybe our Active
Directory authentication is the problem, so we decided to use local
authentication for Samba. This gave us marginally better results.
After asking a Linux specialist in our IT Department to take a look
at this, he found the problem (high log level for Samba) and solved
it. Now Samba on the Solaris box is comparable to the Windows 2008
Server. As our tests are now finished, we can say the winner is NFS:
If you are reading from a server share, the results are slightly
better than for CIFS. When writing to a server share, CIFS is clearly
faster for all writing benchmarks.
If you are interested in the results with charts, please download
this pdf .
Posted in Performance tests | Tags CIFS, NFS, SMB | no comments
Posted by Documentation
Fri, 12 Sep 2008 14:41:00 GMT
HOB RD VPN is a remote access solution based on SSL. The SSL part is quite old, it was first developed for the 3270 data stream to securely access IBM mainframes. Later it was extended to support RDP, then HTTPS for the HOB Web Server Gate and, finally, for tunneling of PPP. The SSL part of HOB RD VPN also has the product name HOBLink Secure. We believe when HOB started the development of its SSL solution, the popular OpenSSL was not yet available.
So over time there was the question at HOB: Should we support SSL Accelerator Cards?
First I have to mention that we at HOB work with the latest servers from leading vendors. We always buy the models with the highest clock speed. The HOB development people should not waste their time working (meaning compiling and debugging) on slow machines.
We acquired some SSL Accelerator Cards as test equipment and got them working. These cards were connected to the PCI bus of an x86 system.
But the results of tests we made were quite disappointing: When calculating the asymmetric RSA key, the SSL Accelerator Cards gave some advantage over the solution in pure software. But the symmetric encryption algorithms, mainly the currently most widely used AES algorithm, did not give an advantage over the software solution. Also, one or more cards were even slower compared to the pure software solution.
The asymmetric RSA key is calculated only once, at session start. The key found may also be re-used between two partners having one or multiple SSL connections between them. So processing of symmetric encryption is far more important compared to the calculation of the asymmetric RSA key.
We believe the reason for not getting more speed out of the SSL Accelerator Cards is the following: The CPU, when an SSL Accelerator Card is used, still has something to do: it has to send all the data down the bus, then the card will process, and afterwards the data is sent over the bus again. Whether there are cards which directly access the main memory is something I don't know.
The HOB SSL suite contains all major encryption algorithms including AES with a 256-bit key length. The HOB SSL also contains, as an option, compression. Netscape defined the original SSL protocol, and in the handshake they already put in parameters for compression. So HOB included compression, but we do not know of any other vendor who included compression as well. Tests have shown, for compression there are about as many CPU resources used as compared to symmetric encryption. But the SSL Accelerator Cards do not include compression.
We have seen hardware that does compression. But, when comparing the compression ratio with software solutions, the hardware compression does not compare well. The reason for that is, that in compression algorithms there is some fine-tuning possible in software. Doing the same in hardware would be too complicated. So we found out compression should be done in software as well.
At HOB, we have successfully tested the WebSecureProxy, the SSL gateway, with 10,000 simultaneous sessions; both on Windows and Linux, and using an x86 CPU on mid-size servers. No SSL Accelerator Card was necessary to reach 10,000 simultaneous SSL sessions. Each of the sessions was run with simulated RDP traffic where the user neither permanently sends nor permanently receives data from the server.
We believe, on big machines, even more than 10,000 simultaneous sessions are possible - without an SSL Accelerator Card. And HOB RD VPN supports clustering as well.
The HOB WebSecureProxy was designed with heavy loads in mind, and it can keep any number of CPUs busy without giving delay to the users.
The HOB SSL encryption routines have been examined by the BSI, the German Bundesamt für Sicherheit in der Informationstechnik. The HOB SSL encryption routines got certified under Common Criteria. In the course of this certification, HOB made a large number of compatibility tests with other SSL solutions.
If the HOB customers would use SSL Accelerator Cards, there would be extra cost for the cards. Also, as hardware can break, our customers would need spare parts.
With the HOB solution, especially with the Unix-based OpenSource operating system HOB SCS, when there is a hardware problem you go to the nearest PC dealer, get a server out of the box, install the software and the problem is fixed.
I believe today we get a lot of processing power out of modern CPUs. These CPUs have many cores today. So spending money for fast CPUs is better compared to spending money for SSL Accelerator Cards.
12.09.08 Klaus Brandstätter
Posted in HOB | no comments
Posted by Documentation
Fri, 12 Sep 2008 13:47:00 GMT
How many servers will we need for a certain application?
This document provides some insight into the servers necessary for WTS (Windows Terminal Services) or VDI (Virtual Desktop Infrastructure).
In the old days, companies had just a single mainframe and certain applications running on it. As CPU load generally is the primary bottleneck, the people responsible for the mainframe just looked at the CPU utilization and, when it was over 80%, they knew they had to buy a bigger one. When paging was too high they had to buy more memory.
Today we can run applications in many ways, and these ways all have different needs for computing power and memory.
First we look at desktops. As Windows Vista has been available since early 2007, most users found out running Windows Vista with less than one gigabyte of memory is quite slow.
When we have desktops, these should share their data. This is typically done over a file server. I have heard people say a modern server can handle 5,000 simultaneous users when this server is used as a file server.
How about Terminal Services? At the moment of this writing, most terminal servers are used by around 50 users. 32-Bit operating systems are mostly used; the problem with 64-Bit operating systems (Windows) is that not all drivers are available in 64-Bit versions. As companies have more users, load-balancing is used to connect all the users to multiple servers.
But Windows Server 2003 and Windows Server 2008 can handle many more concurrent users. In the paper on
http://www.microsoft.com/windowsserver2003/techinfo/overview/tsscaling.mspx
Microsoft says they have tested several hundred users on hardware dated 2003. As today we have more advanced hardware with fast CPUs, many cores and lots of cheap memory, I believe running terminal servers with hundreds of users is no problem. Of course, 64-bit hardware and software is needed in this case.
But some key points should be kept in mind: Windows, as well as other modern operating systems, does paging as a default configuration. Paging means, memory not frequently used is written to the page files on disk, so less memory is needed. What happens if a machine has enough memory so that no paging is needed? As Windows always tries to have some memory space available for when new applications are started, it still writes pages to disk and frees the internal memory as it is not needed. The problem today is that the gap between CPU speed, memory speed and disk speed always widens. And as we have more memory, the page file on disk gets bigger and it takes even longer to read in the requested memory pages when needed.
We have a big WTS in use for our developers, running MS Visual Studio and Eclipse. Our WTS is sometimes up for many months and users do not log off. In the evening they disconnect their RDP session. When they come in the next morning they start their RDP client and can continue to work where they left off the day before. Our users find that straight-forward. When we had paging enabled, and when applications had not been used for maybe several days, the users clicked on the icon in the task bar and had to wait maybe 10 minutes until the application was paged in and the users could work again. Sometimes the application did not show up any more, even after hours. All these problems disappeared when we turned off paging in the Windows operating system. Without paging, our system always immediately responds to every action users make. It's a great system!
I can give the following advice: Buy so much memory for your servers that paging can be disabled. Memory is cheap and will get even cheaper. Disable paging by configuring Windows accordingly.
As you have no more paging, you do not need fast disks any longer. It is sufficient to buy big, cheap SATA disk drives instead of buying the faster but smaller and more expensive SCSI disks.
Let us talk about VDI or desktop virtualization. Using VDI means you have servers running virtualized single-user operating systems such as Windows XP or Windows Vista.
When VDI is used, multiple copies of the (guest) operating system are simultaneously in memory, so much more memory is needed. Remember that you should not have less than one gigabyte for every Windows Vista. And remember you should have paging turned off. When running VDI, I recommend you disable paging on the host level, but paging on the guest level will still be needed (otherwise you would need just too much memory). If you have a Windows Vista system and give it only one gigabyte of memory without paging, you will not be able to start many applications.
So when we have a server with 16 gigabytes of memory, we can only have around 16 simultaneous Windows Vista guests running.
So, compared to WTS, VDI needs much more hardware resources. However, there are still occasions where VDI is more suitable than WTS. And hardware keeps getting more powerful and cheaper, so VDI, in some cases, becomes more attractive.
13.08.08 Klaus Brandstätter
no comments
Posted by Documentation
Fri, 12 Sep 2008 13:38:00 GMT
Recently I was surfing the Web and found something about my company, HOB, at Wikipedia. In the German Wikipedia I found something about 3270 which I believe does not cover the technical background. And also, I think there is something wrong: The article says Attachmate produced 3270 terminals in the past. I remember Attachmate produced 3270 coax cards, but never real terminals.
My name is Klaus Brandstaetter, I was born in 1954, and since 1981 I am CEO of HOB Germany, which was deeply involved in the 3270 market.
As I know much about 3270 I decided to write something about 3270. As 3270 was a billion dollar market in the 70's and 80's, and 3270 is still in use today, there is much to say. I will concentrate on the important facts only, but still this will be a big article.
IBM with the /370 mainframe system was the dominant IT company in the 70's and 80's. At IBM, each product they sold had a four digit number, so the terminal they developed for the /370 mainframe got the number 3277. The first display had a very small screen displaying only 12 rows with 40 characters. The terminal had a white cabinet made from sheet metal. This was called Model one, and there was also the Model two which had the same cabinet but a bigger screen of 15 inches displaying 24 rows with 80 characters each. The characters were displayed in green on black background. Some say WYSIWYG, in the case of 3270, stands for "What You See is what IBM Gave You." Each 3277 terminal was connected over a coaxial cable to a control unit. The transmission speed of this coaxial cable was at first something around one megabit per second. Later, with the next generation, 2.3 megabits per second were achieved. A terminal did have some logic, but no CPU; each terminal, of course, had a screen buffer (memory) where the characters to be displayed were stored.
If each terminal would have been connected to the mainframe directly, each keystroke would have generated an interrupt on the mainframe. At that time, there was only limited computer power, so it was not possible to process a lot of interrupts in a given time. So IBM chose to connect each terminal to a so-called control-unit. The IBM part number of the first control unit was 3272, later 3274 and 3174 followed. The first control units had a CPU, but as memory was very expensive the CPU used the screen buffer of the terminals as memory. Commands which access the memory on the terminals were exchanged over the coaxial cable between control unit and terminal. The terminals that worked that way were also called CUT, Control Unit Terminal. Each control unit could handle up to 32 terminals, later a control unit could handle up to 128 terminals. The control unit was connected to the mainframe (channel) with a so-called Bus/Tag cable. This cable had eight parallel wires for the data and another eight parallel wires for the /370 channel command. A control-unit could also be used remotely: typically used were fullduplex lines with a bandwidth of 9,600 bits per second. Can you imagine 32 users today working over a single telecommunications line with just 9,600 Bits per second? But in the 80's this was common and the users did not complain. It is also worth mentioning that 3270 terminals, especially the 3277 one, could also be connected to an IBM /3 computer, which was less powerful that the /370 mainframe. The IBM /3 was the ancestor of what later would become the /34, /38, /36, for a long time AS/400 and what is now called the i-Series. With the IBM /3 computers, 3277 terminals were used with coaxial cable, but the successors got 5250 terminals with a more sophisticated protocol, connected over twinax cable, which is also called twisted pair.
For the 3270 terminal to work, the software in the mainframe had to use the 3270 protocol. Typically in the 3270 protocol the EBCDIC character set was used. A terminal could display up to 192 different characters, the remaining byte encodings were orders and attributes. The application in the mainframe sent either a complete screen or a part of it, mixed with orders. Such orders included setting the cursor, moving to other locations on the screen and orders to fill in attributes.
Such attributes separated the screen into different fields, a part of them editable by the user, others were protected. When the mainframe application sent data to the screen, the user could edit the page displayed and navigate around on the screen. At all this was independent of the host, the mainframe. When all the page editing was done, the user had to press special keys, either Enter, PFx (Program Function) or PAx (Program Attention), and only then was all edited text sent to the mainframe, to the receiving application.
In this way, computers with, compared to today, relatively small computer power could handle the traffic of many terminals, in some installations thousands or even tens of thousands.
This type of processing is similar to what we got with HTML / WEB 1.0, and is called transactional processing.
When we look back at the history of 3270, the first generation of terminals was 3277, 3275 and 3272 as control unit. After that, the next generation consisted of the terminals 3278, 3276 and 3274 as control unit. With the 3278 there was the model 2, displaying 24 x 80 characters. Additional new models were added: model 3 with 32 x 80 characters, model 4 with 43 x 80 characters and model 5 with 27 x 132 characters. Model 5 displaying 132 characters in a line was useful to view print output, since printers at that time usually printed lines 132 characters wide. All models had an additional line to display status information. All terminals had the capability to switch to the model 2 mode, displaying only 24 x 80 characters.
There followed the color terminal 3279, which could display the characters in up to seven different colors. A special and very expensive terminal, the 3279G, could also handle graphics. Graphics were built by loading special characters with pixels in the desired colors and then addressing these characters in the data stream sent to the terminal. It should also be mentioned that as a base functionality, most of the IBM terminals had an additional, built-in character set called APL characters. APL characters also could be entered from the keyboard. APL stands for A Programming Language, and APL characters were made from the Greek Alphabet.
Besides the graphics addressable through loaded characters, IBM later added vector graphics.
In the 3270 family of terminals, IBM had many different models, for example 3277, 3278, 3178, 3180, 3179, and so on. The different generations of control units were called 3272, 3274 and at last 3174. There were also terminals with a small control unit built-in, like 3275 and 3276. Many different printers were sold, some of them with the number 3286 or 3287. The printers were connected to the control unit over coaxial cable just as the terminals. For the software, IBM tried to have printers that were programmed similarly to a terminal, sending more than one line to the printer in a chunk of the data stream.
IBM sold millions of the 3270 terminals, mainly from the 3278 model and later models. But there was also competition from other manufacturers, such as Memorex, Telex, HOB, Lee Data, Ericson, Nokia, MDS, ADI and Fujitsu. Memorex and Telex later merged into one company. Altogether there were about 15 different vendors producing 3270 terminals. Most just copied IBM's models, some had unique add-ons. Only HOB succeeded in manufacturing a 3270-compatible terminal with graphics support. Some of the vendors also built their own control unit and used a different cabling schema. The company McData was very successful building 3270-type control units.
The market for 3270 terminals was lucrative until the middle of the 90's. By this time standard PCs had already taken over the business with hardware and software emulating 3270 terminals.
Look at this market now: IBM sold the first IBM PC in August 1981 after just 9 months of development time. IBM then, for a certain time, dominated the PC market. Soon after IBM brought out the first PC, the company IDEA developed and sold a so-called Irma coax card, fitting into the IBM PC with the standard bus. This also included software running in MS DOS. Hardware and software both connected to an IBM (or compatible) control unit, and the user could do what he normally would have done with a hardware terminal. This solution also included file-transfer in both directions between the IBM mainframe and the PC.
After that, IBM also developed such a coax card, and other manufacturers did the same. The emulation software from IBM was called Personal Communications or in short, PersCom. Let us name some of the other manufacturers and their products:
Attachemate with Extra!
Wall Data with Rumba
WRQ with Reflection
HOB with HOBLink 3270, later HOBLink Terminal Edition
At the end of the 90's, 3270 emulation was a big market and about one hundred companies had developed such software.
There also are 3270 emulations written in Java, HoD = Host-on-Demand from IBM or HOBLink J-Term (Java Terminal).
Software in use where the 3270 client is connected to: IMS Information Management System CICS Customer Information and Control System TSO Time Sharing Option and many others.
Software that generates 3270 data stream with graphics includes IBM GDDM (Graphical Data Display Manager) and software from SAS.
In the beginning, the 3270 data stream was sent over simple protocols such as channel-attached or a family of protocols called BSC (binary synchronous communication). Around 1970, IBM invented VTAM and SNA, System Network Architecture. SNA dominated the network protocols in use for a long time. Nowadays SNA is only used inside of the IBM mainframes, all real network connections are done over TCP/IP. For 3270 emulations this protocol (a type of telnet) is called TN3270 or TN3270E, defined in several RFCs.
Prominent people of the IT industry had made bets that the last mainframe would be switched off December 31st, 1999. As we know, this did not happen, and mainframes are still in use by many big organizations. And the 3270 protocol is also still in use.
Some time after the year 2000, an IBM marketing campaign was saying that every day there are still more 3270 transactions than there are transactions over the World-Wide-Web.
12.08.08 Klaus Brandstätter
no comments
Posted by hob
Mon, 12 Nov 2007 13:10:00 GMT
The HOB WebSecureProxy is the security gateway for many organizations. It is used to access internal applications over the Internet.
The HOB WebSecureProxy is configured through one (and only one) XML configuration file. XML has the advantage that it is human readable. It is the proven way to simply exchange information between the administrator and the machine (computer).
There is a Java based configuration tool which is used to enter the necessary information.
But this XML configuration file can also be edited with every common text-based editor.
The XML configuration file can be viewed with Web Browsers and their built-in XML functionality, the hierarchy of the definitions can be seen.
We all know that sometimes administrators call all users of certain services and tell them they have to leave the application at a certain time because the configuration is going to be updated then and the application will have to be restarted.
The HOB WebSecureProxy can dynamically update its configuration by reading a new version of the XML configuration file.
This means, users that have logged on before the configuration update keep their old configuration until they log off.
Users who log on after the configuration update automatically get the new parameters.
The service is not interrupted.
The problem of users having a part of their configuration parameters from the old configuration, and the other part of their configuration comes from the new configuration does not exist.
Which techniques are used to enable this scenario?
In Windows the WebSecureProxy is the program IBIPGW08.
IBIPGW08 automatically gets notified when the XML configuration on disk (that was used when IBIPGW08 was started) is changed and then reads in the new parameters.
In Unix and Linux the WebSecureProxy is the program NBIPGW08.
When the XML configuration has been changed, the administrator can start a new instance of NBIFGW08.
The new instance of NBIPGW08 notifies the already running old NBIPGW08; the already running old NBIPGW08 closes its sockets which listen for incoming new connections.
Now the newly started NBIPGW08 can listen on the same ports again and users who log on from now on automatically get connected to the newly started NBIPGW08.
The already running old NBIPGW08 automatically exits when all users have logged off.
Security Risk of Applications Listening on Well-Known Ports
In Unix and Linux only applications running at superuser level can open the well-known ports.
The HOB WebSecureProxy normally listens on HTTPS port 443; this port is one of the well-known ports.
But for security reasons it is less critical when the WebSecureProxy NBIPGW08 runs on a normal user account.
To solve this problem, HOB has developed the listen-gateway NBIPGW12.
The listen-gateway NBIPGW12 is a small application which should run on superuser level and can then open the well-known ports.
The listen-gateway NBIPGW12 needs only little configuration, this can be given in the command line when NBIPGW12 is started.
The HOB WebSecureProxy NBIPGW08 now runs on a normal user account and creates a Unix Pipe (FIFO) to NBIPGW12.
NBIPGW08 over the FIFO sends encrypted commands to the listen-gateway NBIPGW12, such as open a port for listen.
The listen-gateway NBIPGW12 then opens said port for listen and forwards all incoming connection requests to NBIPGW08 over the FIFO.
In this way, NBIPGW08 does not need to run as superuser and still can open well-known ports.
no comments
Posted by hob
Mon, 10 Sep 2007 12:28:00 GMT
1. The Problem
On the serial ports of PCs, asynchronous communication is mostly used. This means, every piece of information, which is normally one byte with 7 or 8 bits of information, is sent individually. There are start-bits at the beginning of each character and there are stop-bits at the end of each character.
Information sent mostly contains multiple characters, forming a block.
The problem now is, that neither the hardware nor the software driver can know how many characters form such a block.
We discuss here how applications handle this type of traffic.
2. Applications We Have Seen
We have seen applications of other vendors and how they work. The have a buffer of a certain length, for example two kilobytes. They set a very short timeout and receive data in a
loop.
In Windows, ReadFile() is done, giving the buffer and its entire length.
The ReadFile() returns when either the entire buffer has been filled by the driver or when the timeout has elapsed.
Now in the loop, there is mostly no data received, and the ReadFile() returns after the short timeout saying it has received nothing.
So these applications constantly give a certain load to the machine they are running on. Another disadvantage of this technique is, that there is also a delay before the application gets the data that have been received, because the buffer normally does not get filled; there are just some bytes received.
This delay is theoretically half of the time of the timeout set.
3. HOB Approach for Receiving Data with the Serial Interface
In the HOB approach, the serial interface is set for no timeout, or a very long timeout. When data is received by the application, ReadFile() is started, giving a buffer of one byte length. Then the ReadFile() operation returns each and every time a single character has been received, and only then.
During times when no data is received over the serial line, this application does not consume any CPU cycles.
When data are received, CPU load is higher, since there is a context switch for every byte received.
When data are received, they can be immediately processed by the application without any delay.
no comments
Posted by hob
Mon, 10 Sep 2007 12:20:00 GMT
Today, many SSL-VPNs are used to access Webservers which are internal to a certain network, for example an enterprise or an organization.
In this way, the access is secure and authentication can be used.
When SSL-VPNs are used to access a Webserver, the HTTP datastream containing HTML, JavaScript, XML for Ajax, CSS or flash input data goes thru the SSL-VPN.
As the Webbrowser has to access the SSL-VPN over its TCP connections, and not the Webservers directly, the SSL-VPN checks the datastream and replaces links (URLs) by links to the SSL-VPN.
This is necessary, since normally the Webservers access directly from browsers in the internal network, and so the links in the Webpages point to the internal Webservers.
Now, as regards finding the links in the HTTP datastream, this is quite complicated, since links can be at different locations. There are also solutions where the link is dynamically built by the Webbrowser. This could be done, for example, by a JavaScript program. Also the JavaScript program could dynamically generate HTML pages containing additional links.
The JavaScript program runs in the browser on the client, and it may use variables which are only known to the browser, not to the SSL-VPN.
You can think of solutions where the SSL-VPN cannot find the link, and so is not able to replace the URL. This means, that these Webpages cannot be distributed over SSL-VPNs.
As this problem exists, what would be a possible solution to this problem?
A possible solution to this problem would be, that a so-called HOOK in the browser can be populated by a JavaScript function. The browser would send any URL, to which it wants to connect, over this HOOK. This HOOK could now check the URL, modify the URL if desired, or give a message-text preventing the browser from connecting to this URL but display the message-text to the user instead.
Of course, this HOOK, written in JavaScript, comes from a Webpage downloaded from the Webserver - or the SSL-VPN which sends this HOOK before sending the original Webpages from the Webserver.
These HOOKs may be nested, which would mean the browser calls several HOOKs one after the other until finally the browser uses the URL to connect to the server.
When HOOKs are nested, the one giving first should be the one which is processed as the last stage before the browser acctually makes the TCP connection.
When a JavaScript program registers a HOOK, it should get a handle in return. This handle would be needed if any JavaScript program wants to remove this instance of the HOOK later.
Modern browsers connect to a single Webserver with multiple TCP connections. There are also browsers which have tabs; each tab shows a single Webpage (made from multiple TCP connections) to the user.
So when a HOOK is set, this should be used for all TCP connections for a single browser tab.
The HOOK, which is programmed in JavaScript, has to be called by all TCP connections from the browser, i.e., from Java programs or Flash animation.
If this functionality is built into all Webbrowsers, SSL-VPNs can correctly distribute all Webpages, and SSL-VPNs would be less complicated compared to what they have to be today.
no comments | no trackbacks
