DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte III)

 No post anterior, vimos a possibilidade de restringir/autorizar a execução de SQL a um utilizador através de listas criadas numa captura de actividade.
Durante a captura não são apenas registados os comandos de SQL, mas também outros dados, o endereço de IP a partir do qual o SQL foi executado, o programa a partir do qual foi executado o SQL e ainda o utilizador de sistema operativo que lançou esse programa.
Este 3 dados adicionais são parte dos contextos que podem ser usados pela SQL Firewall.
Além de restringir a execução de comandos de SQL, é possível limitar a execução através destes contextos, limitar o acesso a partir de um IP ou de um utiliazdor de SO ou até de uma aplicação especifica.

Quando analisamos a lista criada durante a captura vemos que já existe essa informação armazenada.
Podemos ver isso na view dba_sql_firewall_capture_logs.

        
           
SQL> select username, command_type, client_program, os_user, ip_address from dba_sql_firewall_capture_logs;

USERNAME    COMMAND_TYPE     CLIENT_PROGRAM                            OS_USER    IP_ADDRESS    
___________ ________________ _________________________________________ __________ _____________ 
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          ALTER SESSION    java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
HR          SELECT           java@localhost.localdomain (TNS V1-V3)    oracle     127.0.0.1     
     
         

 Vemos que o sql capturado foi todo executado da máquina local (127.0.0.1), pelo user de sistema oracle e que foi uma aplicação java que executou o SQL.
Ao capturar esta informação e com ela gerar uma lista através do procedimento generate_allow_list, estamos não só a gerar listas de SQL mas também dos contextos capturados.
Podemos validar isso através das seguintes views:

        
           
SQL> select * from dba_sql_firewall_allowed_ip_addr;

USERNAME    IP_ADDRESS    
___________ _____________ 
HR          127.0.0.1     


SQL> select * from dba_sql_firewall_allowed_os_prog;

USERNAME    OS_PROGRAM                                
___________ _________________________________________ 
HR          java@localhost.localdomain (TNS V1-V3)    


SQL> select * from dba_sql_firewall_allowed_os_user;

USERNAME    OS_USER    
___________ __________ 
HR          oracle     
     
         

 Quando fizemos o enable das listas através deste comando:

dbms_sql_firewall.enable_allow_list(username => 'HR',enforce => dbms_sql_firewall.enforce_all, block => true);

Decidimos que queremos validar todas as listas através do segundo parâmetro 'enforce', com o valor dbms_sql_firewall.enforce_all.
Temos dois valores adicionais, dbms_sql_firewall.enforce_sql, que apenas valida o SQL e dbms_sql_firewall.enforce_context que apenas valida os contextos capturados.
Com a SQL Firewall podemos nem sequer validar comandos de SQL e apenas a criação da sessão através dos contextos. Caso não seja iniciada com as condições do contexto (IP,OSUSER,PROGRAM) a sessão não é sequer iniciada.

No próximo exemplo ao tentar criar uma ligação a partir de uma máquina windows para a VM com a Oracle 23c free, temos um outro IP, um outro programa e um outro utilizador de SO, o que dá origem a um erro de ligação desencadeado pela SQL Firewall não permitindo sequer a criação da sessão. Basta um deles não coincidir e a sessão será bloqueada.

        
           
SQLcl: Release 23.3 Production on sexta out. 13 11:28:19 2023

Copyright (c) 1982, 2023, Oracle.  All rights reserved.

Username? (''?) hr/oracle@localhost:1521/freepdb1
  USER          = hr
  URL           = jdbc:oracle:thin:@localhost:1521/freepdb1
  Error Message = ORA-47605: ViolaþÒo da Firewall de SQL
Username? (RETRYING) ('hr/*********@localhost:1521/freepdb1'?)     
         

 Podemos ver a informação de ligações atraves da seguinte query:

        
           
SQL> select * from dba_sql_firewall_session_logs;

            SESSION_ID USERNAME    LOGIN_TIME                          IP_ADDRESS    CLIENT_PROGRAM                            OS_USER          
______________________ ___________ ___________________________________ _____________ _________________________________________ ________________ 
   7289077817488179201 HR          12-OCT-23 14.24.40.828779000 GMT    127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           
   7289380881824415745 HR          13-OCT-23 10.00.43.170444000 GMT    10.0.2.2      SQLcl                                     gn-rrodrigues    
   7288719420115386369 HR          11-OCT-23 15.13.54.067050000 GMT    127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           
     
         

E verificar que IP, programa e OS_user não correspondem ao que está nas listas de permissões.
Analisando a view de violações vemos que existe mais uma, a última linha, do tipo context violation devido à tentativa de login falhada. 

        
           
SQL> select username, command_type, ip_address, client_program, os_user, cause, firewall_action from dba_sql_firewall_violations;

