IBM Guardium Khả năng giám sát/ngăn chặn các hoạt động trái phép ở mức Network Activity và Local Activity

GIÁM SÁT, NGĂN CHẶN HOẠT ĐỘNG TRÁI PHÉP Ở MỨC NETWORK ACTIVITY VÀ LOCAL ACTIVITY TRÊN ORACLE DATABASE VÀ MICROSOFT SQL SERVER​

1. Mục tiêu​

  • Xác định S-TAP thu thập được những kênh truy cập nào: kết nối từ máy khác qua mạng (Network Activity) và kết nối ngay trên máy chủ CSDL (Local Activity) gồm TCP cục bộ, bequeath, IPC của Oracle, shared memory, named pipes của SQL Server; kênh không giám sát được thì phải đóng trên CSDL.​
  • Ngăn tài khoản bị hạn chế đọc dữ liệu nhạy cảm qua mạng và trên chính máy chủ CSDL; so sánh S-TAP TERMINATE với S-GATE TERMINATE.​
  • Cảnh báo, ghi lại hoạt động của quản trị viên trên máy chủ CSDL.​

2. Nguyên lý hoạt động​

Hoạt động truy cập CSDL chia thành hai loại theo nơi xuất phát kết nối: Network Activity là kết nối TCP/IP từ máy khác tới cổng 1521, 1433; Local Activity là phiên chạy ngay trên máy chủ CSDL sau khi đăng nhập SSH, RDP. S-TAP nằm trên máy chủ nên giám sát được cả hai loại, với hai lưu ý:
  • Kênh cục bộ không qua TCP chỉ được thu thập khi S-TAP cấu hình đúng. Kết nối TCP, dù từ máy khác hay tới IP:cổng của chính máy chủ, luôn được thu thập. Bequeath, IPC của Oracle cần K-TAP và Inspection Engine khai báo đúng; named pipes, shared memory của SQL Server cần S-TAP Windows theo dõi đúng pipe (tham số NAMED_PIPE).​
  • S-TAP TERMINATE không chặn câu lệnh kích hoạt rule. Phiên chỉ bị ngắt sau khi Collector đánh giá xong, nên câu kích hoạt thường đã chạy và có thể đã trả dữ liệu. Muốn chặn trước khi câu lệnh tới CSDL phải dùng S-GATE.​

2.1. Các kênh truy cập​

Loại​
Kênh​
Oracle (oracledb01)​
SQL Server (SQLDB01)​
Thu thập trong lab​
Network​
TCP từ máy khácsqlplus …@//<IP_ORACLE>:1521/orclsqlcmd -S <IP_MSSQL>,1433Có (K-TAP; driver WFP)
Local​
TCP cục bộsqlplus …@//localhost:1521/orclsqlcmd -S tcp:localhost,1433Có (K-TAP; driver WFP)
Local​
Bequeathsqlplus / as sysdba; sqlplus user/mk không có @–Có, Network Protocol = BEQUEATH
Local​
IPCsqlplus …@(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521))–Có, Network Protocol = IPC
Local​
Named pipes–sqlcmd -S np:\\.\pipe\sql\queryCó (driver NMP), Network Protocol = WINDOWS NAMED PIPES
Local​
Shared memory–sqlcmd -S lpc:SQLDB01; mặc định khi gõ -S localhostCó, qua pipe sqllocal\MSSQLSERVER, cũng ghi là WINDOWS NAMED PIPES
Trên Guardium, hoạt động cục bộ được nhận ra qua Client IP (127.0.0.1, ::1 hoặc IP máy chủ), Network Protocol (TCP, BEQUEATH, IPC, WINDOWS NAMED PIPES), OS User và Source Program trên máy chủ. Rule dùng group Client IP để xác định "cục bộ" vì một group bao được cả TCP cục bộ lẫn các kênh không qua TCP; Network Protocol dùng trong báo cáo để biết chính xác kênh.​

2.2. Điểm kiểm soát và hành động chặn​

S-TAP nằm trên máy chủ nên thấy được hoạt động cục bộ mà thiết bị giám sát mạng (SPAN, network TAP, tường lửa) không thấy; đổi lại, giám sát chỉ liên tục khi S-TAP luôn hoạt động.​

1792646224467.png

Hình 1: Điểm kiểm soát S-TAP và hành động từ Collector​

