Subject Re: [ib-support] final: Where I find a really good security specific IB/FB group?
Author Artur Anjos
You will have some docs and utilities to help you on this journey:

> 1) (...) I'll test a tunneling software (...)
If you will try ZeBeDee, I already made a document to explain the basic
installation. I have send this to Pavel & Paul, so it will be in IBPhoenix &
firebirdsql in a few days. If you are going to install your application on
the workstations, and the Firebird client, you will notice that it's very
easy to install ZeBeDee in a go.

Also you can try iboconsvc utility to track IP's. I don't remember where to
get it (try google) but I've easily modify it to allow only connections from
some dedicated IP's. This could help on brute force atacks.

Artur Anjos

----- Original Message -----
From: "ale_pira" <ale_pira@...>
To: <ib-support@yahoogroups.com>
Sent: Tuesday, July 16, 2002 12:33 PM
Subject: [ib-support] final: Where I find a really good security specific
IB/FB group?


> Hi all,
> My big thanks to everybody that answered, and my apologies for this
> little 'gap answering'..
>
> I taked some decisions here, and as you, want to share my point of
> view:
>
> 1) For local (programs) access, I'll test a tunneling software, since
> my network clients can see my db machine, or snif on the wire;
> but this is really difficult to implement: a demand of installing new
> software on hundreds machines is painful (almost sure to not do it..);
> 2) For web access, will take place a mid-tier machine, the only one
> from 'extranet' wire that could connect to my db machine;
> 3) This registered machine will be surelly SSL-enabled, to protect
> the public internet side of the access;
> 4) The traffic of these two machines will be done over a switch, then
> only they will be seeing the data packets transmitted;
> 5) Console access highly restricted, remote console impossible;
> 6) Some users/roles accounts on db for read-only/web purposes, when
> applicable;
> 7) On final phase, add a mid-tier machine for internal use, with
> logging and alert facilities, watching for massive access (force
> brute tasks) - this may be a good (but not pro-active) substitute for
> task 1)..
>
> This is all for the moment, thanks again!!
>
> ale_pira