[Gelöst] Eigenes Log schreiben

Moins

Vielleicht sowas in dieser Art?

Ich würde ja eher nicht auf Textdateien - irgendwohin geschrieben und dann möglichst noch seriell ohne Abgrenzung nach Datum usw. - setzen ... für die Protokollierung solcher Ereignisse gibt es in Asterisk ja das CEL-Interface (oder notfalls noch das CDR). Da hat man eigentlich alles beisammen, was man braucht ... von einer strukturierten Speicherung (über Backends) bis zu den notwendigen Call-Variablen.

Das macht dann auch die Auswertung wieder leichter, wenn man tatsächlich mal einen Datensatz sucht (sogar dann, wenn man nur mal "so nebenbei" eine Statistik machen will, wann diese Anrufe eigentlich immer auftreten, welche Nummern am häufigsten gefaked werden, usw.). Nach meiner Erfahrung macht eine Datenhalde in Textform eher wenig Sinn ... es sei dann, man weiß ohnehin schon vorher, daß man die nicht braucht und hebt sie nur "vorsichtshalber" auf. Es muß ja auch nicht immer gleich ein ausgewachsener SQL-Server sein, es gibt ja auch strukturierte Alternativen (ob da XML z.B. dabei ist, weiß ich aber nicht aus dem Stand).

Mansaylon schrieb:

Das wäre ja, wie wenn ich einen Maggie Würfel mit einem 40-Tönner transportieren würde.

Zum Vergrößern anklicken....

Kein Problem, muß man ja nicht machen.

Ich möchte lediglich sehen können, welche Nummern aus der Blackliste nochmals versucht haben anzurufen. Dazu reicht eben eine kleine textbasierte Datei mit den wichtigsten Daten ohne weiteres Beigemüse.

Zum Vergrößern anklicken....

Da hast Du zwar nach meinem Empfinden bei der Konfiguration der Backends etwas überlesen (man muß meines Wissens nicht alle Daten speichern), aber daß es nur hobbymäßig sein soll, es gar nicht so viele Anrufe sind und was Du mit den Daten am Ende anfangen willst, hattest Du irgendwie vergessen zu erwähnen.

Auch wenn ich noch nicht so richtig verstehe, wie Du das am Ende von Hand auswertest (ab ca. 100 Anrufe sagen wir mal, wenn es tatsächlich noch weniger sind, dann breiten wir den Mantel des Schweigens darüber), ja hoffentlich nicht tatsächlich durch visuellen Vergleich.

Schon dann würde ich (aus reiner Faulheit) wieder einen Extrakt der Rufnummern sortieren und den dann abzählen lassen, um (mind.) Duplikate - mithin mehrfache Anrufer - zu ermitteln.

Das ist sicherlich auch eine Möglichkeit, aber mit einem SQL-Kommando "SELECT * FROM (SELECT CALLER, COUNT(*) AS ANZAHL FROM CALLERS GROUP BY CALLER) WHERE ANZAHL > 1;" (es geht auch anders, ehe jetzt jemand mit mir über SQL und geschachtelte Views/temp. Abfragen oder SQL-Optimierung allgemein diskutieren will) auf einer SQLite-Datenbank (dafür gibt es m.W. auch ein Backend), ist das in einem Zug erledigt und eine SQLite-Datenbank ist beileibe kein 40-Tonner, aber eben ein "structured storage". Das nur als Anmerkung für spätere Leser, die vielleicht ein paar Datensätze mehr zu verwalten haben ... bei Dir könnte es tatsächlich (die Anzahl der Anrufe ist ja nicht bekannt bzw. nicht angegeben) zu dick aufgetragen sein.

Wenn du auch einen Zeitstempel möchtest...

Klaro, das Linuxkommando date geht natürlich auch, wenn TrySystem() benutzt wird.

Mansaylon schrieb:

exten => s,n(GO_OUT),TrySystem(echo $(date)' ${CALLERID(all)}' >> /var/log/asterisk/black.log)

Zum Vergrößern anklicken....

Asterisk-Server? Öffentlich erreichbar mit SIP-Inbound?

Da würde ich ja zu gerne mal eine Caller-ID in der Form
senden, um zu testen, was das in der Ausgabedatei am Ende ergibt. Das "embedded command" ist auch nur ein ganz schneller Einfall, mit etwas "Voodoo" kriegt man vielleicht ja zuverlässiger heraus, auf was für einem System der Asterisk-Server überhaupt läuft und wie man sich da am besten einklinkt. Das ist als "prediction" schwer, mit "trial and error" eher Zeitvertreib.

Das kann zwar auch grandios schief gehen, wenn da tatsächlich passende Vorkehrungen getroffen werden ... aber wenn mir jemand schon die Möglichkeit bietet, mit CALLERID(all) (lt. Asterisk-Doku die "user-defined string") einen System-Aufruf zu machen (ich weiß tatsächlich nicht, ob Asterisk da schon vorher filtert oder nicht, ich tippe aber mal auf nicht und lasse mich ggf. eines Besseren belehren - außerdem mal wieder ein schönes Beispiel, warum eine Rechtetrennung unter Linux eigentlich unumgänglich ist), dann sollte man diese Gelegenheit sicherlich nicht ungenutzt lassen. Andererseits man muß es ja vorher noch auf die "Blacklist" schaffen, damit der Aufruf auch ausgeführt wird ... wahrscheinlich liegt darin schon eine beträchtliche Hürde.

