Next: Interaction with the base
Up: The ProtoWrap wrapper implementation
Previous: Database of study
  Contents
Basic architecture
In order to allow us to grow to a potentially complex system of wrappers, we
need the basic ProtoWrap wrapper to be easily extendable, have an interface
as simple as possible to understand, deal with and extend, and only to implement
the most basic rules upon which all other rules will be based.
The base ProtoWrap wrapper is implemented as an object class, so that future,
protocol-specific derived classes will be able to override its behavior, specifically
the rule matching section.
Our base wrapper, thus, will be called with the following object properties:
- standalone defines whether the wrapper will act as a standalone daemon
or will be called from the inetd daemon.
- listenPort holds the port number on which we will wait for an incoming
connection. Of course, if it is not in standalone mode, this property will not
be accepted, because when inetd calls a program to handle a request, the socket
is already bound with stdin/stdout.
- destType indicates the type of connection to be opened to the server,
whether it will be an IP connection or a pipe to another program residing on
the same system.
- destAddr has the IP address to the host providing the real service.
This can, of course, be the same host that is providing the wrapper. Care must
be taken, however, not to allow outside hosts to get to the wrapped port. For
an example on how to prevent this, please check the configuration presented
in chapter 4. It will only be accepted if destType
is set to IP.
- destPort holds the port number for the real service. This property,
together with destAddr, defines the exact connection that will be initiated
when an incoming connection arrives. It will only be accepted if destType
is set to IP.
- pipeCmd indicates the command to pipe communication to . It will only
be accepted if destType is set to pipe.
- maxLineLength is the most basic check that can be used for any given
line sent from the client to the server. This is a check that will be almost
always done in order to prevent buffer overflows, so it is directly integrated
in the base class. If maximum line length checking is not desired, this property
should be set to zero.
- logLevel indicates the logging detail desired.
- testLine references the function that will test each line recieved
from the client. If undefined, a default testLine function is provided
by the base ProtoWrap, checking only for maxLineLength.
- testReply indicates whether the data recieved from the server should
be checked or only the data generated at the client.
Keep in mind that, unless testReply is set to bidirectional checking,
all the tests will be applied only to the data coming from the client to the
server. The server will be allowed to send back to the client any data it wishes.
The wrapper is not meant to be a traffic validator, only a helper for the server's
security. testReply is provided for the cases where special states
should be monitored at the wrapper and for the rare cases in which a response
should be modified before getting to the client.
Next: Interaction with the base
Up: The ProtoWrap wrapper implementation
Previous: Database of study
  Contents
Gunnar Wolf
2001-03-12