Hành động​
Thời điểm tác động​
Câu lệnh kích hoạt​
Dùng ở​
ALERT, LOGSau khi câu lệnh tới CSDLĐã chạy
Mọi kịch bản​
S-TAP TERMINATESau khi Collector đánh giá xong câu lệnh, ra lệnh cho S-TAP ngắt kết nốiThường đã chạy, có thể đã trả dữ liệu; các câu sau bị chặn
KB2​
S-GATE TERMINATETrước khi câu lệnh tới CSDL: S-TAP giữ câu lệnh của phiên đã attach, chờ phán quyếtBị hủy, phiên bị ngắt
KB3, KB5​
Ba tham số S-GATE quyết định hành vi chặn:​
Tham số​
Giá trị​
Tác động​
firewall_installed
1​
Bật S-GATE. IBM ghi tham số này không bật đồng thời với Query Rewrite trên S-TAP Windows (SQLDB01 trong lab đang bật cả hai)
firewall_default_state
0​
Phiên chỉ chuyển sang attached khi một câu khớp rule S-GATE ATTACH, nên câu SQL đầu tiên của phiên không bị giữ. IBM nêu giá trị 2 hữu ích cho policy theo phiên, theo user, nhưng cộng đồng IBM ghi nhận S-GATE trên SQL Server không hoạt động với giá trị 2 nên lab giữ 0
firewall_fail_close
0​
Collector không trả phán quyết trong firewall_timeout (10 giây) thì câu lệnh được cho qua, tránh treo CSDL

3. Cấu hình​

3.1. Kiểm tra hiện trạng S-TAP và CSDL​

Bước 1: Truy cập Manage → Activity Monitoring → S-TAP Control, kiểm tra S-TAP của oracledb01 và SQLDB01 ở trạng thái xanh. Mở Manage → System View → S-TAP Status Monitor, ghi lại phiên bản S-TAP.
Bước 2: Trên oracledb01 (root), kiểm tra K-TAP, Inspection Engine và listener:​
lsmod | grep -i ktap
find /usr/local/guardium -name guard_tap.ini 2>/dev/null
grep -inE "^(ktap_installed|firewall_|qrw_|db_install_dir|db_exec_file|db_user|unix_domain_socket_marker)" <đường dẫn guard_tap.ini>
getent passwd oracle | cut -d: -f6
ls -l /u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle
su - oracle -c "lsnrctl status" | grep -iE "PROTOCOL=(ipc|tcp)"
  • lsmod có dòng ktap: K-TAP đã nạp, S-TAP thấy được cả bequeath, IPC. Không có dòng nào: S-TAP đang dùng PCAP, chỉ thấy lưu lượng mạng.​
  • db_install_dir là ORACLE_HOME, khớp mô tả của IBM (đường dẫn thư mục cài đặt CSDL); getent cho thư mục home /home/oracle để đối chiếu. Kịch bản 1 thu được bequeath với giá trị này.​
  • lsnrctl có dòng (PROTOCOL=ipc)(KEY=EXTPROC1521) thì thử được kênh IPC; nếu không có, bỏ kênh c4_ipc ở các kịch bản.​
  • Ghi lại firewall_installed, firewall_default_state (cần là 1, 0).​
1792646260562.png