Just my two cents ... und alles ungetestet, nur weil bei mir bei solchen Konstruktionen sofort die Alarmglocken losgehen.

Eine, über die CALLERID, Injection?

Zum Glück lasse ich meinen Asterisk nur lokal werkeln, dachte ich zu Anfang.
Weil ich nur 2 Asterisk Nummern in der Fritz!Box registriere.
Doch Pustekuchen, alle Nummern im Fritz!Box Router (Internet) sind aus dem WWW erreichbar.
Zwar nicht über den ITSP, aber trotzdem erreichbar.
Deswegen musste ich für diese zwei Nummern auch RULs anlegen...

...die bei ankommenden "friendly-scanner" auf einen "sicheren" Context auflaufen.
...und nicht auf meine Hausautomation über Telefon.

koyaanisqatsi schrieb:

Eine, über die CALLERID, Injection?

Zum Vergrößern anklicken....

Warum nicht? Wie gesagt, nicht getestet, nur der erste spontane Gedanke, als ich die Konstruktion gesehen habe. Je nachdem, wie genau da gefiltert wird und in welcher Reihenfolge die Variablenauflösung erfolgt, ergibt das mit meiner "Caller-ID" (und im Textteil vor dem "<nummer> kann ich vieles angeben, notfalls umkodiert, damit es sich mit dem Transportprotokoll nicht ins Gehege kommt):

Ich hoffe mal, daß ich da jetzt kein Hochkomma o.ä. übersehen habe, es ist eben ungetestet.

Aber solche Konstruktionen sind nun mal - so logisch das auf den ersten Blick auch aussehen mag - kreuzgefährlich, wenn man die Eingabewerte nicht vorher prüft.

Es kann auch genauso gut sein, dass gar nichts weiter passiert, weil der TrySystem-Aufruf mit der Verkettung mit dem Semikolon nichts anfangen kann ... wenn aber "$(date)" funktioniert, ist das eher unwahrscheinlich und notfalls nimmt man eben auch für die "injection" ein Kommando, was keine Ausgabe auf stdout erzeugt und per "$(mein_eigenes_kommando)" in den Text eingebaut wird.

Das einzige, was die Interpretation weiterer Kommandos nach meiner Meinung verhindert, ist das offene Hochkomma. Ist das Bestandteil der Caller-ID und wird erst die Zeichenketten-Substitution gemacht, bevor das Kommando ausgeführt wird, hat man eine klassische "command injection", die die meisten wohl in Form einer SQL-Injection kennen, wenn Eingabeparameter auch nicht ordentlich geprüft und Zeichenketten zu einem SQL-Kommando "zusammengesetzt" werden (eine alte Unsitte, die leider immer wieder anzutreffen ist, dafür gibt es Parameter in SQL-Abfragen und "prepared statements").

Je nachdem, wie die Abfrage der Blacklist umgesetzt ist (vermutlich als Teilkettenabgleich der Rufnummer in den spitzen Klammern oder wie auch immer, es spielt nur eine untergeordnete Rolle), stünde dann ggf. am Beginn anstelle des "ich" eine der gelisteten Nummern ... das "ich" ist nur ein Platzhalter und auch das nachfolgende "echo"-Kommando soll nur dazu dienen, tatsächlich noch eine Zeile in der black.log zu erzeugen, das kann natürlich auch ausgelassen werden.

Das Kommando wird - so es denn funktionieren sollte - im Kontext des Accounts ausgeführt, der den Asterisk-Server gestartet hat. Da muß auch keinesfalls irgendein Daemon gestartet werden, im einfachsten Fall (wegen der vermutlich vorhandenen Schreibrechte im Asterisk-Arbeitsverzeichnis) ist das ein Download eines Callfiles aus dem Internet, mit dem dann der Asterisk-Server seinerseits eine kostenpflichtige Verbindung zu einer Mehrwertnummer aufbaut. Das wird nicht immer so automatisch klappen wie bei einer FRITZ!Box (wo die Monokultur z.B. bei den Nummern ein "number guessing" erleichtert), schon das Ermitteln eines passenden Kontextes für so einen outbound-Call kann eine kleine Herausforderung sein. Aber mit ein oder zwei abgewandelten Kommandos (meinetwegen einem Mail-Versand für die extensions.conf) ist das für einen menschlichen Angreifer mit einiger Wahrscheinlichkeit wirklich nur ein Freizeitspaß, wenn man so einen verwundbaren Eintrag in einem Kontext erst einmal sicher identifiziert hat (und das läuft in aller Regel über "fuzzing", also das automatische Ausprobieren der aberwitzigsten Kombinationen, allerdings immer noch systematisch und nach bestimmten Vorgaben).

Das mag für Hobbyprogrammierer alles noch akzeptabel sein, bei professionellen Programmierern trifft man entsprechendes Unwissen (und mangelnde Phantasie) leider auch sehr häufig an ... sogar unsere über alles geliebten FRITZ!Boxen waren/sind ja über so eine "command injection" (in /etc/init.d/S44-hostname, wo der Hostname aus der ar7.cfg nicht richtig ausgewertet wurde/wird) verwundbar. Das hängt von der Version ab, seit 06.21 für 7390/7490 sind die meines Wissens dicht, andere Modelle auch schon mit der 06.20 - so ungefähr ab Ende Sept./Anfang Okt. 2014, wenn mich nicht alles täuscht.