guzik » DB

FortiAnalyzer i MySQL

guzik — Fri, 09 Apr 2010 20:51:52 +0000

W dokumencie FortiAnalyzer v4.0 MR2 Release Notes w rozdziale ’1.1 Summary of Enhancements Provided by FortiAnalyzer v4.0 MR2 Release’ można znaleźć między innymi coś takiego:

Remote SQL database (MySQL) support
SQL DB PostgreSQL support

Przyznam, że zaintrygowało mnie to na tyle, że postanowiłem od razu sprawdzić z czym to się je i co można z tego wycisnąć.

Konfiguracja prosta – jak na załączonym obrazku:

Podajemy sposób przechowywania danych (Location): lokalny to prawdopodobnie PostgreSQL i zdalny, czyli MySQL. Wybrałem ten ostatni. Po uzupełnieniu niezbędnych danych (serwer, użytkownik, hasło, baza) zaznaczyłem logowanie wszystkich typów zdarzeń.
Jeśli użytkownik, którego podamy ma prawo do zakładania baz, nic więcej nie musimy robić. W przeciwnym razie należy mu pomóc.
Poniżej kawałek mojego query log‘a:

Connect fa@A.B.C.D on Query create database if not exists `fortianalyzer` Query use `fortianalyzer` Query select tbl_name from table_ref where tbl_name like 'FG100A3907510579-elog-%' and row_num=0

Czyli mamy połączenie z serwerem, próbę założenia oraz podłączenie do bazy, a następnie przeszukanie tabeli table_ref (założona wcześniej). Tabela ta zawiera informacje o innych tablicach z logami – podejrzewam, że zaplanowana została jakaś rotacja (wskazują na to kolumny itime_start, itime_end, dtime_start, dtime_end, row_num). Czemu tylko podejrzewam, a nie wiem? Otóż w przypadku, gdy nie zostanie znaleziony żaden wynik, FortiAnalyzer próbuje stworzyć nową tablicę. U mnie próbuje, bo nikt nie pomyslał, że baza może mieć domyślne kodowanie ustawione na utf8 zamiast np. latin1, a przy ograniczeniach MySQL nie każdą tablicę da się założyć. Jakiej się nie da? Wyczerpująco opisuje to dodatek D.7.2. The Maximum Number of Columns Per Table dokumentacji MySQL.
Zapytanie jak poniżej:

create table `FG100A3907510579-elog-20100409220517` (`id` bigint unsigned not null primary key,`itime` datetime,`dtime` datetime,`cluster_id` varchar(24),`device_id` varchar(16),`log_id` smallint unsigned default 0,`subtype` varchar(255),`type` varchar(255),`timestamp` int unsigned default 0,`pri` varchar(255),`vd` varchar(255),`user` varchar(255),`msg` varchar(255),`ssid` varchar(255),`action` varchar(255),`session_id` int unsigned default 0,`count` int unsigned default 0,`proto` varchar(255),`profile` varchar(255),`cpu` tinyint unsigned default 0,`src` varchar(40),`epoch` int unsigned default 0,`mem` tinyint unsigned default 0,`duration` int unsigned default 0,`infected` int unsigned default 0,`from` varchar(255),`dst` varchar(40),`ha_group` tinyint unsigned default 0,`tunnel_id` int unsigned default 0,`status` varchar(255),`bssid` varchar(255),`tunnel_type` varchar(255),`event_id` int unsigned default 0,`ip` varchar(40),`ha_role` varchar(255),`rem_ip` varchar(40),`src_int` varchar(255),`suspicious` int unsigned default 0,`sn` varchar(255),`to` varchar(255),`total_session` int unsigned default 0,`ap` varchar(255),`scanned` int unsigned default 0,`vcluster` int unsigned default 0,`remote_ip` varchar(40),`carrier_ep` varchar(255),`imsi` varchar(255),`loc_ip` varchar(40),`dst_int` varchar(255),`from_vcluster` int unsigned default 0,`rem_port` smallint unsigned default 0,`src_port` smallint unsigned default 0,`msisdn` varchar(255),`tunnel_ip` varchar(40),`intercepted` int unsigned default 0,`vap` varchar(255),`service` varchar(255),`apn` varchar(255),`out_intf` varchar(255),`blocked` int unsigned default 0,`dst_port` smallint unsigned default 0,`mac` varchar(255),`to_vcluster` int unsigned default 0,`acct_stat` varchar(255),`selection` varchar(255),`reason` varchar(255),`group` varchar(255),`rate` tinyint unsigned default 0,`loc_port` smallint unsigned default 0,`vcluster_member` int unsigned default 0,`vcluster_state` varchar(255),`app-type` varchar(255),`nsapi` tinyint unsigned default 0,`dport` smallint unsigned default 0,`channel` tinyint unsigned default 0,`cookies` varchar(255),`checksum` int unsigned default 0,`dst_host` varchar(255),`nf_type` varchar(255),`vdname` varchar(255),`linked-nsapi` tinyint unsigned default 0,`next_stats` int unsigned default 0,`virus` varchar(255),`imei-sv` varchar(255),`devintfname` varchar(255),`security` varchar(255),`policy_id` int unsigned default 0,`rai` varchar(255),`hostname` varchar(255),`xauth_user` varchar(255),`uli` varchar(255),`xauth_group` varchar(255),`sent` bigint unsigned default 0,`policyid` int unsigned default 0,`rcvd` bigint unsigned default 0,`sess_duration` int unsigned default 0,`hbdn_reason` varchar(255),`banned_src` varchar(255),`end-usr-address` varchar(40),`msg-type` tinyint unsigned default 0,`sync_type` varchar(255),`banned_rule` varchar(255),`state` varchar(255),`vpn_tunnel` varchar(255),`sync_status` varchar(255),`alert` varchar(255),`sensor` varchar(255),`endpoint` varchar(255),`stage` tinyint unsigned default 0,`voip_proto` varchar(255),`deny_cause` varchar(255),`desc` varchar(255),`dir` varchar(255),`kind` varchar(255),`init` varchar(255),`mode` varchar(255),`cert-type` varchar(255),`ui` varchar(255),`exch` varchar(255),`rat-type` varchar(255),`c-gsn` varchar(40),`error_num` varchar(255),`u-gsn` varchar(40),`method` varchar(255),`phase2_name` varchar(255),`spi` varchar(255),`name` varchar(255),`c-sgsn` varchar(40),`request_name` varchar(255),`seq` varchar(255),`c-ggsn` varchar(40),`in_spi` varchar(255),`u-sgsn` varchar(40),`out_spi` varchar(255),`u-ggsn` varchar(40),`c-sgsn-teid` int unsigned default 0,`enc_spi` varchar(255),`c-ggsn-teid` int unsigned default 0,`dec_spi` varchar(255),`message_type` varchar(255),`malform_desc` varchar(255),`tunnel` varchar(255),`u-sgsn-teid` int unsigned default 0,`u-ggsn-teid` int unsigned default 0,`malform_data` int unsigned default 0,`tunnel-idx` int unsigned default 0,`line` varchar(255),`column` int unsigned default 0,`c-pkts` bigint unsigned default 0,`phone` varchar(255),`profile_group` varchar(255),`c-bytes` bigint unsigned default 0,`u-pkts` bigint unsigned default 0,`u-bytes` bigint unsigned default 0,`next_stat` int unsigned default 0,`user_data` varchar(255),`role` varchar(255),`result` varchar(255),`xauth_result` varchar(255),`esp_transform` varchar(255),`esp_auth` varchar(255),`error_reason` varchar(255),`peer_notif` varchar(255))

zakończy się niepowodzeniem, a serwer zwróci błąd:

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs

Nie chce mi się nawet liczyć ile bajtów to zajmuje. A wystarczyło dopisać CHARACTER SET latin1…

Podejrzewam, że po poprawnym założeniu tabeli dopisze się coś do table_ref, ale jest już zbyt późno, a ja mam za dużo lat, żeby dochodzić jak to powinno wyglądać.

Tak czy inaczej – inżynierowie Fortinet tracą jeden punkt.

