Beiträge von ostfriese

    So, jetzt aber:


    Das PREROUTIG und POSTROUTING wird durch ein Python Skript erledigt(sieht kompliziert aus ist es aber nicht. Das Skript von dem VPN-Client ausgeführt, der sich mit Perfect Privacy verbindet. Hier zur Info der Output.

    @mainziman

    Wow, tausend Dank für deine Mühe und deine zielführenden Hinweise. Ich glaube ich hab's jetzt hinbekommen.

    DHCP und DNS konnte ich weglassen, habe ich über ccd in openvpn geregelt. Aber guter Hinweis.

    Ping und traceroute habe ich weggelassen, aber wenn ich es mal brauche, weiß ich, dank deiner Hilfe, wie es geht.

    Der entscheidende Hinweis war der für das Forwarding.

    Der vServer ist auch noch VPN-Client bei Perfect-Privacy (anonymes VPN). Einige openvpn-Clients werden dahin weiter geroutet.

    Auch das habe ich dank deiner Hilfe (ich hoffe) sauber gelöst. Die Policies sind jetzt auf DROP und das Logging ist raus, weil jetzt alles funktioniert.

    Nochmal vielen vielen Dank für deine Hilfe!!!

    Jetzt ist das alles viel Übersichtlicher und sieht auch logisch aus. Ich glaube ich hab's jetzt kapiert:)

    Ich hoffe, das passt jetzt so.


    Hier das Ergebnis:

    Warum müllst du dir den syslog damit zu?

    Weil ich überrascht war, was da los ist. Ist nur temporär um zu sehen, ob meine Regeln funktionieren. Ich habe auf meiner Vodafone IP eine Firewall, wo praktisch nie jemand versucht, einzudringen. Aber bei einem Server in einer Serverfarm scheint das für die Bösen lohnenswerter zu sein.

    Wenn ich sicher bin, das meine iptables-rules greifen, fliegt das natürlich 'raus und die default policy wird auf DROP gesetzt.


    Hier mal ein Auszug einer Auswertung der denied per Script (Doppelungen schon gefiltert):

    DATE/TIME Chain IP-ADDRESS

    21.02.2020 20:58:30 INPUT 111.200.54.170

    21.02.2020 20:58:57 INPUT 170.106.36.97

    21.02.2020 20:59:02 INPUT 185.39.10.63

    21.02.2020 20:59:16 INPUT 185.137.233.164

    21.02.2020 20:59:21 INPUT 93.174.95.73

    21.02.2020 20:59:22 INPUT 92.118.37.53

    21.02.2020 20:59:24 INPUT 185.53.88.130

    21.02.2020 20:59:38 INPUT 185.176.27.18

    21.02.2020 20:59:54 INPUT 80.82.78.192

    21.02.2020 20:59:56 INPUT 84.168.35.77

    21.02.2020 21:00:12 INPUT 92.118.37.55

    21.02.2020 21:00:40 INPUT 176.113.115.252

    21.02.2020 21:00:41 INPUT 31.184.215.50

    21.02.2020 21:00:51 INPUT 185.176.27.170

    21.02.2020 21:00:52 INPUT 80.82.65.62

    21.02.2020 21:00:54 INPUT 220.191.249.130

    21.02.2020 21:01:36 INPUT 91.206.15.191

    21.02.2020 21:01:48 INPUT 185.143.223.81

    21.02.2020 21:01:58 INPUT 159.89.181.213

    21.02.2020 21:02:06 INPUT 13.233.149.135

    21.02.2020 21:02:16 INPUT 182.61.163.32

    21.02.2020 21:02:24 INPUT 52.66.239.225

    21.02.2020 21:02:47 INPUT 15.206.172.234

    21.02.2020 21:02:49 INPUT 13.126.190.209

    21.02.2020 21:02:50 INPUT 80.82.70.118

    21.02.2020 21:03:27 INPUT 190.131.151.154

    21.02.2020 21:03:39 INPUT 80.82.70.239

    21.02.2020 21:04:15 INPUT 42.179.227.246

    21.02.2020 21:04:19 INPUT 45.136.109.251

    21.02.2020 21:05:03 INPUT 185.156.73.49

    21.02.2020 21:05:11 INPUT 192.241.224.91

    21.02.2020 21:05:32 INPUT 185.176.27.178

    21.02.2020 21:05:37 INPUT 185.151.242.216

    21.02.2020 21:05:54 INPUT 83.97.20.49

    21.02.2020 21:06:32 INPUT 194.26.29.129

    21.02.2020 21:07:06 INPUT 13.233.113.113

    21.02.2020 21:07:17 INPUT 178.218.200.161

    21.02.2020 21:07:24 INPUT 13.233.112.72

    21.02.2020 21:07:29 INPUT 89.248.168.202

    21.02.2020 21:07:33 INPUT 203.186.48.186

    21.02.2020 21:07:52 INPUT 35.154.80.175

    21.02.2020 21:08:16 INPUT 42.119.216.237

    21.02.2020 21:09:07 INPUT 167.71.202.235

    21.02.2020 21:09:13 INPUT 92.119.160.52

    21.02.2020 21:09:56 INPUT 194.26.29.121

    21.02.2020 21:10:19 INPUT 185.112.249.168

    21.02.2020 21:11:04 INPUT 188.246.224.219

    21.02.2020 21:11:56 INPUT 193.32.161.12

    21.02.2020 21:11:57 INPUT 51.75.52.127

    21.02.2020 21:12:01 INPUT 194.61.27.240

    21.02.2020 21:12:02 INPUT 94.102.56.215

    21.02.2020 21:12:06 INPUT 13.232.182.172

    21.02.2020 21:12:17 INPUT 192.64.112.32

    21.02.2020 21:12:18 INPUT 192.241.223.18

    21.02.2020 21:12:23 INPUT 13.127.15.212

    21.02.2020 21:12:45 INPUT 45.143.221.46

    21.02.2020 21:12:48 INPUT 13.127.158.98

    21.02.2020 21:13:02 INPUT 185.209.0.91

    21.02.2020 21:13:26 INPUT 185.176.27.6

    21.02.2020 21:14:01 INPUT 92.118.37.86

    21.02.2020 21:14:42 INPUT 190.60.213.172

    21.02.2020 21:14:54 INPUT 210.44.14.54

    21.02.2020 21:15:40 INPUT 27.76.81.242

    21.02.2020 21:15:56 INPUT 5.188.210.158

    21.02.2020 21:16:44 INPUT 112.35.76.1

    21.02.2020 21:17:32 INPUT 92.63.196.3

    21.02.2020 21:18:05 INPUT 206.189.177.133

    Ok, hier überarbeitet.

    die Regeln sind irgendwie etwas konfus und inkonsistent ...

    ja, stimmt, liegt daran, dass ein Script die Regeln erstellt und ich die da falsch heraus-kopiert habe.


    ...

    - 2mal ESTABLISHED, RELATED mit INPUT, aber keine mit FORWARD,

    ...

    auch ein Kopierfehler.


    ...

    und vor allem bei FORWARD, welcher Source und welcher Destination Port?

    ...

    alle, weil die openvpn Client über die vServer public IP weiter in's Internet sollen.


    - default Policy jeweils ACCEPT, und dann die OUTPUT Regeln auf die DNS-Server?

    Konzept soll sein, Regel trifft zu und wird angewendet,kein Logeintrag, wenn keine Regel zutrfft, dann wird geloggt und anschließend gedroppt.

    Die OUTPUT Regeln waren Quatsch, danke für den Tipp.


    Hier die Befehle und darunter der Qutput von iptables -L --line-numbers -n -v

    Ich hoffe, dass das schon besser, zumindest aber übersichtlicher ist.

    Habe hier noch einmal die iptables Befehle mit Kommentar zusammengefasst. Dort sind mehr Infos drin.

    Ich hoffe, dass ich mit eurer Hilfe die Kommentare #unsicher warum auflösen kann.

    Kann man in der chain nicht sehen. Auf Jeden Fall ist es so, dass ich nicht mit einer andern ip als 77.22.xx.xx auf irgenetwas außer udp 1194 zugreifen kann.


    ein list ohne line-numbers und ohne -n sieht so aus(da sieht man auch nicht, das das sich wohl auf loopback bezieht)

    ...

    Ich kann dir nicht viel zu deinen Chains sagen, aber beispielsweise der dritte Eintag der Input Chain macht doch den Rest obsolet, oder nicht?

    ...


    Das ist mir ach suspekt. Aber ich habe das irgentdwo gelesen:

    Code
    # Allow all loopback (lo) traffic and reject traffic
    # to localhost that does not originate from lo.
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A INPUT ! -i lo -s 127.0.0.0/8 -j REJECT
    iptables -A OUTPUT -o lo -j ACCEPT

    daraus resultiert der Eintrag:

    Code
    3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

    wenn das nicht drin ist, habe ich immer Einträge im Log das output vom 127.0.0.1 zu 127.0.0.1 denied werden.


    Code
    iptables_OUTPUT_denied:"IN= OUT=lo SRC=127.0.0.1 DST=127.0.0.1


    ufw, ja, bin aber eher old fashioned.

    Ich habe auf einem vServer openvpn und fail2ban installiert. Ich habe mir folgende iptables zusammenprobiert. Die Frage ist, ob ihr das für sicher haltet, oder ob da Schnitzer darin sind?

    Der SSH-Zugriff soll nur von der IP 77.22.xx.xx erlaubt sein, openvpn soll für Roadwarrior als Internet-Relais zur Verfügung stehen, wobei hier die Source-IP natürlich wechselt.

    Vielleicht kann mir ja jemand erklären, was die drei folgenden Regel bedeuten:

    Code
    iptables -I INPUT -i lo -j ACCEPT
    iptables -I INPUT ! -i lo -s 127.0.0.0/8 -j DROP
    iptables -I OUTPUT -o lo -j ACCEPT

    Diese erstellen in der INPUT chain die Einträge #2 und #3 und in der OUTPUT chain den Eintrag #2.

    Das hat wohl was mit dem Loopback zu tun, aber mir ist nicht zu 100% klar, was genau.


    Danke für eure Antworten.

    @ASS

    Danke für den Tipp. Haben die tatsächlich gemacht. Hatte das vor ca. 6 Monaten schon versucht, da war noch die Aussage, dass geht nur im Business-Tarif. Jetzt habe ich einen echten Dualstack. Werde aber meinen vServer weiter behalten, ist ja auch eine nette Spielwiese.


    @mainziman

    Das Script setzt auf 'Standardbordmittel' es setzt ausschließlich auf iptables-Rules. Ich habe das Ganze jetzt in Python 3 umgesetzt. Also wird das Script solange funktionieren, wie es iptables und Python 3 gibt. Hier ist aber nicht die richtige Stelle um das zu veröffentlichen.


    @H6G

    Habe deine Tipps umgesetzt. Das Script ist jetzt Python 3 und wird über systemd gestartet. Mal schauen, ob ich das auf github oder github gists mache. Ich arbeite noch an der Optimierung.


    Danke für alle sehr hilfreichen Hinweise hier im Forum.

    Danke für den Tipp. Habe hier einen Gigabit Anschluss mit Docsis 3.1. Da muss ich die Provider Fritzbox nehmen. Die ist kastriert und kann keinen Bridge Mode. Kann auch im Kundencenter nichts umstellen. Das Ding macht bei mir nur Telefonie und dahinter kommt dann eine ipfire Firewall und dann erst mein Netz. Direkt an der Fritzbox hängt nur die Firewall. Habe den vServer im Angebot für 2,75/Monat. Und ein bisschen frickeln hält ja auch die Grauen Zellen jung.:)


    @Gunah

    Ja, habe ich schon was gelesen. Das kommt evtl. für Openvpn Road Warrior in Frage. Obwohl, da ist auch clientseitig Android im Spiel=O

    Da muss man ja sehr viel auf der Clientseite machen. Und 'ne Android App zu schreiben, dass tu ich mir nicht mehr an.

    Ich musste mich mein halbes Berufsleben mit Windoof 'rumquälen. Bin dann privat, Alter macht ja auch Weise;), spät zu Linux umgestiegen

    Aber finde es gut, wie alle hier mitdenken und sinnvolle Vorschläge machen. Danke dafür!


    By the way, ich habe festgestellt, dass fail2ban sich für Portscans gar nicht interessiert, solange keine Verbindung zu Stande kommt.


    hab mal den Vorschlag von @sdellenb umgesetzt. Habe dann von einem Perfect Privacy VPN Gateway(dort teilen sich hunderte Benutzer eine IP , also ein idealer Weg, wenn man Böses im Sinn hat!) Portscanns gemacht. Null Reaktion seitens fail2ban. Nur, wenn ich tatsächlich versuche, eine Verbindung aufzubauen, schnappt die Falle zu.

    Du hast natürlich Recht mit Python2.7. Aber als IT Mensch im Ruhestand ist man natürlich ein wenig hinterher. Wenn überhaupt Interesse an dem Skript besteht, werde ich mir die Mühe machen das auf Python3 umzuschreiben.

    Aus dem selben Grund ist mir natürlich auch IPv6 suspekt. Das ist was für deine Generation;)

    Das ist tatsächlich der einzige Grund, warum mein vServer hier überhaupt existiert.

    Vodafone Kabel gibt mir keine echte von 'außen' erreichbare IPv4/die nennen das Dual-Stack-Lite, ist totaler Quatsch). Hab mich versucht in IPv6 einzulesen.

    Aufgegeben. Da wird ja alles, womit ich IT-Technisch 'aufgewachsen' bin über Bord geworfen.

    Also, für mich einfachste Lösung: vServer mit echter IPv4. Openvpn-Client im Netz hinter meiner ipfire-Firewall und dann Client to Client.

    Schon ist alles wieder IPv4 und ich fühl mich zuhause.

    Wie gesgagt, ich bin von Haus aus kein Netzwerker. IPv4 auf hohem 'Hausgebrauch-Niveau' ist ok für mich.

    Und mit dem systemd hast du natürlich auch Recht.

    Ein SYN-Scan

    nmap -sS könnte da doch durchrutschen, oder?



    "

    Der SYN-Scan ist die schnellste und meistgenutzte Scan-Methode. Sie erlaubt eine zuverlässige Unterscheidung zwischen den Zuständen geschlossen und gefiltert. Wenn das Netzwerk schnell genug ist, dann kann man damit innerhalb weniger Sekunden mehrere Tausend Ports scannen.

    Den SYN-Scan bezeichnet man auch als Halfopen oder Stealth Scan. Er basiert darauf, dass der Drei-Wege-Handshake nur initiiert, aber nicht mit ACK bestätigt, sondern vorzeitig mit RST abgebrochen wird.

    • OPEN: SYN -> SYN+ACK -> RST
    • CLOSED: SYN -> RST (Das Zielsystem antwortet mit einem RST-Paket.)
    • FILTERED: SYN -> keine Antwort (Das SYN-Paket wird beim Zielsystem verworfen.)

    Dadurch, dass man die TCP-Verbindung nicht erst mit ACK bestätigt, sondern sofort mit RST beendet, ist die Scan-Geschwindigkeit um ungefähr 30 bis 40% schneller als beim Full-Connect-Scan.

    Der SYN-Scan bleibt oft unbemerkt, weil in der Regel nur Full-Connects bei der Anwendung protokolliert werden. Nachteilig ist für den Angreifer oder Pentester, das der SYN-Scan von einem IDS erkannt werden kann, weil der Ablauf ziemlich untypisch für eine "normale Verbindung" ist.

    "

    aus https://www.elektronik-kompendium.de/sites/net/2103061.htm

    Meinst du so?


    Ist ja genial, wenn das geht.

    Aber wie reagiert diese Konfiguration denn auf einen Portscan? Wie gesagt, bin kein Netzwerkspezialist.

    Das Folgende dokumentiert mal, was das Skript macht:

    Ausgeführt von einer beliebigen nicht berechtigten IP:

    Code
    :~$ ssh root@94.16.xxx.xxx -p 6666
    ssh: connect to host 94.16.xxx.xxx port 6666: Connection timed out

    Ausgeführt von der einzigen berechtigten IP:



    Und hier das Ergebnis von nmap ohne Skript von beliebiger nicht zugelassener IP:

    Code
    # nmap -sS 94.16.xxx.xxx
    Nmap scan report for v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.xxx.xxx)
    Host is up (0.036s latency).
    Not shown: 999 filtered ports
    PORT     STATE SERVICE
    6666/tcp open  irc
    
    Nmap done: 1 IP address (1 host up) scanned in 38.00 seconds

    Und hier nmap mit Skript von beliebiger nicht zugelassener IP:

    Code
    # nmap -sS 94.16.xxx.xxx
    
    Starting Nmap 7.01 ( https://nmap.org ) at 2020-02-15 06:52 CET
    Nmap scan report for v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.1xxx.xxx)
    Host is up (0.039s latency).
    All 1000 scanned ports on v2xxxxxxxxxxxxxxx.bestsrv.de (94.16.xxx.xxx) are filtered
    
    Nmap done: 1 IP address (1 host up) scanned in 40.40 seconds


    Es macht also, was es machen soll.

    Das gilt ja wohl nur für Nutzer auf dem Server. Und da bin ich in diesem Fall der einzige Nutzer. Der Server ist mein ganz persönlicher VPN-Relay Server um das Vodafone ds-lite Dual Stack Problem zu umgehen. Bei einem Public-Server mit mehren Usern hast du natürlich Recht. Kommt halt auf den Anwendungsfall an. Aber das Skript funktioniert ja auch mit Port 22.


    Als Angreifer würde ich erst einmal die Standardports über eine IP-Range scannen. Erhalte ich dort eine Antwort, lohnt es sich, weiter zu bohren.


    Als nächstes arbeite ich daran die udp openvpn Ports automatisiert nur dann zu öffnen, wenn ein (zugelassener) Road Warrior darauf zugreift.

    Das ist aber komplexer, wegen der wechselnden IP. Der Vorteil liegt dann darin, das der Server bei einem Scan durch einen Angreifer die meiste Zeit so reagiert, als wäre er nicht vorhanden. Wo nichts ist, lohnt kein Angriff.


    und warum rc.local. Hey, ich will nur ein Python Skript, welches mit 0.0 Cpu-Last dümpelt auf einem vServer mit einem core starten. Wozu systemd?;)