Klanten die een KPN verbinding hebben, kunnen problemen hebben met het verbinden naar hun website en/of server. Dit ligt niet aan de server (of aan ons netwerk), maar aan KPN zelf!
Wij hebben hier al eerder melding gemaakt in november 2024 (zie nieuwsbericht hier), maar het probleem is nog steeds actueel in 2025. Zie hieronder de originele melding en wat te doen.

Wij ontvangen meldingen van KPN-klanten die geen verbinding kunnen maken via FTP met hun hostingaccount of server. Dit probleem houdt verband met een recente update die door KPN is doorgevoerd en staat los van onze dienstverlening.

KPN heeft naar eigen zeggen op 13 november een beveiligingsupdate uitgevoerd, die heeft geleid tot het blokkeren van uitgaande FTP-verbindingen via de KPN-router. Deze maatregel valt onder het mom van "extra beveiliging", maar kan voor veel gebruikers tot ongemakken leiden, aangezien FTP wereldwijd als standaard communicatiemiddel wordt gebruikt voor het beheren van websites en servers.

Helaas kunnen wij vanuit onze kant weinig doen om dit probleem op te lossen, omdat wij geen toegang hebben tot uw KPN-routerinstellingen. Het probleem ligt dus niet bij onze servers, maar bij de instellingen van uw KPN-router. Om het probleem te verhelpen, dient u zelf in te loggen op uw KPN-router en de regel die uitgaande FTP-verbindingen blokkeert, te verwijderen. Meer informatie over deze situatie vindt u op het KPN-forum via de volgende link: https://community.kpn.com/modems-123/ftp-werkt-niet-meer-op-experia-box-v10-sinds-update-625186

Als u hulp nodig heeft bij het aanpassen van de instellingen, raden wij u aan om contact op te nemen met KPN. Zij kunnen u ondersteunen bij het ongedaan maken van deze wijziging, aangezien deze direct verband houdt met de door KPN doorgevoerde update. Dit staat geheel los van de bereikbaarheid van onze servers.

Dus wanneer u problemen ondervindt met het verbinden via FTP en u beschikt over een KPN-verbinding, dan is kans zeer aannemelijk dat het dan aan KPN ligt. Hierboven kunt u lezen op het KPN forum wat u dient te doen. U zal iets moeten aanpassen op uw KPN router; dit kunnen wij natuurlijk niet doen, daar wij geen toegang hier toe hebben. Dit heeft dus niks met onze servers en/of netwerk te maken, maar komt puur en alleen door een update vanuit KPN. Dus indien u hierover een klacht wenst in te dienen, dan zal u zich moeten vervoegen bij KPN zelf.

Tags: kpn, ftp, ftp probleem, kan niet verbinden met server, filezilla, sftp, ssh, ftp verbinding, ftp connectie, connectie ftp, probleem ftp, verbinding ftp, ftp verbinding, ftp filezilla, ftp-verbinding

Spamprotector biedt een uiterst kostenefficiënte oplossing voor spamfiltering, speciaal ontwikkeld voor onze hostingklanten. Voor resellers en klanten met een eigen server (VPS/DPS) die in bulk inkopen, bieden we bovendien extra scherpe prijsstellingen.

Beperkte ondersteuning vanwege lage prijsstelling

Vanwege de bijzonder scherpe tarieven van Spamprotector, kunnen wij slechts beperkte ondersteuning bieden. Mocht er toch behoefte zijn aan technische ondersteuning, bijvoorbeeld voor diepgaande onderzoeken of uitgebreide analyses, dan kunnen hier technische kosten voor worden berekend. Dit geldt met name voor herhaalde verzoeken of terugkerende problemen.

Gezien het tarief van €16,00 (of zelfs lager bij bulk) per account, is het voor ons helaas niet mogelijk om gratis support te leveren. Vergeet niet dat dit een dienst is die 24/7/365 werkt, dus als je dit terug rekend naar per dag is dit natuurlijk sowieso al een absurd laag bedrag. Daarnaast Spamprotector functioneert in de meeste gevallen zonder problemen, en het merendeel van onze klanten ervaart dan ook een storingsvrije werking. Slechts een klein aantal gebruikers ondervindt aanhoudende problemen, en voor deze gevallen zullen we voortaan technische kosten in rekening brengen wanneer er ondersteuning wordt gevraagd. Buiten kantoortijden geldt een toeslag inzake tech kosten.

Belangrijk om te weten: als u niet akkoord gaat met ons beleid omtrent supportkosten, staat het u uiteraard vrij om Spamprotector op te zeggen en op zoek te gaan naar een alternatieve, betaalbare anti-spamoplossing. Echter, met betrekking tot prijs en functionaliteit zijn er nauwelijks vergelijkbare alternatieven beschikbaar.

We rekenen niet direct technische kosten voor éénmalige vragen, maar als er sprake is van herhaalde supportverzoeken met betrekking tot Spamprotector, dan worden er wel kosten in rekening gebracht. De exacte hoogte van deze kosten hangt af van het type klant dat u bent. Zo zullen hostingklanten met één Spamprotector-account mogelijk minder betalen dan resellers of klanten met een eigen server (VPS/DPS) en meerdere accounts, vanwege de hogere kortingen die we bieden bij bulkverkoop. We raden u aan hier rekening mee te houden.

Om de mogelijke tech en/of onderzoekskosten beperkt te houden dient u altijd zoveel mogelijk informatie aan te leveren, zoals screenshots, headers en duidelijke foutmelding in tekst. Hierdoor kan een eventueel probleem sneller opgelost worden en scheelt dit mogelijk kosten, indien van toepassing.

Geen ondersteuning Spamprotector bij externe diensten

Daarnaast bieden wij geen ondersteuning meer voor Spamprotector in combinatie met externe diensten, zoals Office365, Exchange-servers, domeinnamen of hostingaccounts die niet door ons worden beheerd. Dit soort configuraties zijn complex en vereisen vaak langdurige en intensieve onderzoeken. Dit past niet binnen de prijsstructuur van Spamprotector. Verzoeken om ondersteuning voor Spamprotector in combinatie met externe diensten zullen daarom niet worden behandeld.

Indien u toch wenst dat wij een onderzoek uitvoeren naar Spamprotector-configuraties die via een externe dienst verlopen, dan zullen wij hiervoor onderzoeks- en technische kosten in rekening brengen. Voor dit soort gevallen hanteren wij een standaardtarief van €75,00 per uur tijdens kantooruren. Buiten kantooruren geldt een hoger tarief. Houd er rekening mee dat onze technici volledige toegang moeten hebben tot de externe diensten om effectief te kunnen troubleshooten. Indien deze toegang niet beschikbaar is, kan dit resulteren in aanvullende technische kosten omdat dit moeilijker en (veel) meer tijd kost om te troubleshooten. Zie ook hier.

Let op! Dus als u een support ticket aanmaakt en het probleem ligt niet bij ons of aan Spamprotector zelf, maar aan uw externe dienst (waar wij geen toegang tot hebben), dan zullen wij standaard de tech kosten zoals hierboven vermeld in rekening brengen! Indien het probleem wel direct aan onze dienst (Spamprotector) ligt, dan wordt dit natuurlijk niet gefactureerd!

Tags: spamprotector, anti-spam, virus filtering, spam filtering, spamprotector bulk, spamprotector support, spamprotector office365, office 365, microsoft office 365

Spamprotector wordt steeds vaker aangeschaft door klanten die hun diensten elders hebben draaien (hosting, DNS, etc.).

Hierdoor kunnen er wel eens problemen optreden waar wij géén support opleveren, daar wij geen toegang hebben tot externe diensten en dan troubleshooten zo goed als onmogelijk is. Zeker voor de prijs waarvoor Spamprotector aangeboden wordt. Het is daarom een pre dat klanten met externe diensten en hierop Spamprotector hebben draaien dit zelf gaan controleren en troubleshooten, alvorens dat u een support ticket hiervoor bij ons indient. Indien wij hier tech support op moeten leveren, dan rekenen wij hier het standaard tech tarief voor van 75.00 Euro. Dit bedrag kan verder oplopen, naarmate het probleem lastiger is te troubleshooten en ons meer tijd kost. Daarnaast dient u ook zoveel informatie aan te leveren in uw ticket. Als u een ticket aanmaakt dan gaat u automatisch akkoord met de genoemde tech kosten.

Veel problemen kan u zelf oplossen door sowieso te controleren of bij uw hosting, registrar, DNS service (o.a. CloudFlare, Microsoft, etc.) alle IPv4- en IPv6-adressen wel op de white-list staan of vrijgegeven staan in de firewall binnen uw externe diensten. Dit kunenn wij sowieso niet controleren natuurlijk, daar wij dus hier géén toegang toe hebben. Spamprotector gebruikt de onderstaande IPv4- en IPv6-adressen:

• 83.172.128.4
• 83.172.188.4
• 83.172.128.5
• 83.172.128.6

• 2a02:cec0:10:16::1
• 2a02:cec0:10:16::2
• 2a02:cec0:10:16::5
• 2a02:cec0:10:16::6

Indien u deze IP-adressen heeft gecontroleerd binnen uw eigen diensten, waar wij niet bij kunnen komen en u er zeker van bent dat het niet uw eigen diensten ligt of aan de afgenomen diensten elders, dan kan u altijd een support ticket inschieten. Lever daarbij wel zoveel mogelijk informatie aan, want anders kunnen onze technici ook niks beginnen. Zoals aangegeven zal een technisch onderzoek minimaal 75.00 Euro kosten. Indien het probleem aan onze kant ligt, dus aan de kan van Spamprotector, dan zal er coulance worden betracht inzake de tech kosten. Wanneer het probleem wel aan uw kant ligt of bij de afgenomen diensten elders (hosting, DNS beheer, CloudFlare, etc.), dan zullen deze tech kosten alsnog in rekening gebracht worden. Wanneer u een ticket inschiet dan gaan wij er altijd vanuit dat u sowieso onze Kennisbank artikelen heeft geraadpleegd inzake Spamprotector en dat u dan ook automatisch akkoord gaat met de tech kosten.

Zie ook het volgende uitgebreide kennisbank artikel voor meer informatie: Beperkt (gratis) support inzake Spamprotector.

Let op! Dus als u een support ticket aanmaakt en het probleem ligt niet bij ons of aan Spamprotector zelf, maar aan uw externe dienst (waar wij geen toegang tot hebben), dan zullen wij standaard de tech kosten zoals hierboven vermeld in rekening brengen! Indien het probleem wel direct aan onze dienst (Spamprotector) ligt, dan wordt dit natuurlijk niet gefactureerd!

Met de groei van verschillende applicaties die beschikbaar zijn op de markt en de vrijheid die klanten hebben om deze zelf te installeren via SSH, DirectAdmin, Plesk of andere methoden, is het voor ons onmogelijk om hier volledige support op te leveren. Onze primaire expertise ligt bij serverbeheer en hostingomgevingen en niet bij applicaties van derden. Wij bieden, waar mogelijk, beperkte ondersteuning, maar dit is geen standaard dienstverlening.

Het is belangrijk om te begrijpen dat ondersteuning op specifieke applicaties zoals Laravel, GitLab, Node.js, Magento, Prestashop en andere custom PHP-applicaties buiten onze standaard services valt. Indien er toch behoefte is aan technische ondersteuning, dan kan dit enkel op basis van een betaald supporttarief, waarbij wij geen garantie kunnen geven op een mogelijke oplossing.

Applicaties met géén of (zeer) beperkte support

Laravel

Laravel is een krachtig PHP-framework waarmee uitgebreide webapplicaties kunnen worden gebouwd. Echter, vanwege de custom aard van Laravel-projecten bieden wij hierop geen ondersteuning.

• Er bestaan uitgebreide Laravel communities waar problemen en vragen besproken kunnen worden.
• Zowel Plesk als DirectAdmin bieden geen support op Laravel-gerelateerde problemen en verwijzen naar de Laravel-community en ontwikkelaars.

GitLab

GitLab en GitHub zijn platformen voor versiebeheer en ontwikkelaars hebben hierin miljoenen projecten aangemaakt. Wij kunnen hier geen support op leveren.

• Indien u tegen problemen aanloopt, adviseren wij contact op te nemen met de beheerder van de betreffende GitLab/GitHub-applicatie of een beroep te doen op de GitLab-community.
• Plesk en DirectAdmin bieden hierop ook geen ondersteuning.

Node.js

Node.js is een populair runtime-platform voor JavaScript-applicaties. Aangezien deze applicaties vaak maatwerk zijn, bieden wij hier geen support op.