Hình 2: Hiện trạng K-TAP, guard_tap.ini và listener trên oracledb01​
Bước 3: Trên SQLDB01, mở PowerShell bằng Run as administrator:​
Get-Service | Where-Object { $_.DisplayName -like "*Guardium*" } | Format-Table Name, DisplayName, Status
driverquery | findstr /i "Wfp Nmp Correlator"
Select-String -Path "C:\Program Files\IBM\Windows S-TAP\Bin\guard_tap.ini" `
-Pattern "FIREWALL|QRW|QUERY_REWRITE|NAMED_PIPE|TCP_DRIVER"
sqlcmd -S tcp:localhost,1433 -U sa -P "<MK_SA>" -No -Q "EXEC sys.xp_readerrorlog 0, 1, N'provider is ready'"
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL*.MSSQLSERVER\MSSQLServer\SuperSocketNetLib\*" | Select-Object PSChildName, Enabled
  • Dịch vụ GUARDIUM_STAP (IBM Guardium S-TAP) phải ở trạng thái Running. Driver WfpMonitor thu thập TCP; NmpMonitor, NmpProxy thu thập named pipes. Nếu guard_tap.ini không nằm ở đường dẫn trên, tìm bằng Get-ChildItem C:\ -Recurse -Filter guard_tap.ini -ErrorAction SilentlyContinue.​
  • Ghi lại FIREWALL_INSTALLED, FIREWALL_DEFAULT_STATE, QUERY_REWRITE_INSTALLED, NAMED_PIPES_DRIVER_INSTALLED (lab: 1, 0, 1, 1). NAMED_PIPE = sql\query,sqllocal\MSSQLSERVER: S-TAP theo dõi cả pipe của named pipes lẫn pipe của Shared Memory.​
  • Errorlog cho biết pipe SQL Server đang mở: \\.\pipe\SQLLocal\MSSQLSERVER là Shared Memory, \\.\pipe\sql\query là Named Pipes. Registry của lab có Np = 0, Sm = 1, Tcp = 1; dù Np tắt, pipe sql\query vẫn nhận kết nối từ chính máy chủ (kênh m4_np ở kịch bản 1).​
1792646308098.png

Hình 3: Dịch vụ, driver và tham số guard_tap.ini của S-TAP trên SQLDB01
1792646312544.png

Hình 4: Trạng thái giao thức Np, Sm, Tcp của SQL Server trên SQLDB01​

3.2. Tạo tài khoản và script kiểm thử​

SEC_TEST là tài khoản bị hạn chế: có quyền SELECT trên customers, orders nhưng chính sách không cho đọc dữ liệu nhạy cảm. Không dùng INTERN_TEST, OPS_TEST vì hai tài khoản này đã thuộc group che, chặn và group theo dõi.
Bước 1: Trên oracledb01 (user oracle), kết nối Oracle bằng SYSTEM qua listener (không kèm as sysdba) và tạo SEC_TEST; máy quản trị không có sqlplus:​
sqlplus system@//<IP_ORACLE>:1521/orcl
SQL> CREATE USER sec_test IDENTIFIED BY "<MK_SEC_TEST>";
SQL> GRANT CREATE SESSION TO sec_test;
SQL> GRANT SELECT ON retail.customers TO sec_test;
SQL> GRANT SELECT ON retail.orders TO sec_test;
1792646322672.png

Hình 5: Tạo tài khoản SEC_TEST trên Oracle​
Bước 2: Trên SQLDB01 (SSH, PowerShell), kết nối SQL Server bằng sa và tạo sec_test:​
sqlcmd -S <IP_MSSQL>,1433 -U sa -P "<MK_SA>" -No -C
1> CREATE LOGIN sec_test WITH PASSWORD = N'<MK_SEC_TEST>', CHECK_POLICY = OFF;
2> GO
1> USE RetailDB;
2> GO
1> CREATE USER sec_test FOR LOGIN sec_test;
2> GO
1> GRANT SELECT ON retail.customers TO sec_test;
2> GO
1> GRANT SELECT ON retail.orders TO sec_test;
2> GO
1> SELECT OBJECT_SCHEMA_NAME(major_id) + '.' + OBJECT_NAME(major_id) AS doi_tuong, permission_name FROM sys.database_permissions WHERE grantee_principal_id = USER_ID('sec_test');
2> GO
  • Dùng mật khẩu riêng cho bài này vì câu CREATE USER, CREATE LOGIN bị ghi lại trong vết kiểm toán; CHECK_POLICY = OFF chỉ dùng cho tài khoản kiểm thử, xóa sau bài.​
1792646346430.png

Hình 6: Tạo login, user sec_test trên SQL Server và kiểm tra quyền​
Bước 3: Tạo hai script kiểm tra kênh. Trên oracledb01 (user oracle) tạo 2 script Oracle trong /tmp/uc8 (mkdir -p /tmp/uc8 && cd /tmp/uc8, tạo file bằng cat > tên_file <<'EOF' … EOF); trên SQLDB01 (qua SSH) và máy quản trị tạo 2 script SQL Server trong C:\lab\uc8 (New-Item -ItemType Directory -Force C:\lab\uc8) bằng PowerShell theo mẫu @' <nội dung> '@ | Set-Content -Encoding ASCII tên_file. Câu đầu hỏi chính CSDL đang phục vụ kết nối qua kênh nào để đối chứng với Guardium; Q_NL_CHANNELS lọc theo câu này. Mã kênh đặt làm tên cột của câu đếm để phân biệt các lần chạy trên client.​
Script Oracle uc8_kenh_ora.sql (tham số &1 là mã kênh):
SET VERIFY OFF
SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') AS proto,
SYS_CONTEXT('USERENV','IP_ADDRESS') AS ip,
SYS_CONTEXT('USERENV','OS_USER') AS os_user,
USER AS db_user
FROM dual;
SELECT COUNT(*) AS uc8_&1 FROM retail.customers;
EXIT
Script SQL Server uc8_kenh_mss.sql (biến KENH truyền bằng -v):
SELECT CONNECTIONPROPERTY('net_transport') AS net_transport,
CONNECTIONPROPERTY('client_net_address') AS client_ip,
SUSER_SNAME() AS login_name;
GO
SELECT COUNT(*) AS uc8_$(KENH) FROM retail.customers;
GO
Bước 4: Tạo hai script thử chặn: câu đầu không chạm dữ liệu nhạy cảm, câu thứ hai đọc CCCD, câu thứ ba đọc bảng không nhạy cảm.​
Script Oracle uc8_chan_ora.sql:
SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') AS proto FROM dual;
SELECT customer_id, full_name, cccd FROM retail.customers WHERE ROWNUM <= 3;
SELECT COUNT(*) AS so_don_hang FROM retail.orders;
EXIT
Script SQL Server uc8_chan_mss.sql:
SELECT CONNECTIONPROPERTY('net_transport') AS net_transport;
GO
SELECT TOP 3 customer_id, full_name, cccd FROM retail.customers;
GO
SELECT COUNT(*) AS so_don_hang FROM retail.orders;
GO
1792646362491.png

Hình 7: Tạo hai script Oracle trong /tmp/uc8 trên oracledb01
1792646366956.png

Hình 8: Tạo hai script SQL Server trong C:\lab\uc8 trên SQLDB01​

3.3. Tạo group​

Truy cập Setup → Tools and Views → Group Builder, nhấn + và tạo các group sau (Application type = Public):​

Tên group​
Group Type​
Thành viên​
GRP_NL_LOCAL_CLIENTS
Client IP​
127.0.0.1, <IP_ORACLE>, <IP_MSSQL>
GRP_NL_RESTRICTED_USERS
Users​
SEC_TEST

  • GRP_NL_LOCAL_CLIENTS là các Client IP Guardium ghi cho kết nối xuất phát từ chính máy chủ CSDL; danh sách được đối chiếu lại ở bước 2 kịch bản 1.
  • Chỉ dùng địa chỉ IP đơn: theo IBM, S-TAP TERMINATE và S-GATE TERMINATE không hoạt động với group Client IP có thành viên chứa ký tự đại diện.
  • Guardium chuẩn hóa tên người dùng thành chữ hoa nên sec_test của SQL Server cũng khớp SEC_TEST.
1792646374429.png

Hình 9: Group GRP_NL_LOCAL_CLIENTS (3 thành viên) và GRP_NL_RESTRICTED_USERS (1 thành viên)​

3.4. Tạo policy POL_NET_LOCAL_CONTROL​

Bước 1: Truy cập Protect → Security Policies → Policy Builder for Data, nhấn New, đặt Policy Description = POL_NET_LOCAL_CONTROL.
Bước 2: Thêm ba access rule theo đúng thứ tự trong bảng, mọi rule đặt Category = Network Local Control.
Bước 3: Nếu lab đã cấu hình Alerter, Syslog, ở hành động ALERT của rule 1, 2 chọn Message Template = TPL_RT_ACCESS và thêm receiver SYSLOG. Nhấn Save, chưa cài policy (cài ở kịch bản 2).​

#​
Rule​
Điều kiện​
Hành động; Continue​
1​
NL_BLOCK_NET_SENSITIVEClient IP address Not In Group GRP_NL_LOCAL_CLIENTS; Database user In Group GRP_NL_RESTRICTED_USERS; Object In Group GRP_SENSITIVE_OBJECTSALERT PER MATCH (HIGH) + S-TAP TERMINATE; không tích Continue
2​
NL_ALERT_LOCAL_SESSIONClient IP address In Group GRP_NL_LOCAL_CLIENTS; Database user Not In Group GRP_AUTHORIZED_USERSALERT ONCE PER SESSION (MED); tích Continue
3​
NL_LOG_LOCAL_ACTIVITYClient IP address In Group GRP_NL_LOCAL_CLIENTS; Database user Not In Group GRP_AUTHORIZED_USERSLOG MASKED DETAILS; tích Continue

  • Rule 1 dùng S-TAP TERMINATE ở kịch bản 2, chuyển sang S-GATE ở kịch bản 3 để so sánh hai cách chặn. Rule chỉ nhắm GRP_NL_RESTRICTED_USERS để không ngắt phiên INTERN_TEST và phiên quản trị từ máy quản trị; không tích Continue vì câu đã bị chặn không cần đánh giá tiếp.
  • Rule 2 áp dụng cho mọi phiên cục bộ của tài khoản không phải ứng dụng, kể cả khi không chạm bảng nhạy cảm. ONCE PER SESSION vì một phiên quản trị có thể chạy hàng trăm câu.
  • Rule 3 dùng LOG MASKED DETAILS để không làm lộ mật khẩu trong CREATE USER, ALTER LOGIN … PASSWORD mà POL_AUDIT_DB_CHANGES đã che.
  • Hai rule được thêm khi kiểm thử: NL_SGATE_ATTACH_RESTRICTED (kịch bản 3) và NL_BLOCK_LOCAL_SENSITIVE (kịch bản 5).
1792646395270.png

Hình 10: Ba rule của POL_NET_LOCAL_CONTROL
1792646399483.png

Hình 11: Điều kiện của rule NL_BLOCK_NET_SENSITIVE​

3.5. Cài đặt policy theo đúng thứ tự​

POL_NET_LOCAL_CONTROL đứng sau POL_AUDIT_DB_CHANGES, POL_RT_ACCESS_ALERT (chỉ ghi nhận, cảnh báo, mọi rule tích Continue) và trước POL_PROTECT_SENSITIVE_DATA. Rule cuối của POL_PROTECT_SENSITIVE_DATA là LOG_SENSITIVE_ACCESS không tích Continue, nên câu SELECT trên customers dừng tại đó và không tới được policy cài sau.
Bước 1: Truy cập Protect → Security Policies → Policy Installation, chọn POL_AUDIT_DB_CHANGES, chọn Install and override.
Bước 2: Lần lượt chọn Install last cho POL_RT_ACCESS_ALERT (nếu đang có trong lab), POL_NET_LOCAL_CONTROL, POL_PROTECT_SENSITIVE_DATA, POL_BASIC_DATA_SECURITY.
Bước 3: Kiểm tra mục Currently Installed Policies hiển thị đúng thứ tự trên và S-TAP Control vẫn xanh.​
grdapi policy_install policy="POL_AUDIT_DB_CHANGES|POL_RT_ACCESS_ALERT|POL_NET_LOCAL_CONTROL|POL_PROTECT_SENSITIVE_DATA|POL_BASIC_DATA_SECURITY"
grdapi list_installed_policies
1792646423610.png

Hình 12: Thứ tự cài đặt policy trong Currently Installed Policies​

3.6. Báo cáo và dashboard​

Truy cập Reports → Report Configuration Tools → Query-Report Builder, tạo các query sau:​

Query​
Domain; điều kiện​
Cột​
Q_NL_CHANNELSAccess (Main Entity = SQL)
Sql LIKE '%AS proto%' OR Sql LIKE '%AS net_transport%'		Session Start, Server IP, Client IP, Network Protocol, DB User Name, OS User, Source Program, Sql, Total access
Q_NL_SESSIONSAccess (Main Entity = Session)
DB User Name IN GROUP GRP_NL_RESTRICTED_USERS		Session Start, Session End, Server IP, Client IP, Network Protocol, DB User Name, OS User, Source Program
Q_NL_VIOLATIONSAccess (Main Entity = Policy Rule Violation)
Category Name = Network Local Control		Timestamp, Access Rule Description, Severity Description, Server IP, Client IP, DB User Name, Source Program, Full SQL String
Q_NL_LOCAL_ACTIVITYAccess (Main Entity = FULL SQL)
Client IP IN GROUP GRP_NL_LOCAL_CLIENTS		Timestamp, Server IP, Client IP, Network Protocol, DB User Name, OS User, Source Program, Full Sql

  • Q_NL_CHANNELS sắp xếp theo Session Start tăng dần, Q_NL_SESSIONS giảm dần. Network Protocol thuộc entity Client/Server: TCP; BEQUEATH, IPC với K-TAP trên Oracle; WINDOWS NAMED PIPES trên SQL Server.​
  • Q_NL_CHANNELS đọc cột Sql nên không phụ thuộc rule nào; kênh không có dòng là kênh S-TAP không thu thập được.​
  • Q_NL_SESSIONS cho thấy phiên bị ngắt (Session End ngay sau câu bị chặn). Q_NL_LOCAL_ACTIVITY là nhật ký từng câu lệnh trên máy chủ; câu do rule 3 ghi có giá trị đã bị thay bằng dấu ?.​
Bước 1: Truy cập My Dashboards → Create New Dashboard, đặt tên Network and Local Activity, thêm bốn query trên và hai report có sẵn S-TAP Status Monitor, Inactive S-TAPs Since.
Bước 2: Ở mỗi report, mở Customize và đặt khoảng thời gian bao trùm lúc kiểm thử.​
1792646450624.png

Hình 13: Dashboard Network and Local Activity​

4. Kịch bản kiểm thử​

4.1. Kịch bản 1 – Độ phủ thu thập theo kênh truy cập​

Chạy cùng script kiểm tra kênh qua 10 kênh khi chưa cài POL_NET_LOCAL_CONTROL. Mã kênh: c là Oracle, m là SQL Server; net là TCP từ máy khác, lo là TCP cục bộ, beq là bequeath, ipc là IPC, sysdba là / as sysdba, shm là shared memory, np là named pipes, win là xác thực Windows với -S localhost.
Bước 1: Chạy script kiểm tra kênh cho đủ 10 mã kênh. Ghi lại kết quả câu đầu (kênh theo CSDL); kênh nào không kết nối được thì ghi lại thông báo lỗi.​
# Máy quản trị
python uc4_ora.py sec_test "SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') AS proto, SYS_CONTEXT('USERENV','IP_ADDRESS') AS ip, SYS_CONTEXT('USERENV','OS_USER') AS os_user, USER AS db_user FROM dual" "SELECT COUNT(*) AS uc8_c1_net FROM retail.customers"
sqlcmd -S <IP_MSSQL>,1433 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -C -i uc8_kenh_mss.sql -v KENH=m1_net -W

# oracledb01
sqlplus -S 'sec_test/"<MK_SEC_TEST>"@//localhost:1521/orcl' @uc8_kenh_ora.sql c2_lo
sqlplus -S 'sec_test/"<MK_SEC_TEST>"' @uc8_kenh_ora.sql c3_beq
sqlplus -S 'sec_test/"<MK_SEC_TEST>"@(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))' @uc8_kenh_ora.sql c4_ipc
sqlplus -S "/ as sysdba" @uc8_kenh_ora.sql c5_sysdba

# SQLDB01
sqlcmd -S tcp:localhost,1433 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_kenh_mss.sql -v KENH=m2_lo -W
sqlcmd -S lpc:SQLDB01 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_kenh_mss.sql -v KENH=m3_shm -W
sqlcmd -S np:\\.\pipe\sql\query -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_kenh_mss.sql -v KENH=m4_np -W
sqlcmd -S localhost -E -d RetailDB -No -i uc8_kenh_mss.sql -v KENH=m5_win -W
  • c3_beq không có @ nên sqlplus nối thẳng tới instance theo ORACLE_SID qua bequeath, không qua listener.​
  • Trên oracledb01, chuỗi đăng nhập đặt trong nháy đơn để bash giữ nguyên nháy kép quanh mật khẩu. Máy quản trị không có sqlplus nên kênh c1_net dùng uc4_ora.py (python-oracledb, TCP tới cổng 1521), chạy trong thư mục chứa uc4_ora.py và tai_khoan_lab.md; sqlcmd chạy trong C:\lab\uc8.​
1792646469968.png

Hình 14: Kiểm tra kênh từ máy quản trị: c1_net, m1_net đi qua TCP
1792646474063.png

Hình 15: Kiểm tra kênh trên oracledb01: c2_lo (tcp) và c3_beq
1792646478223.png

Hình 16: Kiểm tra kênh trên oracledb01: c4_ipc (ipc) và c5_sysdba
1792646483331.png

Hình 17: Kiểm tra kênh trên SQLDB01: m2_lo (TCP), m3_shm và m5_win (Shared memory), m4_np (Named pipe)​
Bước 2: Chờ khoảng 1 phút, mở Q_NL_CHANNELS với khoảng thời gian bao trùm bước 1. Ghi lại kênh nào có dòng, kèm Client IP, Network Protocol, OS User, Source Program; đối chiếu Client IP của các kênh cục bộ với GRP_NL_LOCAL_CLIENTS, thêm giá trị còn thiếu (chỉ dùng địa chỉ đơn).​
1792646487746.png

Hình 18: Q_NL_CHANNELS: kênh qua mạng từ máy quản trị và Oracle TCP cục bộ
1792646491802.png

Hình 19: Q_NL_CHANNELS: Oracle TCP cục bộ, BEQUEATH, IPC và phiên SYS (/ as sysdba)
1792646495909.png

Hình 20: Q_NL_CHANNELS: SQL Server TCP cục bộ và ba kênh ghi là WINDOWS NAMED PIPES​
Đánh giá: Guardium thu thập đủ 10 kênh với cấu hình hiện tại, kể cả bequeath, IPC, / as sysdba. Shared memory được ghi là WINDOWS NAMED PIPES, không phân biệt được với named pipes. Client IP cục bộ là 127.0.0.1 hoặc IP máy chủ, đều thuộc GRP_NL_LOCAL_CLIENTS.​

4.2. Kịch bản 2 – Chặn truy cập qua mạng bằng S-TAP TERMINATE​

Tài khoản bị hạn chế đọc bảng nhạy cảm từ máy khác.
Bước 1: Cài POL_NET_LOCAL_CONTROL theo mục 3.5.
Bước 2: Trên máy quản trị, chạy ba câu thử chặn trên Oracle bằng uc4_ora.py và script thử chặn trên SQL Server:​
python uc4_ora.py sec_test "SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') AS proto FROM dual" "SELECT customer_id, full_name, cccd FROM retail.customers WHERE ROWNUM <= 3" "SELECT COUNT(*) AS so_don_hang FROM retail.orders"
sqlcmd -S <IP_MSSQL>,1433 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -C -i uc8_chan_mss.sql
  • Lặp lại trên SQL Server bằng sqlcmd tương tác (bỏ -i, thêm -W): gõ câu đọc CCCD, khoảng 10 giây sau gõ câu đếm orders.​
1792646509166.png

Hình 21: Kịch bản 2, Oracle: câu đọc CCCD trả 3 dòng, câu đếm orders báo DPY-4011
1792646513380.png

Hình 22: Kịch bản 2, SQL Server (sqlcmd tương tác): câu đọc CCCD trả 3 dòng, câu đếm orders không có kết quả​
Bước 3: Mở Q_NL_VIOLATIONS, Q_NL_SESSIONS. Ghi lại số dòng customers trả về và câu nào báo mất kết nối.​
1792646517892.png

Hình 23: Q_NL_VIOLATIONS: vi phạm NL_BLOCK_NET_SENSITIVE mức HIGH trên Oracle và SQL Server
1792646522096.png

Hình 24: Q_NL_SESSIONS: các phiên SEC_TEST từ máy quản trị​
Đánh giá: NL_BLOCK_NET_SENSITIVE khớp trên cả hai CSDL nhưng S-TAP TERMINATE không chặn câu kích hoạt: cả hai đều trả 3 dòng kèm CCCD. Phiên chỉ bị ngắt từ câu sau: Oracle báo DPY-4011, sqlcmd đứng chờ không có kết quả.​

4.3. Kịch bản 3 – Chặn trước khi thực thi bằng S-GATE TERMINATE​

Bước 1: Trong Policy Builder, mở POL_NET_LOCAL_CONTROL, sửa như sau rồi nhấn Save và cài lại policy (mục 3.5):
  • Thêm access rule NL_SGATE_ATTACH_RESTRICTED ở vị trí đầu tiên: Database user In Group GRP_NL_RESTRICTED_USERS; Action = S-GATE ATTACH; tích Continue; Category = Network Local Control.
  • Mở NL_BLOCK_NET_SENSITIVE, xóa hành động S-TAP TERMINATE, thêm S-GATE TERMINATE; giữ ALERT PER MATCH.
1792646538482.png

Hình 25: POL_NET_LOCAL_CONTROL sau khi thêm NL_SGATE_ATTACH_RESTRICTED và chuyển sang S-GATE TERMINATE​
Bước 2: Lặp lại bước 2 của kịch bản 2.​
1792646541902.png

Hình 26: Kịch bản 3, Oracle: câu đọc CCCD bị hủy, client báo DPY-4011​
Bước 3: Kiểm tra trường hợp câu đọc CCCD là câu SQL đầu tiên của phiên: chạy lệnh dưới, sau đó lặp lại bằng sqlcmd tương tác như kịch bản 2 (gõ câu đọc CCCD trước, câu đếm orders sau).​
sqlcmd -S <IP_MSSQL>,1433 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -C `
-Q "SELECT TOP 3 customer_id, full_name, cccd FROM retail.customers"
1792646546547.png