LOCATE() na innym podwórku

guzik — Thu, 18 Mar 2010 21:00:56 +0000

Rozpędziłem się z tym wpisem dot. Blind SQL injection i nie wspomniałem o innych bazach. LOCATE() to oczywiście funkcja MySQL. PostgreSQL ma swoją POSITION(substing in string), a MS SQL – CHARINDEX(substring, string[, position]). Jest jeszcze INSTR(string, substring [,position [,occurrence]]) dla Oracle.

Innych nie znam, bo nie używałem. No, ale co tam z PHP może jeszcze być? SQLite? Ten akurat ma ograniczoną w ogóle liczbę funkcji (w dokumentacji nie znalazłem żadnego odpowiednika).

Koło fortuny (Blind SQL injection)

guzik — Thu, 18 Mar 2010 14:01:00 +0000

Od wczoraj przeglądam blog Michała Ławickiego i w komentarzach uzupełniam artykuły dot. baz danych (vide Analiza struktury bazy danych czy Obsługa plików, a SQL Injection). Dziś przyjrzałem się jego podejściu do Blind SQL injection czyli ataku na stronę, która nie wyświetla błędów.
Metoda na odgadywanie hasła znak po znaku jest rzeczywiście toporna. Biorąc pod uwagę 95 dostępnych znaków i hasło o długości 16, możliwych kombinacji jest dość sporo. Wysyłanie 1k5 zapytań zajmie trochę czasu. Dlatego można to zmodyfikować wstawiając pomiędzy LENGTH(passwd), a SUBSTRING(passwd, x, y) funkcję LOCATE(char, passwd), która pokaże jakie znaki mamy w ogóle dostępne (jak w teleturnieju – stąd temat wiadomości).

Nie znam się prawie w ogóle na atakach i bezpieczeństwie, ale wydaje mi się, że jeżeli ktokolwiek stosuje tą metodę, to pewnie chce sam proces skrócić do minimum. Tu LOCATE() wywołujemy maksymalnie 95 razy i jeśli się znaki w haśle nie powtarzają to po sprawie. Jeśli natomiast któryś się powtarza, możemy jeszcze raz wykonać tą funkcję, podając jako trzeci argument pozycję, od której zaczynamy szukać – LOCATE(char, passwd, pos), ew. męczymy SUBSTRING().

MySQL: konwersja daty i import plików – studium przypadku

guzik — Wed, 13 Jan 2010 14:07:28 +0000

Niniejszy wpis powstał przy rozwiązywaniu konkretnego problemu. Jest tu opis polecenia LOAD DATA INFILE (import danych z pliku) oraz sposób wykonania konwersji daty podczas importu danych, co może komuś się przydać (niekoniecznie przy walce z takim samym problemem).

Opis problemu: Potrzebujemy wyciągnąć wszystkie próby logowania z wykorzystaniem programu OTC Terminal konkretnego dnia, albo o konkretnej godzinie każdego dnia zdefiniowanego użytkownika.

Rozeznanie terenu: Wspomniany program tworzy log w następującym formacie:

4. BS2 LOGIN ERROR 25.03.2009 07:02:08 Password expired. 4. BS2 CHPWD OK 25.03.2009 07:02:16 Password for user 'BS2' successfully changed. 0. BS2 LOGIN OK 30.03.2009 06:54:25 1. BS2 LOGIN OK 30.03.2009 06:54:29 0. BS2 LOGOUT OK 30.03.2009 06:54:29 1. BS2 LOGOUT OK 30.03.2009 06:54:42 10. BS2 LOGOUT ERROR 24.04.2009 11:47:58 Login limit (session) 6. BS2 LOGIN ERROR 21.05.2009 14:32:57 No such name

Nie wnikam co oznacza pierwsza kolumna w logach, kolejne to: nazwa użytkownika, akcja, data oraz godzina, a także dodatkowa informacja dla akcji. Nie interesuje nas zarówno pierwsza, jak i ostatnia kolumna. Plik tekstowy ma kolumny o stałej szerokości (tutaj tego nie widać).
Do realizacji zadania można użyć awk, sed, grep, find (Windows) lub innych podobnych narzędzi w połączeniu z wyrażeniami regularnymi, ale można też skorzystać z bazy danych, która będzie przechowywać wspomniane informacje w konkretnym formacie, a samo przeszukiwanie będzie wygodniejsze, szybsze i bardziej elastyczne.

