Wir sammeln Protokolle der Mikrotik-Firewall in einer Datenbank

Guten Tag.

Ich möchte Ihnen sagen, wie einfach und natürlich Sie einen Metadatenerfassungsserver für den Netzwerkverkehr für Mikrotik-Router konfigurieren können.

Zweck: Das Ziel besteht darin, die "gekauten" Firewall-Protokolle zur weiteren Analyse in einer Datenbank zu speichern.

Mittel: Jede neue Linux-Distribution mit rsyslogd v8 und höher ist für die Implementierung geeignet. Möglicherweise funktioniert die vorgeschlagene Syntax auch unter v7. Wir brauchen auch ein DBMS, ich habe Mariadb gewählt. Das Datenbankwachstum hängt von der Anzahl der protokollierten Regeln ab, da die Größe des Laufwerks in Ihrem Ermessen liegt. In meinem Fall werden 30 bis 40 Regeln protokolliert, was ungefähr 1200.000 Zeilen pro Tag entspricht. Während des Monats der Nutzung der Datenbank, einschließlich der Indizes, wuchs sie auf 3,8 GB.

Mechanik: Der Router sendet ein Protokoll über UDP an den Remote-Server. Mit regulären Ausdrücken bereinigt der rsyslog-Server Zeichenfolgen von unnötigen Informationen, generiert eine SQL-Einfügung und sendet sie an das DBMS. Das DBMS führt vor dem Einfügen mithilfe eines Triggers eine zusätzliche Bereinigung und Trennung von Feldern durch, die in rsyslog nicht analysiert werden konnten.

Konfigurieren Sie RSYSLOG


Bearbeiten der Datei /etc/rsyslog.conf
Fügen Sie dort die folgenden Zeilen hinzu:

module(load="ommysql") module(load="imudp") input(type="imudp" port="514") 

Daher laden wir die erforderlichen Module und öffnen den 514 UDP-Port.

Die Protokollzeile von Mikrotik sieht folgendermaßen aus:

 20180927155341 BLOCKSMKNETS forward: in:ether6 - LocalTORF out:VLAN55 - RT_INET, src-mac 00:15:17:31:b8:d7, proto TCP (SYN), 192.168.0.234:2457->192.168.6.14:65535, len 60 

Wie Sie sehen können, wird es schwierig sein, viel mehr für die Speicherung in der Datenbank und eine klare Auswahl zu benötigen.
Theoretisch muss ich solche Daten hinzufügen:

 20180927155341 ether6 VLAN5 192.168.0.234 2457 192.168.6.14 65535 00:15:17:31:b8:d7 TCP SYN forward BLOCKSMKNETS 60 

Ich konnte eine solche Zeile nicht mit nur einem rsyslog erhalten. Rsyslog-Stammgäste verwenden POSIX ERE / BRE, daher gibt es keine Möglichkeit, Funktionen wie Lookahead oder Lookbehind anzuwenden.

Es gibt ein Tool, mit dem Sie Stammgäste debuggen und ausprobieren können. Vielleicht können Sie den Port von der Adresse sowie den Namen der Schnittstelle von in: und out: trennen. Denken Sie daran, dass einige Sport- und Dport-Protokolle fehlen.

Im Allgemeinen war meine Ausgabe wie folgt:

 20180927155341 in:ether6 out:VLAN5 192.168.0.234:2457 192.168.6.14:65535 00:15:17:31:b8:d7 TCP (SYN) forward BLOCKSMKNETS 60 

Es gibt eine Dokumentation zum Kochen von rsyslog-Stammgästen.

Im endgültigen Formular sieht die Konfigurationsdatei für den Empfang des Protokolls von Mikrotik /etc/rsyslog.d/20-remote.conf folgendermaßen aus:

 $template tpl_traflog,"insert into traflog.traffic (datetime, inif, outif, src, dst, smac, proto, flags, chain, logpref, len) values ('%timereported:::date-mysql%', '%msg:R,ERE,0,DFLT,0:in:[a-zA-Z]+[0-9]+|in:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,BLANK,0:out:[a-zA-Z]+[0-9]+|out:<[a-zA-Z]+-[a-zA-Z]+>--end%', '%msg:R,ERE,0,DFLT,0:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,DFLT,1:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end%', '%msg:R,ERE,0,BLANK:([0-f]+:){5}[0-f]+--end%', '%msg:R,ERE,0,BLANK:\b[AX]{3,4}\b--end%', '%msg:R,ERE,0,BLANK:\([AZ]+\)|\(([AZ]+\,){1,3}[AZ]+\)--end%', '%msg:R,ERE,0,DFLT:[ax]+--end%', '%msg:F,32:2%', '%msg:R,ERE,0,DFLT:[0-9]+$--end%' )",SQL if ($fromhost-ip == '192.168.0.230') and ($syslogtag contains "firewall") then {action(type="ommysql" server="localhost" serverport="3306" db="traflog" uid="rsyslogger" pwd="rsyslogger" template="tpl_traflog") stop} 