Hình 27: Kịch bản 3, SQL Server: câu đọc CCCD là câu đầu tiên của phiên vẫn trả 3 dòng​
Bước 4: Mở Q_NL_VIOLATIONS, Q_NL_SESSIONS, so sánh với kịch bản 2.​
  • Nếu SQLDB01 không chặn được trong khi oracledb01 chặn được, kiểm tra FIREWALL_INSTALLED và Query Rewrite trên SQLDB01 (mục 3.1). Không tắt Query Rewrite vì sẽ mất che dữ liệu đang dùng trong lab.​
1792646550753.png

Hình 28: Q_NL_VIOLATIONS: NL_BLOCK_NET_SENSITIVE ở kịch bản 2 và kịch bản 3​
Đánh giá: Trên Oracle, S-GATE chặn trước khi thực thi: câu đọc CCCD bị hủy (DPY-4011), không trả dòng nào. Trên SQL Server, rule khớp cả ba lần nhưng câu đọc CCCD vẫn trả dữ liệu; IBM ghi FIREWALL_INSTALLED bị tắt khi QUERY_REWRITE_INSTALLED = 1, mà SQLDB01 bật cả hai.​

4.4. Kịch bản 4 – Quản trị viên làm việc trên máy chủ CSDL​

Quản trị viên đăng nhập máy chủ và truy vấn bằng kết nối cục bộ. Quản trị viên được phép làm việc nên không bị chặn, nhưng mọi phiên phải được cảnh báo và ghi lại.
Bước 1: SSH vào SQLDB01 bằng tài khoản Windows quản trị, gõ powershell và chạy:​
sqlcmd -S localhost -E -d RetailDB -No -W -Q "SELECT TOP 5 customer_id, full_name FROM retail.customers"
sqlcmd -S localhost -E -No -W -Q "SELECT CONNECTIONPROPERTY('net_transport') AS kenh; SELECT name FROM sys.server_principals WHERE name LIKE '%test%'"
1792646566536.png