• Bij problemen met Node.js adviseren wij gebruik te maken van de officiële documentatie of communities.
• Plesk en DirectAdmin bieden eveneens geen ondersteuning op Node.js gerelateerde problemen.

Magento

Magento is een complex e-commerceplatform dat gespecialiseerde kennis vereist.

• Magento-specialisten zijn vaak kostbaar en noodzakelijk voor onderhoud en probleemoplossing.
• Wij bieden geen support op Magento. Indien wij toch ondersteuning moeten bieden, geldt een starttarief van €300,00 aan tech kosten.
• Plesk en DirectAdmin bieden geen ondersteuning op Magento en verwijzen naar specialisten.
• Voor betaalde support dient volledige toegang tot de Magento-installatie te worden verstrekt.

Prestashop

Prestashop is een ander populair e-commerceplatform waarvoor wij enkel tegen betaling beperkte controle kunnen uitvoeren.

• Indien u support wenst, dient u ons toegang te geven tot de Prestashop-interface.
• Wij bieden enkel beperkte ondersteuning tegen een starttarief van €125,00 aan tech kosten.
• Plesk en DirectAdmin ondersteunen geen Prestashop-problemen en verwijzen naar Prestashop-forums.

Custom PHP-applicaties (incl. CakePHP)

Aangepaste PHP-applicaties vallen buiten onze standaard dienstverlening.

• Indien u zelf een applicatie heeft geschreven, dient u zelf eventuele problemen op te lossen.
• Wanneer een derde partij de applicatie voor u heeft gemaakt, dient u contact op te nemen met deze partij.
• Mocht u toch ondersteuning wensen, dan hanteren wij een starttarief van €100,00 tot €250,00 aan tech kosten, afhankelijk van de complexiteit.
• Voor betaalde ondersteuning dient u ons zoveel mogelijk informatie aan te leveren over de applicatie en het probleem.

Overige custom scripts

Voor maatwerk scripts geldt hetzelfde beleid als voor custom PHP-applicaties.

Algemeen support beleid

Wij leveren uitsluitend support op de producten en diensten die wij zelf aanbieden. Wat klanten zelf installeren of laten installeren door derden valt niet binnen onze standaard ondersteuning. Zelfs indien wij tegen betaling support leveren, blijft onze dienstverlening beperkt tot het troubleshooten van een probleem en niet tot doorlopende support of maatwerkoplossingen.

Wij beheren en onderhouden meer dan 1100 servers, 68.000 hostingaccounts en een nog groter aantal domeinnamen en SSL-certificaten. Onze focus ligt op het direct aanpakken van serverproblemen, zoals:

• Het restoren en/of repareren van gecrashte databases, al dan niet tegen minimale tech kosten (afhankelijk van de oorzaak)
• Het oplossen van problemen met hostingaccounts en emailaccounts.
• Het uitvoeren van gemiddeld 3 tot 4 servermigraties per week.

Gezien deze verantwoordelijkheden hebben wij geen tijd en capaciteit om uitgebreide support te leveren op externe applicaties.

Ook Plesk en DirectAdmin hebben hun supportbeleid gewijzigd en bieden geen ondersteuning meer op problemen met geïnstalleerde applicaties van derden. Zij adviseren, net als wij, om relevante forums, communities of experts in te schakelen.

Uitzondering: (beperkte) support op WordPress installaties

De enige uitzondering op ons beleid is WordPress, gezien het marktaandeel van dit platform. Toch blijft onze support beperkt.

• WordPress-websites maken gebruik van diverse thema’s en plugins, wat vaak de oorzaak is van problemen.
• Veelvoorkomende issues ontstaan door verouderde of conflicterende plugins.
• In onze kennisbank op Helpburo vindt u artikelen die u kunnen helpen bij het oplossen van problemen.
• Indien u zelf verantwoordelijk bent voor uw WordPress-website, raden wij aan de logbestanden na te lopen om mogelijke fouten te achterhalen.
• Bij onoplosbare problemen kunt u een supportticket aanmaken. Wij kunnen dan, indien mogelijk, het probleem analyseren en oplossen, mogelijk tegen betaling.
  
  

Samenvatting

Uiteraard staat het u vrij om een supportticket aan te maken voor een probleem, maar:

• Wij garanderen geen oplossing.
• Wij bieden enkel ondersteuning wanneer onze agenda dit toelaat.
• Technische ondersteuning op applicaties van derden wordt uitsluitend tegen betaling geleverd en beperkt zich tot probleemdetectie en troubleshooting.

Voor alle verdere vragen omtrent externe applicaties adviseren wij om rechtstreeks contact op te nemen met de ontwikkelaar, een expert in te schakelen of een beroep te doen op de relevante community.

 
Tags: support op applicaties, support op wordpress, custom php, custom scripts, gitlab, github, git, laravel, prestashop, magento, custom scripting, wordpress plugins, nodejs, cakephp, cake, php

Gezien de afnemende beschikbaarheid van repositories en het wegvallen van officiële ondersteuning voor CentOS 6.x (inclusief platforms zoals Plesk en DirectAdmin), hebben wij besloten om geen gratis support meer te bieden op deze omgevingen. Het troubleshoot-proces op dergelijke legacy-systemen is uiterst tijdsintensief en vaak niet meer effectief, met name bij omvangrijke technische problemen.

CentOS 6.x heeft sinds 30 november 2020 de End-of-Life (EOL)-status bereikt en wordt al geruime tijd niet langer ondersteund door upstream-organisaties zoals Plesk en DirectAdmin. Ook wij ontvangen geen enkele vorm van support of security-updates meer voor deze systemen. Dit maakt het onmogelijk om zonder aanzienlijke inspanning en risico’s technische ondersteuning te bieden.

Tech-support op verouderde omgevingen
Voor alle supportverzoeken met betrekking tot CentOS 6.x-servers dient u er rekening mee te houden dat:

• Het oplossen van technische problemen langer kan duren door het ontbreken van actuele repositories en upstream-support.
• Alle supportaanvragen voor deze omgevingen tech-kosten met zich meebrengen.

Advies: migreren naar een ondersteund besturingssysteem
Wij adviseren om te migreren naar een modern alternatief zoals AlmaLinux 8.x. Let op: ook CentOS 7.x heeft sinds juni 2024 de EOL-status bereikt.

• Plesk: biedt nog beperkte ondersteuning via het Extended Lifecycle Support (ELS)-programma, maar hier zijn aanvullende kosten aan verbonden.
• DirectAdmin: functioneert nog op CentOS 7.x, maar nieuwe feature-updates worden niet langer doorgevoerd. U zult de melding ontvangen:
  "This Linux distribution is no longer supported by DirectAdmin. New releases of DirectAdmin are no longer compatible with this system and will not be available."
  
  

Resumé

Indien u nog een CentOS 6.x-server (met Plesk of DirectAdmin) in gebruik heeft, moet u er rekening mee houden dat:

• Technische support aanzienlijk langer kan duren door beperkingen zoals ontbrekende repositories.
• Alle supportverzoeken onderhevig zijn aan tech-kosten.

En mocht u uw serveromgeving willen migreren naar een modern en ondersteund besturingssysteem, dan is dit uiteraard mogelijk. Wij hebben hiervoor twee gedetailleerde kennisbankartikelen beschikbaar:

• Voor Plesk-servers:
  Plesk-server (VPS/DPS) migratie naar een nieuw OS

• Voor DirectAdmin-servers:
  DirectAdmin-server (VPS/DPS) migratie naar een nieuw OS

Deze kennisbankartikelen bieden een zeer uitgebreide documentatie documeover de migratieprocedure, inclusief met aandachtspunten zoals:

• Impact op bestaande configuraties en functionaliteiten
• Eventuele downtime en hoe dit te minimaliseren
• Kosten en technische vereisten

Wij raden u ten zeerste aan om het relevante kennisbankartikel voor uw serveromgeving zorgvuldig door te nemen—mogelijk zelfs meerdere keren. Dit voorkomt onnodige support tickets met vragen die reeds in het bijbehorende kennisbank artikel zijn beantwoord.
Wanneer u interesse heeft, dan kan u een support ticket aanmaken. Vermeld hierbij duidelijk uw hostname (naam van de server) en dat u het kennisbank artikel heeft doorgelezen en akkoord mee bent gegaan. Vervolgens gaat de tech uw server controleren en vervolgens een aantal data voor een eventuele migratie van uw server voorstellen.


Tags: centos6, centos7, eol, legacy, server migratie, end-of-life, os upgrade, migratie centos, centos migratie, centos 6, centos 7, centos eol

Op de gratis SSL certificaten van Let's Encrypt bieden wij geen support. Indien wij toch een support ticket moeten behandelen inzake Let's Encrypt, dan rekenen wij daarvoor tech kosten. Deze kosten zijn tijdens kantooruren 30.00 Euro en buiten kantooruren 75.00 Euro (per domein / LE certificaat). Hou hier rekening mee! Uiteraard worden deze kosten niet in rekening gebracht wanneer het daadwerkelijk een server probleem betreft, in alle andere gevallen worden deze kosten wel doorberekend. Op betaalde SSL certificaten van derden leveren wij helemaal geen support.

De reden hiervoor is dat er steeds vaker problemen optreden met deze gratis SSL certificaten en wij geen directe support hebben bij de organisatie bij Let's Encrypt. De enige vorm van support aldaar is via een forum en dat laat (veel) te wensen over. Dus als u problemen heeft met een gratis Let's Encrypt SSL certificaat en u wenst dit te blijven gebruiken, dan zal u zelf op het forum van Let's Encrypt hier melding van moeten maken. Pas daarbij wel op dat u geen (directe) gegevens van uw hostingaccount of server plaatst!

Wij krijgen met regelmaat klachten dat de gratis SSL certificaten van Let's Encrypt problemen opleveren. Niet alleen tijdens het aanmaken, maar ook tijdens het vernieuwen van bestaande Let's Encrypt SSL certificaten. De Let's Encrypt SSL certificaten hebben een korte "levensduur" en worden, normaliter, tussen de 30 en 45 dagen automatisch vernieuwd. Wanneer er een probleem optreed (om welke reden dan ook), dan wordt het certificaat niet vernieuwd of in ieder geval niet correct. Dit kan weer talloze problemen opleveren inzake de website zelf (onbeveiligd), FTP of zelfs emailverkeer hinderen.

Het is niet verwonderlijk dat wij altijd een betaald SSL certificaat adviseren om dergelijke problemen te voorkomen. Tegenwoordig bieden wij ook SSL certificaten abonnementen aan waarbij een SSL certificaat automatisch door ons vernieuwd worden na 1 jaar. Op die manier heeft u het minst hinder van verschillende mogelijke problemen. Voor meer informatie over Let's Encrypt SSL certificaten, betaalde SSL certificaten en SSL certificaten in het algemeen, kijk hier.

Resumé; vanwege de huidige (opstapelende) problemen rondom de Let's Encrypt SSL certificaten en het feit dat wij geen directe support bij Let's Encrypt hebben, heeft ons er toe doen besluiten om hierop dan ook geen support te (meer) te leveren. Dus als u problemen heeft met een dergelijke Let's Encrypt SSL certificaat, dan zal u op het forum van Let's Encrypt het problemen moeten melden of een betaald SSL certificaat afnemen. Het spreekt daarnaast voor zich dat wij alleen support kunnen leveren op SSL certificaten die bij ons zijn afgenomen.

Betaalde SSL certificaten (3rd party)

Inzake support op SSL certificaten die elders zijn aangeschaft, dus niet via ons; hier geldt beperkte support op. Wij zullen ons best doen om te helpen, maar hier kunnen geen garanties aan verbonden worden. Indien wij dit voor u moeten controleren, dan is het aannemelijk dat er tech kosten hiervoor in rekening gebracht worden. Controleer altijd of het door (elders) aangeschafte SSL certificaat nog steeds geldig is en voldoet aan de nieuwste eisen die worden gesteld. Eventueel kunt u proberen om een "re-issue" aan te vragen voor het SSL certificaat bij de organisatie c.q. parrtij waar u het SSL certificaat heeft aangeschaft.

Uiteraard kan u ook altijd bij ons gewoon een professioneel SSL certificaat bestellen. Wij hanteren zeer lage tarieven en u kan zelfs het SSL certificaat door ons laten installeren tegen een minimale meerprijs. Dan heeft u ook alles op één adres en daarbij ook maar één aanspreekpunt inzake mogelijke problemen.

Geen support, wel een aantal mogelijkheden om toch Let's Encrypt te activeren

