block connections sysdbopen
User asked how to block ODBC connections in sysdbopen(). Responses indicated ODBC connections cannot be easily distinguished from other client APIs. Solutions suggested: filter by hostname/client PC address, use syssessions tty field to identify ODBC users, implement role-based access control with restricted permissions for ODBC users, validate client application names (v11.70+), or check feprogram column in sysmaster:syssession.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, As I can block access to odbc connections within sysdbopen?
I don't think so, no. I don't know how you would recognize an ODBC connection. You could block the client PCs hostname/address in the /etc/hosts.reject file or the Informix equivalent. I suppose you could check in the sysdbopen() function whether the client is connecting from an approved host also. Other than that, you can't tell the difference between a client connecting from host A using ODBC from a client connecting from the same host using ESQL/C or 4GL using the native API. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Feb 18, 2014 at 6:54 AM, ANTONIO DIAZ <adiaz@aisistemas.net> wrote: > Hi, > > As I can block access to odbc connections within sysdbopen? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11347b7cea534c04f2ad0c22
I'm doing this now. Takes some work but, if your ODBC users have a "smart"
name then:
SELECT UNIQUE y.tty INTO p_tty
FROM system:systables AS s, sysmaster:syssessions AS y
WHERE s.tabid = 1 AND DBINFO( "sessionid" ) = y.sid ;
SELECT COUNT(*) INTO p_odbc_user
FROM sp_setup:tty_odbc WHERE tty = p_tty[1,3];
If p_tty matches I know they are comming in via ODBC. I instituted ROLEs and
REVOKEd PUBLIC access from objects of interest. Each user is a member of a
ROLE. Each ROLE has defined access to an object. If a user is an odbc_role
type then they have only SELECT access otherwise they have more object access.
Each user is granted CONNECT to the database.
The trick to to manage the users as they are created/deactivated. Some
configuration tables are used in a seperated database (sp_setup) in this
example.
This was brought about as a result of users unknowing UPDATEing data.
In most, I agree with Art, I don't see an easy way to identify the client API. There is a client version, but: 1- It's not properly documented 2- I don't think it will reflect if it's ODBC, ESQL etc. But having said this maybe there is a solution. As Art mentioned, you can filter the hostname. If you want to allow 4GL or ESQL/C coming from a specific host where the users are "trapped" inside a menu from the same users coming from their workstations (PC) it could be done. Another option, would be to validate the client application name. This works in recent versions (I'd have to check, but latest 11.70, 12.10 for sure, and possibly latest 11.50 fixpacks). Consider this depends on information sent by the client side. If you want to restrict the average user that's probably ok. If you want to prevent hacking attacks from security experts I would not use it. Other things to consider: - If you want to allow 4GL connections.. do they use passwords or are they trusted? If they're trusted do the users know their passwords on the database system? They would need them for ODBC... if you can define them (assuming they won't be necessary for the authorized sessions) this could be another way to do it - If the "allowed" applications are developed "in house" you could configure PAM to raise a challenge that would require a specific answer. This would need to be provided by a function in the client application. Without this function, the connections would fail. This would require more skills that the other solutions, but it's not rocket science We would need more information to provide more help. Versions are always important.... Regards On Tue, Feb 18, 2014 at 11:54 AM, ANTONIO DIAZ <adiaz@aisistemas.net> wrote: > Hi, > > As I can block access to odbc connections within sysdbopen? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a11c1def2688b4404f2ad7a58
IDS version is 11.50 UC1E. I think it might be a good idea to play with fields (tty and hostname) of syssession. Case in point is that each user has their user / password linux and run the 4GL application, plus there is also an application (. Net) to access through the CSK of informix (Informix Cli). This application (. Net) always runs with a particular user which can rule to control access. Would have to check that users other than the latter should come from a PC and to deny access to these. The idea is to avoid accessing the database with odbc access tools from a pc. Thank you.
You don't mentioned the version. If you are using v11.70 , check if the column feprogram at sysmaster:syssession .... not be exactly what you looking for...but maybe give some information which solve a part of the problem. 2014-02-18 8:54 GMT-03:00 ANTONIO DIAZ <adiaz@aisistemas.net>: > Hi, > > As I can block access to odbc connections within sysdbopen? > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e011779f598bfd004f2afd4cc