- Dette emne har 61 svar og 8 stemmer, og blev senest opdateret for 5 år, 12 måneder siden af Bjarne. This post has been viewed 3371 times
-
Indlæg
-
Bjarne- Super Nova
Du har muligvis ret. Jeg har nu installeret tor-browser på min normale arbejdsmaskine. Jeg får straks en en CAPTCHA med besked om, at forum.astronomisk.dk kræver tilladelse til cookies. Jeg fjerner “private browsing” og tillader alle 3. parts cookies. Det gør absolut ingen forskel. Det må være web-hotellet som bremser al trafik fra enhver tor-knude. De viser så denne tåbelige CAPTCHA, som man ikke kan besvare. Den kommer bare igen og igen. Det minder mig om programmet Kontant, som afslørede, at YouSee’s kundecenter bevidst gav forkerte oplysninger for at holde kunderne fra livet. Jeg kender ikke lovgivningen i Holland, så jeg ved ikke, om det er ulovligt. De burde tælle faktiske login forsøg på Astro-Forum i stedet for at filtrere al trafik til en CAPTCHA. Det hævder de også, men i betragtning af Kontants afsløring, så er jeg ikke overbevist….
Bjarne- Super Nova
Der er måske en anden forklaring. En hær af robotter plejer at betyde et ssh-botnet af ssh-servere på usikre Internet-of-Things, som forsøger at logge på ssh-servere med passwords. En dynamisk firewall kan blokere IP-adresser, som gentagne gange forsøger at logge på en ssh-server uden held. Alle andre protokoller vil også blive blokeret på adressen, altså også https på port 443. VPN og Tor anvender UDP (User Datagram Protokol) pakker. Fordelen ved UPD-pakker er, at disse ikke kan underkastes DPI (Deep Package Inspection), som man kan med TCP-pakker. Dataindholdet kan ikke undersøges ved en filtrering, så indholdet bestemmer prioriteringen. Netneutraliteten kan således ophæves for TCP-pakker, men ikke for UDP-pakker. Men hvor Deep er Deep?
Vi er inde på et område, som jeg ikke ved tilstrækkeligt om. Kan man overhovedet logge på en ssh-server via UDP? Hvis dette er muligt, vil et botnet via Tor kunne medføre, at en dynamisk firewall også vil lukke for andre protokoller som https. En mere elegant løsning (hvis antagelsen er korrekt) ville være kun at tillade ssh-login via public keys. Dette er noget, som jeg selv gør mellem mine maskiner.
Bjarne- Super Nova
Jeg har rodet rundt i begreberne. TOR = The Onion Router er blot en router med flere knudepunkter. Der kan sendes TCP pakker via routeren, men der kan også sendes UDP pakker via en såkaldt tunnel, men UDP pakker kan også sendes via en tunnel over en ssh forbindelse, som normalt anvender TCP pakker. En ssh-forbindelse kan selvfølgelig også sendes via TOR routeren. Det korte af det lange er, at en Tor udgangsknude både kan have en ssh-forbindelse og en tunnel med en https forbindelse. Hvis man anvender en dynamisk firewall, som stopper en IP adresse med mange ssh-login forsøg, vil man automatisk også stoppe tunnelforbindelsen med web-forbindelsen. Man burde stoppe muligheden for ssh login med password. Så kunne man droppe den dynamiske firewall, som har taget web-forbindelsen som gidsel.
Bjarne- Super Nova
Det jeg skrev var ikke helt korrekt. Der er stor forskel på en ssh-tunnel og en UDP-tunnel. En ssh-tunnel består altid af TCP-pakker med et krypteret indhold. En UDP tunnel indkapsler en TCP-pakke i en UDP pakke, så TCP indholdet ikke kan “inspiceres”. Ved udgangen af UDP-tunnelen frigives TCP-pakken. Et VPN er normalt en UDP-tunnel. TOR kan både tormidle TCP-trafik og en UDP-tunnel, såvidt jeg kan læse mig til. En Tor-Browser anvender en UDP-tunnel, som indkapsler TCP-pakker med Web-trafik. Jeg mener, at konklusionen ovenfor er korrekt. En udgangsknude fra TOR-netværket han indeholde ssh-login med password. Man må beskytte sig mod ssh-login med password. Dette kan gøres enten ved en dynamisk firewall eller ved at forbyde ssh-login med password.
Frank Larsen- Super Nova
Jeg er ikke sikkerhedsekspert og har iøvrigt ikke noget med driften af den tekniske platform eller AS at gøre (hjælper kun omkring det grafiske) – men:
Jeg kan ikke se hvad Google Analytics har noget med noget at gøre i denne forbindelse.
Der anvendes WordPress.com stat i forbindelse med Jetpack – det anvender ikke GA – men GA kan ganske rigtig integreres hvis ønsket.Det er jo iøvrigt tidligere afgjort med sikkerhed at problemet ligger hos Siteground og de kører med ekstrem høj sikkerhed for at holde bots ude af deres systemer. metoden de anvender er desværre ikke særlig venlig overfor Tor brugere eller brugere der sider på store netværk bag proxyer/firewalls.
Det er derudover tydeligt fra whois at serveren ligger på netværket SG-GETCLOUDER-AMS1 – hvilket indikere at siteground anvender en getclouder løsning til allokering af virtuelle servere – hvilket næppe heller har noget med afvisningen af TOR/sikre browsere at gøre.
Det er Sitegrounds anti-bot-ai system der blev lanceret i 2017 og som de praler med vidt og bredt som giver anledning til problemet og det er de helt åbne omkring:
https://www.siteground.com/blog/new-anti-bot-ai/
Der er et fint screenshot et stykke nede som matcher det screenshot som Lars postede i starten af tråden.
Scroll dernæst ned til indlægget fra Eric G og læs svaret.
Svaret de giver er at TOR forbindelser hele tiden skifter IP og med det endelige antal TOR exit nodes resulterer kontinuerte bot attacks via TOR netværket i at stortset alle exit nodes permanent er blokeret på sitegrounds servere. Deres support anbefaler helt kontant at man bør anvende en regulær browser – hvilket indikerer at de tilsyneladende ikke har tænkt sig at gøre noget ved det.
Det er ikke særlig positivt !! –
Det forklare umiddelbart også hvorfor at Lars ikke oplever problemer med andre sites – det kunne være interressant at besøge andre siteground hostede sites som kræver login og se om der er tilsvarende problemer med login der.
et par opklarende spørgsmål – bare for at jeg også forstår problemet i lidt mere detaljer – jeg vil gerne hjælpe biberadm med at formulere en kort og præcis fejlbeskrivelse der er skåret ind til benet uden for meget støj.
– Kan I se og læse forum uden at logge ind fra jeres forskellige sikkerhedsløsninger eller bliver i blokeret inden I når så langt.
Lars – du nævner at det ikke kun er TOR – det ville være formålstjenstligt at vide hvilke andre beskyttelse metoder der giver tilsvarende problemer så der kan oprettes en velbegrundet bug report hos siteground.
– Hvis forums admin kan påvise overfor siteground at problemet er mere omfattende end bare TOR så er de (siteground) måske mere lydhøre.Jeg har prøvet at bruge incognito mode i en hel del forskellige browser fra forskellige platforme uden at blive afvist eller blive præsenteret for en captcha
Er der nogen sikkerhedsindstillinger i TOR som kunne løsnes lidt for at få det til at virke?
Hvilke andre alternativer til TOR er der som ville være acceptable.
Når jeg er færdig med at arbejde med grafikken her i slutningen af denne uge, vil jeg gerne tilbyde at se nærmere på TOR sammen med biberadm og Bjarne, og afsøge om der skulle være en indstilling der slipper TOR igennem mere rent og hvad det er der forhindre korrekt redirect fra captchaen – hvilket vel er det grundlæggende problem!?
Frank Larsen- Super Nova
Ok – har så installeret TOR og kan nu replicere problemet.
Først en captcha der kører i ring på http://forum.local/.well-known/captcha/botdetect
Dernæst får jeg fint adgang ved at slette ./well-known….
Og ender i en meddelelse fra JETpack om at “Jetpack has locked your site’s login page” med angivelse af et ip det givetvis er tor.
Jeg går så ikke videre herfra.
Jeg fodrer biberadmin med data, så må vi se hvad vi kan få ud af det.
Bjarne- Super Nova
Tak Frank, for at have fundet ondets rod.
Det er selvfølgelig det opreklamerede AI, som er i sving. Det minder om den den danske digitalstats seneste påfund, nemlig at samkøre samtlige registre uden at oplyse borgeren om den alternative automatiske samkørsel. Formålet er at anvende Deep Learning til at forudsige, hvem der vil udvikle sig til skattesnyder eller mere generelt forbryder. Ideen bag er, at anvendelsen er forskning, som man mener skal fritages for datasikkerhed.
Det er for øvrigt også AI, som giver anledning til de store problemer med Intels spekulative instruktioner, som man nu kæmper for at afhjælpe.
nightsky- Neutron star
Hej Frank
Passer meget godt med hvad jeg ser. Ufattelig at de roser deres system, for det er “forholdsvis” nemt at om gå det, men dog bøvlet.
Jeg gør ikke mere herfra. Hvis man ikke ønsker brugere der værner om deres privatliv eller har kommer gennem med høj sikkerhed, så er den vel ikke længere. Min tålmodighed er brugt på nu.
Dog utroligt at et professionelt firma som Biberkopf, der har lavet forum, ikke kan navigere uden om dette, men i stedet bare vælger den nemme løsning. Det er ikke noget at gøre.
Bjarne- Super Nova
Firmaet synes så begejstret for deres eget anti-bot-AI, at de har mistet jordforbindelsen. Jeg er ikke i tvivl om, at visse højtprofilerede sider, kan drage fordel af deres produkt. Men hvordan fordeler de fejlslagne login forsøg sig på de forskellige web-sites? Har det nogen praktisk betydning for Astro-Forum, at der kommer nogle få fejlslagne login-forsøg? Er det rimeligt, at et par sider med 99% af login-forsøg gør livet surt for de resterende sider. Der burde ikke være et problem, hvis man gennemtvinger rimeligt lange passwords. Jeg anvender selv et auto-genereret password med 20 tegn. Det er klart, at man har problemer, hvis brugerne anvender passwords som 12345 eller lignende. Produkter som Anti-bot-AI medvirker blot til at opretholde en slap password-politik.
Jeg anvender selv ProtonVPN med openvpn som klient. Jeg har ikke problemer med at logge på Astro-Forum.
Bjarne- Super Nova
Jeg er gået på jagt efter, om andre web-sider beskytter sig med AI mod bots. Jeg forsøger mig først med version2.dk fra TOR-Browseren. Ingen problemer. Derimod finder jeg nogle meget kritiske kommentarer fra Linus Torvalds om Intels anvendelse af AI til at oversætte fra virtuelle instruktioner til det gamle instruktionssæt for fysiske adresser:
Intel er ikke seriøse omkring fiks af CPU-sårbarheder, mener Linux-udvikleren.
En meget diplomatisk oversættelse.
»Som det står, er de her patches helt og aldeles skrald,« skriver han og fortsætter:
»De gør bogstaveligt talt sindssyge ting. De gør ting, der ikke giver mening.«
»WHAT THE F*CK IS GOING ON?«
Torvalds er blandt andet ikke tilfreds med en ny feature kaldet IBRS_ALL, som er en af flere elementer, der skal gøre CPU’en mindre sårbar overfor Meltdown-angreb, ved at begrænse den såkaldt spekulative udførsel, som Version2 tidligere har beskrevet.
Journalisten blander dog tingene sammen. Torvalds omtaler Spectre 7515.
Funktionen er dog designet som opt-in, og det er således op til brugeren at markere, at man ønsker, at CPU’en ikke skal være sårbar.
»Hele IBRS_ALL-funktionen siger meget klart, ‘Intel tager ikke dette alvorligt, vi laver et grimt hack, som er så dyrt, at vi ikke vil slå det til som standard, fordi det ville se skidt ud på vores benchmarks’,« skriver Linus Torvalds. .
»Så hele IBRS-skraldet implicerer, at Intel ikke har planer om at gøre det rette for indirect branch speculation. Ærlig talt, det er helt uacceptabelt,« fortsætter Linux-udvikleren.
IBRS = Indirect Branch Restricted Speculation
En indirect branch et hop (GOTO) til en adresse i et register. Det drejer sig om instruktionen:
jmp, eax
Denne instruktion foregår i fysiske adresser. Intel anvender AI til spekulativ oversættelse fra det lineære virtuelle adresserum til de fysiske instruktioner. Dette betyder, at processoren når at oversætte en adresse til den fysiske adresse og placere den i eax, inden en exception stopper udførelsen. Dette betyder igen, at en anden bruger kan få fat i indholdet i eax og det den peger på i det fysiske adresserum, som tilhører en anden bruger.
»Der er ikke nogen god grund til, at det er opt-in. Bare fiks det!« skriver han.
Til gengæld mener han ikke, at en grim løsning nødvendigvis er en dårlig løsning:
»Hvis alternativet var hjemkaldelse af produkter fra to årtier, og at give alle gratis CPU’er, så er jeg ikke sikker på, at det var helt sindssygt,« skriver han og fortsætter:
»Det er helt bestemt et nasty hack, men hey – verden brændte, og i sidste ende var vi ikke nødt til at slukke for datacentrene og gå tilbage til at opdrætte geder, så det er ikke kun skidt.«
Problemet betyder, at der ikke er isolation mellem containere.
Bjarne- Super Nova
Jeg har prøvet politiken.dk, eb.dk, tv2.dk og dr.dk med TOR-Browseren ingen af dem giver problemer. Det er helt ud i hampen, at Astro-Forum skulle beskyttes bedre end de store mediehuse. Ah-ha. Rigspolitiet: http://www.politi.dk giver heller ingen problemer for TOR-Browseren.
Jeg kan altså ikke lige se, at Astro-Forum skal sikres bedre end Rigspolitiet!
Er der sket noget nyt? https://astronomisk.dk giver heller ingen CAPTCH fra TOR-Browseren.
Bjarne- Super Nova
Login på forum.astronomisk.dk giver heller ingen CAPTCHA, men jeg tror, at jeg ved hvorfor. Jeg kører med ProtonVPN slået til. Jeg skal prøve uden ProtonVPN. Nej. ProtonVPN er ikke slået til. Jeg opgiver. Jeg forstår ikke, hvad der foregår. Ned med AI!
Bjarne- Super Nova
For at undgå misforståelser: Min negative holdning til AI gælder kun Deap Learning med et neuralt netværk med 3 lag. Man kan læse om anvendelsen af neurale netværk i astronomien i et af de seneste numre af Sky & Telescope. Det er et uundværligt værktøj ved klassifikation af milliarder af objekter, hvor mere traditionelle metoder er for langsomme. Men anvendelsen kræver træning på et stort datasæt, som er klassificeret med en traditionel metode. Fordelen ved et NN er, at der altid gives en klassifikation. Bagdelen er, at der aldrig gives et estimat for fejlen. Man ved ikke, om resultatet giver mening i det enkelte tilfælde. Man kan kun få et statistisk estimat for fejlen ved at sammenligne med et stort datasæt, som er klassificeret på den traditionelle langsomme metode.
Der findes imidlertid andre metoder, som angiver sandsynligheder, det kausale netværk. Jeg har også andet sted fortalt om neuroevolution, som er en helt anden anvendelse af et neuralt netværk, som ikke kræver nogen træning.
Bjarne- Super Nova
Jeg vil slutte denne tråd med en rapport om anvendelsen af den seneste tor-browser version 7.5 fra den 23. januar. Der kom heldigvis ikke noget CAPTCHA ved login på forum.astronomisk.dk. Login var dog noget langsom. Jeg har heller ingen problemer med arxiv.org.
Bjarne- Super Nova
Det var for tidligt. Mr. A.I. strikes again. Der var kommet en opdatering til tor-browseren, som jeg lige skulle prøve på forum.astronomisk.dk. Jeg fik en CAPTCHA inden jeg kom til login. Det var fra en laptop med Fedora 27.
- Emnet 'Endnu en gang – stadig fejl CAPTCHA' er lukket for nye svar.