Hình 29: Quản trị viên truy vấn trên SQLDB01 qua -S localhost -E (Shared memory)​
Bước 2: SSH vào oracledb01, chuyển sang user oracle và chạy:​
sqlplus -S "/ as sysdba" <<'EOF'
SELECT SYS_CONTEXT('USERENV','NETWORK_PROTOCOL') AS proto FROM dual;
SELECT username, account_status FROM dba_users WHERE username LIKE '%TEST';
SELECT customer_id, full_name FROM retail.customers WHERE ROWNUM <= 5;
EOF

1792646615659.png

Hình 30: Quản trị viên truy vấn trên oracledb01 bằng / as sysdba​
Bước 3: Mở Q_NL_VIOLATIONS, Q_NL_LOCAL_ACTIVITY.​
1792646615674.png

Hình 31: Q_NL_VIOLATIONS: NL_ALERT_LOCAL_SESSION mức MED của SYS và SQLDB01\ADMINISTRATOR
1792646623336.png

Hình 32: Q_NL_LOCAL_ACTIVITY: câu lệnh cục bộ đã che giá trị​
Đánh giá: Quản trị viên không bị chặn nhưng mọi phiên đều bị phát hiện: SYS (BEQUEATH) và SQLDB01\Administrator (WINDOWS NAMED PIPES) sinh NL_ALERT_LOCAL_SESSION mức MED. Q_NL_LOCAL_ACTIVITY ghi từng câu, kể cả câu sqlcmd tự gửi, giá trị thay bằng dấu ?; vi phạm vẫn lưu nguyên văn.​