Wanneer Let's Encrypt problemen vertoond, wat dus steeds vaker gebeurt, dan kan u proberen een Wildcard LE certificaat uit te geven. Het is niet gezegd dat dat wél werkt, maar dit is een andere controle waarbij er een TXT DNS-record aangemaakt wordt voor controle en dus op een andere manier benaderd wordt door Let's Encrypt. Zie hieronder een screenshot bij een Plesk server. Mocht dit ook niet baten, dan zal u op een andere dag moeten proberen (soms 2 á 3 dagen wachten wil ook soms helpen) of een betaald SSL certificaat af te nemen.

Ook bij DirectAdmin heeft u de mogelijkheid om een Wildcard te installeren. Zie hieronder:

Mocht dit eveneens niet werken, dan resteren er twee mogelijkheden; u wacht 2 á 3 dagen of u besteld een betaald SSL certificaat.

LET OP!!! Extra mededeling inzake support ticket inzake Let's Encrypt SSL certificaten !!!

Let op!!! Aangezien er regelmatig toch support tickets worden aangemaakt met betrekking tot de gratis Let's Encrypt (LE) SSL-certificaten, zullen wij vanaf nu standaard kosten in rekening brengen wanneer hiervoor een supportticket wordt ingediend. De kosten bedragen €40,00 tijdens kantooruren en €90,00 buiten kantooruren/weekend (per domein/LE-certificaat). Deze kosten worden uiteraard niet in rekening gebracht als het daadwerkelijk om een serverprobleem gaat; in alle andere gevallen worden deze kosten wel doorberekend.

Daarnaast is dit nog steeds géén garantie dat het onze technici wel lukt om een LE certificaat aan te vragen, immers zijn en blijven wij dus afhankelijk van de uitgifte van LE certificaten. De kosten hiervoor worden dan wel in rekening gebracht. Voor betaalde SSL-certificaten van derden, dus niet via ons aangeschaft, bieden wij helemaal géén support. U zal voor betaalde SSL certificaten via een andere partij aldaar support moeten aanvragen.

Probeer de hierboven eerdere vermelde methoden of wacht enkele dagen (1 tot 3 dagen). En wilt u helemaal geen problemen met LE certificaten iedere 30 á 45 dagen? Neem dan een betaald SSL certificaat voor slechts 14.95 Euro. Dan heeft u een jaar lang geen zorgen en/of omkijken naar een gratis (en vaak problematisch) SSL certificaat!

Tags: LE certificaat, Let's Encrypt, SSL certificaat, problemen LE, Lets Encrypt foutmelding, LE foutmelding, LE firewall melding, Authorization for the domain failed, Could not issue a Let's Encrypt SSL/TLS certificate, Timeout during connect (likely firewall problem), Let's Encrypt SSL certificaat

Vooropgesteld; gezien de vele (en herhaaldelijke) problemen met Let's Encrypt SSL certificaten en slechte (forum) support, leveren wij géén support op de gratis Let's Encrypt SSL certificaten. Zie ook hier.

Er kunnen veel verschillende problemen optreden bij Let's Encrypt SSL certificaten, zo kan u tegen een limiet aanlopen (als u te vaak een gratis LE certificaat aanvraagt) en hier is niks aan te doen, dan te wachten (dit wordt dagelijks gereset bij Let's Encrypt). Let's Encrypt heeft inmiddels het aantal pogingen drastisch verminderd naar drie (3) keer per dag. Na drie keer proberen een LE certificaat te vernieuwen, dan zal u een melding krijgen dat het limiet inzake het aantal pogingen bereikt is en dan moet u minimaal 24 uur (1 dag) wachten voordat u het week kan proberen. Hier kunnen wij niks aan doen/veranderen!

Daarnaast kregen wij in het verleden vaak tickets inzake dat het A- of AAAA-record niet zou kloppen. Vaak is dit probleem te wijten aan een domeinnaam alias die ook gekoppeld staat aan het hoofddomein. Vaak is men vergeten de extra domeinnaam c.q. domeinnaam alias ook te laten verwijzen naar de server. Controleer dus altijd goed de foutmelding. Vaak krijgt men ook een link in de vorm van "https://acme-v02.api.letsencrypt.org/acme/authz-v3/XXXXXX" (waar "XXXXXX" staat voor een cijferreeks). Als men die link dan opent, dan zal u een compleet inzicht krijgen waar de foutmelding betrekking op heeft. Vaak dus op een alias die ooit een keer toegevoegd is door u, maar niet eens actief / geregistreerd is. Verwijder dan de alias of zorg ervoor dat die actief/geregistreerd wordt.

Is dat het geval, dan kun ervoor kiezen om de alias (voorlopig) niet te beveiligen met een Let's Encrypt SSL certificaat, de alias correct laten verwijzen naar de server of gewoonweg de alias te verwijderen. Indien de problemen aanhouden, dan dient men support aan te vragen via het forum van Let's Encrypt hier. Let's Encrypt biedt zelf geen directe support, derhalve bieden wij dit ook dan ook niet aangezien wij ook aan dit forum zijn overgeleverd en support aldaar is behoorlijk beperkt en langzaam.

Dit is dan ook de belangrijkste reden dat wij dus géén support leveren op deze gratis Let's Encrypt SSL certificaten, wat hier ook staat vermeld. Hetzelfde geldt ook voor SSL certificaten die elders, dus niet via ons, zijn aangeschaft/besteld. Wanneer u problemen heeft met een dergelijk (extern) aangeschaft SSL certificaat, dan zal u bij die partij support moeten aanvragen. Wij hebben geen inzicht in SSL certificaten van derden c.q. andere partijen.

Ook krijgen wij regelmatig een melding dat onze firewall Let's Encrypt blokkeert. Dit is NIET het geval! Wij blokkeren helemaal geen diensten of IP-adressen van Let's Encrypt. Dit hebben wij nog nooit gedaan en zullen dit ook nooit doen. Sowieso zijn de IP-ranges van Let's Encrypt niet openbaar en daarnaast gaan wij echt onze klanten niet "pesten" om dit soort zaken te blokkeren.

Op dit moment (2024) geeft Let's Encrypt per dag 2 tot 3 miljoen SSL certificaten uit! Dus dan is het zeer aannemelijk dat er ook meer problemen optreden met een dergelijke gratis dienst. Doordat er steeds meer Let's Encrypt SSL certificaten worden uitgegeven, nemen de problemen dus ook toe. In de afgelopen 5 jaar zien wij een toenname van rond de 60% bij alle Let's Encrypt SSL certificaten. Ook komen deze problemen herhaaldelijk terug omdat de Let's Encrypt SSL certificaten vaak (automatisch) vernieuwd worden tussen de 30 en 45 dagen.

Op een gegeven moment waren 90% van de support tickets op Helpburo gerelateerd aan Let's Encrypt SSL certificaten problemen, waardoor technici amper tijd hadden om "serieuze" problemen op te lossen. Dit alles bij elkaar heeft ons er toe doen besluiten om dus géén support meer te leveren op Let's Encrypt SSL certificaten. Wij willen een goede dienstverlening leveren aan al onze klanten, daarbij kunnen wij ons niet blijven focussen op één bepaald (nota bene gratis) product, waarbij géén directe support ingangen zijn voor ons.

Geen support, wel een aantal mogelijkheden om toch Let's Encrypt te activeren

Wanneer Let's Encrypt problemen vertoond, wat dus steeds vaker gebeurt, dan kan u proberen een Wildcard LE certificaat uit te geven. Het is niet gezegd dat dat wél werkt, maar dit is een andere controle waarbij er een TXT DNS-record aangemaakt wordt voor controle en dus op een andere manier benaderd wordt door Let's Encrypt. Zie hieronder een screenshot bij een Plesk server. Mocht dit ook niet baten, dan zal u op een andere dag moeten proberen (soms 2 á 3 dagen wachten wil ook soms helpen) of een betaald SSL certificaat af te nemen.

Ook bij DirectAdmin heeft u de mogelijkheid om een Wildcard te installeren. Zie hieronder:

Mocht dit eveneens niet werken, dan resteren er twee mogelijkheden; u wacht 2 á 3 dagen of u besteld een betaald SSL certificaat.



LET OP!!! Extra mededeling inzake support ticket inzake Let's Encrypt SSL certificaten !!!

Let op!!! Aangezien er regelmatig toch support tickets worden aangemaakt met betrekking tot de gratis Let's Encrypt (LE) SSL-certificaten, zullen wij vanaf nu standaard kosten in rekening brengen wanneer hiervoor een supportticket wordt ingediend. De kosten bedragen €40,00 tijdens kantooruren en €90,00 buiten kantooruren/weekend (per domein/LE-certificaat). Deze kosten worden uiteraard niet in rekening gebracht als het daadwerkelijk om een serverprobleem gaat; in alle andere gevallen worden deze kosten wel doorberekend.

Daarnaast is dit nog steeds géén garantie dat het onze technici wel lukt om een LE certificaat aan te vragen, immers zijn en blijven wij dus afhankelijk van de uitgifte van LE certificaten. De kosten hiervoor worden dan wel in rekening gebracht. Voor betaalde SSL-certificaten van derden, dus niet via ons aangeschaft, bieden wij helemaal géén support. U zal voor betaalde SSL certificaten via een andere partij aldaar support moeten aanvragen.

Probeer de hierboven eerdere vermelde methoden of wacht enkele dagen (1 tot 3 dagen). En wilt u helemaal geen problemen met LE certificaten iedere 30 á 45 dagen? Neem dan een betaald SSL certificaat voor slechts 14.95 Euro. Dan heeft u een jaar lang geen zorgen en/of omkijken naar een gratis (en vaak problematisch) SSL certificaat!

Tags: LE certificaat, Let's Encrypt, SSL certificaat, problemen LE, Lets Encrypt foutmelding, LE foutmelding, LE firewall melding, Authorization for the domain failed, Could not issue a Let's Encrypt SSL/TLS certificate, Timeout during connect (likely firewall problem), Let's Encrypt SSL certificaat

Aangezien er nog een aantal Plesk reseller nodes nog op een zeer oud besturingssysteem draaide (CentOS 6.x) zijn deze automatisch gemigreerd naar een nieuwere omgeving. Indien uw (oude) Plesk reseller pakket op één van de onderstaande reseller nodes stond, dan is deze inmiddels gemigreerd naar een nieuwe reseller node. De grootste voordeel is dat u o.a. van nieuwere PHP-versies gebruik kunt maken nu (o.a. PHP 8.x).

Verderop deze pagina ziet u welke (oude) Plesk reseller nodes inmiddels zijn gemigreerd naar een nieuwe omgeving. Wij willen u adviseren om de onderstaande informatie toch goed door te lezen. Op die manier bent u volledig op de hoogte van wat er wel en niet is gemigreerd. Door verschillende server configuraties (besturingssysteem, Plesk versie e.d.) kan niet alles gemigreerd worden. Dus lees dit aandachtig door!

Deze automatische migratie betekend niet dat u van alle nieuwe functies kunt gebruik maken die vandaag de dag worden geleverd met de reseller pakketten. U blijft na deze migratie uw "oude" reseller pakket behouden, zoals deze destijds besteld is. Indien u wenst gebruik te maken van de functionaliteiten van de nieuwe reseller pakketten, dan zal u een nieuw reseller pakket hiervoor moeten bestellen. Eventueel kunnen wij uw huidige reseller pakket handmatig migreren naar deze (allernieuwste) reseller node. Normaliter zitten hier dan wel tech kosten aan verbonden.

Zoals hierboven aangegven kan u dus gebruik maken van nieuwere PHP-versies, waaronder dus ook PHP 8.x. Helaas heeft deze migratie ook een aantal keerzijden, namelijk;

• Apache PHP (mod_php) wordt niet meer ondersteund
  • Het uitvoeren van PHP via Apache PHP is onveilig en langzaam
  • U kan gewoon een andere PHP runtime kiezen, zoals PHP-FPM of FastCGI
  • Wij hebben al talloze keren aangegeven dat mod_php end-of-life (EOL) is

• Website functioneert niet meer of geeft een foutmelding
  • Raadpleeg de log-bestanden van uw website
  • Probeer een andere PHP-versie (lager of hoger)
  • Update uw (Wordpress) website en/of PHP programma's
  • Controleer of u niet dubbele index bestanden heeft staan

• Oude PHP-versies worden voorlopig nog ondersteund
  • Alle PHP 5.x versies blijven momenteel ondersteund worden op de server
  • In de toekomst kan dit uiteraard wel veranderen, daar deze versies EOL zijn

• RoundCube adressenlijst/-bestanden zijn niet gemigreerd
  • Dit was niet mogelijk om mee te migreren van de oude server i.v.m. configuratie verschillen
  • Eventueel kan dit handmatig gedumpt en gemigreerd worden door onze technici
    • Hier zitten wel tech kosten aan verbonden (éénmalig 50.00 Euro)
    • Deze kosten zijn noodzakelijk gezien de uitgebreide handelingen