In der ersten Zeile ist die Beschreibung der Vorlage (Vorlage) eine Zeile mit SQL-Code zum Übertragen an das DBMS.
Die zweite Zeile ist die Bedingung, unter der die Aktion ausgeführt wird, dh der Datensatz im DBMS.
Die Bedingung sieht folgendermaßen aus: Wenn die Protokollquelle = 192.168.0.230 ( if ($fromhost-ip == '192.168.0.230') ) und wenn die Nachrichtenzeile "Firewall" enthält (und ($ syslogtag "Firewall" enthält), verwenden Sie das Modul ommysql mit Verbindungsparametern ( then {action(type="ommysql" server="localhost" serverport="3306" db="traflog" uid="rsyslogger" pwd="..." ) rufen wir die Vorlage tpl_traflog ( template="tpl_traflog") ), und danach stoppen wir die weitere Verarbeitung der Zeile ( stop} ).

Es ist möglich, dass in Ihrem Fall etwas schief geht. Dies kann an den Namen der Schnittstellen oder Protokollpräfixen liegen, möglicherweise an etwas anderem. Zum Debuggen gehen wir wie folgt vor, kommentieren die zweite Zeile, fügen eine neue Vorlage und zwei neue Bedingungen hinzu:

 $template tpl_traflog_test,"%timereported:::date-mysql% %msg:R,ERE,0,DFLT,0:in:[a-zA-Z]+[0-9]+|in:<[a-zA-Z]+-[a-zA-Z]+>--end% %msg:R,ERE,0,BLANK,0:out:[a-zA-Z]+[0-9]+|out:<[a-zA-Z]+-[a-zA-Z]+>--end% %msg:R,ERE,0,DFLT,0:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end% %msg:R,ERE,0,DFLT,1:([0-9]+\.){3}[0-9]+[:]?([0-9]+)?--end% %msg:R,ERE,0,BLANK:([0-f]+:){5}[0-f]+--end% %msg:R,ERE,0,BLANK:\b[AX]{3,4}\b--end% %msg:R,ERE,0,BLANK:\([AZ]+\)|\(([AZ]+\,){1,3}[AZ]+\)--end% %msg:R,ERE,0,DFLT:[ax]+--end% %msg:F,32:2% %msg:R,ERE,0,DFLT:[0-9]+$--end%\n" if ($fromhost-ip == '192.168.0.230') then {action(type="omfile" file="/var/log/remote/192.168.0.230.log" )} if ($fromhost-ip == '192.168.0.230') then {action(type="omfile" file="/var/log/remote/192.168.0.230.log" template="tpl_traflog_test" ) stop} 

Starten Sie den Logger neu.

Die Vorlage tpl_traflog_test ähnelt tpl_traflog, jedoch ohne SQL INSERT.

Die erste Bedingung fügt der Datei /var/log/remote/192.168.0.230.log die unverarbeitete Zeile% msg% hinzu, da die Vorlage nicht angegeben ist.

Die zweite Bedingung fügt die verarbeitete Zeile derselben Datei hinzu.
So wird es bequemer zu vergleichen.
Bereiten Sie als Nächstes die Datenbank vor.

Wir bereiten eine DB vor


Wir werden die DBMS-Einstellung verringern, hier ist alles Standard.

Wir starten die MySQL-Konsole und führen den folgenden Code aus:

 --   create database traflog character set utf8 collate utf8_bin; use traflog; --  create table traffic (id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, datetime DATETIME, inif VARCHAR(20), outif VARCHAR(20), src VARCHAR(21), sport INT(5), dst VARCHAR(21), dport INT(5), smac VARCHAR(17), proto VARCHAR(4), flags VARCHAR(11), chain VARCHAR(8), logpref VARCHAR(24), len INT(5)) ENGINE=MYISAM; --  create user rsyslogger@localhost identified by '...'; grant all privileges on traflog.* to rsyslogger@localhost; 

Die Tabelle ist fertig, der Benutzer ist.

Fügen Sie nun einen Trigger hinzu, der das tut, was der Logger nicht konnte, um die Adresse vom Port zu trennen, die Namen der Schnittstellen zu bereinigen und die Klammern vom Flag zu entfernen:

 --   traffic DELIMITER // create TRIGGER delim_ip_port_flags BEFORE insert ON traffic FOR EACH ROW begin set NEW.inif = REGEXP_REPLACE ((NEW.inif), 'in:', '' ); set NEW.outif = REGEXP_REPLACE ((NEW.outif), 'out:', '' ); set NEW.sport = REGEXP_REPLACE ((NEW.src), '([0-9]+\.){3}[0-9]+:|([0-9]+\.){3}[0-9]+', '' ); set NEW.src = REGEXP_REPLACE ((NEW.src), ':[0-9]+', '' ); set NEW.dport = REGEXP_REPLACE ((NEW.dst), '([0-9]+\.){3}[0-9]+:|([0-9]+\.){3}[0-9]+', '' ); set NEW.dst = REGEXP_REPLACE ((NEW.dst), ':[0-9]+', '' ); set NEW.flags = REGEXP_REPLACE ((NEW.flags), '\\(|\\)', '' ); end // delimiter ; 

REGEXP_REPLACE sucht nach dem zweiten Parameter nach dem Dezimalpunkt (reguläre Saison) und ersetzt ihn durch den dritten Parameter. In unserem Fall enthält das Anführungszeichen nichts. Daher wird einfach entfernt, was gefunden wurde.

Lassen Sie uns eine Testeinfügung erstellen, ähnlich wie der Logger:

 --   insert into traffic (datetime, inif, outif, src, dst, smac, proto, chain, logpref) values (20180730075437, 'in:ether6', 'out:VLAN55', '192.168.0.234:4997', '192.168.6.18:65535', '00:15:17:31:b8:d7', 'TCP', '(SYN)', 'forward', 'BLOCKSMKNETS'); 

Mal sehen, was passiert ist:

 select * from tarffic; 

Wenn alles korrekt ist, fahren Sie fort. Wenn nicht, suchen Sie nach dem Fehler.

Fügen Sie mindestens einen Index hinzu. Ich bin kein Meister im Erstellen von Indizes, aber so wie ich es verstehe, ist es in MySQL korrekter, Indizes mit unterschiedlichen Verknüpfungsfeldern für unterschiedliche Abfragen zu verwenden, da eine Abfrage nur einen Index verwenden kann (oder irre ich mich?). Wenn Sie verstehen, tun Sie es nach Ihrem Ermessen.
Ich muss oft Anfragen mit einem bestimmten Präfix stellen, deshalb habe ich diesen Index hinzugefügt:
 --  create index traffic_index on traffic (datetime,logpref,src); 

Fertig.

Jetzt müssen Sie mit dem Senden auf dem Router beginnen, die Einstellungen und Aktionen des Remote-Protokollservers hinzufügen, die Protokolloption zu einer der Firewall-Regeln hinzufügen und ein Präfix von nicht mehr als 24 Zeichen hinzufügen.

In der Mikrotik-Konsole sieht es ungefähr so ​​aus:

 /system logging action set 3 remote=192.168.0.94 src-address=192.168.0.230 add name=remote2 remote=192.168.0.19 syslog-facility=local6 target=remote /system logging add action=remote topics=error,account,critical,event,info add action=remote2 topics=firewall /ip firewall filter ... add action=drop chain=input comment="drop ssh brute forcers" dst-port=22,8291 log=yes log-prefix=DROP_SSH_BRUTE protocol=tcp src-address-list=ssh_blacklist ... 

Während 192.168.0.230 die Adresse des Routers ist, 192.168.0.19 die Adresse des Protokollservers für die Firewall-Protokolle ist und 192.168.0.94 ein anderer Protokollserver ist, liegen Mikrotik-Systemprotokolle dort, wir brauchen sie jetzt nicht. Unser Setup ist remote2.

Als nächstes sehen Sie, was in die Datei fällt:

 tail -f /var/log/remote/192.168.0.230.log 

Zeilen vom Router sollten in die Datei gestreut werden, es sei denn, Ihre Regel wird häufig ausgelöst.

Wenn einige Felder fehlen, dh die Sequenz datetime, inif, outif, src, dst, smac, proto, flags, chain, logpref, len nicht befolgt wird, können Sie versuchen, den Parameter in den Debugging-Vorlagen des Loggers zu ändern und BLANK durch DLFT zu ersetzen. Anstelle der Leere eines Feldes erscheinen dann einige Buchstaben. Ich kann mich nicht erinnern, welche bereits vorhanden sind. In diesem Fall stimmt etwas mit dem regulären Zeitplan nicht und Sie müssen ihn beheben.

Wenn alles so lief, wie es sollte, schalten Sie die Testbedingungen und die Vorlage aus.

Sie müssen auch die Standardkonfiguration in /etc/rsyslog.d/ ausführen. Ich habe sie in 50-default.conf umbenannt, damit Remote-Protokolle nicht in das Systemprotokoll / var / log / message eingefügt werden
Starten Sie den Logger neu.

Warten wir etwas, bis unsere Datenbank voll ist. Dann können wir mit der Auswahl beginnen.

Einige Fragen zum Beispiel:

So zeigen Sie die Größe der Datenbank und die Anzahl der Zeilen an:
 MariaDB [traflog]> select table_schema as "database", round(sum(data_length + index_length)/1024/1024,2) as "size Mb", TABLE_ROWS as "count rows" from information_schema.tables group by table_schema; +--------------------+---------+------------+ | database | size Mb | count rows | +--------------------+---------+------------+ | information_schema | 0.17 | NULL | | traflog | 3793.39 | 21839553 | +--------------------+---------+------------+ 2 rows in set (0.48 sec) 

In einem Monat sind fast 4 GB gewachsen, dies hängt jedoch von der Anzahl und den Eigenschaften der protokollierten Firewall-Regeln ab

Anzahl der protokollierten Präfixe
Die Anzahl der protokollierten Präfixe entspricht nicht der Anzahl der Regeln. Einige Regeln arbeiten mit einem Präfix, aber wie viele Gesamtpräfixe gibt es noch? und wie viele Regeln wurden für sie ausgearbeitet?:

 MariaDB [traflog]> select logpref,count(logpref) from traffic group by logpref order by count(logpref) desc; +----------------------+----------------+ | logpref | count(logpref) | +----------------------+----------------+ | ACCEPT_TORF_INET | 14582602 | | ACCEPT_SMK_PPP | 1085791 | | DROP_FORWARD_INVALID | 982374 | | REJECT_BNK01 | 961503 | | ACCEPT_MMAX_TORF | 802455 | | ACCEPT_TORF_PPP | 736803 | | SMTP_DNAT | 689533 | | ACCEPT_SMK_INET | 451411 | | ACCEPT_INET_TORF | 389857 | | BLOCK_SMKNETS | 335424 | | DROP_SMTP_BRUTE | 285850 | | ACCEPT_ROZN_TORF | 154811 | | ACCEPT_TORF_MMAX | 148393 | | DROP_ETHALL_ETHALL | 80679 | | ACCEPT_SMTP | 48921 | | DROP_SMTP_DDOS | 32190 | | RDP_DNAT | 28757 | | ACCEPT_TORF_ROZN | 18456 | | SIP_DNAT | 15494 | | 1CWEB_DNAT | 6406 | | BLOCKSMKNETS | 5789 | | DROP_SSH_BRUTE | 3162 | | POP_DNAT | 1997 | | DROP_RDP_BRUTE | 442 | | DROP_BNK01 | 291 | | DROPALL | 138 | | ACCEPT_RTP_FORWARD | 90 | | REJECT_SMTP_BRUTE | 72 | | L2TP_INPUT_ACCEPT | 33 | +----------------------+----------------+ 29 rows in set (2 min 51.03 sec) 

ACCEPT_TORF_INET ist führend. Mit diesem Präfix können Sie jeden finden, der über unser lokales Netzwerk ins Internet gegangen ist. Protokolle und Ports werden aufgezeichnet. Die Zeit wird kommen und der Zugriff wird für einige geschlossen. Es gibt Referenzdaten für zukünftige Arbeiten an Fehlern.

Smtp Speerführer
Mal sehen, wer heute versucht hat, zum SMTP-Server zu gelangen:

 MariaDB [traflog]> select src,count(dport) from traffic where logpref='SMTP_DNAT' and datetime > '2018101600000000' group by src order by count(dport) desc limit 10; +----------------+--------------+ | src | count(dport) | +----------------+--------------+ | 191.96.249.92 | 12440 | | 191.96.249.24 | 4556 | | 191.96.249.61 | 4537 | | 185.255.31.122 | 3119 | | 178.57.79.250 | 226 | | 185.36.81.174 | 216 | | 185.234.219.32 | 211 | | 89.248.162.145 | 40 | | 45.125.66.157 | 32 | | 188.165.124.31 | 21 | +----------------+--------------+ 10 rows in set, 1 warning (21.36 sec) 

Der Knoten 191.96.249.92 ist heute eindeutig der Gewinner. Mal sehen, in welchen protokollierten Regeln er noch auftauchte:

 MariaDB [traflog]> select src,dport,count(dport),logpref from traffic where src='191.96.249.92' group by logpref order by count(dport) desc; +---------------+-------+--------------+-----------------+ | src | dport | count(dport) | logpref | +---------------+-------+--------------+-----------------+ | 191.96.249.92 | 25 | 226989 | SMTP_DNAT | | 191.96.249.92 | 25 | 170714 | DROP_SMTP_BRUTE | | 191.96.249.92 | 25 | 2907 | DROP_SMTP_DDOS | | 191.96.249.92 | 25 | 2061 | ACCEPT_SMTP | +---------------+-------+--------------+-----------------+ 4 rows in set (10 min 44.21 sec) 

Dieser ist nur auf SMTP spezialisiert, ~ 1% der Treffer für den Versuch, das Passwort zu erraten oder etwas Müll zu schicken, der Rest ging ins Badehaus.

Die Anfrage hat 10 Minuten gedauert, das ist viel, die aktuellen Indizes sind nicht dafür geeignet, oder Sie können die Anfrage neu formulieren, aber jetzt werden wir nicht darüber sprechen.

In Zukunft ist geplant, die Weboberfläche mit Standardabfragen und -formularen zu verschrauben.
Der Vektor ist gegeben, ich hoffe, dass dieser Artikel nützlich sein wird.

Danke an alle!

Referenzliste:

Rsyslog-Dokumentation
MySQL-Dokumentation
Mikrotik-Protokollierungsdokumentation

Vielen Dank an die LOR-Community für die Tipps.

UPD.1
Das Flag-Feld wurde zur Datenbank hinzugefügt. Jetzt können Sie die Verbindungsdauer verfolgen, indem Sie SYN, FIN abrufen.
Einige Fehler in rsyslog-Stammgästen sowie MySQL-Trigger wurden behoben.

Seltsamerweise löscht die Standardregel defconf: drop invalid alle endgültigen Pakete von TCP-Verbindungen. Infolgedessen schlagen alle Knoten, die versuchen, die Verbindung in der Wissenschaft zu schließen, fehl und senden mehrere FINs. Ist das richtig

Ich habe eine Regel hinzugefügt, die das Durchlaufen von TCP mit ACK- und FIN-Flags ermöglicht.

Unter dem SQL-Spoiler eine Prozedur, die die Zeit der TCP-Verbindungen in den letzten fünf Minuten anzeigt
verbindungsliste ()
 DROP PROCEDURE IF EXISTS connections_list; DELIMITER // CREATE PROCEDURE connections_list() BEGIN DECLARE logid BIGINT UNSIGNED; DECLARE done INT DEFAULT FALSE; DECLARE datefin DATETIME; DECLARE datesyn DATETIME; DECLARE conntime TIME; DECLARE connsport INT; DECLARE conndport INT; DECLARE connsrc VARCHAR(21); DECLARE conndst VARCHAR(21); DECLARE cur CURSOR FOR SELECT id,datetime,src,sport,dst,dport FROM conn_syn_fin WHERE flags='SYN'; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=TRUE; DROP TABLE IF EXISTS conn_syn_fin; DROP TABLE IF EXISTS connless; CREATE temporary TABLE connless(datestart DATETIME,dateend DATETIME,duration TIME,src VARCHAR(21),sport INT,dst VARCHAR(21),dport INT); CREATE temporary TABLE conn_syn_fin (SELECT * from traffic WHERE datetime > now() - interval 5 minute and src in (select src from traffic where datetime > now() - interval 5 minute and logpref='TCP_FIN' and flags like '%FIN%') and (flags like '%SYN%' or flags like '%FIN%') order by id); OPEN cur; read_loop: LOOP FETCH cur INTO logid,datesyn,connsrc,connsport,conndst,conndport; IF done THEN LEAVE read_loop; END IF; set datefin=(SELECT datetime FROM conn_syn_fin WHERE id>logid and src=connsrc and sport=connsport and flags like '%FIN%' and dst=conndst and dport=conndport limit 1); set conntime=(SELECT timediff(datefin,datesyn)); INSERT INTO connless (datestart,dateend,duration,src,sport,dst,dport) value (datesyn,datefin,conntime,connsrc,connsport,conndst,conndport); END LOOP; CLOSE cur; select * from connless; END; // DELIMITER ; 


Als Ergebnis der Prozedur werden zwei temporäre Tabellen erstellt.
Die Tabelle conn_syn_fin enthält Protokolleinträge mit den Flags SYN und FIN. Anschließend wird eine Suche mit dem Cursor in dieser Tabelle durchgeführt.
Die connless- Tabelle enthält eine Liste von Verbindungen, offen und abgeschlossen, abgeschlossen haben eine Dauer von offen bzw. Nr.
Notieren Sie die Abtastzeit minus fünf Minuten von der aktuellen Zeit. Meine Anfrage ist langsam. Langsam durchläuft es die Cursorsuche, verarbeitet ungefähr 10 Datensätze pro Sekunde und versucht, sie in jeder Hinsicht zu beschleunigen, aber die Ausführungszeit ist immer ungefähr gleich.
Beachten Sie auch, dass dieses Verfahren nur zu Demonstrationszwecken dient. Wenn Sie eine Auswahl für einen bestimmten src / sport / dst / dport treffen müssen, ist es besser, ein separates Verfahren ähnlich diesem zu erstellen. Wenn Sie ein SQL-Master sind, können Sie Ihre Abfrage besser schreiben.

call connection_list ();
 MariaDB [traflog]> call connections_list(); +---------------------+---------------------+----------+---------------+-------+-----------------+-------+ | datestart | dateend | duration | src | sport | dst | dport | +---------------------+---------------------+----------+---------------+-------+-----------------+-------+ | 2019-03-20 14:12:19 | 2019-03-20 14:13:14 | 00:00:55 | 192.168.0.81 | 41868 | 87.250.250.207 | 443 | | 2019-03-20 14:12:25 | NULL | NULL | 192.168.0.65 | 49311 | 52.5.23.125 | 443 | | 2019-03-20 14:12:31 | 2019-03-20 14:12:51 | 00:00:20 | 192.168.0.104 | 54433 | 217.69.139.42 | 443 | | 2019-03-20 14:12:31 | 2019-03-20 14:12:51 | 00:00:20 | 192.168.0.104 | 54434 | 217.69.139.42 | 443 | | 2019-03-20 14:12:32 | NULL | NULL | 192.168.0.119 | 37977 | 209.85.233.95 | 443 | ... | 2019-03-20 14:17:12 | NULL | NULL | 192.168.0.119 | 39331 | 91.213.158.131 | 443 | | 2019-03-20 14:17:13 | NULL | NULL | 192.168.0.90 | 63388 | 87.240.185.236 | 443 | +---------------------+---------------------+----------+---------------+-------+-----------------+-------+ 399 rows in set (33.17 sec) Query OK, 0 rows affected (33.18 sec) 



Nachdem der Vorgang abgeschlossen ist, bleiben die temporären Tabellen conn_syn_fin und connless erhalten. Sie können sie genauer betrachten, wenn Sie etwas Verdächtiges oder Unzuverlässiges finden. Nach dem Start des Vorgangs werden die alten Tabellen gelöscht und neue angezeigt. Schreiben Sie, wenn Sie einen Fehler finden.

Source: https://habr.com/ru/post/de427159/


All Articles