4.5. Kịch bản 5 – Chặn tài khoản bị hạn chế trên kênh cục bộ​

Rule chặn ở kịch bản 2, 3 chỉ áp dụng cho kết nối từ máy khác. Kịch bản này mở rộng chặn sang kênh cục bộ để SEC_TEST không đọc được dữ liệu nhạy cảm trên mọi kênh, kể cả khi dùng ngay trên máy chủ CSDL.
Bước 1: Với policy như sau kịch bản 3, chạy script thử chặn bằng SEC_TEST trên máy chủ:​
# oracledb01
sqlplus -S 'sec_test/"<MK_SEC_TEST>"@//localhost:1521/orcl' @uc8_chan_ora.sql
sqlplus -S 'sec_test/"<MK_SEC_TEST>"' @uc8_chan_ora.sql
# SQLDB01
sqlcmd -S tcp:localhost,1433 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_chan_mss.sql -W
1792646629378.png

Hình 33: Trước khi thêm rule: SEC_TEST đọc được CCCD qua Oracle TCP cục bộ
1792646633393.png

Hình 34: Trước khi thêm rule: SEC_TEST đọc được CCCD qua Oracle bequeath
1792646638502.png

Hình 35: Trước khi thêm rule: SEC_TEST đọc được CCCD qua SQL Server TCP cục bộ​
Bước 2: Mở Q_NL_VIOLATIONS, ghi lại dữ liệu customers có trả về không và vi phạm nào được sinh.​
1792646643628.png

