• 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.

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:

Replikacja baz MySQL

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:

• Lua 5.1 Reference Manual
• Getting started with MySQL Proxy

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ć.

• 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…

Postanowiłem przyjrzeć się temu w połączeniu z PostgreSQL i MySQL z C/C++ i Perl API. Wersja 0.39.4.
Jest w portach dla FreeBSD, nie ma w paczkach dla Gentoo. Potrzebuje dodatkowej biblioteki Rudiments (devel/rudiments we FreeBSD, dev-cpp/rudiments w Gentoo) i jeśli chcemy jakiegoś API, to odpowiednio: Perl, PHP, Python, Ruby, TCL, Java lub Zope. GTK+ i glib da nam GUI.

Konfiguracja nietrudna – w pliku XML. W tagu instance definiujemy proces nasłuchu. Tag user to definicje użytkowników wraz z hasłami. Na koniec tag connection, który wskazuje konfigurację do konkretnej bazy.
W bardziej złożonej konfiguracji mamy jeszcze router i filter. Pierwszy tag odpowiada za kierowanie zapytań do odpowiedniej bazy, drugi – za filtrowanie zapytań (zdefiniowane nie będą w ogóle przesyłane do serwera, a klient dostanie błąd). W obu przypadkach jest możliwość dopasowania zapytań za pomocą wyrażeń regularnych.

Jeżeli uruchamiamy SQL Relay za pomocą sqlr-start, musimy pamiętać, że wszystkie programy, które wywołuje, np. sqlr-listener muszą być w ścieżce ($PATH). Baza również musi działać. Jeśli nie, pozostaje walka z czyszczeniem shared memory segment i semaphore (ipcs, ipcrm), bo SQL Relay nie sprząta po sobie.

Na tym skończyłem walkę. To znaczy próbowałem uruchomić SQL Relay zarówno z MySQL jak i PostgreSQL, ale niestety zakończyło się to niepowodzeniem (SQL Relay nasłuchiwał, przy połączeniu cisza). Mam nadzieję, że kiedyś wrócę do tego tematu.

Przepraszam, jeśli ktoś był pełen nadzieji, że czegoś się dowie z tego artykułu. Zmieniłem pracę i już nie robię tego co robiłem, więc wiele rzeczy pozostało niedokończonych…

Uruchomienie samego serwera (również przy założeniu, że skompilowany ze wsparciem SSL) sprowadza się do podania dodatkowych parametrów w linii komend. Przykładowo może to wyglądać tak:

mysqld --defaults-file=/etc/mysql/my.cnf --ssl --ssl-ca=</path/to/CA.crt> --ssl-cert=</path/to/file.crt> --ssl-key=</path/to/file.key>

Ewentualnie odpowiednie parametry podać w pliku konfiguracyjnym (my.cnf):

ssl-ca = </path/to/CA.crt>
ssl-cert =</path/to/file.crt>
ssl-key =</path/to/file.key>

Pamiętać należy, że w przypadku, gdy certyfikat jest zabezpieczony hasłem, MySQL może być jedynie uruchomiony ręcznie. Korzystając ze skryptów startowych (na pewno w Gentoo Linux) czy nawet wrzucając proces w tło (&) serwer nie skorzysta z certyfikatu i nie nawiążemy szyfrowanej transmisji. Próba takiego uruchomienia zakończy się podobnym wpisem w logach:

[Warning] Failed to setup SSL

Testowe połączenie do serwera z konsoli mysql możemy wykonać podając jedynie ścieżkę do certyfikatu CA (format PEM), np.

mysql -h <host> -u <user> -p --ssl-ca=</path/to/CA.crt> <database>

Wywołując STATUS możemy sprawdzić czy bieżące połączenie ma wsparcie SSL:

SSL:            Cipher in use is DHE-RSA-AES256-SHA

czy też nie:

SSL:            Not in use

Wymuszanie szyfrowanych połączeń możliwe tylko poprzez REQUIRE SSL przy nadawaniu praw użytkownikowi (GRANT). W takim przypadku połączenie bez SSL zakończy się komunikatem podobnym jak w przypadku np. podania błędnego hasła:

ERROR 1045 (28000): Access denied for user 'exg'@'192.168.1.101' (using p assword: YES)

Więcej o używaniu SSL w MySQL można poczytać tutaj:

• MySQL 5.0 Reference Manual :: 5.5.7.2 Using SSL Connections

Wracając do samej funkcji mysql_ssl_set(), to jako parametry przyjmuje: uchwyt połączenia zwrócony przez mysql_init(), ścieżkę do pliku klucza, certyfikatu i certyfikatu CA oraz ścieżkę do katalogu z certyfikatami CA w formacie PEM, a także listę wspieranych algorytmów.
Nieużywane parametry powinny przyjmować wartość NULL.
Funkcja zawsze zwraca 0, o błędach SSL informuje mysql_real_connect().

ERROR 2026 (HY000): SSL connection error

Na koniec łyżka dziegciu – libmysql (i klient mysql) dla Windows (ten z binarnej paczki) nie jest skompilowany z obsługą SSL. Aby korzystać z bezpiecznych połączeń należy pobrać źródła i samodzielnie dokonać kompilacji. Mi się nie udało… Może przez zbyt stare Visual C++.

CREATE TABLE `mix_stats` (
`id` int(11) NOT NULL auto_increment,
`id_produktu` decimal(20,0) NOT NULL default ’0′,
`data` date default NULL,
`count` decimal(1,0) NOT NULL default ’0′,
`session` varchar(255) NOT NULL default ”,
`ip` varchar(20) NOT NULL default ”,
`referer` varchar(255) NOT NULL default ”,
PRIMARY KEY  (`id`)
) TYPE=MyISAM