• Installatron backups en/of instellingen zijn niet gemigreerd
  • Bij server migraties worden Installatron backups nooit gemigreerd
  • Dit komt door onderlinge server verschillen, waardoor dit niet mogelijk is
  • Ook handmatig dumpen en restoren is niet mogelijk

• In Plesk gemaakte back-ups zijn niet gemigreerd
  • Bij server migraties worden Plesk back-ups nooit gemigreerd
  • Dit komt door de onderlinge verschillen van OS en Plesk systeem
  • Ook handmatig dumpen en restoren is niet mogelijk
    • Tip: maak na de migratie z.s.m. een nieuwe Plesk back-up
      

Welke Plesk reseller nodes zijn er inmiddels gemigreerd?

Hier een overzicht van de (oude) Plesk reseller nodes die volledig uitgemigreerd zijn:

• ns1.securenameserver5.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver12.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 18 november 2022

• ns1.securenameserver14.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

• ns1.securenameserver15.net
  • Gemigreerd naar ns1.securenameserver1.net
  • Gemigreerd op 16 november 2022

• ns1.securenameserver16.net
  • Gemigreerd naar securenameserver1.net
  • Gemigreerd op 17 november 2022

De hierboven vermelde oude Plesk reseller nodes, zijn allemaal gemigreerd naar ns1.securenameserver1.net. Dus vanaf nu kan u deze ook gebruiken als zijnde nameservers voor eventuele domeinnaamregistries en/of verhuizingen. Voor de goede orde, u nieuwe nameservers zijn dus als volgt:

• ns1.securenameserver1.net
• ns2.securenameserver1.net

De oude nameservers blijven sowieso (maximaal) 1 jaar actief; dan heeft u voldoende tijd om de nameservers aan te passen. Hetzelfde geldt als u de hostname gebruikt voor de inkomende en uitgaande mailserver. Onderaan deze pagina vindt u de (nieuwe) aanbevolen email instellingen terug voor deze nieuwe omgeving.

Om in te loggen op uw Plesk reseller omgeving, kan u gebruik maken van de volgende link: https://ns1.securenameserver1.net:8443
Uiteraard is ook webmail weer actief op deze Plesk reseller omgeving; deze kan u openen via: https://webmail.securenameserver1.net

De aanbevolen emailinstellingen voor deze reseller node ziet u hieronder terug.

Let op!
Vroeger werd vooral mail.domeinnaam.nl gebruikt. Dit is niet meer van toepassing vandaag de dag. Met dient dus de opgegeven servernaam (zie hieronder) te gebruiken! Deze is namelijk beveiligd met een professioneel SSL certificaat die zorgt voor een beveiligde verbinding tussen uw email programma en de mailserver.

Inkomende email IMAP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 993
Versleuteling: SSL/TLS
Optioneel: hoofdmap instellen op "Inbox" (zonder aanhalingstekens) voor synchronisatie

Inkomende email POP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 995
Versleuteling: SSL/TLS

Uitgaande email SMTP-instellingen
Servernaam: ns1.securenameserver1.net
Gebruikersnaam: uw volledige emailadres
Wachtwoord: wachtwoord van uw emailadres
Poort: 587
Versleuteling: STARTTLS

Voorheen werd voor de uitgaande mailserver poort 465 (met SSL) gebruikt. Aangezien deze poort behoorlijk verouderd begint te worden, is vandaag de dag het advies om poort 587 (met STARTTLS) te gebruiken. Zie voor uitgebreidere uitleg hier en hier. Dus wanneer u in de gelegenheid bent, dan adviseren wij u niet meer poort 465 (met SSL) te gebruiken, maar poort 587 (met STARTTLS) voor de uitgaande mailserver. Op die manier zal u ook in de toekomst geen problemen ondervinden met het versturen van email.

In (bijvoorbeeld) Outlook kan u deze instellingen gemakkelijk controleren door te klikken op "Bestand", vervolgens (in het nieuwe scherm) selecteert u het emailaccount waarmee u "problemen" ondervindt. Wanneer u hier het juiste emailaccount heeft geselecteerd, dan klikt u op het icoon met "Accountinstellingen" en aldaar te klikken op "Serverinstellingen". Controleer hier zowel de "Inkomende e-mail"- alsook de "Uitgaande e-mail"-instellingen. Vaak wordt door Outlook automatisch mail.domeinnaam.nl gevonden/gebruikt, dit is echter incorrect!

Wanneer u email problemen ondervindt, controleer dan of uw SPF-record goed staat. Deze moet vergelijkbaar zijn met:

• v=spf1 mx a ip4:83.172.188.51 ip4:83.172.138.9 a:mail.DOMEINNAAM.TLD a:ns1.securenameserver1.net include:relay.mailchannels.net ~all

Met name het laatste gedeelte is zeer belangrijk! Wij gebruiken op alle (nieuwere) reseller nodes een uitgaand mailfilter. Hiermee voorkomen wij dat server op de zwarte lijst komen te staan, wanneer iemand verzuimd om een contactformulier correct te beveiligen of gewoonweg zijn/haar emailadres gehackt is en spam verstuurd. Door dit uitgaande mailfilter voorkomen wij dus dat de mailserver op de zwarte lijst komt en dat niemand meer emails kan versturen. Dus het is zaak om dit de te controleren. Indien u email extern laat lopen lopen, bijvoorbeeld via Gmail of Microsoft, dan is deze aanpassing natuurlijk niet nodig.

De oude nameservers blijven dus maximaal nog 1 jaar actief (tot medio 11.2023). Daarna verlopen de oude nameservers en kan u deze niet meer gebruiken. Hou hier rekening mee!
Indien u vragen en/of opmerkingen heeft inzake de migratie van uw reseller pakket en u heeft het bovenstaande goede gelezen, dan kan u hiervoor een support ticket openen.

Normaliter plaatsen wij geen individuele bestanden terug. De enige uitzondering hierop is wanneer er een volledige server crash plaats vindt. In dat geval wordt er een volledige kopie van de server teruggeplaatst.

U kan altijd zelf back-up's maken via de Plesk/DirectAdmin interface. U kan dan zelf een back-up terug plaatsen. Daarnaast bieden wij ook nog Backupmaster aan. Indien u hiervan gebruik maakt, dan kunnen wij eventueel voor u een back-up terug plaatsen.

Indien u zelf géén back-up's heeft (via Plesk/DirectAdmin) en/of u geen Backupmaster heeft en u per se wenst dat er bepaalde cruciale bestanden worden teruggeplaatst, dan kan u een support ticket openen. Dan overleggen wij wat er mogelijk is om de bestanden (of database) te restoren. Dit zal dan gebeuren vanuit de server kopie. Hou er wel rekening mee dat er hoge kosten hieraan verbonden zittten, daar dit een behoorlijk karwei is!

Configuring Firewall

Make sure these ports are opened for all Parallels Plesk Panel services to work with a firewall:

• 20 for ftp-data;
• 21 for ftp;
• 22 for ssh;
• 25 for smtp;
• 53 for dns (TCP and UDP);
• 80 for http (web server and Parallels Plesk Panel updater);
• 106 for poppassd (for localhost only);
• 110 for pop3;
• 113 for auth;
• 143 for imap;
• 443 for https;
• 465 for smtps (dit was de oude poort om emails te versturen)
• 587 for mail message submission (aanbevolen poort om emails te versturen);
• 990 for ftps;
• 993 for imaps;
• 995 for pop3s;
• 3306 for mysql;
• 5224 for (outgoing connections only) plesk-license-update;
• 5432 for postgres;
• 8443 for plesk-https;
• 8880 for plesk-http;
• 9080 for tomcat;
• 5224 for license updates.

Het meerendeel van de klanten weet tegenwoordig wel hoe een nep / fake email eruit ziet. Gelukkig! Want je moet nooit ergens op klikken of geld/crypto overmaken.

Helaas blijkt het in de praktijk dat dit nog altijd niet voor iedereen duidelijk is en worden er (onnodige) tickets aangemaakt inzake dit onderwerp. Van al dit soort dergelijke emails is altijd 999 van de 1000 emails gewoonweg nep, dus niet echt. Als dit in een percentage neergezet moet worden, dan zijn van dit soort emails dus 99.9% altijd fake.

Hieronder een een drietal voorbelden van de nep emails die momenteel de ronde doen.

Hallo, hoe gaat het met jou? Ik weet het, het is vervelend om een gesprek te beginnen met slecht nieuws, maar ik kan niet anders.
Enkele maanden geleden heb ik toegang gekregen tot je apparaten die je gebruikt om op het internet te browsen.
Vervolgens heb ik al je internet activiteiten kunnen traceren. Hieronder kun je lezen hoe ik dit voor elkaar heb gekregen:
Allereerst heb ik van hackers de toegang tot meerdere e-mail accounts gekocht (tegenwoordig is dat een fluitje van een cent om dat online te doen).

I am aware one of your passphrase: <oud wachtwoord>. Lets get directly to point.
Not a single person has compensated me to investigate about you. You do not know me and you are probably wondering why you're getting this e-mail?
I actually installed a software on the adult vids (sex sites) site and you know what, you visited this web site to have fun (you know what I mean).
When you were viewing videos, your internet browser initiated working as a Remote control Desktop that has a key logger which provided me access to your display screen and also web cam.

Hi, victim.I write yоu becаusе I put а mаlware оn the wеb раge with porn whiсh yоu hаve visitеd.
My virus grаbbed all your рersonal infо аnd turnеd on yоur сamеrа which сaрtured the рroсеss оf your onаnism.
Just aftеr that the soft savеd yоur соntaсt list.I will dеlеte thе сompromising video and infо if you pаy me 999 USD in bitcoin.

Dit zijn stuk voor stuk allemaal nep emails. Ongeacht waar ze vandaan komen! Vaak lijkt het alsof ze van je eigen emailadres komen, maar dat is niet het geval!
Als je kijkt naar de headers, dan zal je zien, dat deze ergens anders vandaan komen; meestal een heel vreemd emailadres of rechtstreeks van een IP-adres (via een sciript verstuurd wellicht). Gewoon geen aandacht aan dit soort emails besteden en direct verwijderen. Ja, maar de email is van mij afkomstig? Neen, dat is niet zo. het mag dan wel zo lijken, maar dat is niet het geval. Het is dus gewoon onzin!

Ook zijn er vandaag talloze andere nep emails, waar men probeert om je geld, je rekeninggegevens of je privegegevens te onfutselen. Banken sturen je nooit, maar dan nooit een bericht dat je pas geblokkeerd is. T-Mobile verzoekt je nooit, maar dan ook nooit om te betalen in Bitcoin. Andere voorbeelden van nep emails die wij regelmatig voorbij zien komen zijn ondere andere van:

• ING (rekening geblokkeerd)
• ABN AMRO (betaalpas vervangen)
• Rabobank (pas geblokkeerd)
• T-Mobile (rekening, betalen met Bitcoin)
• PostNL (pakket gemist)
• CJIB (rijbewijs ingenomen)
• Intrum Justitia (spookfactuur met virus)
• ICS (creditcard beblokkeerd)

En ga zo maar door... Er zijn tientallen, zo niet honderden verschillende voorbeelden op te nomen (zie ook screenshots onderaan). Trap hier niet in! Klik nergens op! Vul nergens gegevens in naar aanleiding van dit soort emails. Dit geldt voor ieder emailaccount of emailadres die u heeft; of deze nu wel of niet bij ons gehost is. Verwijder dit soort emails altijd. Hiermee voorkomt u altijd problemen. En voorkomen is altijd beter dan genezen!

Controleer en/of raadpleeg bij twijfel de Fraudehelpdesk in dit soort gevallen. Deze partij heeft afgelopen jaar al meer dan 600.000 (!) meldingen gehad van verschillende nep emails. Of neem telefonisch contact op het bedrijf vermeld in de email (zoek het nummer online op en gebruik niet het nummer welke eventueel vermeld staat in de email). Dus u bent niet de eerste die een dergelijke email ontvangt en zeer zeker niet de laatste. Het is gewoonweg niet te voorkomen dat u dergelijke emails ontvangt. Spammers worden steeds slimmer en verzinnen nieuwe methoden om geld en/of gegevens van u te kunnen krijgen.

Nogmaals; 99.9% van al dit soort emails zijn gewoon nep. Trap er niet in en verwijder een dergelijke email.

