19:07 door Anoniem
Daardoor heb ik dus wel last van vage blokkades als ik zelf buiten tor om websites benader, en om op de originele vraag terug te komen: tweakers doet het hier prima.
Met Torbrowser?
Met of zonder aanpassingen in de Torbrowser configuratie / Torbutton proxy instellingen ?
Gisteren, 23:10 door johanwIk draai zelf een Tor exitnode en krijg tweakers.net wel degelijk geladen.
Met Torbrowser?
Met of zonder aanpassingen in de Torbrowser configuratie / Torbutton proxy instellingen ?
________________________________________________________________________________________________
Wat ik wel krijg is een melding dat ik niet kan reageren via het forum als ik dat zou willen omdat ik via een Tor adres kom.
Die 'verBANnen' melding is mij bekend, dat is het probleem ook niet bij het lezen van nieuws. Je hoeft daarvoor niet in te loggen of te reageren.
Tweakers.net website melding naar Torbrowser gebruikers
Reactie-ban
Beste bezoeker,
Tweakers beperkt de functionaliteit van de site voor bepaalde netwerken om zo de hoeveelheid spam, oplichting en ander misbruik van de site te beperken. Onder deze toegangsbeperking vallen ook diverse mobiele providers en het Tor-netwerk.
Jouw IP-adres (xx.xxx.xxx.xx) valt helaas binnen een van die netwerken en daardoor is het momenteel uitgesloten van het plaatsen van reacties op Tweakers.
Als je ons een e-mail stuurt op frontpage@tweakers.net, dan kunnen we de situatie verder toelichten en indien mogelijk de blokkade verwijderen of voor jou een uitzondering maken. Stuur daarbij je gebruikersnaam en IP-adres mee.
Als je de beschikking hebt over een andere (vaste) internet verbinding, dan kan je daar uiteraard ook gebruik van maken.
________________________________________________________________________________________________
Gisteren, 23:10 door johanw
Misschien probeert de OP automatisch in te loggen en gaat dat fout?
Nee, ik probeer niet in te loggen, ook niet automatisch, ik probeer de website te bezoeken en allereerst de pagina te laden wat niet gebeurt.
________________________________________________________________________________________________
Nader onderzoekOmdat sommige gebruikers melden (met Torbrowser?) geen problemen te ervaren in het bezoeken van Tweakers.net rijst de sterke vraag hoe dat dan kan.
In de afgelopen ruime maand zag ik immers geleidelijk de bezoekmogelijkheid af nemen tot het punt dat de site in de praktijk eigenlijk niet meer bereikbaar is.
Niet meer bereikbaar via diverse systemen, diverse OS-en, diverse Torbrowser versies, diverse Torbrowser configuraties waaronder de standaard configuratie zoals het door Torproject wordt aangeboden.
Daarbij nog eens alle DNS settings bekeken, systeem caches, browser caches en DNS Caches geschoond.
Een parallelle test gedaan, één window met Tweakers.net laten proberen te laden , in een ander window Tweakers.net via een willekeurige free proxy bezoekend.
Het free proxy window laadt de site direct, het andere window niet.
Na enig geduld, 7 tot 10 minuten wachten op de Tweakers site die niet wil laden verschijnt de volgende melding :
Secure Connection Failed
An error occurred during a connection to tweakers.net. SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Alternatively, use the command found in the help menu to report this broken site.
Die melding zie ik wel vaker, oplossing; algehele verbinding vernieuwen onder Torbutton.
Werkt vrijwel altijd, behalve bij Tweakers.
________________________________________________________________________________________________
Tweakers & Security
Het laatste jaar is er op Tweakers het onderdeel 'eigen security' onder het kopje 'tweakers fans zet al je adblock-addons uit want wij willen geautomatiseerde reclame aan jullie tonen' aan de orde gekomen.
De standaard meld tekst van Tweakers aangaande Addons is na die discussie uitgebreid van alleen het uitschakelen van een Adblocker naar ook het uitschakelen van NoScript en Ghostery. (De omissie in laatste twee addons werd trouwens op security.nl vastgesteld).
Daarna is er nog een discussie geweest op Tweakers over het gebruik van https.
Tweakers was begonnen een https versie van de website in de steigers te zetten maar heeft ervoor gekozen een site met mixed content aan te bieden.
Veel afbeeldingen worden geladen via het onveilige http. Nogal wat gebruikers plaatsen links naar afbeeldingen op andere sites of embedden deze op de tweakers site, die embedded afbeeldingen zijn (uit de losse pols) meestal niet over https (over security risico's gesproken).
Vanwege het gestoei met https en http door Tweakers en daarop nog eens geattendeerd door een geplaatste link hier naar Tweakers met alleen http in de url, ontstond het inzicht dat vermoedelijk de meeste bezoekers http://tweakers.net bezoeken en geen http
s://tweakers.net .
Torbrowser gebruikers hebben echter voorgeïnstalleerd de addon HTTPS Everywhere. Wie heeft hem hier ook?
Uitgelegd: Deze addon dwingt de browser te kiezen voor een beveiligde verbinding wanneer die beschikbaar is, dus als een site zowel een http versie als een https versie aanbiedt.
Voel je hem aankomen?
HTTPS Everywhere uitgezet in de Torbrowser, tweakers.net ingetoetst, resultaat?
Tweakers.net pagina wordt direct geladen!
Over http en geen https welteverstaan!
Vervolgens de https variant https://tweakers.net ingetoetst, resultaat?
Tweakers.net pagina blijft hangen in het laden.
Nog eens http://tweakers.net ingetoetst, resultaat?
Dit
De toegang tot Tweakers.net vanaf dit IP is geweigerd
Het komt geregeld voor dat vanaf een IP veel pageviews naar Tweakers.net worden gestuurd, meer dan gebruikelijk - zelfs voor hele grote organisaties zoals KPN, de Belastingdienst en de diverse Ministeries. Om onszelf te behoeden tegen (verder) overlast wordt in zo'n geval vaak een IP geblokkeerd in onze firewall.
Hier staan in ieder geval een aantal gebruikelijke oorzaken:
Opera's Speeddial bevat een bug waarbij het kan voorkomen dat als je geen refresh wilt, Opera juist elke paar seconden gaat refreshen
Oudere versies van de Skype-plugin voor Firefox, die bij installatie van Skype vanzelf meekomt, veroorzaakte soms grote hoeveelheden pageviews naar Tweakers.net
Piclens en Cooliris zijn ook vaak veroorzakers van de vele pageviews
Proxy-servers, linkcheckers of crawlers die foutief ingesteld zijn en/of onze robots.txt negeren
Te enthousiaste feed-readers die elke paar seconden een RSS-feed opvragen
Naast bovenstaande redenen zijn ook misdragingen op Tweakers.net aanleiding om een IP te blokkeren. Dan gaat het meestal om zaken als het doen van hack-pogingen of herhaaldelijk lastig vallen van medegebruikers.
Mocht je de oorzaak hebben opgelost of geen idee hebben wat het was, stuur ons dan een e-mail. Ook voor verdere vragen of opmerkingen kun je mailen.
Dat mailen doe je naar gathering-at-tweakers.net, vergeet niet om je IP in deze mail te melden. Welk IP je hebt kun je zien op bijvoorbeeld whatismyip.com.
Waar het bezoekend ip adres normaal op de site zelf onder de BAN melding getoond wordt mag de bezoeker hem nu ineens weer zelf gaan opzoeken. Geeft niet, ik weet dat ik van een Tor exitnode surf en nee ik ga geen tijd besteden aan correspondentie met een onwillige redactie over een ip van een tor exitnode.
Kennelijk is er iets mis met de moraal van de Tweakers onderling, veelvuldige hackpogingen? Toe maar, hoe zien die er dan uit, gaat vast niet over de nieuwspagina's.
Lastigvallen van medegebruikers, Tweakers hebben toch maar één (facebookachtig) eeuwig durend en niet op te zeggen account gerelateerd aan een uniek ip account?
Bij misdragingen wordt er toch een BAN opgelegd van de duur van wel 7 jaar? VervolgensAlle handmatig ingetypte http pogingen daarna (een aantal), inclusief iedere keer vernieuwen van de verbinding met een andere ip exitnode leveren vervolgens dezelfde melding op.
Na minder dan tien pogingen (in de hoop dat er een ip tussen zit dat Tweakers acceptabel vindt) wordt ineens de Tweakers pagina weer wel geladen, zij ziet er wel wat anders uit dan ik gewend ben.
Apache2 Ubuntu Default Page
It works!This is the default welcome page used to test the correct operation of the Apache2 server after installation on Ubuntu systems. It is based on the equivalent page on Debian, from which the Ubuntu Apache packaging is derived. If you can read this page, it means that the Apache HTTP server installed at this site is working properly. You should replace this file (located at /var/www/html/index.html) before continuing to operate your HTTP server.
If you are a normal user of this web site and don't know what this page is about, this probably means that the site is currently unavailable due to maintenance. If the problem persists, please contact the site's administrator.
Configuration Overview
Ubuntu's Apache2 default configuration is different from the upstream default configuration, and split into several files optimized for interaction with Ubuntu tools. The configuration system is fully documented in /usr/share/doc/apache2/README.Debian.gz. Refer to this for the full documentation. Documentation for the web server itself can be found by accessing the manual if the apache2-doc package was installed on this server.
The configuration layout for an Apache2 web server installation on Ubuntu systems is as follows:
/etc/apache2/
|-- apache2.conf
| `-- ports.conf
|-- mods-enabled
| |-- *.load
| `-- *.conf
|-- conf-enabled
| `-- *.conf
|-- sites-enabled
| `-- *.conf
• apache2.conf is the main configuration file. It puts the pieces together by including all remaining configuration files when starting up the web server.
• ports.conf is always included from the main configuration file. It is used to determine the listening ports for incoming connections, and this file can be customized anytime.
• Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/ directories contain particular configuration snippets which manage modules, global configuration fragments, or virtual host configurations, respectively.
• They are activated by symlinking available configuration files from their respective *-available/ counterparts. These should be managed by using our helpers a2enmod, a2dismod, a2ensite, a2dissite, and a2enconf, a2disconf . See their respective man pages for detailed information.
• The binary is called apache2. Due to the use of environment variables, in the default configuration, apache2 needs to be started/stopped with /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not work with the default configuration.
Document Roots
By default, Ubuntu does not allow access through the web browser to any file apart of those located in /var/www, public_html directories (when enabled) and /usr/share (for web applications). If your site is using a web document root located elsewhere (such as in /srv) you may need to whitelist your document root directory in /etc/apache2/apache2.conf.
The default Ubuntu document root is /var/www/html. You can make your own virtual hosts under /var/www. This is different to previous releases which provides better security out of the box.
Reporting Problems
Please use the ubuntu-bug tool to report bugs in the Apache2 package with Ubuntu. However, check existing bug reports before reporting a new bug.
Please report bugs specific to modules (such as PHP and others) to respective packages, not to the web server itself.
Ik krijg meer en meer het idee (maar wie ben ik?) dat er achter de website config schermen bij Tweakers nogal wat rommelt en begin onderhand de waarde van de laatste strohalm van het blokkeren van ip adressen te begrijpen (kuch).
Begrijp ik het goed dat het een aannemelijke aanpak is dat als je het niet voorelkaar krijgt zaken secure werkend te krijgen, je om je schutting met gaten nog maar een tweede schutting zet (die ook weer gaten heeft : benaderen via anonieme free proxies werkt wel alsmede het benaderen via vermoedelijk massa's aan zombie botnets en honderdduizenden/miljoenen particuliere computers. Dat gaat nog een aardige veel en veel grotere lijst worden al die besmette ip adressen blokkeren).
________________________________________________________________________________________________
Misbruik & AttacksEr wordt nogal eenvoudig gesproken over attacks.
Bij herhaling gesteld, dit wordt niet onderbouwd door degenen die dit aandragen, ook niet door tweakers.
Hier bijvoorbeeld
Tweakers price watch - Torbrowser melding
In verband met veelvuldig misbruik via het Tor-netwerk is de pricewatch momenteel niet toegankelijk via Tor
Request ID: Parrot_xxxx_xxxxxxxxxxxxxx.xxxxxxxx
Dat is nogal een bewering / stelling.
Tweakers hoeft dat op die pagina natuurlijk niet helemaal te gaan uitleggen maar het maakt wel nieuwsgierig omdat iets stellen nog geen onderbouwing is.
Omgekeerd vergissen sommige regeerders zich hier een beetje in de reacties op mijn constatering dat ik in dit geval en andere gevallen onderbouwing mis, de constatering dat je een onderbouwing mist is niet gelijk aan het ontkennen van een mogelijk probleem of dreiging.
De dreiging of het probleem wordt wel een stuk aannemelijker als zij ook (goed) onderbouwd wordt.
Veel (overduidelijk vooringenomen) mening, weinig wol tot dusver in de reacties hierboven.
Dat schiet niet op, zullen we (jullie) het eens constructiever proberen, of was het alleen de bedoeling op te trollen met een anti-tor mening?
Wie het weet mag het zeggen, ik ben geïnteresseerd in security (niet in ongefundeerde borrelpraat meningen).
Analyse puntenWat handreikingen voor diegenen die technisch verstand van zaken hebben
- Als je over een aanval op een website spreekt waar blijkt dat dan uit en definieer die aanval eens.
Als je geen goede definitie hebt van een aanval kan je ook niet stellen dat het een aanval is, dan kan je hooguit spreken van (veel) verkeer vanaf ip adressen waarvan de kans bestaat dat er misbruik van wordt gemaakt (de kans dat is niet gelijk aan dat).
(geloof, uit mijn hoofd dat ddos via Tor al niet werkt, capaciteitsdingetje.., sluiten we die uit).
- Wanneer je een website wil aanvallen, op welke delen van de site richt te je dan?
Ik heb geen verstand van hacken(security testen) maar het lijkt me dat er een essentieel verschil in interesse zit tussen het bezoeken van een standaard nieuwspagina en de (beveiligde) inlogpagina.
Als daar een verschil tussen zit (namelijk de zeer hoge voorkeur voor de inlogpagina? Je wil als hacker namelijk ergens naar binnen) kan je stellen dat verkeer naar de gewone nieuws pagina's van tor ip adressen geen bedreiging vormt (tenzij je security helemaal niet op orde is?).
- Zou het nog uitmaken in de analyse op welke poorten het verkeer binnenkomt? Ook op de standaard poorten als 80, 443, 8080 vindt misbruik plaats, van de meerderheid van andere porten wordt misbruik genaakt door malware en aanvallers terwijl die (in meerderheid) niet nodig zijn voor bezoek aan je website.
Zou het blokkeren van porten zinvoller zijn dan het blokkeren van ip adressen?
- Wat dacht je van de reële dreiging dat een website tijdelijk besmet raakt omdat het automatische embedded reclames serveert via iFrames waar niemand volledig zicht op heeft omdat het te dynamisch is?
- Wat te denken van het aanbieden van mixed content waardoor het aanvallen/onderscheppen van een inlog sessie mogelijk is met alle mogelijke consequenties vandien?
Dat is al eens op security.nl aangekaart.
- Wat te denken van embedded materiaal op een site dat vele gebruikers mogen uploaden. Scripts die in Malvertising redirect infectie scripts voorkomen, kunnen vermoedelijk ook in door gebruikers embedded gif's, video's en afbeeldingen worden verstopt.
->> Nu.jij.nl met de rest van de veel voorkomende aanvalsvoorbeelden (ik heb er als gezegd geen inzicht in maar ben wel heel benieuwd naar bijdragen van de echte security-testers).
...
...
...
________________________________________________________________________________________________
(future discussie reality)Goed,
dank voor de vele (komende) ondersteunende constructieve inhoudelijke reacties met voorbeelden van veelvookomende attack vectoren op websites.
We hebben op basis van de reacties nu in ieder geval goed helder gekregen hoe een attack op een website kan plaatsvinden.
Hoe die attack er dus uit kan zien en waaraan je het duidelijk concreet kan herkennen (in plaats van de vage indicatie van bezoek van verdacht verkeer dat wel eens over een bepaald ip adres is gekomen.)
Als we nu eens al die meest voorkomende attack vectoren op een rij zetten naar veelvoorkomendheid en dreigingslevel en we kijken naar de rol die het blokkeren van ip adressen heeft.
* Welke kwaliteit heeft het blokkeren van ip adressen binnen je hele defensie?
Is het :
- Belangrijker dan je website security op orde hebben?
- Belangrijker dan aanwezige kwetsbaarheden op je website oplossen?
* Welk effect heeft het blokkeren van 5 a 6 a 7 duizend Tor exitnode ip adressen afgezet tegen alle ip adressen wereldwijd waar ooit of nog steeds verdacht verkeer vanaf komt?
* Weten we een getal van dat aantal ip adressen? Alle botnets, alle geïnfecteerde computers wereldwijd die op een of andere manier met virussen/malware besmet zijn?
* Op welke plaats, in deze top honderd van al die aanvalsfactoren voor een website, zou verkeer vanaf een Tor exitnode over poort 80 of 443 naar een gewone content nieuwspagina (niet de inlogpagina) staan ? Ongeveer?
Wanneer al deze inzichtelijke feiten op tafel liggen zal de security discussie omtrent zinvolle security maatregelen en de rol van het blokkeren van Tor exitnodes daarin hopelijk een stuk helderder worden en ook plezieriger.
Dan hoeven jij en jou bakken onder het mom van subjectiviteit, vooropgezette meningen, veronderstelde naïviteit, verondersteld gebrek aan inzicht en meer niet meer te hoeven gebezigd.
Kan er verwezen worden naar de maatregelen waarvan we allemaal denken dat die zinvol zijn bij het beveiligen van een website (niet hetzelfde als een Nasje).
Kan er desgewenst ruimte blijven voor de verschillen van inzicht in de marges van effectiviteit en plaats in de algehele security measure rankings.
________________________________________________________________________________________________
Een mening blijft vaak particulier als je het niet onderbouwt (er zijn nogal wat snelle meningen, wat moet je ermee?).
Goed onderbouwde security bijdragen kunnen anderen weer wel helpen (mits je je voorsprong in kennis niet bewust inzet om punten te bewijzen die de waarheid geweld aandoen).
In afwachting van meer inhoudelijk gefundeerde reacties (svp hele artikelen lezen, + vermelde links, waaruit je quotet) *,
(Reactie van Topic Starter)
* Tegen goede security bijdragen als voornemen voor 2015 helemaal geen bezwaar!