MySQL 3.23, w logach następujące wpisy:

# Time: 080726 10:40:51
# User@Host: xxx[xxx] @ localhost []
# Query_time: 48  Lock_time: 0  Rows_sent: 1  Rows_examined: 639552
SELECT count(id) FROM mix_stats WHERE id_produktu = ’84092324382e93e’ AND session = ”;

Jeżeli ktoś jest na tyle cierpliwy, by czekać 48 sekund na wynik, to musi mu bardzo zależeć…

Analizę bazy wykonywałem na MySQL 5.0.60, więc mam większe pole do popisu, np.:

mysql> SELECT count(id) FROM mix_stats WHERE id_produktu = '84092324382e93e' AND session = '';
+-----------+
| count(id) |
+-----------+
|         0 |
+-----------+
1 row in set, 65535 warnings (0.99 sec)

mysql> SHOW WARNINGS LIMIT 3;
+---------+------+-----------------------------------------------------+
| Level   | Code | Message                                             |
+---------+------+-----------------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: '84092324382e93e' |
| Warning | 1292 | Truncated incorrect DOUBLE value: '84092324382e93e' |
| Warning | 1292 | Truncated incorrect DOUBLE value: '84092324382e93e' |
+---------+------+-----------------------------------------------------+
3 rows in set (0.00 sec)

Na początek polecam: DECIMAL. Choć pewnie skończy się przejściem do innego usługodawcy, gdzie mocniejsza maszyna bazodanowa przemieli to szybciej (ostrzeżenia i błędy i tak użytkowników nie interesują)…

MySQL oprócz funkcji INET_ATON() i INET_NTOA() nie oferuje nic więcej, ale to i tak lepsze niż przechowywanie adresów w CHAR(15) czy VARCHAR(15). Wskazany typ kolumny to UNSIGNED INT, a konwersja przy wstawianiu rekordów czy ich pobieraniu właśnie za pomocą wspomnianych funkcji.

PostgreSQL daje nam następujące typy danych: cidr, inet i dodatkowo macaddr (do przechowywania adresów MAC). Umożliwia także łatwe zarządzanie danymi za pomocą operatorów i funkcji.

Oczywiście sposób przechowywania adresu IP na pewno nie powinien być kryterium wyboru silnika baz danych, ale może być drobnym argumentem.

Do przeanalizowania kwestia szybkości przeszukiwania, indeksowania i wielkości danych.

Do poczytania:

• Arjen’s Journal – Storing an IP address in a database table

Prosty sposób – REVOKE i telefon. Mało elegancki! My szukamy czegoś na poziomie ;-)

Od pewnego czasu śledzę projekt mysql-proxy. Wprawdzie już jakiś czas projekt jest nieuaktualniany (At revision 511.), ale mam nadzieję, że Jan Kneschke cały czas pracuje…

Początkowo używałem mysql-proxy jako typowego pośrednika, co było pomocne przy przenoszeniu baz (sporo klientów łączyło się przez UNIX socket). Nie sprawdzał się za dobrze (ostatnia testowana wersja nie zawsze łączyła z PHP, wcześniejsze miały duże problemy ze stabilną pracą w ogóle). Na podobny projekt – pgpool-II (dla PostgreSQL) nie narzekałem nigdy. Niemniej z racji długości życia nie ma ich co porównywać.

Dla śledzenia użytkowników z tematu napisałem skrypt (LUA), który każde połączenie zapisuje do pliku dziennika (można przerobić na zapisywanie do bazy + jakiś licznik). Informacją wystarczającą jest IP klienta, nazwa użytkownika oraz baza, do której się podłączył. Do posprzątania nic więcej nas nie interesuje.
Sposób uruchomienia mysql-proxy opisany jest w dokumentacji, więc warto tam zajrzeć.
Skrypt wygląda tak:

local log_file = ‘/tmp/mysql.log’
local fh = io.open(log_file, „a+”)

function read_auth_result(auth)
if auth.packet:byte() == proxy.MYSQLD_PACKET_OK then
fh:write(
string.format(„%s %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))
end
fh:flush()
end

Ze struktury proxy.connection.client przyda nam się address (adres IP klienta), username (nazwa uzytkownika) oraz default_db (baza, do której zostało wykonane połączenie). Jest jeszcze scrambled_password, ale logowanie tego podpada pod inwigilację. Logujemy tylko uwierzytelnionych użytkowników (MYSQLD_PACKET_OK – 0, ale jest jeszcze możliwość użycia MYSQLD_PACKET_ERR – 255). I w wyniku otrzymujemy:

2008-07-18 11:52:40 127.0.0.1:43228    root    test
2008-07-18 12:00:16 127.0.0.1:62133    exg    exg
2008-07-18 12:00:32 127.0.0.1:62901    root    mysql
2008-07-18 12:07:54 10.74.0.254:11243 guzik
2008-07-18 12:08:00 10.74.0.254:16369 guzik test

Log bez bazy, to połączenie z konsoli. \u czy USE nie loguje się w ogóle.
Po długoterminowym zbieraniu informacji (do miesiąca) mamy już listę wykorzystywanych baz. Pozostaje dump i DROP :>

Pamiętajmy też, że baza widzi połączenie z mysql-proxy, więc należy dać stosowne uprawnienia dla tego hosta.

Więcej do poczytania:

• MySQL :: MySQL 5.0 Reference Manual :: 16.4 MySQL Proxy Scripting
• MySQL :: Getting started with MySQL Proxy
• Mystic’s Random Blog » (partial) MySQL Proxy API Doc