Hi, Jim!

> >> fb_dpb_ip_path <total length> <count byte> <ip address list>
> >>
> >>
> >
> >I implemented this piece in my tree some time ago to support
> Trace API
> >functionality.
> >The difference of implementation is that IPv4 is not the
> only protocol
> >supported by the design.
> >IPv6 address is longer, SSL certificate header is much longer.
> >
> >
> It sounds like more internal structure for a connection
> description is necessary. Could you describe what you
> implemented in more detail?

My implementation of this piece is very simple and sketchy at the
moment. The whole Trace API/plugins thing is not complete yet and will
require piece-by-piece discussion before including it into Firebird.

So speaking in your terms I build the following structure:

isc_dpb_address_path <total length> <count byte> <address list>

<address list> ::= <protocol name length> <protocol name string>
<address length> <address string>

My change of remote server appends a pair of protocol name ('IPv4') and
protocol-specific address ('172.20.1.1') as strings into DPB block so
Trace API hooks can parse it from DPB block and use to their
convenience. No connection description, no anything. Do you want to see
the engine patch? It is pretty much trivial.

Also I can trivially add a couple internal_info nodes to provide access
to this information from DSQL.

> >IPv4 addresses can almost always be forged and in many cases
> cannot be
> >trusted for security purposes.
> >
> >
> Are you sure that's true? The IP address comes from the
> socket information. If it has a forged IP, how can the
> connect get established in the first place?

If you are root on the machine you normally have access to 2 facilities:
1) raw sockets
2) ethernet driver interface

Ethernet driver interface allows to set MAC address and generally craft
Ethernet frames. You can find scripts which turn common switches to hubs
and allow you to listen to desired segment of network even if it is
behind switches. Approach is based in overflow of MAC/port dispatch
table of switch. Cheap switches become hubs in this case.

Raw sockets allow to craft custom IP packets. You can put whatever
source and destination address you like in them. You set header flags
whatever you need.
And this packet gets delivered to its destination if routing rules on
the path from sender do not preclude opposite. Nmap is the convenient
utility for exploration phase of cracking attempt, you can look at it to
see what you can do with raw sockets.

So the challenging part is to receive replies to maintain the TCP/IP
protocol. But if you compromise one of the boxes in the same ethernet
segment where box you need to get access resides (or where sender you
trying to forge resides) you can use ethernet tricks (promisc mode,
forged MAC if needed) and get replies.

So see, neither sender nor destination box is cracked, but IP is forged
and given the ease you can compromose Windows machines it is a viable
approach.
Also you may try to compromise one of the hosts in between transmission
and forge address there.

My knowledge is somewhat outdated regarding network cracking techniques,
but in general, sender IP is usually not considered a very useful sender
identify for internet security purposes.

> >Repeating structure in mentioned block (isc_dpb_address_path) is
> >consisted of protocol identifier, address block length and address
> >block containing protocol-specific address in human-readable form
> >suitable for matching.
> >
> >
> I'm wary about "human readable form". The binary API is for
> the convenience and simplicity of the implementations. I'd
> rather the underlaying implementation be aware of the
> differences between IPv4 and
> IPv6 and behave accordingly than to obscure the semantics for
> pattern matching. Pattern matching, to my taste, favors one
> form of usage at the expense of others. And in most cases,
> it's much easier to turn a canonical representation to human
> readable form than to turn human readable stuff into a
> canonical representation. But lets see what you have.

I do not have strong opinion about it at the moment. My current
implementation is the simpliest thing possible to do the job.

> Jim Starkey

Nickolay