Posts by noobee


    Nein, weil du damit localhost/127.0.0.1 sperren müsstest, was du warscheinlich nicht möchtest.


    richtig, möchte ich nicht :lol:



    Gibt dem db-User nur minimale Rechte (grant) an der aktuell benutzen DB und keinen Zugriff auf eine andere DB.


    bereits geschehen...


    ich hab halt nur gedacht, dass man apache & co (also auch php, mysql) eben n bissi mit fail2ban absichern kann :blush: :blush:


    edit: hab die überschrift mal n bissi erweitert

    moin@community,


    ich habe auf meinem pi3 eine kleine website laufen, welche öffentlich zugänglich ist. es wird dort auch jede menge in die DB geschrieben (mysqli). ich nutze bereits prepared statements, bin jedoch lieber n bissi mehr paranoid als zu wenig. im moment ist mit fail2ban nichts abgesicht außer der "standard" ftp-zugang und ssh.


    die frage:
    falls jemand irgendwie nun doch versucht, dass sql-pw mittels bruteforce o.ä. rauszubekommen, kann ich diese versuche mit fail2ban nach 2-3 anläufen auch blocken??


    meine jail.conf für ftp und ssh


    gibt es standardeinträge in der jail.local, welche auf true zu setzen sind, um o.g. problem ein wenig einzudämmen??

    Ok, so richtig schlau werde ich aber aus dem Beschriebenen bei Wiki nicht. Um also Phpmyadmin abzusichern, ändere ich folgenden Eintrag:


    <Directory /usr/share/phpmyadmin>
    Options FollowSymLinks
    DirectoryIndex index.php
    Order Deny,Allow
    Deny from all
    Allow from 192.168.2.0/1
    <IfModule mod_php5.c>
    ??


    Wobei ich sagen muss, dass 192.168.2.0/1 schon seltsam aussieht. Stimmt das so wirklich?

    negativ, bringt nichts. jetzt steht

    Code
    bantime  = 600

    einmal oben in den standard einstellungen und zusätzlich in dem part [ssh] mit drin. jedoch kann ich mich nach 6 versuchen erneut mit dem öffnen von putty einloggen


    sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
    hab ich gemacht. Änderungen wurden in die jail.local übertragen


    es geht aber auch für proftp nicht. da kann ich mich ununterbrochen versuchen einzuloggen. scheint wohl ein generelles problem mit fail2ban zu sein :no_sad:



    EDIT:
    sudo tail -f /var/log/fail2ban.log
    2016-11-27 01:53:01,936 fail2ban.actions[4281]: WARNING [ssh] Ban 192.168.2.100
    2016-11-27 01:53:12,417 fail2ban.actions[4281]: WARNING [ssh] Unban 192.168.2.100
    2016-11-27 02:05:10,209 fail2ban.actions[4281]: WARNING [ssh] Ban 192.168.2.100
    2016-11-27 02:05:21,012 fail2ban.actions[4281]: WARNING [ssh] Unban 192.168.2.100
    2016-11-27 02:10:12,117 fail2ban.server [4281]: INFO Stopping all jails
    2016-11-27 02:10:12,595 fail2ban.jail [4281]: INFO Jail 'proftpd' stopped
    2016-11-27 02:10:13,259 fail2ban.jail [4281]: INFO Jail 'pure-ftpd' stopped
    2016-11-27 02:10:14,266 fail2ban.jail [4281]: INFO Jail 'wuftpd' stopped
    2016-11-27 02:10:14,449 fail2ban.jail [4281]: INFO Jail 'ssh' stopped
    2016-11-27 02:10:14,465 fail2ban.server [4281]: INFO Exiting Fail2ban


    warum wird nach ca. 10sec alles "unban" ?? und warum werden alle jails gestoppt?? :wallbash: :wallbash:

    die Absicherung, PhpMyAdmin nicht von außen erreichbar zu machen funzt leider nicht mehr. Gibt es für Jessie andere Vorgehensweisen? Ich habe es mit dem Tut von Seite 2 probiert:



    Ich habe es beschränkt auf die IP 192.168.2.200/24. Jedoch komme ich vom Rechner mit der IP 192.168.2.100 auch auf PhpMyAdmin. Muss noch etwas beachtet werden, um den Zugang zu beschränken?

    morgen@community,


    ich habe mir fail2ban inst. in der /etc/fail2ban/jail.conf habe ich lediglich den eintrag

    Code
    [ssh]
    
    
    enabled  = true
    port     = 50144
    filter   = sshd
    logpath  = /var/log/auth.log
    maxretry = 6


    geändert. ich gehe nun über putty rein, geben 6x das falsche pw ein und putty schließt sich. jedoch kann ich putty sofort wieder öffnen und 6 neue versuche starten. die bannzeit von 600s wird also nicht eingehalten. was ist da falsch eingestellt?

    Quote

    Für mich fast nicht nachvollziehbar. Aber egaal, Hauptsache, es funktioniert jetzt.


    Ja und nein. Schön, dass das Gesendete ankommt. Blöd ist jetzt, dass ich nicht weiß, welche der Parameter gesetzt sein müssen und welche nicht. Sicher könnte ich jetzt mit ner Schleife alle Parameter mit und ohne "-" testen... Naja.


    Quote

    Ich würde mal das Programm cuteCom installieren. Damit kannst Du Hex-Codes an die serielle Schnittstelle senden und die Rückmeldung ebenso als Hex-Code anzeigen lassen. Dann siehst Du direkt ob 0x06 oder 0x15 zurückkommt. Und Du siehst auch, was noch so alles übertragen wird.


    Des wird gemacht. Mal sehen, was da so für Bandsalat zurück kommt... Ich könnte doch aber sicher auch mit den "echo-Parametern" spielen, oder? Sind die nicht für die Rückgabe zuständig?

    Code
    Wird's besser, wenn Du intr und eof jeweils auf <undef> setzt?


    Nein, das ändert nichts. Kommt nichts zurück, bzw an.


    Code
    Und schließlich: Du bist Dir sicher dass die Prüfsummenbytes korrekt angegeben sind?


    Ja. Also bei dem "Hex-String"
    \x10\x02\x06......\x10\x03\xD3\x02 sollte ein NAK (15) zurück kommen und bei
    \x10\x02\x06......\x10\x03\xD3\x01 ein ACK (06).
    "06" ist also eine korrekte Nachricht mit korrekter Prüfsumme, "15" ist eine korrekte Nachricht mit falscher Prüfsumme. Syntaktisch sind aber beide korrekt.


    Ich zieh nochmal den USB raus und teste mal die Geschichten stty sane, stty cooked und stty raw durch. Irgendwas muss doch gehen :no_sad: :no_sad:



    EDIT: Ich fasse es nicht. Der Befehl stty -F /devttyUSB0 raw funktioniert. Damit kann ich meinen "Hex-String" senden. Dieser kommt an. Jetzt muss ich nur noch schauen, wie ich mit "cat" meine "06" bzw "15" ordentlich in eine Datei speichern kann. Im Screens sieht man, dass wohl erst mal nicht verarbeitbares Zeug zurück kommt...


    Achja, mal die Einstellungen, welche "stty -F /dev/ttyUSB0 raw" gesetzt hat:

    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
    -iuclc -ixany -imaxbel -iutf8
    -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    -isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke

    Images

    • cat.PNG
    Code
    8 Datenbit ==> cs8
    2 Stopbits ==> cstopb
    keine Parität ==> -parenb (-parodd oder parodd sollte egal sein, dito für ignpar)


    Sehr gut, ist gesetzt :thumbs1:


    Code
    Dann hat das vermutlich an den Stopbits gelegen. Ich ging da gestern noch von einem einzigen aus.


    Naja, wenn das eigentlich der Standard ist, war es ja ok :bravo2:


    Nur so am Rande: Meine test.sh geht nicht. Weder

    Code
    echo -en '\x10\x02\x06\x00\......\x10\x03\xD3\x01' > /dev/ttyUSB0

    noch

    Code
    echo -en "\x10\x02\x06\x00\......\x10\x03\xD3\x01" > /dev/ttyUSB0

    Aber das soll hier nicht das Problem werden. Ich mach einen neuen dafür auf :s


    Code
    Ich gehe dann nochmal tiefer in die einzelnen Parameter - vielleicht fällt mir noch irgendwas auf. Ich vermute weiterhin, dass ein Zeichen aufgrund der Parameter-Definition nicht übertragen wird oder stattdessen ein anderes. Und dem Empfänger dann kein vollständiger Datensatz vorliegt oder kein richtiger. In allen diesen Fällen erfolgt keine Rückmeldung, auf die Du wartest.


    Ich kann dir alle Parameter bei meinem "Hex-String" genau erklären:
    \x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02


    \x10 =DLE
    \x02 = StartText
    \x06 = BeginnRegistrierung
    \x00 = BeginnRegistrierung-Unterpunkt
    \x0E = 14 - Länge der folgenden Nachricht inkl. Passwort (habs mal unterstrichen)
    \x10 =DLE
    \x03 = EndText
    \xD3 = Prüsummenbit High
    \x02 = Prüfsummenbit Low


    Vielleicht hilfts ja irgendwie weiter :danke_ATDE:

    So, nochmal kurz das Herz stehen geblieben :-/ Aber hat doch gepasst:


    dmesg

    Code
    [19598.955673] usb 1-1.4: pl2303 converter now attached to ttyUSB0


    Code
    [color=#333333]dann setze bitte noch intr und quit jeweils auf <undef>[/color]


    unverändert, keine Ergebnisse. Auch nicht mit -cstopb für 1 Stopbit


    Edit:
    Ok, nach langem Probieren vllt. ein kleiner Erfolg. Mittels "stty sane" hab ich erst mal wieder alles in eine Art Standard zurück versetzt (sane: sets all modes to reasonable values).

    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    parenb -parodd -cmspar cs8 -hupcl cstopb cread clocal -crtscts
    -ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl ixon -ixoff
    -iuclc -ixany imaxbel -iutf8
    opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke


    Jetzt kommt wieder dieses "a32de" auf dem Display. Also scheint ja irgend was anzukommen. Zurück kommt aber noch nix. Des weiteren habe ich im Netz einen Flyer von Gerät gefunden. Leider stand nix verwertbares drin außer: 9600 Baud, 8 Datenbit, 2 Stoppbit, keine Parität.
    Was hat es denn mit stty sane, stty raw, stty cooked auf sich??


    Noch ne Frage außer der Reihe. Wie sende ich in nem sh-script meinen String? So geht es leider nicht:

    Code
    echo '-en "\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x02"' > /dev/ttyUSB0

    Alle empfohlenen Änderungen eingearbeitet. Mit -noflsh und noflsh getestet. Ohne Erfolg, keine Besserung. Ich hab auch mal mein brkint und -brkint getestet, zusammen mit noflsh und -noflsh. Keine Besserung :no_sad:


    EDIT: 3. Ansatz hab ich zu spät gesehen. mach ich mal


    Ach du sch***. Das sieht eher nicht so einfach aus :s Ok... hilft ja nix :bravo2:


    Quote

    Deine serielle Schnittstelle reagiert auf einen Interrupt ^C. Das heißt, wenn dieser Code = ETX "End of Text" kommt, dann wird dieser Code nicht durchgelassen sondern bewirkt irgendeine Aktion. Das heißt, ETX kommt niemals an. Willst Du das so? Dann lasse diese Einstellung, willst Du es nicht, dann lösche dieses Zeichen.


    Richtig, es wird mit jedem "Hex-String", den ich sende, auch ein EXT mitgesendet. Und zwar in der Form \x10\x03. Wobei \x10 = DLE und die \x03 = EXT. ABER danach schicke ich noch ein High- und ein Low-Level-Bit mit als Prüfsumme. Es darf also nach EXT nicht abbrechen. Laut "stty man" setze ich also:


    -brkint (breaks cause an interrupt signal)


    Der Rest ist ja recht fix mit stty negiert.

    Code
    erase, kill eof, eol (ist schon), ..., start, stop, susp und rprnt, werase, lnext, flush auf <undef> setzen.
    -echo, -echoe, -echok, -echonl, -echoctl, -echokl


    Ok, neues "-a" ergibt:



    Soo, ein erneutes Senden über shell:

    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x10\x03\xD3\x01' > /dev/ttyUSB0


    brachte nix. Das Gerät blinkt kurz. Es kommt also was an. Rückmeldung gibts aber nicht. Auch das "a32de" kommt immer noch nicht wieder :blush:

    ok, erstmal die Ausgabe von "stty -F /dev/ttyUSB0 -a":



    Code
    speed 9600 baud; rows 0; columns 0; line = 0;
    intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
    eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
    werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
    -parenb -parodd -cmspar cs8 hupcl cstopb cread clocal -crtscts
    -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
    -iuclc -ixany -imaxbel -iutf8
    opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
    isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
    echoctl echoke


    ls -la /dev/ttyUSB0

    Code
    crw-rw-rw- 1 root dialout 188, 0 Okt 30 19:38 /dev/ttyUSB0

    Uiuiui. Zu viele Fragen :D. Also.


    Quote

    Was macht Dich sicher, dass /dev/ttyUSB0 das richtige Device ist?


    Ich muss zu meiner Schande gestehen, dass vor dem Reboot "alles" lief. Ich konnte das Gerät ansprechen und habe auch eine "06" bzw "15" zurück bekommen (ACK bzw NCK). Also stimmt ttyUSB0 :bravo2:


    Quote

    Es gibt noch wesentlich mehr Parameter, die über stty zu setzen sind, damit eine serielle Datenübertragung reibungslos funktioniert. Hast Du Dich mal über man stty eingelesen?


    Japp, das weiß ich. Bei mir reichten aber die wenige Parameter zu setzen. Das Gerät lief dann. Ich hab mir die Befehlte eben vor dem Reboot leider nicht notiert :no_sad:


    Quote

    Ob Senden funktioniert, weißt Du auch nicht wirklich?


    Doch, siehe oben. Vorm Reboot lief es.


    Quote

    Hast Du darauf geachtet, dass über GPIO-Pins RX nur maximale Pegel von 3,3 V eintrudeln dürfen - über USB nur 5 V


    Das Gerät läuft NUR über USB. Ich achte also nicht auf 3,3/5V.


    Quote

    Es besteht ein Unterschied zwischen stty -F /dev/ttyUSB0 und stty ohne Device-Angabe. Es werden jeweils andere Geräte angesprochen / abgefragt. Deswegen ist die Information der Ausgabe stty belanglos.


    Sehr gut, danke. Das wusste ich nicht. Also ab sofort nur noch stty -F /dev/ttyUSB0.


    Quote

    Ob es eine gute Wahl ist, die Sonderzeichen in ihrer Funktion zu belassen...


    ...ich nutze keine Sonderzeichen. Ist alles hex was ich sende. Siehe das Beispiel ganz unten


    Quote

    Quote

    Ein zweites Konsolenfenster bei seriellen Schnittstellen zu öffnen ist meistens keine gute Idee. Es kann nur ein Programm Daten empfangen. Das Programm, dass die Daten zuerst - im wahrsten Sinne des Wortes - heraus liest, lässt einem anderen Programm keine Möglichkeit mehr, die gleichen Daten erneut zu lesen. Genauso macht es keinen Sinn, wenn mehrere Geräte über die gleiche Schnittstelle gleichzeitg senden. Der Empfänger bekommt zwar alles mit, es kommt aber nur Bandsalat an.


    Danke für den Hinweis. Wie oben erwähnt, ging es aber mit dem zweiten Fenster vor dem Reboot - wenn auch u.U. nur mit Glück :rolleyes: Ich kann aber hinter dem Sendebefehl ja noch ein "&& cat < /dev/ttyUSB0" anhängen. Dann isses in einem Fenster.


    Quote

    Quote

    Wozu diese ganzen Freigabe-Versuche? Pure Verzweiflung?


    ABSOLUT :wallbash:


    Quote

    Quote

    Wie hast Du die serielle Schnittstelle eingerichtet?


    mittels stty -F /dev/ttyUSB0 speed 9600 cs8 cstopb -parenb. Ich war der Meinung, dass ich vor dem Reboot auch nicht mehr gemacht habe :daumendreh2: :s


    Quote

    Quote

    Quote

    Welches RPi-Modell, welches Betriebssystem, welche Betriebssystemversion?


    Im Moment steckt es nicht am Pi, sondern am PC: Linux debian 3.16.0-4amd64 #1 SMP Debian 3.16.36- 1+deb8ul (2016-09-03) x86_64GNU/Linux.
    Mit dem Debian wird es getestet.


    Quote

    Hast Du mal Programme wie cuteCom oder minicom ausprobiert, um Dir anzeigen zu lassen, wer was sendet oder empfängt?


    Wie oben geschrieben, funktionierte ja vor dem Reboot alles ohne minicom & co...


    Quote

    Wahrscheinlich sind dort noch Sonderzeichen aktiv, die der Sender sendet, mit denen das Kartenlesegerät nicht anfangen kann - und dann auf einen korrekten Satz wartet. Daher musst Du herausfinden, welche Bytes genau gesendet werden müssen, um eine gewünschte Aktion auszulösen. Diese Bytes musst Du dann senden (können) und alle weiteren Sachen (wie echos) ausschalten. Sonst kommt auch nur Bandsalat.


    Auch schon wie oben. Ich sende lediglich in hex. Das kam vorm Reboot auch an und wurde mit "06" bzw "15" bestätigt. Das Senden sieht so aus:


    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x03' > /dev/ttyUSB0


    ergibt als Rückantwort auf den zweiten geöffnetem Terminalfenster: 15, also NCK
    und

    Code
    echo -en '\x10\x02\x06\x00\x0E\x00\x00\x00\x9E\x09\x78\x06\x06\x26\x04\x0A\x02\x06\xD3\x01' > /dev/ttyUSB0


    ergibt als Rückantwort auf den zweiten geöffnetem Terminalfenster: 06, also ACK.


    Ach ja, das Gerät heißt "REA T6 retail".

    Folgendes Problem:
    Ich habe am Pi über USB/RS232 ein Kartenlesegerät hängen. Dieses läuft mit 9600 Baud, 8N2. Ansprechbar ist dies über /dev/ttyUSB0. Ich habe eine gefühlte Ewigkeit gefummelt, um mit im Netz gefundenen Anleitungen vom Gerät eine Antwort zu bekommen. Bisher ohne Erfolg.


    Senden funktioniert soweit, glaube ich. Jedesmal wenn ich etwas zum Gerät sende, leuchtet auf dem Display unter dem Telefonicon "a32de" auf. Vor dem Senden habe ich "stty -F /dev/ttyUSB0 speed 9600 cs8 cstopb -parenb" gemacht. Der Befehlt "stty" gibt mir folgendes zurück:


    Code
    speed 9600 baud; line = 0;
    eol = M-^?; eol2  = M-^?; swtch = M-^?;


    Der erweiterte Befehl "stty -a -F /dev/ttyUSB0" zeigt mir u.a.: "cstopb -parenb". Das wäre ja richtig. Jedoch zeigt der Befehl "stty -a" (also ohne -F /dev/...)
    "-cstopb -parenb". Welche stimmt denn nun?


    Zum Abfragen habe ich ein zweites Konsolenfenster geöffnet. Dort lausche ich mittels "cat < /dev/ttyUSB0" auf irgend einen Eingang (hab auch schon "od -x < /dev/ttyUSB0" gestestet). Jedoch kommt nichts zurück :(


    Aus Verzweiflung habe ich jetzt "chmod 777 /dev/ttyUSB0" gemacht. In der entsprechenden Gruppe "dialout" habe ich mich auch hinzugefügt (dialout:x:20:noobee,root). Hab auch jedem zugriff gewährt mittels "chmod a+rw /dev/ttyUSB0". Mehr ist mir an Freigaben nicht eingefallen.


    Jemand noch ne Idee, warum ich keine Antwort vom Gerät bekomme`?

    Quote

    Einen Einwand, über den Du mal nachdenken solltest:


    Wenn ich Deinen teuren Neuwagen klauen wollte und es steckt irgendwas im Zigarettenanzünder, was ich nicht kenne, ich glaube ich würde es entfernen und dann erst losfahren.


    Lol, das würde ich auch :D :bravo2:
    Stimmt, das müsste also versteckt werden. Guter Einwand :thumbs1: :thumbs1:


    Quote

    - keinen GPS-Sender sondern GPS-Empfänger

    :blush: japp, natürlich.



    EDIT: ist ein Pi Zero dafür ausreichend? Der ist ja n bissi billiger als der Pi 3...

    Moin @ community,


    ich hätte da auch mal eine Frage zur Machbarkeit einer Idee. Ich bin mir auch incht sicher, ob es diese Ide nicht schon irgendwo in den weiten Welten des Inet gibt.


    Ich habe mir einen teuren Neuwagen gekauft. Diesem möchte ich nun eine eigene Alarmanlage gönnen. Mittels Pi Zero soll dann eine SMS/Email gesendet werden, sobald ein GPS-Sensor Bewegung erkennt. Ich möchte dies vorerst an den Zigianzünder stecken, es soll aber auch noch ne kleine USV dazwischendran. Diese USV wird geladen, sobald Zündung an ist (weil dann Strom anliegt). Sollte das Austo aus sein (kein Strom da Zündung aus), sollte die USV einspringen.


    Was benötige ich dafür?
    Pi Zero
    GPS-Sender
    GSM-irgendwas ??
    USV


    Ist das realisierbar? Wenn ja/nein, was brauch ich noch? Wenn nein, was ist das Problem?