1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Bundestagsanhörung: Eco warnt…

wie man den bnd merkt

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. wie man den bnd merkt

    Autor: amdonly 23.02.21 - 04:40

    -



    2 mal bearbeitet, zuletzt am 23.02.21 12:50 durch sfe (Golem.de).

  2. Re: wie man den bnd merkt

    Autor: amdonly 23.02.21 - 05:11

    wenn eure ssl-verindungen im browser auf populären websites wie ebay/ebay-kleinanzeigen oder paypal oder googlemail nicht nachgeladene bilder oder kaputtes layout oder aber generell sehr lahmer aufbau insb von pics, dann wisst ihr: da ist jemand in der leitung am schnüffeln, mit einem state-of-the-art mitm-ssl-proxy.
    bei tls1.2 verbindungen ist das nicht so deutlich sichtbar (firefox lädt keine addons nach bsw, addons-ansicht zeigt keine app-symbilik, ebay-kleinanzeigen lädt die pics sehr vezögert nach), aber sobald tls1.3 im spiel ist, wird die seite unbenutzbar.
    am bsp. paypal wird die seite dargestellt, als ob man einen superaggresiven adblocker nutzt (obwohl keiner aktiv ist!), das layout kreuz und quer - einfach unbenutzbar. und der login klappt damit auch nicht...
    aber wie in etwa mach der bnd das? nun, die verschlüsselung an sich knackt er nicht, in echtzeit, ABER a) metadaten (wohin geht das paket, dns-leaks) und b) man hat zuvor auf eurem rechner eine eindeutige fingerprint-datei hinterlegt.
    bei mir war das leicht ersichtlich: in einer frischen virtuellen maschine (ob linux oder windoof) wurde die website sauber angezeigt, nur auf dem lokalen host nicht. konsistente konfiguration des ffoks durch gleiche user.js (der ffox ist @default sehr unsicher ;).
    wie kann man sich am besten gegen den bnd schützen?
    SSH-VPN! anders als OpenVPN encapsuliert ssh nämlich die verschlüsselten datenpakete nicht, sondern ersetzt die sichtbaren IP-Header (klar, sonst würde routing nicht gehen) vollständig (!). dadurch hat man gleichzeitig eine echte netztrennung client-(ssh)-socksproxy-inet, das inet kennt nur die externe ssh-server ip.
    ein ssh-vpn auf diese weise hat noch einen weiteren großen vorteil: viel günstiger als xyz-vpn dienstleister (!). man braucht dazu nämlich nur einen xyz vserver irgendwo auf der welt verstreut.
    die gibts für 2-5 eur/usd monatlich.
    weiterhin ist ssh deutlich performanter als openvpn - und schützt durch die tatsächliche netztrennung die privatsphäre deutlich besser (!). denn openvpn encapsuliert dein ip-paket von zuhause, d. h. der ip-fingerprint deines betriebesystems wird beibehalten, nur dadrüber halt noch die openvpn encalsulation, damit es in den tunnel passt...
    sog. 'echte' vpn-tunnel wie mit ipsec oder openvpn sind NICHT dazu geeignet, die privatsphäre zu schützen! diese protokolle wurden designed, um private netze miteinander zu verbinden, ggf. auch auf layer2 niveau, damit sogar broadcasts/dhcp/multicast über den tunnel das andere vertrauenswürde netz erreichen kann.
    also primär für den reibungslosen unternehmenseinsatz. schon in den 90ern haben aber unix-admins schon ssh-socks-proxys für remote-einwahl und privatshäre bevorzugt!
    ein socks-proxy hat aber doch einen kleinen nachteil: ein schlecht konfiguriertes system kann daten trotzdem leaken!
    dem beugt man aber vor, indem man nämlich a) vor allem den ssh-vserver vollständig kontrolliert und dort mittels firewalling nur ausgehendes https zulässt und b) auf dem client lokal die fierwall so dicht macht für ausgehende(!) verbindungen, dass der browser nur noch zum lokalen socks-port des temporär gestarteten vpn-clients verbinden darf ...
    daran sieht man schon: durch diese ssh-socks-proxy-konstellation kann man lokal nicht mehr effektiv firewallen, wohin der firefox verbindet und b) zu welchen tcp-port, letztendlich.
    hier kann ich nur nochmal wiederholen: auf dem vserver wird effektiv firewalled, für ausgehende connections (!). klar, die noobs unter den iptables-nutzern (ööööhm, ich lasse mal alles raus und blocke nur eigehend, hat ja immer so funktioniert, zuhause...) sehen hiermit kein land, aber die sind dann idr auch zu blöd, sowas sicher zu betreiben - geschweige denn richtiges stateful-firewalling mit iptables auf die kette zu kriegen - in beiden richtungen ;)

    tip: in einem localen client-setup mit browser & ssh-client (suboptimal) konfiguert den ffoks zunächst für DNS-over-HTTPS und DANACH erst für den ssh-client mit unbeding Socks4 - nicht Socks5! letzteres erlaubt auch das ip-proto UDP und ein dns-leak ist garantiert. außerdem funktionert dann der ganze schmu nicht mehr, über die ssh-verbindung ;)
    zu guter letzt sorgt man mit der lokalen firwall auf dem client dafür, dass der firefox wirklich nur den zielport des lokalen ssh-vpn-socks-ports erreichen darf - und noch parallel per https etc ins internet - dann hätte man sich das auch gleich sparen können ;)
    achja: auf dem externen vserver mit ssh-server aktivieren wir KEINEN tunnel in der sshd_config. denn das würde ein tun-device anlegen, wodurch ggf. Layer2-leakage statt finden könnte ... nein will man nicht ;)
    weiterhin sollte man immer möglichst auf dhcp verzichten! denn dhcp ist ein layer2 protokoll, kann man also mit keiner ip-stateful-firewall blocken.
    sobald aber ein interface statisch konfiguriert ist, ignoriert es alle dhcp-offer. so beugen wir vor, dass ein angreifer oder eher der vserver-hoster uns an der server-ip rumfummelt (wes wurden schon nic-fimwares durch dhcp umgeflasht...!(intel^^).
    wobei das in punkt vhoster egal sei, weil dort eh sehr viele vhosts nur ein physisches interface nutzen... wer maximale sicherheit will, nutzt nur eigene hardware zuhause vorkonfiguriert und extern aufgestellt, mit sicherheitssiegeln ;)
    (die meisten vserver hoster nutzen nämlich dhcp, aber mit einer sehr langen leastime...)

    da ich so nett bin, hier ein auszug aus der vserver iptables-konfiguration, damit dieses ssh-vpn funtioniert und sicher bleibt ;)
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT DROP [0:0]
    -A INPUT -s <subnet(s)-vserver-hosters!> -j DROP
    -A INPUT -m conntrack --ctstate INVALID -j DROP
    -A INPUT -s <eigene-wanip-zuhause> -d <feste vserver-ip> -i eth0 -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    -A INPUT -i eth0 ! -s <subnet(s)-vserver-hoster> -p tcp -m tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    -A INPUT -j DROP
    -A FORWARD -j DROP
    -A OUTPUT -d <subnet(s)vserver-hoster> -j DROP
    -A OUTPUT -m conntrack --ctstate INVALID -j DROP
    -A OUTPUT -s <ssh-vserver-ip> -d <eigene-wanip-zuhause> -o eth0 -p tcp -m tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
    -A OUTPUT -o eth0 ! -d <subnet(s) vserver-hoster> -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    -A OUTPUT -j DROP
    COMMIT

    wer diese iptables verstanden hat, ist würdig einen ssh-vpn-proxy zu betreiben ;)
    ps: der ssh-serverdienst wird natürlich NICHT auf dem loopback device konfiguriert.
    sondern auf der erreichbaren festen ip-adresse des vservers. hat den vorteil, dass iptables hierbei alle loopbackverbindungen blockiert! wir wollen nämlich nur den ssh-server am laufen haben. dns macht nämlich schon unser browser zuhause per dns-over-https, welches dann noch über ssh ausgeleitet wird zur vserver-ip ;)
    pps: der ssh-server läuft natürlich NICHT auf dem standardport 22, sondern tcp443, what else ^^
    obacht bei der oberen iptables-regelsatz: wer es nicht auf die kette kriegt, diesen persistent einzupflegen mittels iptables-restore etc an den richtigen stellen der konfig, blockiert sich automatisch aus ^^

    hauptsche gesund.



    4 mal bearbeitet, zuletzt am 23.02.21 05:22 durch amdonly.

  3. Re: wie man den bnd merkt

    Autor: amdonly 23.02.21 - 06:43

    härten des kernels:
    sysctl -p
    net.ipv4.conf.default.rp_filter = 1
    net.ipv4.conf.all.rp_filter = 1
    net.ipv4.ip_forward = 0
    net.ipv6.conf.all.forwarding = 0
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv6.conf.all.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv6.conf.all.accept_source_route = 0
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 10
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv4.tcp_keepalive_intvl = 0
    net.ipv4.tcp_keepalive_probes = 0
    net.ipv4.tcp_keepalive_time = 0
    net.ipv4.tcp_fin_timeout = 1

    - ipv6 rundum deaktiviert. denn wir fahren kosequent vom lokalen browser bis ins inet ipv4. ipv6 wäre hier ein seitenkanal...
    - keine keepalives seitens des servers. wenn überhaupt dann pollt der ssh-client regelmäßig, damit die firewall im router zuhause nicht den state killt... ein server sollte IMMER muxmäuschenstill sein.
    - forwarding und umleitungen rigoros deaktiviert. wir nutzen nur ein interface und der vserver ist KEIN router.
    - tcp-fin-timeout so gering wie möglich (nsa-empfehlung btw.)



    2 mal bearbeitet, zuletzt am 23.02.21 06:47 durch amdonly.

  4. Re: wie man den bnd merkt

    Autor: Zensur_ist_Kacke 23.02.21 - 07:14

    Wow!
    Dieser Kommentar ist deutlich wertvoller als der Artikel selbst (der ist auch schon gut)!
    Vielen Dank dafür!

  5. Re: wie man den bnd merkt

    Autor: amdonly 23.02.21 - 07:39

    ach scheiße! ich habe mir gerade meine ganze sysctl.conf gekillt als ich gerade echo "xyz=0" > /etc/sysctl.conf ausführte, ich linux noob ^^

    auch interessant: default ist iptables connectiontracking ziemlich unsicher (lange timeouts, keine strikte sessions)
    https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt

    'sysctl -a' zeigt die aktuelle gesamte kernelkonfig an, da kann man dann ansetzen... wenn einem langeweilig ist.
    aber zumindest sollte man bei einem netzlastigen host wie einem von-server connection tracking richtig machen ;)
    d.h. auch, dass net.ipv4.tcp_fin_timeout = 1 keine wirkung hat, weil iptables conntrack-modul nun die kontrolle hat.

    PS: ich glaube der bnd braucht garnicht den zielrechner manipulieren mit irgendwelchen fingerprintfiles. der mächtige bnd-ssl-proxy observiert einfach deine verbindung und erstellt automatisch den fingerprinkt. umso eher, je öfter man mit demselben (unsicheren) ssl-protokoll surft. ssh ist aber nicht ssl, sondern sicher konfiguriert unknackbar (aes256-cbc (nicht ctr, das wäre browser-niveau! + hmac-sha2-512 oder -256 zur authentifizierung der pakete. keyxchange per diffie-hellman-group-sha256 oder mit mind 4096bit rsa oder so).



    4 mal bearbeitet, zuletzt am 23.02.21 07:46 durch amdonly.

  6. Re: wie man den bnd merkt

    Autor: Zensur_ist_Kacke 23.02.21 - 08:03

    amdonly schrieb:
    --------------------------------------------------------------------------------
    > ach scheiße! ich habe mir gerade meine ganze sysctl.conf gekillt als ich
    > gerade echo "xyz=0" > /etc/sysctl.conf ausführte, ich linux noob ^^

    XD
    Ohne solche Flüchtigkeitsfehler wird es ja auch langweilig ;).

  7. Re: wie man den bnd merkt

    Autor: Zensur_ist_Kacke 23.02.21 - 08:24

    amdonly schrieb:
    --------------------------------------------------------------------------------
    > PS: ich glaube der bnd braucht garnicht den zielrechner manipulieren mit
    > irgendwelchen fingerprintfiles. der mächtige bnd-ssl-proxy observiert
    > einfach deine verbindung und erstellt automatisch den fingerprinkt. umso


    Hm. Aber warum würde dann in deinem Fall die vm anders reagieren als der lokale Rechner?
    Die rausgehende Verbindung ist doch gleich?

  8. Re: wie man den bnd merkt

    Autor: amdonly 23.02.21 - 08:56

    Zensur_ist_Kacke schrieb:
    --------------------------------------------------------------------------------
    > amdonly schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > ach scheiße! ich habe mir gerade meine ganze sysctl.conf gekillt als ich
    > > gerade echo "xyz=0" > /etc/sysctl.conf ausführte, ich linux noob ^^
    >
    > XD
    > Ohne solche Flüchtigkeitsfehler wird es ja auch langweilig ;).

    hab nochmal die kurve gekriegt, per vnc-session auf den vhost...
    die netfilter-settings sind eine wissenschaft für sich, habe mir schon mal heute den ast damit weggesägt ^^ aber die default-timeout-werte für insb. established (tage!) sind irgendwie nicht safe?
    jetzt fühle ich mich etwas sichrer, aber das inet wird zäher.. vllt wegen "net.netfilter.nf_conntrack_tcp_loose = 0" ? whatever
    /etc$ cat sysctl.conf
    net.netfilter.nf_conntrack_acct = 0
    net.netfilter.nf_conntrack_buckets = 8192
    net.netfilter.nf_conntrack_checksum = 1
    net.netfilter.nf_conntrack_count = 2222
    net.netfilter.nf_conntrack_events = 0
    net.netfilter.nf_conntrack_events_retry_timeout = 15
    net.netfilter.nf_conntrack_expect_max = 124
    net.netfilter.nf_conntrack_generic_timeout = 0
    net.netfilter.nf_conntrack_helper = 1
    net.netfilter.nf_conntrack_icmp_timeout = 0
    net.netfilter.nf_conntrack_log_invalid = 0
    net.netfilter.nf_conntrack_max = 32000
    net.netfilter.nf_conntrack_tcp_be_liberal = 0
    net.netfilter.nf_conntrack_tcp_loose = 0
    net.netfilter.nf_conntrack_tcp_max_retrans = 3
    net.netfilter.nf_conntrack_tcp_timeout_close = 10
    net.netfilter.nf_conntrack_tcp_timeout_close_wait = 15
    net.netfilter.nf_conntrack_tcp_timeout_established = 60
    net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 1
    net.netfilter.nf_conntrack_tcp_timeout_last_ack = 15
    net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 3
    net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 15
    net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 15
    net.netfilter.nf_conntrack_tcp_timeout_time_wait = 15
    net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 15
    net.netfilter.nf_conntrack_timestamp = 0
    net.netfilter.nf_conntrack_udp_timeout = 1
    net.netfilter.nf_conntrack_udp_timeout_stream = 1
    net.ipv4.conf.default.rp_filter = 1
    net.ipv4.conf.all.rp_filter = 1
    net.ipv4.ip_forward = 0
    net.ipv6.conf.all.forwarding = 0
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv6.conf.all.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    net.ipv4.conf.all.accept_source_route = 0
    net.ipv6.conf.all.accept_source_route = 0
    vm.dirty_background_ratio = 5
    vm.dirty_ratio = 10
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv4.tcp_keepalive_intvl = 0
    net.ipv4.tcp_keepalive_probes = 0
    net.ipv4.tcp_keepalive_time = 0
    net.ipv4.tcp_fin_timeout = 1
    net.ipv4.conf.all.secure_redirects = 0
    net.ipv4.conf.default.accept_redirects = 0
    net.ipv4.conf.default.accept_source_route = 0
    net.ipv4.conf.eth0.accept_redirects = 0
    net.ipv4.conf.eth0.accept_source_route = 0
    net.ipv4.conf.eth0.secure_redirects = 0
    net.ipv4.conf.eth0.send_redirects = 0
    net.ipv4.icmp_echo_ignore_all = 1
    net.ipv4.tcp_ecn = 0
    net.ipv4.tcp_fastopen = 0



    1 mal bearbeitet, zuletzt am 23.02.21 09:16 durch amdonly.

  9. Re: wie man den bnd merkt

    Autor: amdonly 23.02.21 - 09:06

    Zensur_ist_Kacke schrieb:
    --------------------------------------------------------------------------------
    > amdonly schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > PS: ich glaube der bnd braucht garnicht den zielrechner manipulieren mit
    > > irgendwelchen fingerprintfiles. der mächtige bnd-ssl-proxy observiert
    > > einfach deine verbindung und erstellt automatisch den fingerprinkt. umso
    >
    > Hm. Aber warum würde dann in deinem Fall die vm anders reagieren als der
    > lokale Rechner?
    > Die rausgehende Verbindung ist doch gleich?

    achso, eine vm dediziert für den browser und ssh-client im socks-modus (ssh -D <lokaler-port> -p <serverport> user@ssh-sever-extern | client-verbindungseigenschaften setzt man lieber @ ssh_config) schafft nur insofern sicherheit, als dass man mit dem zurücksetzen auf den offline (!) schlüsselfertigen master-snapshot quasi immun ist für malware, die man sich ja idr schon mit dem ersten verbindungsaufbau ins inet ins haus holen kann?
    ansonsten: viele versch. vm parallel eingerichtet haben, möglichst versch. distrubutionen, betriebssysteme etc ;)
    ich schäte aber es liegt vor allem daran, _wie_ ssh verschlüsselt, im vergleich zum browser-ssl.
    und wie geschrieben die möglichkeit möglichst sichere ciphersuites für verschlüsselung, authentifizierung und schlüsselaustausch zu definieren ist quasi das nennenswerte kriterium.

    ach nochwas zu aes: es ist prinzipbedingt unsicher(!), sobald es nicht in hardware (per aes-ni cpu-erweiterung) beschleunigt wird. klingt komisch, ist aber so!
    d. h. wenn man nur auf nummer sicher gehen will nutzt man heute ... twofish (quasi aes²) oder doch das alte 3des ;) als blockcipher für den payload.



    2 mal bearbeitet, zuletzt am 23.02.21 09:07 durch amdonly.

  10. Re: wie man den bnd merkt

    Autor: wurstdings 23.02.21 - 14:39

    Krass, freut mich auch auf Golem mal richtige Checker zu sehen, die eindeutig die Fähigkeiten haben den BND lahm zu legen.

    Immer vorwärts!

    Aber Achtung! DES wurde von der NSA und NIST entwickelt, da solltet ihr lieber die Finger von lassen, ich empfehle Skytale.

  11. Re: nervige tcp_fin_wait1 states zügig killen

    Autor: amdonly 23.02.21 - 15:04

    sobald man den browser schließt bzw. den alt+strg+shift tätigt zum löschen aller browsersession-daten. solche 1-3 eur vserver haben den ram oft dynamisch geshared, da ist jede freie computeressource wertvoll...
    net.ipv4.tcp_retries2 = 2 # ggf 0 ?
    net.ipv4.tcp_orphan_retries = 1 # ggf 0?
    net.ipv4.tcp_retrans_collapse = 0

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT-Administrator mit Schwerpunkt Elektronische Akte (w/m/d)
    IT-Systemhaus der Bundesagentur für Arbeit, Nürnberg
  2. IT Service & Support Professional (m/w/d)
    ConSense GmbH, Aachen
  3. (Junior) Inhouse IT - Consultant (m/w/d)
    Nordwest Industrie Group GmbH, Bundesweit
  4. Softwareentwickler C#, VB.Net (m/w/d) für unsere CNC-Schleifmaschinen
    Schütte Schleiftechnik GmbH, Köln

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Star Wars AT-ST auf Hoth mit Chewbacca und Driode für 31,59€ statt 49,99€)
  2. (u. a. Gigabyte RTX 3090 Ti für 1.099€, RTX 3070 für 539€)
  3. (u. a. Team Group DDR4/DDR5-RAM u. SSD)
  4. (u. a. Computer, TV, Handys, PC- und Videospiele)


Haben wir etwas übersehen?

E-Mail an news@golem.de