USERNAME    COMMAND_TYPE    IP_ADDRESS    CLIENT_PROGRAM                            OS_USER          CAUSE                FIREWALL_ACTION    
___________ _______________ _____________ _________________________________________ ________________ ____________________ __________________ 
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          EXECUTE         127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          EXECUTE         127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          EXECUTE         127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          EXECUTE         127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          EXECUTE         127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          SELECT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          INSERT          127.0.0.1     java@localhost.localdomain (TNS V1-V3)    oracle           SQL violation        Blocked            
HR          CONNECT         10.0.2.2      SQLcl                                     gn-rrodrigues    Context violation    Blocked            
     
         

Em qualquer momento podemos alterar esta situação mudando a informação que existe nas listas de permissões. Podemos remover ou acrescentar qualquer destes contextos caso faça sentido.
Imaginando que faz sentido o acesso aos dados através da sessão que eu tentei criar a partir do windows, poderei acrescentar essa informação aos contextos existentes.
Isso será feito através do procedimento add_allowed_context que me permite acrescentar dados ou caso queira o contrario o procedimento delete_allowed_context.
 

        
           
SQL> exec dbms_sql_firewall.add_allowed_context(username => 'HR', context_type => dbms_sql_firewall.ip_address, value => '10.0.2.2');

PL/SQL procedure successfully completed.

SQL> exec dbms_sql_firewall.add_allowed_context(username => 'HR', context_type => dbms_sql_firewall.os_username, value => 'gn-rrodrigues');

PL/SQL procedure successfully completed.

SQL> exec dbms_sql_firewall.add_allowed_context(username => 'HR', context_type => dbms_sql_firewall.os_program, value => 'SQLcl');

PL/SQL procedure successfully completed.     
         

 Depois de actualizar os dados nas listas temos então acesso à BD a partir da máquina windows.

        
           
SQLcl: Release 23.3 Production on sexta out. 13 11:49:26 2023

Copyright (c) 1982, 2023, Oracle.  All rights reserved.

Username? (''?) hr/oracle@localhost:1521/freepdb1
Connected to:
Oracle Database 23c Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.3.0.23.09

SQL>     
         

 Ao analisarmos a informação nas listas percebemos que elas foram actualizadas com os dados acrescentados.

        
           
SQL> select * from dba_sql_firewall_allowed_ip_addr;

USERNAME    IP_ADDRESS    
___________ _____________ 
HR          10.0.2.2      
HR          127.0.0.1     

SQL> select * from dba_sql_firewall_allowed_os_prog;

USERNAME    OS_PROGRAM                                
___________ _________________________________________ 
HR          SQLcl                                     
HR          java@localhost.localdomain (TNS V1-V3)    

SQL> select * from dba_sql_firewall_allowed_os_user;

USERNAME    OS_USER          
___________ ________________ 
HR          gn-rrodrigues    
HR          oracle           
     
         

Podemos para cada uma das listas existente acrescentar ou remover dados dos contextos, conseguindo assim limitar o acesso à BD com o SQL Firewall, indo além da limitação de execução de SQL.
Cada utilizador poderá ter validações diferentes, actuando ao nível dos contextos, do SQL ou dos dois em simultâneo.

No próximo texto falarei da possibilidade de capturar também actividade de SQL executada através de PLSQL e de como isso poderá limitar a execução de SQL Injection. 

Comentários

Enviar um comentário

Mensagens populares deste blogue

DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte I)

  O SQL firewall é uma opção que nos permite detectar, bloquear e criar log sobre actividades anormais de SQL e de alguns contextos das sessões. No fundo permite que consigamos detectar e bloquear com mais facilidade actividades suspeitas na nossa base de dados. Esta opção é introduzida na versão 23c da base de dados Oracle em forma de package ( DBMS_SQL_FIREWALL ). Nesta primeira parte de diferentes textos, vou falar sobre como fazer o setup/configuração da SQL Firewall. Vou começar por criar um novo user que será o administrador do SQL Firewall. Para isso existe um role chamado SQL_FIREWALL_ADMIN que contém todas as permissões necessárias a essa tarefa. Existe um outro role, SQL_FIREWALL_VIEWER, que permite ter utilizadores mais orientados à auditoria e que terão acesso aos dados gerados pelo firewall para poderem analisar. SQL> create user fwalladmin identified by oracle; SQL> grant create session, sql_firewall_admin to fwalladmin; ...
Ler mais

DBMS_SQL_FIREWALL - Firewall dentro da Base de Dados (Parte IV)

Este será o ultimo texto sobre o SQL firewall. Irei ver como impedir um possível ataque de SQL injection através do uso da SQL Firewall Criei uma stored procedure que será usada nos diferentes testes, quer de execução quer de tentativa de SQL Injection e usarei ainda a opção de top_level_only a false para verificar o que é capturado com essa opção. Vou começar por criar um procedimento simples, no schema HR, que executa alguns selects depois de receber um parâmetro de entrada, devolvendo um valor relacionado. O execute immediate do final do procedimento está apenas como exemplo para ser usado com o top_level_only a false e fazer alguns testes.  create or replace procedure empname(lst_name in varchar2) is comando varchar2(2000); type c_ref is ref cursor; c c_ref; ult_nome employees.last_name%type; Begin comando :='select first_name from hr.employees '|| 'where last_nam...
Ler mais