Het heeft weinig zin/nut om hier een support ticket voor aan te maken, daar wij hier ook weinig tegen kunnen doen. Wij zullen u verwijzen naar dit KB artikel en u het advies meegeven om deze email te verwijderen. Meer kunnen wij niet doen helaas. Onze anti-spam software (Spamprotector) wordt iedere dag voorzien van nieuwe updates en herkenbaarheden in mogelijke spam, maar zoals u hierboven heeft kunnen lezen worden de spammers ook steeds slimmer en vinden telkens nieuwe manieren uit om voorbij dergelijke anti-spam filters te komen. En zolang dit nog rendabel voor hun is, zal dit ook wel zo blijven...

Hieronder een aantal zeer bekende voorbeelden van nep emails.

Er zijn twee mogelijkheden om uw website van te voren te bekijken (preview) op een Plesk omgeving.

De eerste mogelijkheid is alleen beschikbaar op de nieuwere Plesk servers. Dit is simpel te gebruiken, door in te loggen met de gegevens die u heeft ontvangen van ons op uw Plesk omgeving.
Eénmaal ingelogd, dan ziet u op het hoofdscherm (links in het midden) een icoon staan met de tekst "Preview". Als u hierop klikt, dan kunt u uw website alvast bekijken oftewel previewen via een tijdelijke link aangemaakt door de server. Deze functie is met name gemakkelijk voor nieuwe domeinnaam registraties en/of een verhuizing van een domeinnaam.

Er is ook een 2e methode (voor als u geen gebruik kunt maken van de "Preview"-functie) via een kleine aanpassing in de Windows "hosts"-file. Dit is, zoals wij het noemen, een echte oldskool oplossing die vroeger heel veel toegepast werd. Noteer als eerste het IP-adres van uw domeinnaam in de Plesk interface (onder "Hosting & DNS" > "DNS Settings"). Dit IP-adres zal als volgt opgebouwd zijn: 83.172.XX.XXX. Daarna volgt u de onderstaande stappen:

1. Op uw Windows computer opent u het hosts bestand (onder "C:\WINDOWS\system32\drivers\etc\hosts") met Kladblok.
2. Op de laatste regel geeft u het IP-nummer op en daarachter uw domeinnaam, dus bijvoorbeeld: 83.172.XX.XXX uwdomeinnaam.nl
3. Sla de wijzigingen op en herstert uw computer
4. Open nu met uw browser (Firefox, Chrome, Edge, etc.) uw website, bijvoorbeeld: uwdomeinnaam.nl
5. Nu wordt normaliter de website vanaf het nieuwe IP-adres getoond