Realizacja: Za pomocą arkusza kalkulacyjnego przekształciłem logi w format CSV (najszybsze, co przyszło mi do głowy). Wyrzuciłem niepotrzebne kolumny. Utworzyłem tabelę w MySQL, która może wciągnąć te dane:

CREATE TABLE `trmlog` ( `user` char(3) NOT NULL, `action` varchar(24) DEFAULT NULL, `date` date DEFAULT NULL, `time` time DEFAULT NULL, KEY `useridx` (`user`), KEY `dateidx` (`date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Data i godzina są osobno. Jako, że data ma postać DD.MM.YYYY, a chcemy YYYY-MM-DD, stworzyłem funkcję, która może to skonwertować (nie wiem czy MySQL w locie coś może sam zrobić):

delimiter //

CREATE FUNCTION dateconv (date CHAR(10)) RETURNS DATE BEGIN RETURN CONCAT(SUBSTRING(date, 7), "-", SUBSTRING(date, 4, 2), "-", SUBSTRING(date, 1, 2)); END//

delimiter ;

I ostatecznie zaimportowałem dane:

LOAD DATA INFILE 'E:\\temp\\termlog\\log.csv' INTO TABLE trmlog FIELDS TERMINATED BY ';' (user, action, @var1, time) SET date = dateconv(@var1);

Uwagi wymaga proces konwersji kolumny z datą. Domyślnie LOAD DATA INFILE zakłada, że każde pole w pliku CSV odpowiada jednej kolumnie w tabeli. Jeśli chcemy zaimportować dane tylko do niektórych kolumn, musimy podać ich nazwy (czy sam ich porządek). Jeśli natomiast chcemy je w jakiś sposób przekształcić, używamy klauzuli SET, która może przybrać różne formy. Po przykłady odsyłam do dokumentacji MySQL. U mnie wygląda to tak, że do kolumny date wciągamy dane, które wyrzuci nam (nasza własna) funkcja dateconv(). Może nie do końca intuicyjne, ale nie tak trudne.
Dalej obrabiamy to jak chcemy w SQL.

Oczywiście nie musimy używać MySQL, a jeśli już użyliśmy, zawsze możemy migrować do innej bazy:

Microsoft chce pomóc w migracji z MySQL-a na SQL Server

Trochę Lua w mysql-proxy

guzik — Mon, 02 Nov 2009 12:31:38 +0000

Replikacja baz MySQL działa jako tako. Jeśli to typ MASTER – SLAVE, to na ogół ten drugi serwer się nudzi. Skoro się nudzi, można wykorzystać go do zapytań, które nie zmieniają niczego (SELECT). Jeśli oddamy go w takim stanie programiście, to pewne jest, że prędzej czy później będzie to jego serwer testowy i dziać się będą na nim różne rzeczy.

Pewnie sposobów na ograniczenie tego jest parę, ja zrobiłem to wykorzystując mysql-proxy i odpowiedni skrypt Lua. A wygląda to tak:

function read_query( packet ) -- local log_file = '/var/log/mysql-proxy.log' -- local fh = io.open(log_file, 'a+') if string.byte(packet) == proxy.COM_QUERY then local query = string.sub(packet, 2) if not (string.match(string.upper(query), '^%s*SELECT') or string.match(string.upper(query), '^%s*SHOW')) then -- fh:write(string.format("%s %s\t%s\t%s\t%s\n", os.date('%Y-%m-%d %H:%M:%S'), proxy.connection.client.address, proxy.connection.client.username, proxy.connection.client.default_db, query)) proxy.response.type = proxy.MYSQLD_PACKET_ERR proxy.response.errmsg = "Only SELECT and SHOW queries are available" return proxy.PROXY_SEND_RESULT end end -- fh:flush() end

W powyższym kodzie zakomentowałem linijki odpowiadające za logowanie wszystkiego, co nie zaczyna się od SELECT lub SHOW.

Przy okazji poznałem głębiej jak działają takie skrypty (kiedyś coś tam już grzebałem). Do tego doszedłem:

proxy.queries to kolejka zapytań, które sami (w skrypcie) stworzymy. reset() nie usunie nam zapytania, które przesyła klient (tym samym len() zawsze pokaże 0),
jeżeli nie będziemy manipulować kolejką, to do serwera zawsze dojdzie to co wysłał klient,
manipulować kolejką możemy poprzez np. append(), a następnie wysyłać zapytania przez proxy.PROXY_SEND_QUERY,
możemy zupełnie pominąć to co wysyła klient i przygotować dla niego własną odpowiedź lub błąd (jak w skrypcie wyżej).

Warto zajrzeć na:

nagios: check_mysql-replication.pl

guzik — Thu, 22 Oct 2009 11:27:49 +0000

Do monitorowania replikacji MySQL pod Nagios postanowiłem użyć wtyczki mysql_check-replication.pl, ktrej autorem jest Erwan Labynocle Ben Souiden. Instrukcja mówi o nadaniu prawa REPLICATION CLIENT użytkownikowi, który łączył się będzie z bazą. Sam skrypt napisany jest w Perl, gdzie w DSN podana jest baza, do której użytkownik będzie się podłączał. Wspomniane prawa dają tylko możliwość wywołania SHOW MASTER STATUS oraz SHOW SLAVE STATUS i nie dają praw do żadnej bazy. Tym samym skrypt się nie wykona.

Proponuję (wersja 0.1) przerobić DSN (linia 298) i wyrzucić nazwę bazy zupełnie (pozostawić `:’ – dwukropek) lub zmienić nazwę na information_schema, bo do tego prawo ma każdy użytkownik (dla wersji > 5.0).

--- /usr/lib64/nagios/plugins/check_mysql-replication.pl 2009-10-22 13:17:26.000000000 +0200 +++ check_mysql-replication.pl 2009-10-22 13:17:33.000000000 +0200 @@ -295,7 +295,7 @@ EOT # ------------------------------ sub request_executor() { my ($host,$port,$user,$pwd,$request) = @_; - my $dsn = "DBI:mysql:mysql;host=$host:$port"; + my $dsn = "DBI:mysql:;host=$host:$port"; my $dbh = DBI->connect($dsn, $user, $pwd) or die "connexion failed $DBI::errstr\n"; my $sth = $dbh->prepare($request); $sth->execute();

Autor obiecał, że wprowadzi stosowną poprawkę – tymczasem można łatać.

MS SQL 2008

guzik — Tue, 01 Sep 2009 09:00:49 +0000

Przeniosłem bazy Płatnika i Pudełko z MSDE 2000 na MS SQL 2008 (Express). Nic trudnego, ale dostawcy obu rozwiązań nie wspierają (jeszcze) oficjalnie tej bazy, wiec można mieć wątpliwości. Działa poprawnie, łącznie ze zmianą poziomu kompatybilności baz.

ALTER DATABASE [platnik] SET COMPATIBILITY_LEVEL = 100 GO ALTER DATABASE [pudelko] SET COMPATIBILITY_LEVEL = 100 GO

Przeniesienie w najprostszy z możliwych sposobów – detach i attach. Pamiętać należy, że jeśli nie uwierzytelniamy się na sa (!!!), w nowej instancji założyć trzeba login i powiązać go z użytkownikiem w bazie. Co ciekawe przy robieniu tego z GUI (Microsoft SQL Server Management Studio) możemy wybrać istniejącego użytkownika, a narzędzie będzie próbowało go założyć (CREATE) zamiast zmienić (ALTER) i zgłosi błąd (login zostanie założony, ale mapowania nie będzie). Dla niedomyślnych pomocny przykład:

USE [pudelko] GO ALTER USER [opek] WITH LOGIN = [opek] GO

MySQL slow_queries

guzik — Tue, 10 Feb 2009 19:49:15 +0000

Już kiedyś płakałem z tego powodu – Analiza log-slow-queries (z życia wzięte…), a tu stary klient narzeka na wydajność swojego serwera. I co my tu mamy?

tabela 1 – 117’608 wierszy,
tabela 2 – 730 wierszy,
tabela 3 – 709 wierszy.

Niby niewiele, ale da się z tego zrobić taki wynik:

# Query_time: 11'005 Lock_time: 0 Rows_sent: 1 Rows_examined: 88'891'086

Dla porównania 10 miesięcy temu to samo zapytanie:

# Query_time: 53 Lock_time: 0 Rows_sent: 615 Rows_examined: 8'674'949

Nie mam pytań. Zdecydowanie potrzeba nowego procesora, więcej pamięci i szybszych dysków. Programisty przecież nie przekonamy…

DBD::Sybase na Gentoo

guzik — Wed, 24 Dec 2008 10:59:59 +0000

Gdyby ktoś chciał robić DBD::Sybase (ja potrzebowałem do monitorowania bazy MS SQL) na Gentoo, to poniżej Manifest (dla 1.07 i 1.09):

DIST DBD-Sybase-1.07.tar.gz 189553 SHA1 881fc8f1c65e39e8537f4cc2e93308caeab87eed SHA256 be41f930fda27447b520773a1461ba3f43d20e0a859bef0504c40f3f3fe067b0 DIST DBD-Sybase-1.09.tar.gz 194414 SHA1 23cad59ab7892732175336087093b1e3c2bda09a SHA256 516d44567f1c76aa6aba76879a371d3a44f4a69da3b06b304f375eb57bb2daf1 EBUILD DBD-Sybase-1.07.ebuild 669 SHA1 03a85b4da544032957b312dde5b0cf44e910e562 SHA256 14a2eca747ad29e297299ad3282e9f000a6e61f5eb63783f9c79f481250c465a EBUILD DBD-Sybase-1.09.ebuild 661 SHA1 8719cb6544289ed71d74d9a06c8cab5a60ba021d SHA256 e49e709405fc2b5c3ddf4bf1d27be1925c47446b1b2927b09dad571079aba93b

Ebuild można pobrać z Gentoo Bug (42040 – DBD-Sybase-1.02 (new package)). Przeróbka tego do 1.09 nie powinna być problemem.
Oczywiście wszystko do /usr/portage/dev-perl/DBD-Sybase.

DBD::Oracle – problem z kompilacją

guzik — Wed, 24 Dec 2008 08:14:30 +0000

Budowałem DBD::Oracle na Gentoo 1.12.11.1 (Linux 2.6.18-xen-r12 x86_64), ale nie wyszło. Błędy po make:

[...] x86_64-pc-linux-gnu-gcc -c -I/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux/auto/DBI -I../ -DLINUX -D_GNU_SOURCE -D_REENTRANT -g -fno-strict-aliasing -pipe -Wdeclaration-after-statement -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -pipe -march=nocona -DVERSION=\"1.22\" -DXS_VERSION=\"1.22\" -fPIC "-I/usr/lib64/perl5/5.8.8/x86_64-linux/CORE" -Wall -Wno-comment -DUTF8_SUPPORT -DNEW_OCI_INIT -DORA_OCI_VERSION=\"10.2.0.3\" Oracle.c In file included from Oracle.xs:1: Oracle.h:37:17: error: oci.h: No such file or directory Oracle.h:38:22: error: oratypes.h: No such file or directory Oracle.h:39:20: error: ocidfn.h: No such file or directory [...]

Rzeczywiście nigdzie nie ma ścieżki do katalogu z oci.h. Po instalacji dev-db/oracle-instantclient-basic (na Gentoo) wszystkie pliki nagłówkowe są w /usr/lib64/oracle/10.2.0.3/client/include. Żeby budowanie się powiodło, do x86_64-pc-linux-gnu-gcc trzeba dodać tą ścieżkę (-I).

Wszystko po to, by z Nagios można było monitorować stan Oracle (poprzez check_oracle_health).