Hình 36: Q_NL_VIOLATIONS trước khi thêm rule: chỉ có NL_ALERT_LOCAL_SESSION mức MED
1792646647536.png

Hình 37: Q_NL_VIOLATIONS trước khi thêm rule (tiếp): các phiên Oracle cục bộ​
Bước 3: Trong POL_NET_LOCAL_CONTROL, thêm access rule sau ngay sau NL_BLOCK_NET_SENSITIVE, Category = Network Local Control, rồi cài lại policy:

Rule​
Điều kiện​
Hành động; Continue​
NL_BLOCK_LOCAL_SENSITIVEClient IP address In Group GRP_NL_LOCAL_CLIENTS; Database user In Group GRP_NL_RESTRICTED_USERS; Object In Group GRP_SENSITIVE_OBJECTSALERT PER MATCH (HIGH) + S-GATE TERMINATE; không tích Continue

Bước 4: Chạy lại các lệnh ở bước 1, thêm kênh IPC, named pipes và shared memory:​
# oracledb01
sqlplus -S 'sec_test/"<MK_SEC_TEST>"@(DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521))(CONNECT_DATA=(SERVICE_NAME=orcl)))' @uc8_chan_ora.sql
# SQLDB01
sqlcmd -S np:\\.\pipe\sql\query -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_chan_mss.sql -W
sqlcmd -S lpc:SQLDB01 -d RetailDB -U sec_test -P "<MK_SEC_TEST>" -No -i uc8_chan_mss.sql -W
1792646653158.png