Let op! Vergeet niet na het testen om de wijziging in het Windows hosts bestand ongedaan te maken! Dit kan u doen door de regel te verwijderen of een hashtag (#) ervoor te plaatsen.

Securing the /tmp Partition

It is recommended to run /tmp as separate partition and mount it with the noexec, nodev and nosuid options.

• The noexec option disables the executable file attribute within an entire file system, effectively preventing any files within that file system from being executed.
• The nodev option disallows creation of so-called device files with which you can get direct access to devices like the memory or disk
• The nosuid option disables the SUID file-attribute within an entire file system. This prevents SUID attacks on, say, the /tmp file system.

To secure the /tmp partition of your VPS or DPS server:

• run the command "mount" without parameters. If it contains the following line:
  
  /dev/simfs on /tmp type simfs (rw,nosuid,nodev,noexec,relatime,usrquota,grpquota)
  
  then the VPS / DPS has already a secured /tmp directory. All newer VPS / DPS are delivered with secured /tmp directory!
• If the /tmp directory is not yet configured, add the following line at the end of the file /etc/fstab :
  
  /usr/tmp /tmp simfs bind,rw,nosuid,nodev,noexec,relatime,usrquota,grpquota 0 0
• restart your VPS / DPS
  Please don't simply run a mount /tmp because programs like eg. MySQL or PHP might miss files they stored into the old /tmp directory. Only by restarting the server, all programs get aware of the new /tmp directory.

Op de markt zijn talloze verschillende goede (en ook slechte FTP) programma's beschikbaar. In dit voorbeeld hanteren wij Filezilla.
Filezilla is al jaren op de markt en is een gratis (en zeer betrouwbaar) FTP programma. Wanneer u dus bestanden wenst te uploaden en u heeft nog geen FTP programma, dan kunt u Filezilla hier downloaden.

U kan op diverse manieren connecteren naar uw website, waaronder;

• via de domeinnaam van uw hosting
• via het IP-adres van uw website
• via de hostname van de server

Het gemakkelijkste is uiteraard via de domeinnaam van uw webhosting. Wanneer uw domeinnaam www.helpburo.eu is, dan gebruikt u dus als naam: helpburo.eu.

Wanneer u Filezilla geinstalleerd en opgestart heeft, dan krijgt u venster te zien waarin vier (4) invulvelden te zien zijn:

• Host: uw domeinaam (zonder www of toevoegingen ervoor) in. Bijvoorbeeld: helpburo.eu (*)
• Username: is de gebruikersnaam gekoppeld aan uw FTP. Bijvoorbeeld: helpbeu
• Password: het wachtwoord gekoppeld aan de gebruikersnaam van uw FTP.
• Poort: deze is altijd standaard ingesteld op 21 (dit werkt voor alle servers zonder problemen).

(*) u kan bij "Host" ook het IP-adres van uw website invullen of de hostname (start met ns1 ervoor) van de server invullen op waar uw hostingaccount zich op bevindt. Klik hier om de hostname van de server te vinden.

Als het goed is bent u nu ingelogd op de FTP-omgeving van uw website. Mocht u niet kunnen connectoren, controleer dan of u de correcte gegevens gebruikt (hostnaam, gebruikersnaam, wachtwoord en/of poortnummer).
Ook kan het zijn dat uw (lokale) firewall op uw computer de verbinding blokkeert; controleer dit eveneens. Wanneer u 3x foutief inlogt, dan kunt u voor 15 minuten geblokkeerd worden. Dit is een extra beveiliging op onze servers om eventuele hackers tegen te gaan.

We gaan de handleiding nu opsplitsen voor Plesk en DirectAdmin, daar de uploadpaden anders zijn bij beide producten.

Plesk interface / controle paneel

In een Plesk omgeving dient u bestanden te uploaden in de map met de naam /httpdocs/. In andere mappen dient u niets te uploaden. Alles wat u in de map /httpdocs/ plaatst is ook zichtbaar op het internet.
Normaliter staat hier al een index.html of zelfs een index.php bestand in aangemaakt (of meerdere bestanden als u reeds iets heeft geupload in het verleden).
Wanneer dit de eerste keer is dat u connectie maakt naar de hosting van uw website, dan kunt u deze bestanden uiteraard verwijderen. Vanzelfsprekend dient u dit niet te doen als u reeds een website online heeft staan!

Kanttekening; u kan bij Plesk ook gebruik maken van de ingebouwde "File Manager" in de interface. Deze is simpeler qua gebruik maar ook qua functies, echter een prima simpel alternatief om kleine bestanden te uploaden of bestanden aan te passen.

DirectAdmin interface / controle paneel

Bij DirectAdmin moet u uw bestanden uploaden in de map met de naam /public_html/. In andere mappen dient u niks te uploaden. Alles wat u in deze map plaatst, zal ook direct zichtbaar zijn op het internet.
Normaliter staan hier al een paar standaard bestanden in, waaronder een index.html bestand. Of andere bestanden indien u al een keer bestanden heeft geupload.
Indien dit de eerste keer is dat u verbinding maakt naar de hosting van uw website, dan kunt u de bestanden onder /public_html/ uiteraard verwijderen. Als u reeds een website heeft staan, dan dient u deze bestanden niet te verwijderen!

Kanttekening; ook DirectAdmin heeft een standaard "File Manager" waarmee u simpele aanpassingen kunt verrichten aan (tekst)bestanden of verschillende bestanden kunt uploaden. Deze is vrij éénvoudig te gebruiken, maar daarnaast mist deze ook een aantal geavanceerde optie's die terug te vinden zijn in (bijvoorbeeld) FileZilla.

Uiteraard kan u de hierboven genoemde instellen ook toepassen op eventuele programmatuur die u gebruikt voor het onderhouden of aanpassen van uw website (bijvoorbeel Dreamweaver).

Welke rechten moeten bestanden en mappen standaard krijgen?

Standaard behoren alle bestanden chmod 644 te krijgen en mappen 755

Let op!!

Zet bestanden NOOIT op 777!!

Welke rechten moeten cgi-perl bestanden krijgen?

CGI en perl bestanden moeten chmod 755 krijgen.

Hoe pas ik de chmod rechten aan via een ftp programma?

De chmod rechten kunt u aanpassen via uw ftp programma door op het bestand of map met de rechtermuisknop te drukken en kiezen voor chmod of change attribute.

Hierbij vind u een chmod calculator:

Schrikbarend aantal (zeer) zwakke wachtwoorden
Helaas moeten we anno 2016 nog altijd constateren dat een groot aantal mensen en/of bedrijven gewoonweg te simpele wachtwoorden gebruiken voor hun websites, emailaddressen, cms, databases en ga zo maar verder.

Simpel gezegd; wachtwoorden die alleen bestaan uit woorden, alleen letters en/of cijfers zijn absoluut niet veilig meer tegenwoordig. Sterker nog, dit is al meer dan 8 jaar niet veilig! Ook het gebruik van straatnamen, postcodes, woonplaatsen en dergelijke zijn niet veilig. Enkele voorbeelden van wat wij, helaas, nog dagelijks tegenkomen qua wachtwoorden:

- vogels1
- aardbei
- 3306cj
- socrates
- qwerty123
- dummy1

Dit zijn dus wachtwoorden die absoluut niet veilig zijn en derhalve ook nooit gebruikt dienen en mogen worden. Indien u toch dit soort wachtwoorden blijft gebruiken of gewoonweg niet aanpast, dan is de kans aannemelijk dat uw account binnen de kortste keren gehackt is en uw (gevoelige) data en/of emails voor iedereen zichtbaar wordt.

Daarnaast kan uw account dan ook misbruikt worden om te spammen. Hier ondervinden wij niet alleen last van, maar ook de overige klanten op de desbetreffende server! Indien dit zich voor doet, dan zijn wij genoodzaakt het desbetreffende account compleet at te sluiten, dit om de overlast voor ons netwerk en andere te beperken.


Waarom zo streng of zelfs agressief optreden?
De reden hiervoor is simpel. Wij adviseren klanten al sinds jaar en dag om altijd sterke wachtwoorden te gebruiken. Indien een klant dit niet doet en vervolgens zijn/haar account wordt gehackt en vervolgens 100.000 (spam)emails worden verstuurd (of zelfs erger), dan wordt de integriteit van ons netwerk aangetast.

Daarnaast wordt de desbetreffende IP-range op de blacklist geplaatst en worden emails van andere klanten bij providers geweigerd. Dit allemaal omdat u heeft verzuimd om een sterk wachtwoord voor uw account aan te maken. Ook hier geldt voorkomen, is beter dan genezen...


Wat zijn dan sterke wachtwoorden?
Sterke wachtwoorden bestaan altijd uit een combinatie van kleine en grote letters, afgewisseld met getallen en speciale karakters. Als u zorgt dat u combinatie van deze gebruikt, dan weet u zeker dat u een sterk wachtwoord heeft. Het mogen best woorden zijn, maar dan wel dus gecombineerd met getallen en (vooral) speciale karakters.

Wel is het aan te bevelen om minimaal 1x per jaar uw wachtwoord(en) aan te passen voor nog meer zekerheid. Voorbeelden van sterke wachtwoorden:

- Ch75^SxhT33
- S0cR4t€s
- 855Jy975Rg#
- 8g7G9E3$$Dx
- Kjnn_8Dc3

Dit zijn enkele voorbeelden van sterke wachtwoorden. En op die manier bent u een stuk zekerder dat uw account niet zo snel gehackt zal worden. In ieder geval niet op basis van een sterk wachtwoord.

Wij snappen dat het onthouden van wachtwoorden vandaag de dag een stuk lastiger is geworden, zeker aangezien de complexiteit van de wachtwoorden enorm is toegenomen. Ook is er voor iedere website of webshop die u bezoekt inloggegevens nodig of ooit een keer ingevuld. Aangezien dit allemaal lastig is om te onthouden (opschrijven is ook niet te adviseren), willen wij u erop attenderen dat er een gratis oplossing bestaat, namelijk: LastPass.

Met LastPass kunt u eenvoudig uw wachtwoorden beheren, voor welke website dan ook. Op hun website wordt geadverteerd met de tekst: "LastPass onthoudt uw wachtwoorden, zodat u dat zelf niet hoeft te doen."
Zover wij kunnen hebben constateren is dit programma voor de meeste gebruikers volledig gratis, al bestaat er een mogelijkheid om tegen een minimaal bedrag te upgraden naar een premium account.

Wij verdienen hier helemaal niks aan en is gewoon een stukje vriendelijk advies, wanneer u moeite heeft met de enorme aantallen wachtwoorden te onthouden vandaag de dag.

U kan altijd oude Helpburo support tickets opnieuw openen, dus ook oude tickets die reeds gesloten zijn!

Maak aub hiervan gebruik, wanneer dit noodzakelijk is en maak geen nieuwe tickets aan over hetzelfde probleem of met een verwijzigng naar een ticket ID.
Anders wordt het zeer onduidelijk voor onze support medewerkers en daarnaast kan dit de verwerking van uw ticket vertragen.

Om oude en/of gelosten tickets opnieuw te openen, volgt u de 3 onderstaande simpele stappen:

1. Log in op uw Helpburo account
2. Klik vervolgens op de knop "Mijn tickets" (bovenaan)
3. Klik vervolgens op de knop "Afgehandelde tickets weergeven" (rechterkant)

Dat is alles! U ziet nu al uw oude tickets en u kan ieder ticket gewoon opnieuw openen door een reactie hierop te geven uiteraard.
Dus u hoeft geen nieuwe/extra tickets aan te maken over dezelfde probleem of vraag!

Ter extra verduidelijking ook een paar screenshots toegevoegd.

Stap 1:

Stap 2:

Stap 3:

Wat is impact van de websitesnelheid?

Zoals we allemaal wellicht al weten is dat Google veel waarde hecht aan snelle websites. In Google Webmaster Tools kun je dit bijvoorbeeld terug zien in de speedmetrics, maar je kunt dit ook terug zien in de Real User Measurement informatie in Google Analytics.

Hierin kun je zeer uitgebreide informatie vinden zoals redirection time, server response time en domain lookup time. Allemaal waardevolle informatie dus als het gaat om de snelheid van je website. Maar wat voor impact heeft de snelheid van je website op de website zelf en je bezoekers?

Gebruikerservaring van bezoekers

De laadtijd van de website heeft uiteraard direct impact op de gebruikerservaring. Veel bezoekers ergeren zich kapot aan een website die traag reageert of juist helemaal niet reageert. Dan kan opeens de website van de concurrent in één keer een stuk interessanter zijn.

Negatieve gebruikerservaring kan leiden tot een daling van je omzet of een daling van je bezoekers. Daarom hoort de focus van een website altijd te liggen bij de gebruikerservaring. Laadtijd heeft niet alleen effect op de gebruikerservaring, maar ook zaken zoals content, layout en functionaliteiten hebben invloed op de gebruikerservaring van je bezoekers.

Rankings in de zoekresultaten (Google)

Google heeft in 2010 al meegedeeld dat de snelheid van een website mee wordt genomen in de berekening van je positie in Google. Ook al zegt Matt Cutts dat het een kleine impact heeft op je rankings in de zoekresultaten, toch worden tragere websites minder gewaardeerd door Google.

Het vervelende is dat slechte hosting veel invloed heeft op de snelheid van je website. Je ziet uiteraard niet te wachten op 404- en 503-serverfouten. Slecht beheer van de server of slechte hosting kunnen dit allemaal veroorzaken en heeft uiteraard een negatief effect op de gebruikerservaring van bezoekers.

Indien je website hoge laadtijden heeft, zal het volgens Google niet heel veel verschil maken voor je positie in Google. Hierdoor zul je dus altijd veel organisch verkeer moeten ontvangen, echter de vraag is natuurlijk hoelang ze op de website willen blijven.

Wat houdt SEO-hosting precies in?

De term SEO-hosting is een term die steeds vaker voorkomt in de hostingwereld, maar voor de meeste mensen is SEO-hosting nog een volledig nieuw begrip. Vooral in Amerika is SEO-hosting ontzettend populair en ook steeds meer Nederlandse hostingpartijen lijken SEO-hosting aan willen bieden. Maar wat houdt SEO-hosting nu precies eigenlijk in?

Wanneer je meerdere website hebt is het een logische keuze om dit onder één of enkele hostingaanbieders te brengen. Hierdoor kun je eenvoudig het overzicht behouden en kun je natuurlijk ook eenvoudiger jouw websites beheren.

Maar wanneer je met SEO bezig gaat kan dit weer anders liggen. Als je bezig bent om via SEO de online vindbaarheid van je website te vergroten, dan kun je voor een SEO-strategie met landingspagina’s kiezen. Deze landingspagina’s kunnen allemaal een eigen domeinnaam hebben. Als je bijvoorbeeld gevonden wilt worden op SEO hosting, dan kan het domeinnaam seohosting.nl zeer interessant zijn.

Vervolgens zul je veel energie en tijd steken in deze landingspagina’s door SEO-teksten te gaan schrijven, websites te gaan bouwen en backlinks te gaan bouwen. Je wilt natuurlijk dat jouw websites en inspanningen goed beloond worden door Google. Maar wanneer je unieke websites maakt in dezelfde hostingomgeving, dan zul je daar niet veel kans op maken.

Wanneer je websites in dezelfde hostingomgeving bouwt, dan is de kans groot dat alle websites dezelfde ip-adressen hebben. Google ziet de unieke websites dat niet als een reguliere website zien, maar meer als een interne link naar uw website. En een interne link heeft veel minder waarde dan een externe link. 

Met SEO-hosting is dit gemakkelijk op te lossen, omdat je met SEO-hosting een aantal unieke ip-adressen ontvangt waar je jouw websites aan kunt koppelen. Hierdoor ziet Google het gewoon als unieke websites.

Wat zijn de nadelen van SEO-hosting?

Helaas zitten er ook een aantal nadelen aan SEO-hosting. Er is op dit moment nog niet echt een serieuze aanbieder van SEO-hosting in Nederland te vinden. De meeste aanbieders zitten in Amerika en om SEO-hosting te kunnen bestellen zul je dan vaak een PayPal-rekening of creditcard moeten hebben.

Daarnaast zijn de kosten voor SEO-hosting erg hoog. Dit komt omdat je een aantal unieke ip-adressen afneemt en deze zijn uiteraard duurder om te beheren, dan wanneer je bijvoorbeeld voor shares webhosting kiest.

5 handige tips voor een snelle website

Wanneer je een website voor e-commerce doeleinden gebruikt, dan weet je als geen andere dat je website goed moet presteren. Dat betekent dat je website aantrekkelijk en gebruiksvriendelijk moet zijn voor je bezoekers. Hierdoor zorg je ervoor dat bezoekers een langere tijd op je website doorbrengen.

En hierbij is snelheid misschien wel het belangrijkste, want hoe sneller pagina’s laden, hoe langer bezoekers op je website zullen blijven en meer pagina’s zullen bezoeken. Ook dit werkt weer positief door op de conversie van een website. Een snelle website zorgt niet voor een klein effect in de marge, maar kan een aanzienlijke bijdrage leveren aan de omzet. Hieronder vindt je 5 handige tips waarmee je een snelle website kunt  realiseren.

1. Maak een afweging tussen performance en design

Wanneer een bezoeker je website bezoekt, zal de browser van de bezoeker niet alleen informatie laden, maar ook bestanden en afbeeldingen. Dit zijn zaken die alles bijdragen aan een mooi design, maar het zijn ook zaken die het vertragen van het laden aanzienlijk kunnen beïnvloeden. Daarom is het verstandig om alle overbodige zaken weg te halen en vraag je altijd af of de extra content meerwaarde voor de bezoeker biedt.

2. Maak gebruik van caching

Gebruik maken van caching is de perfecte manier om de snelheid van je website te verbeteren. Met caching komt namelijk de inhoud van je website in statische bestanden op de computer van de bezoeker terecht. De volgende keer wanneer een bezoeker je website bezoekt, hoeft de bezoeker niet weer de originele data weer te downloaden van de server. Een klein deel van de website staat hierdoor al in cache op de computer van de bezoeker en dit vermindert weer aanzienlijk het dataverkeer van je hosting en bevordert uiteraard de snelheid.

Bij het verbeteren van de snelheid van je website is het verstandig om te weten hoe groot je website is. Wanneer je weet hoe groot je website precies is, kun je rekenen hoeveel servercapaciteit je precies nodig hebt.

Wanneer je onvoldoende capaciteit hebt dan zullen de webpagina’s langzamer gaan laden, dit kun je vooraf met je hostingprovider bespreken. Wanneer je een kleine website hebt met een blog, dan kun je simpel een klein hostingpakket kiezen. Maar wanneer je een grotere website hebt, dan kun je bijvoorbeeld beter met een dedicated en VPS server werken. Probeer hier dus bewust mee om te gaan en informeer hoe het precies zit.

4. Laad scripts als laatste

Wanneer je scripts als laatste laat laden, dan zal op deze manier alle content als eerst geladen worden, voordat de browser aan de scripts begint. De bezoeker krijgt als eerste de informatie te zien waar de bezoeker voor kwam en het vermindert ook de wachttijd voor het laden van je website.

5. Gebruik een content delivery network

Nu zul je denken, wat is een content delivery network? De locatie van een bezoeker die je website bezoeker is van grote invloed op de laadtijd van je pagina’s. Als je bezoekers van de andere kant van de wereld hebt, dan zal de data daar eerst helemaal heen moeten gaan. Dit kost natuurlijk wat tijd.

Maar een content delivery network helpt je hierbij door gestandaardiseerde delen van de website in een database onder te brengen over de hele wereld. Zo kan een browser je website ophalen vanuit een datacenter wat dichterbij zit en dit vermindert weer de vertraging.

Je kan je webbrowser (Internet Explorer, Firefox, Chrome, Safari, etc.) legen via de instellingen van de gebruikte webbrowser.
Een andere manier is om DNS-cache gewoon te legen op de computer zelf.

Dit is met name handig wanneer u een nieuw IP-nummer heeft toegewezen aan uw website.

Hieronder wordt uitgeleged hoe je dit kun doen in verschillende besturingssytemen.

In Windows
Open een opdacht prompt venster (Start > Uitvoeren) en geef daarin het commando "cmd".
Vervolgens krijgt u (normaliter) een zwart venster te zien. Geef hierin het commando "ipconfig /flushdns"

U krijgt daarna de volgende melding te zien: "Windows IP configuration successfully flushed the DNS Resolver Cache"
U heeft nu de DNS-cache geleegd van uw Windows besturingssysteem.

In Mac OS X
Open het programma terminal (Programma's > Hulpprogramma's) en geef het commando in de DNS-cache te flushen.
Het commando is verschillend bij verschillende versies van Mac OS X.

• Mountain Lion of Lion: sudo killall -HUP mDNSResponder
• Snow Leopard: dscacheutil -flushcache
• Leopard en ouder: lookupd -flushcache

Indien er gevraagd wordt om een wachtwoord, dan dient u het beheerders wachtwoord in te geven van uw computer.
U heeft nu de DNS-cache geleegd op uw Mac OS X besturingssysteem.

In Linux
Open een terminal als root of typ eerst sudo voordat je het commando om de DNS-cache te legen ingeeft.
Geef vervolgens de volgende commando's in om de DNS te flushen:

• sudo /etc/init.d/dns-clean
• service network-manager restart

U heeft nu de DNS-cache geleegd van uw Linux besturingssysteem.

We merken dat er regelmatig reacties op support tickets binnenkomen vanaf een ander e-mailadres dan het e-mailadres dat geregistreerd is bij Helpburo. Als dit andere e-mailadres niet gekoppeld is aan uw Helpburo-account, wordt de reactie helaas niet toegevoegd aan het ticket. Dit kan ervoor zorgen dat uw reactie niet gezien wordt door ons support team.

Het is belangrijk om bij het beantwoorden van een support ticket altijd hetzelfde e-mailadres te gebruiken waarmee het ticket is aangemaakt of waaraan het is geadresseerd. Dit wordt ook vermeld bij het aanmaken van een support ticket en in de automatische bevestiging. Daarnaast is het cruciaal om het ticket ID in de onderwerpregel te laten staan.

Helaas zien we dat dit nog niet altijd gebeurt. Bijvoorbeeld, als een ticket wordt aangemaakt via info@pietjepuk.nl en later wordt beantwoord via pietjepuk@gmail.com, dan herkent Helpburo dit e-mailadres niet en wordt de reactie niet toegevoegd aan het ticket.

Dit probleem kunt u eenvoudig voorkomen door extra e-mailadressen toe te voegen onder uw profielinstellingen op Helpburo, of door gewoonweg het juiste e-mailadres te gebruiken bij het beantwoorden van een support ticket per e-mail.

Zie ook screenshots in de bijlage voor meer duidelijkheid.

Door de jaren heen is de prijs van Installatron gestegen. Tot op heden hebben wij deze prijsstijging echter niet doorberekend aan klanten met een eigen server (VPS/DPS). Gezien de beperkte kennis die wij hebben over Installatron en de complexiteit van het platform, raden wij aan om bij problemen direct contact op te nemen met de supportafdeling van Installatron.

Mogelijke problemen kunnen zijn: problemen met het installeren of updaten van applicaties, beschikbaarheid van alleen oudere versies, en problemen bij het klonen van websites binnen Installatron. Installatron wordt steeds uitgebreider, evenals de servers en controlepanelen (zoals DirectAdmin en Plesk). Daarom hebben wij besloten onze expertise te beperken tot servergerelateerde kwesties. Voor serieuze problemen met Installatron kunt u direct een supportticket aanmaken bij Installatron via deze link.

Voor problemen met niet (automatisch) verlengde licenties voor Installatron kunt u uiteraard nog steeds een supportticket bij ons indienen. Dit geldt ook voor reguliere hostingklanten.

Wij zien steeds meer het gebruik van CloudFlare inzake servers (en ook websites). Wanneer CloudFlare gebruikt wordt en er zijn problemen (zoals een overload door een mogelijke DDoS aanval, brute-force attempts, etc.), dan kunnen wij hier bijna geen support op leveren.
Dit komt doordat wij géén toegang hebben tot uw CloudFlare account en op de server worden alle inkomende IP-adressen weergegeven als afkomstig van CloudFlare; derhalve kunnen wij zeer weinig betekenen in dit geval.

Indien u toch support wenst, dan heeft u twee mogelijkheden;

1. U geeft ons de inloggegevens t.b.v. uw CloudFlare account
   • Vervolgens kan de tech direct kijken wat de mogelijke oorzaak is en hierop actie ondernemen om de load terug omlaag te brengen
   • Het spreekt voor zich dat wij deze gegevens niet met derden delen en worden gewist nadat het probleem is opgelost
2. U zet de nameservers om naar de originele nameservers van de server
   • Deze methode is omslachtiger als de eerste methode en duurt ook langer voordat dit gerealiseerd is
   • Daarom het advies om de eerste methode op te volgen en ons de gegevens toe te sturen inzake uw CloudFlare account

Servers en/of websites die wij zelf hebben ondergebracht bij CloudFlare vallen niet onder het bovenstaande uiteraard.

In een tijd waarin API's steeds meer worden gebruikt voor het optimaliseren van bedrijfsprocessen, met name in webshops, zien we dat veel van deze API’s gehost worden op cloudplatformen zoals Amazon AWS en Microsoft Azure. Deze platformen bieden een hoge mate van flexibiliteit tegen lage kosten, maar brengen ook substantiële risico's met zich mee. In deze toelichting leggen we uit waarom bepaalde IP-adressen en IP-ranges geblokkeerd worden, welke impact dit kan hebben op API-verzoeken, en hoe we met dergelijke situaties omgaan.

De risico’s van publieke cloudplatformen

Cloudplatformen zoals Amazon AWS en Microsoft Azure bieden diensten aan die wereldwijd toegankelijk zijn. Dit betekent echter ook dat:

• Servers eenvoudig gehuurd kunnen worden: Iedereen met een creditcard kan een server opzetten, vaak binnen enkele minuten, en deze gebruiken voor uiteenlopende doeleinden.
• Minimale controle op misbruik: Cloudproviders controleren niet actief wat gebruikers op hun servers doen. Hierdoor zijn deze platformen een aantrekkelijk doelwit voor kwaadwillenden.
• Veelvuldig gebruik voor aanvallen: Een aanzienlijk deel van de DDoS-aanvallen, brute-force attempts, phishingcampagnes en andere vormen van cybercriminaliteit wordt uitgevoerd vanaf servers op deze platforms.

Als gevolg hiervan komen IP-adressen en IP-ranges van deze cloudplatformen vaak op internationale zwarte lijsten terecht. Dit is een realiteit waarmee wij, net als veel andere hostingproviders, te maken hebben.

Waarom blokkeren wij IP-adressen en IP-ranges?

Onze prioriteit is het waarborgen van een veilige, stabiele en presterende serveromgeving voor al onze klanten. Dit betekent dat wij proactief maatregelen nemen om ons netwerk te beschermen tegen aanvallen en misbruik. Enkele belangrijke overwegingen:

1. Bescherming van klanten: Onbeveiligde of slecht onderhouden websites, bijvoorbeeld oudere WordPress-installaties, zijn extra kwetsbaar voor aanvallen. Het blokkeren van malafide IP-adressen voorkomt misbruik en minimaliseert downtime.
2. Bescherming van ons netwerk: Aanvallen die niet worden gefilterd, kunnen leiden tot hoge belasting op onze infrastructuur en reputatieschade. Wanneer ons netwerk wordt geassocieerd met malafide activiteiten, lopen wij het risico zelf op zwarte lijsten te worden geplaatst.
3. Efficiëntie: In plaats van per individuele server aanvallen te mitigeren, implementeren we globale IP- en rangeblokkades. Dit stelt ons in staat om snel en effectief te reageren op bedreigingen.

Wij blokkeren IP-adressen en ranges op basis van:

• Historisch misbruik, zoals betrokkenheid bij DDoS-aanvallen of brute-force pogingen.
• Aanwijzingen dat een IP-adres of range momenteel actief wordt gebruikt voor malafide activiteiten.
• Gedragsanalyses en waarschuwingen van derde partijen, zoals internationale blacklists.
  
  

Impact op API-gebruik

Een groeiend aantal klanten meldt problemen met API’s die niet correct functioneren of geen verbinding kunnen maken. Dit kan verschillende oorzaken hebben:

1. ModSecurity-regels: Onze Plesk- en DirectAdmin-servers hebben een extra beveiligingslaag genaamd ModSecurity. Deze filtert verdachte verzoeken en kan API-verzoeken blokkeren die bepaalde patronen vertonen. Dit is doorgaans eenvoudig op te lossen.
2. Blokkades op IP-niveau: Wanneer een API gehost wordt op een server waarvan het IP-adres of de range eerder betrokken was bij malafide activiteiten, kan dit geblokkeerd zijn. In sommige gevallen blokkeren we zelfs volledige IP-ranges van cloudproviders zoals AWS of Azure om grootschalige aanvallen te mitigeren.
   
   

Ons beleid en procedure

Beveiligingsmaatregelen

Wij nemen beveiligingsmaatregelen niet lichtvaardig. IP-blokkades worden alleen toegepast op basis van duidelijke aanwijzingen van misbruik. Elke blokkade wordt grondig geanalyseerd en gedocumenteerd. Onze maatregelen zijn gericht op:

• Preventie: Het voorkomen van aanvallen op onze servers en netwerken.
• Minimalisatie van risico’s: Het beperken van de impact van aanvallen op klanten en ons netwerk.
• Efficiënt beheer: Het globaal toepassen van blokkades voorkomt dat individuele servers kwetsbaar blijven of handmatig beheerd moeten worden.

Wanneer een API hinder ondervindt

Indien een klant rapporteert dat een API-verzoek wordt geblokkeerd, hanteren wij de volgende aanpak:

1. Onderzoek: Op verzoek analyseren wij of de blokkade legitiem is en gerelateerd is aan de gemelde API. Dit omvat een technische controle van logs en een validatie van de betrokken IP-adressen en ranges.
2. Kosten: Vanwege de tijdsinvestering brengen wij een eenmalige onderzoekskosten van €75,00 in rekening.
3. Resultaat van het onderzoek:
   • Als blijkt dat de blokkade onterecht is of niet langer nodig is, wordt deze opgeheven.
   • Als de blokkade noodzakelijk blijft, bieden wij alternatieven (zoals het uitsluiten van de server van globale blokkades, zie hieronder).
     
     

Risico’s van het uitsluiten van blokkades

Klanten kunnen ervoor kiezen om hun server uit te sluiten van onze globale IP-blokkades. Hoewel dit specifieke problemen met API’s kan oplossen, brengt dit aanzienlijke risico’s met zich mee:

1. Hogere serverbelasting: Zonder filtering zal de server aanzienlijk meer verkeer verwerken, waaronder malafide verzoeken. Dit resulteert in een verhoogde CPU- en netwerkbelasting.
2. Toegenomen veiligheidsrisico: Ongefilterd verkeer maakt de server kwetsbaar voor brute-force attempts, DDoS-aanvallen en andere bedreigingen.
3. Schade aan netwerkintegriteit: Als onbeveiligde verzoeken vanuit uw server ons netwerk schaden, behouden wij ons het recht voor om eventuele gevolgschade bij u in rekening te brengen.
   
   

Conclusie

Onze beveiligingsmaatregelen zijn essentieel voor de veiligheid en stabiliteit van ons netwerk en de servers van onze klanten. Hoewel wij altijd bereid zijn om blokkades te herzien, moeten we een balans vinden tussen het faciliteren van specifieke verzoeken en het beschermen van onze gehele infrastructuur. Mocht u problemen ondervinden met een API of vragen hebben over onze beveiligingsmaatregelen, neem dan contact met ons op via Helpburo. Wij staan klaar om u te helpen binnen de kaders van ons beleid en onze verantwoordelijkheden.

Tags: API-blokkades, ModSecurity, IP-adres blokkades, Cloudplatformen, Amazon AWS, Microsoft Azure, DDoS-aanvallen, Beveiliging hosting, DDoS-bescherming, WordPress API, Serverveiligheid, Plesk, DirectAdmin, Cybersecurity, IP-range blokkering, Nullrouting

Spamprotector gebruikt de onderstaande IPv4- en IPv6-adressen:

• 83.172.128.4
• 83.172.188.4
• 83.172.128.5
• 83.172.128.6

• 2a02:cec0:10:16::1
• 2a02:cec0:10:16::2
• 2a02:cec0:10:16::5
• 2a02:cec0:10:16::6

Indien u problemen ervaart, dan dient u te controleren of er ergens niet een firewall deze IP-ranges blokkeert.
Dit is met name vaak het probleem bij klanten die Spamprotector afnemen bij ons, maar elders (dus extern) hun overige diensten hebben ondergebracht staan. Zie ook het volgende kennisbank artikel: https://www.helpburo.eu/Knowledgebase/Article/View/spamprotector-support-bij-externe-diensten.

Op dit moment circuleert er nieuws inzake een kwetsbaarheid m.b.t. Apache Log4j.

Alle (opgeleverde) servers met Plesk of DirectAdmin maken geen gebruik hiervan en dus vormt deze kwetsbaarheid geen risico.
Dus wanneer u een server heeft met Plesk of DirectAdmin, dan hoeft u zich geen zorgen te maken.

De enige servers die (in theorie) een probleem hier mee kunnen hebben zijn zogenaamde plain servers (LAMP). Dit zijn specifieke servers en worden alleen door klanten besteld met technische Linux kennis.
Dit zijn "kale" servers zonder een interface (zoals Plesk of DirectAdmin) en worden door ons alleen voorzien van Linux, Apache, MySQL en PHP (vandaar de naam LAMP). De klanten die dergelijke servers afnemen zijn zelf verantwoordelijk voor wat men installeert op zijn/haar server. Normaliter maken dergelijke servers ook geen gebruik van Apache Log4j, maar het kan zijn doordat u een bepaalde applicatie heeft geinstalleerd op uw server die deze functie wel gebruikt. In dat geval raden wij u aan om deze kwetsbaarheid te dichten. Wij leveren nagenoeg nauwelijks tot geen support op zogenaamde plain (= LAMP) servers, daar hier ontelbare configuratie mogelijkheden voor zijn.

Voor de goede orde; heeft u een server (of hostingaccount) met een Plesk interface of met een DirectAdmin interface, dan heeft u geen last van de Apache Log4j kwetsbaarheid!

Wanneer u gebruik maakt van CloudFlare diensten voor uw website en/of server (via de nameservers van CloudFlare), dan dient u altijd "DDoS protection" in te schakelen.
Dit voorkomt niet alleen DDoS aanvallen, maar zorgt er ook voor dat uw website (en server) niet offline gaat door duizenden queries en/of connecties die getunneld worden via CloudFlare!

Dit is zeer gemakkelijk in te stellen binnen CloudFlare. Volg hiervoor de onderstaande stappen:

• Log in op CloudFlare
• Ga naar de domeinnaam in kwestie
• Open het "Security"-menu (linkerzijde)
• Klik nu op "DDoS"

U krijgt nu een nieuw scherm te zien, namelijk:

Schakel in ieder geval "HTTP DDoS attack protection" in. U kan deze instellen door op "Configure" te klikken.
Kies op de nieuwe pagina de volgende opties:

• Ruleset action: Default
• Ruleset sensitivity: Default

Vervolgens klikt u op de "Save"-knop (rechtsonderin).

Nog steeds een DDoS aanval?
Bij zeer zware DDoS aanvallen en wanneer het bovenstaande niet helpt (website continue niet bereikbaar, laad langzaam of server offline) dan zal u de optie "Under Attack Mode" moeten activeren binnen CloudFlare. Dit is eveneens vrij snel in te stellen, namelijk:

• Selecteer (indien nodig) de domeinnaam in kwestie
• Klik nu op "Overview" (linkerzijde)
• Activeer nu (aan de rechterkant) de optie: Under Attack Mode

Nu zal u moeten wachten tot de DDoS aanval afgelopen is. Dit kan enkele minuten zijn, maar kan ook uren duren. Helaas is hier geen vast antwoord op te vinden.

Wellicht is het wel verstandig om de oorzaak te achterhalen van de DDoS aanval op uw website (of server). De voornaamste redenen zijn:

• slecht onderhouden website (al geruime tijd niet voorzien van updates)
• slecht of helemaal niet beveiligde (Wordpress) website
• oude en te gemakkelijke wachtwoorden (website, email, database, etc.)
• mail scripts of comment systeem (o.a. bij Wordpress) misbruik
• u heeft kwaad bloed gezet bij een ander persoon/bedrijf

Zoals u kunt constateren zijn er vele redenen die voor een DDoS aanval kunnen zorgen op uw website of server. De hierboven genoemde redenen zijn de meest voorkomende, al zijn er natuurlijk ook nog andere (minder vaak voorkomende) redenen voor een mogelijke DDoS aanval.

Indien u wenst kunnen wij een technisch onderzoek opstarten tegen tech kosten (tarief afhankelijk van tijdsperiode). Er wordt altijd minimaal één uur gerekend voor een dergelijk onderzoek. Indien u dit wenst, dan zal u een support ticket moeten aanmaken op Helpburo. Vermeld in het ticket dan zoveel mogelijk informatie, denk aan; inloggegevens, periode van DDoS aanval, etc. Hoe meer informatie u kan aanleveren, hoe sneller de oorzaak achterhaald kan worden en hoe lager de tech kosten uiteindelijk zullen zijn.

Wij hebben de afgelopen jaren al meerdere keren vermeld (via websites, nieuwsbrieven, Kennisbank artikelen en in diverse support tickets) dat het absoluut noodzakelijk is om formulieren altijd te beveiligen met een captcha code. Er is géén enkele reden om dit niet te doen!

Wanneer dit niet gedaan wordt, dan zal het formulier altijd misbruikt worden om spam te versturen. Met als resultaat dat de mail server op een zwarte lijst komt te staan en u (en mogelijk ook andere klanten) geen emails meer kunnen versturen. U dient dus altijd formulieren te beveiligen hiertegen! Doet u dit niet, dan zetten wij de sendmail functie t.b.v. de PHP uit inzake uw website! Wij hebben hier al talloze keren op gehamerd om dergelijke formulieren te beveiligen.

Welke formulieren dienen beveiligd te worden? Ieder formulier waar een emailadres op staat dient beveiligd te worden. Denk bijvoorbeeld aan:

• contact formulieren
• inschrijving nieuwsbrief
• reactie / reageer pagina's (ook wel comments genoemd)
• overig formulieren waar een emailadres opgegeven moet worden

Dergelijke formulieren dienen altijd afgschermd te worden. Nogmaals; er is géén enkele reden om dit niet te doen. Doet u dit niet, dan zullen wij bij misbruik de PHP sendmail functie in zijn geheel uitschakelen voor uw website. Dat wil zeggen dat men geen formulieren meer kan verzenden (en dus ook geen spam). Ondanks al onze waarschuwingen en meldingen zijn er nog altijd veel te veel websites die deze beveiliging niet doorvoeren. Resultaat? De mailserver komt op de zwarte lijst te staan en (overige) klanten kunnen geen emails meer versturen. Vervolgens kunnen wij een de-listing aanvragen voor de mailserver (wat vaak 24 uur duurt). Dit kost ons niet alleen een hoop tijd en geld, maar ook gaat dit iedere keer ten koste van de reputatie van onze IP-ranges.

Hier ook een voorbeeld van een onbeveiligd (contact) formulier:

En ja, dit formulier werd ook misbruikt om spam te versturen (enkele honderden spam emails). Ook van deze website hebben wij de PHP sendmail functie compleet uitgezet. Hierdoor werkt het contact formulier niet meer, maar zal deze ook geen spam meer versturen met alle problematiek van dien.

Dit betreft nota bene een Wordpress website, waar het heel gemakkelijk is om dergelijke formulieren kinderlijk éénvoudig af te schermen via een captcha code of een andere beveiliging. Hiervoor zijn een legio aan verschillende Wordpress plugins voor beschikbaar om dit gemakkelijk en snel te kunnen realiseren.

Ook voor "losse" formulieren (dus niet gekoppeld aan een CMS, zoals Wordpress) zijn er verschillende oplossingen beschikbaar. Zo is de meest bekendste van Google, met de naam reCAPTCHA. Zie voor meer informatie hier. Dus er is absoluut geen enkele reden om welk formulier dan ook niet te beveiligen! En nogmaals; indien uw website ons en overige klanten (herhaaldelijk) problemen bezorgd, dan zetten wij vandaag de dag gewoon de PHP sendmail functie uit. Het kost ons gewoonweg teveel tijd en energie om klanten hierop individueel te attenderen en dan af te wachten totdat er een oplossing wordt toegepast. Sterker nog; onze ervaring leert ons, dat klanten die verzuimen om formulieren te beveiligen, niet eens merken dat hun contact formulier niet meer werkt c.q. functioneert. Ook dat zegt al voldoende...

Resumé; iedere vorm van een formulier waar email mee verstuurd wordt, dient beveiligd te worden. Wordt dit niet gedaan en wij constateren misbruik (in de vorm van spam), dan zetten wij de PHP sendmail functie direct uit. Dit voorkomt niet alleen een hoop werk en kosten voor ons, maar voorkomt ook ellende voor andere klanten.

Doorverwijzing naar dit artikel via support ticket

Indien u naar aanleiding van uw support ticket naar dit Kennisbank artikel bent doorverwezen, dan is de kans zeer aannemelijk dat het formulier op uw website (herhaaldelijk) misbruikt werd/wordt om spam te versturen. Als een gevolg hiervan (en zoals u hierboven ook al heeft kunnen lezen) hebben wij dus de PHP sendmail functie compleet uitgeschakeld voor uw domein en/of webhostingaccount.

Dit zal pas wederom geactiveerd worden als u (of uw website bouwer c.q. beheerder) het probleem heeft opgelost en het (contact) formulier beveiligd heeft. Wanneer dit gebeurd is, dan kan u dit aangeven in het support ticket. Wanneer wij constateren dat dit daadwerkelijk is gebeurd en dat het formulier inderdaad is beveiligd, dan zullen wij wederom de PHP sendmail functie weer inschakelen voor uw domein en/of website.

Problemen met email verzenden en/of ontvangen

Onbeveiligde contact formulieren en/of uitgeschakelde PHP sendmail functie hebben niks te maken met problemen bij het verzenden of ontvangen van email via een email programma (op computer, laptop, tablet, telefoon e.d.) of via webmail. Indien u puur en alleen problemen heeft met het verzenden en/of ontvangen van email, dan raden wij u aan om één van de andere Kennisbank artikelen te raadplegen hierover.

Vaak is het probleem dat u verkeerde of oudere instellingen gebruikt, die vandaag de dag niet meer goed functioneren of onveilig zijn.

Tags: contact formulier, sendmail php, formulieren, onbeveiligde formulieren, captch, recaptcha

Ons online support systeem (Helpburo.eu) is 24/7 bereikbaar. Dit online support systeem wordt daarnaast ook direct gebruikt door onze technici.

Dus indien u problemen ondervindt met uw emailadres, webhosting, server of wat dan ook (wat gerelateerd is aan onze diensten en/of producten), dan kan u hiervoor altijd een support ticket voor aanmaken. Een support ticket werkt vaak vele malen sneller dan bellen of een email sturen, daar wij vaak aanvullende informatie nodig hebben bij eventuele problemen. Dit laatste is behoorlijk lastig om dit via de telefoon te doen uiteraard. Ook kan het zijn dat er screenshots worden gevraagd inzake het probleem. Ook dit is moeilijk per telefoon te realiseren. Dus vandaar dat een support ticket altijd de voorkeur heeft.

Hou ook rekening met het volgende:

Wanneer u een support ticket per email wilt beantwoorden, gebruik dan altijd hetzelfde emailadres waar u het support ticket mee heeft aangemaakt of waar deze aan geaddresseerd is. Doet u dit niet, dan wordt uw reactie niet toegevoegd aan het ticket en zien wij deze dus niet! En laat ook altijd het ticket ID in de onderwerpregel staan.

Indien een support ticket is opgelost, dan wordt deze gesloten door ons. Een support ticket wordt ook automatisch gesloten wanneer er géén reactie komt binnen afzienbare tijd. Uiteraard kan u altijd gesloten tickets opnieuw openen. U hoeft dus niet een nieuw ticket aan te maken inzake hetzelfde probleem. Wanneer dit ticket is gesloten, dan kan u deze hier opnieuw openen of door te reageren via email.

Dus wanneer u op een ticket gaat antwoorden met een ander emailadres dan in het systeem bekend is, dan wordt uw reactie niet toegevoegd aan het support ticket en zal deze niet door ons gezien worden! Bij problemen inzake de email kan u altijd uw support tickets ook online inzien; dit is sowieso de aanbevolen methode (daar reacties direct worden toegevoegd). Indien u toch een support ticket per email beantwoord, dan dient dit wel gekoppeld te staan aan uw account op Helpburo.

U kan extra emailadressen (zoals bijvoorbeeld Gmail, Outlook e.d.) gewoon toevoegen aan uw account op Helpburo. Log hiervoor in op Helpburo en ga vervolgens naar het "Mijn profiel"-tabblad. Onderaan op de nieuwe pagina kunt u extra emailadressen toevoegen. Wanneer u hier emailadressen toevoegd, dan kan u voortaan ook daarmee antwoorden op support tickets. Alleen dan kan u dus ook antwoorden met andere emailadressen op (bestaande) support tickets.

Verder is het altijd raadzaam om de kennisbank artikelen te raadplegen inzake eventuele problemen met uw website, email, hostingaccount, server of overige door ons geleverde diensten en/of producten. Vaak zijn standaard problemen of veelvoorkomende problemen al opgelost en staat dit vermeld in een dergelijke kennisbank artikel. Zo zijn 9 van de 10 emailproblemen vandaag te wijten aan verkeerde of oude instellingen. Ook tijdens het aanmaken van een support ticket geeft het Helpburo online support systeem al kennisbank suggesties aan. Controleer deze suggesties dan ook. Dit scheelt ons onnodige support tickets en kunnen wij support blijven leveren voor (echte) urgente zaken en/of problemen.

Wanneer wij een support ticket in behandeling hebben en/of ermee bezig zijn, ga dan niet de urgentie van het ticket veranderen. Dit heeft geen effect en het zal echt niet de zaak bespoedigen. Wij pakken vrijwel altijd support tickets direct op (zeker tijdens kantooruren). Daarnaast worden tickets met een verkeerde urgentie niet eerder afgehandeld. Dus als u bijvoorbeeld erachter komt na een dag dat uw website niet functioneert of dergelijke, ga dan geen support ticket inschieten met "Critical", dit werkt averechts en zorgt er alleen maar voor dat het langer duurt voordat wij uw ticket in behandeling nemen. Wij krijgen per dag tussen de 20 en 50 support tickets binnen, dus dergelijke tickets (met een verkeerde urgentie) worden vervolgens onderaan geplaatst. Hou hier rekening mee aub.

Tot slot; het is natuurlijk altijd aan te bevelen dat men de nieuwspagina (met mededelingen) controleert, alvorens met een support ticket inschiet dat een website of emailadres niet functioneert. Er is altijd een kans dat met meer dan 1000 actieve servers er ergens een technisch probleem is. Als wij dit constateren (via onze monitoring software), dan pakken wij dit altijd direct op en (indien noodzakelijk) plaatsen wij hier ook een melding van op onze nieuwspagina's.