Hình 38: Sau khi thêm rule: Oracle TCP cục bộ vẫn trả CCCD, câu sau báo ORA-03113
1792646658472.png

Hình 39: Sau khi thêm rule: Oracle bequeath chạy hết cả ba câu
1792646662267.png

Hình 40: Sau khi thêm rule: Oracle IPC chạy hết cả ba câu
1792646666868.png

Hình 41: Sau khi thêm rule: SQL Server TCP cục bộ và named pipes chạy hết cả ba câu
1792646671739.png

Hình 42: Sau khi thêm rule: SQL Server shared memory chạy hết cả ba câu​
Bước 5: Mở Q_NL_VIOLATIONS. Với từng kênh, ghi lại có vi phạm NL_BLOCK_LOCAL_SENSITIVE không, dữ liệu customers có trả về không và phiên có bị ngắt không.
1792646676501.png

Hình 43: Q_NL_VIOLATIONS sau khi thêm rule: NL_BLOCK_LOCAL_SENSITIVE mức HIGH trên SQL Server
1792646679965.png

Hình 44: Q_NL_VIOLATIONS sau khi thêm rule (tiếp): SQL Server và Oracle
1792646683684.png

Hình 45: Q_NL_VIOLATIONS sau khi thêm rule (tiếp): các phiên Oracle cục bộ
1792646688075.png

Hình 46: Q_NL_VIOLATIONS sau khi thêm rule (tiếp): Oracle TCP cục bộ (127.0.0.1)​

Đánh giá: Trước khi thêm rule, SEC_TEST đọc được CCCD, chỉ sinh cảnh báo MED. Sau khi thêm NL_BLOCK_LOCAL_SENSITIVE, ba phiên SQL Server và hai phiên Oracle có vi phạm HIGH nhưng mọi kênh vẫn trả dữ liệu; chỉ Oracle TCP cục bộ bị ngắt từ câu sau (ORA-03113).​
 

Đính kèm

  • 1792646570482.png
    1792646570482.png
    32.6 KB · Lượt xem: 0
Sửa lần cuối:
Nhấn để mở rộng...
Bạn phải đăng nhập hoặc đăng ký để bình luận.
Back
Top