CyberCr33p

Ο μισθός του είναι εντάξει; Γιατί μετά τις 22:00 υπάρχει προσαύξηση: https://www.kepea.gr/aarticle.php?id=217

Είτε το χαρακτηρίσουμε ως DDoS είτε ως κάτι άλλο, τα δεδομένα παραμένουν τα ίδια. Το "facebookexternalhit" δεν εκτελεί τη λειτουργία για την οποία υποτίθεται ότι προορίζεται, αλλά, καμουφλαρισμένα, χρησιμοποιείται για να εκπαιδεύσει το AI τους. Στέλνει χιλιάδες αιτήματα ανά λεπτό σε κάθε domain από πολλαπλές IP, προς τυχαία URL, συμπεριλαμβανομένων και πολύ παλιών που κανένας δεν θα επισκεπτόταν, και συχνά στο ίδιο URL επαναλαμβανόμενα. Eίναι δηλαδή και κακοσχεδιασμένο, αφού η συγκαλυμμένη λειτουργία του δεν εκτελείται σωστά, επαναλαμβάνοντας αιτήματα στα ίδια URL. Αντιθέτως, τα υπόλοιπα bots που βασίζονται σε AI, παρά το γεγονός ότι μπορεί να είναι ενοχλητικά, διαθέτουν συγκεκριμένο user-agent, που σου επιτρέπει να τα μπλοκάρεις εύκολα αν το επιθυμείς.

Το Facebook συχνά προκαλεί μια μορφή DDoS επίθεσης (http flood) σε διάφορους ιστότοπους, συνδεόμενο τυχαία σε χιλιάδες άρθρα (αν πρόκειται για ειδησεογραφική ιστοσελίδα) ή σε χιλιάδες προϊόντα (αν πρόκειται για e-shop). Το αποτέλεσμα είναι να καταναλώνονται υπερβολικοί πόροι σε σύντομο χρονικό διάστημα, καθώς μπορούν να σημειωθούν εκατοντάδες ή και χιλιάδες αιτήματα μέσα σε λίγα λεπτά. Συνήθως, όταν εμφανίζεται αυτό το πρόβλημα, παρατηρείται ότι πάνω από το 60-80% των ημερήσιων requests προέρχονται από τον user-agent "facebookexternalhit", ενώ το υπόλοιπο 20-40% είναι κανονικές επισκέψεις και άλλα καλά bots (Googlebot, Bing, κ.λπ.). Επιπλέον, σε τέτοιες περιπτώσεις το Facebook ενδέχεται να στέλνει δεκάδες ταυτόχρονα αιτήματα στο ίδιο URL, ακόμα και αν τα προηγούμενα έχουν ήδη επιστρέψει status code 200. Αυτός ο καταιγισμός αιτημάτων μπορεί να οδηγήσει σε καθυστερήσεις ή και διακοπή λειτουργίας (downtime), ακόμα και σε αξιόλογου επιπέδου hosting χωρίς περιορισμούς από το CloudLinux. Ο user-agent "facebookexternalhit" υποτίθεται ότι χρησιμοποιείται, βάσει της περιγραφής του ίδιου του Facebook, όταν κάποιος μοιραστεί έναν σύνδεσμο στο Facebook, ώστε να ανακτήσει τον τίτλο και την εικόνα για την προεπισκόπηση του άρθρου, τα οποία κατόπιν αποθηκεύονται σε cache. Ωστόσο, φαίνεται ξεκάθαρα πως το Facebook χρησιμοποιεί τον ίδιο user-agent για την εκπαίδευση του AI του, παρότι θεωρητικά υπάρχει άλλος user-agent ("meta-externalagent") για αυτόν τον σκοπό. Η πιο λογική εξήγηση για τη χρήση του “facebookexternalhit” για εκπαίδευση του ΑΙ τους είναι ότι οι webhosts αδυνατούν να το αποκλείσουν εντελώς, καθώς κάτι τέτοιο θα εμπόδιζε την εμφάνιση της προεπισκόπησης (τίτλος και εικόνα) όταν κοινοποιείται ένα URL στο Facebook. Με άλλα λόγια, το Facebook εκμεταλλεύεται την ανάγκη των πελατών των webhosts να εμφανίζονται σωστά τα δημοσιευμένα ποστ τους, αναγκάζοντάς τους να δέχονται αυτά τα μαζικά αιτήματα. Επίσης είναι ξεκάθαρο ότι αυτό αποτελεί μορφή διαδικτυακού "εκβιασμού". Η μοναδική, ας το πούμε, "λύση" είναι η εφαρμογή rate limiting. Σε περίπτωση που η κατάσταση κλιμακωθεί υπερβολικά, αποκλείουμε προσωρινά ορισμένα από τα αιτήματα, προστατεύοντας έτσι τους servers από υπερφόρτωση και τις ιστοσελίδες από καθυστερήσεις ή και διακοπές λειτουργίας. Το συγκεκριμένο πρόβλημα με τις «επιθέσεις DDoS» από το Facebook υφίσταται πάνω από έναν χρόνο σε πολλούς ιστότοπους, είτε πρόκειται για e-shops είτε για ειδησεογραφικά sites. Από την περίοδο της πανδημίας Covid και έπειτα, το Facebook έχει καταργήσει το τμήμα τεχνικής υποστήριξής του, οπότε δεν είναι εφικτό να επικοινωνήσει κανείς με κάποιον εκπρόσωπό του. Πολλοί έχουν δημοσιεύσει για το ζήτημα σε forum του Facebook, όμως η εταιρεία δεν δείχνει να ενδιαφέρεται για το πρόβλημα που προκαλεί και δεν έχει απαντήσει σε κανέναν. Εξάλλου γιατί να ασχοληθούν όταν αυτοί για να συνδεθούν με το "facebookexternalhit" χρειάζονται ελάχιστους πόρους για το κάθε request από τη δικιά τους υποδομή, ενώ από την πλευρά της υποδομής που φιλοξενείται η σελίδα χρειάζονται πολλές φορές περισσότεροι πόροι. Ενδεικτικά στέλνω κάποια links με αναφορές για αυτό το πρόβλημα: 1. https://www.facebook.com/groups/WordPressGreekCommunity/posts/8063658323657310/ 2. https://developers.facebook.com/support/bugs/1894024420610804/ 3. https://developers.facebook.com/support/bugs/385275384858817/ 4. https://stackoverflow.com/questions/9773954/why-facebook-is-flooding-my-site 5. https://webmasters.stackexchange.com/questions/113178/facebook-crawler-with-no-user-agent-spamming-our-site-in-possible-dos-attack 6. https://developers.facebook.com/community/threads/752652313583613/ 7. https://developers.facebook.com/community/threads/1101311951307153/ 8. https://developers.facebook.com/community/threads/3050340598328665/ 9. https://developers.facebook.com/community/threads/1396267727883151/ 10. https://developers.facebook.com/community/threads/974370274080457/ 11. https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/issues/577

Στα .gr, η αλλαγή καταχωρητή ολοκληρώνεται άμεσα, η ημερομηνία λήξης παραμένει η ίδια και δεν υπάρχει κόστος. Στα .eu, η αλλαγή καταχωρητή ολοκληρώνεται άμεσα, γίνεται παράλληλα ανανέωση για 1 έτος, οπότε υπάρχει το κόστος της ανανέωσης. Στα .com, η αλλαγή καταχωρητή συνήθως ολοκληρώνεται σε 5-7 ημέρες, γίνεται παράλληλα ανανέωση για 1 έτος, οπότε υπάρχει το κόστος της ανανέωσης. Επομένως, καλό είναι η διαδικασία να ξεκινάει τουλάχιστον 10 ημέρες πριν από τη λήξη. Η διαδικασία μπορεί να ξεκινήσει και 1-2 ημέρες πριν τη λήξη ή ακόμα και μετά τη λήξη, αλλά σε αυτή την περίπτωση, για όσο διάστημα είναι "ληγμένο," το domain δεν θα λειτουργεί και θα αρχίσει να λειτουργεί ξανά μετά την αλλαγή του καταχωρητή, όταν θα ανανεωθεί αυτόματα.

Πράγματι εξαρτάται από την τράπεζα που έχει εκδώσει τη κάρτα. Συνήθως παίρνει 5-10 εργάσιμες ημέρες.

Όση διερεύνηση και να κάνεις ο αρμόδιος να απαντήσει είναι ο webhost σου. Μόνο αυτός ξέρει εάν και πότε θα κάνουν αναβάθμιση στη MySQL. Έτσι και αλλιώς η υποστήριξη της προηγούμενης σειράς έχει τελειώσει πριν από περισσότερο από ένα έτος, οπότε εάν υπάρξει κάποιο σοβαρό κενό ασφαλείας τι θα κάνουν; Πάντως δεν θα έπρεπε να σε απασχολεί η αναβάθμιση διότι είναι βέβαιο ότι το WordPress σου θα είναι συμβατό. Δεν γνωρίζω τι κάνουν άλλοι webhosts στην Ελλάδα, πάντως εξωτερικό έχω πετύχει webhosts και με εκδόσεις 5.5 και 5.6. Εμείς την αναβάθμιση από 5.7 σε 8.0 την είχαμε κάνει αρχές του 2022 και δεν συναντήσαμε κάποιο ιδιαίτερο πρόβλημα. Όμως το είχαμε ψάξει πολύ πριν την αναβάθμιση και ξέραμε τι έπρεπε να κάνουμε μετά την αναβάθμιση για τις περισσότερες σελίδες που ήταν σε παλιές εκδόσεις, κυρίως Joomla 1.5 & 2.5, Drupal 6 & 7, και παλαιότερες εκδόσεις CsCart, Prestashop και Opencart. Kάποιες από τις σημειώσεις που έχω κρατήσει τις έχω δημοσιεύσει στο:

Κανονικά πρέπει να ενημερώσουν εκ των προτέρων γιατί έτσι και αλλιώς κατά την αναβάθμιση θα υπάρξει downtime όπως επίσης ίσως να υπάρξουν μετά την αναβάθμιση και προβλήματα με παλαιότερες εκδόσεις εφαρμογών. Αλλά γιατί δεν ρωτάς τον πλέον αρμόδιο να σου δώσει απάντηση, δηλαδή τον webhost σου;

Θα σε πληρώνουν μόνο τους εργάσιμους μήνες ή θα σε πληρώνουν και το μήνα που θα έχεις άδεια;

Στα .gr domains πάντα τα στοιχεία του ιδιοκτήτη (ή καλύτερα φορέα μιας και τα domains δεν έχουν ιδιοκτήτες) ήταν κρυφά. Το ίδιο ισχύει με την άφιξη του GDPR και στις υπόλοιπες καταλήξεις που δεν τα είχαν κρυφά μέχρι τότε.

Ναι την κάνουμε εμείς δωρεάν.

Οι web hosts συνήθως προσφέρουν υποστήριξη για πολλές εκδόσεις PHP, δίνοντας στους χρήστες τη δυνατότητα να επιλέξουν την έκδοση που είναι συμβατή με την ιστοσελίδα τους. Για όσους χρησιμοποιούν CloudLinux, τα patches για τις παλαιότερες εκδόσεις PHP παρέχονται από την ίδια την CloudLinux. Όσοι, όπως εμείς, δεν χρησιμοποιούν CloudLinux, συχνά κάνουν μόνοι τους το backporting των patches ώστε οι παλαιότερες εκδόσεις της PHP, που πλέον δεν υποστηρίζονται επίσημα, να παραμένουν ασφαλείς. Όσο αφορά την MySQL o κάθε server συνήθως υποστηρίζει μόνο μία έκδοση. Αυτό σημαίνει ότι, κάποια στιγμή, οι web hosts θα αναβαθμίσουν από την έκδοση 5.7 στην 8.0, καθώς η Oracle έχει ήδη διακόψει από πέρυσι την υποστήριξη της 5.7. Η αναβάθμιση από την έκδοση 5.7 στην 8.0 περιλαμβάνει το σταμάτημα του MySQL server, την εγκατάσταση της νέας έκδοσης και την εκκίνηση του MySQL server. Ο MySQL server στη συνέχεια θα προσαρμόσει αυτόματα τη δομή των δεδομένων ώστε να είναι συμβατά με την 8.0. Σε περίπτωση προβλήματος, θα χρειαστεί να γίνει επαναφορά από ένα sql dump που δημιουργήθηκε πριν από την αναβάθμιση. Όμως, έχω παρατηρήσει πως αρκετοί web hosts εξακολουθούν να χρησιμοποιούν την έκδοση MySQL 5.7, και πιστεύω ότι αυτό οφείλεται στο γεγονός ότι δεν θέλουν να επιβαρύνουν το τμήμα τεχνικής υποστήριξης με επιπλέον αιτήματα από πελάτες, λόγω του ότι κάποιες παλιότερες εφαρμογές θα σταματήσουν να λειτουργούν σωστά μετά από αναβάθμιση. Γενικά τα WordPress δεν έχουν πρόβλημα, θα συνεχίσουν να δουλεύουν κανονικά και με την MySQL 8.0. Σε κάποια παλιές εκδόσεις άλλων εφαρμογών χρειάζεται να γίνουν κάποιες τροποποιήσεις στον κώδικα και συνήθως αφορούν "reserved words" που έχουν προστεθεί στην MySQL 8.0. Για παράδειγμα σε Joomla 2.5 χρειάζεται να τρέξεις την παρακάτω εντολή για να προσθέσει ` ` στη λέξη groups: sed -i "" -e "s|AS groups|AS `groups`|g" ./components/com_content/models/category.php ./components/com_content/models/archive.php ./components/com_content/models/article.php ./components/com_content/models/frontpage.php ./components/com_content/models/section.php Σε CS Cart (παλιά έκδοση) χρειάζεται να ενεργοποιήσεις το debug στο config.php του ώστε να δεις ποια queries "χτυπάνε" ώστε να κάνεις τις κατάλληλες μετατροπές. Σε OpenCart (παλιά έκδοση) στο αρχείο system/library/db/mysqli.php χρειάζεται να αλλάξεις το: $this->connection->query("SET SESSION sql_mode = 'NO_ZERO_IN_DATE,NO_ZERO_DATE,NO_ENGINE_SUBSTITUTION'"); με: $this->connection->query("SET SESSION sql_mode = 'NO_ZERO_IN_DATE,NO_ENGINE_SUBSTITUTION'"); Σε Drupal (παλιά έκδοση) στο includes/database/mysql/database.inc αφαιρείς σε ένα σημείο που έχει την λέξη: NO_AUTO_CREATE_USER Γενικά, επειδή μετά την αναβάθμιση από την έκδοση 5.7 στην 8.0 δεν υπάρχει δυνατότητα επιστροφής στην 5.7 χωρίς επαναφορά από αντίγραφο ασφαλείας, είναι απαραίτητος από πλευράς web host ο προσεκτικός σχεδιασμός και οι δοκιμές για να εξασφαλιστεί ότι η διαδικασία θα ολοκληρωθεί με όσο το δυνατόν λιγότερα προβλήματα.

Συμφωνώ και εγώ. Έχουν πλέον καταντήσει τα κινητά σαν tablet και δεν έχουμε πλέον επιλογές για μικρότερες συσκευές.

Μόνο έναν ελληνικό webhost γνωρίζω που δεν παρέχει Let's Encrypt. Όπου αλλού και να κοιτάξεις το υποστηρίζουν οπότε δεν θα δυσκολευτείς να βρεις κάποιον να καλύπτει αυτό το απαιτούμενο. Σχετικά με τα domains, επειδή υπάρχουν καταχωρητές που χρεώνουν πολύ κοντά στο κόστος τότε χρειάζεται να έχεις υπό τη διαχείριση σου αρκετά domains για να αρχίσει να σε συμφέρει να γίνεις ο ίδιος καταχωρητής. Ας υποθέσουμε ότι τα παίρνεις από καταχωρητή που τα χρεώνει 13,28 ευρώ τότε έχουμε: 257 domains x 13,28 ευρώ = 3.412,50 ευρώ / 2 έτη = 1.706,25 ευρώ κόστος ανά έτος Εάν γίνεις ο ίδιος καταχωρητής: 257 domains x 12,50 ευρώ + 200 ευρώ (τα τέλη) = 3.412,50 ευρω / 2 έτη = 1.706,25 ευρώ κόστος ανά έτος Επομένως στα 257 domains είσαι ίσα βάρκα ίσα πανιά. Ας υποθέσουμε τώρα ότι έχεις 500 domains και τα παίρνεις από άλλον καταχωρητή που τα χρεώνει 13,28 ευρώ: 500 domains x 13,28 ευρώ = 6.640 ευρώ / 2 έτη = 3.320 ευρώ κόστος ανά έτος Και εάν γίνεις ο ίδιος καταχωρητής: 500 domains x 12,50 ευρώ + 200 ευρώ (τα τέλη) = 6.450 ευρώ / 2 έτη = 3.225 ευρώ κόστος ανά έτος Και έτσι θα έχεις όφελος: 3.320 ευρώ - 3.225 ευρώ = 95 ευρώ όφελος ανά έτος, δηλαδή κάτι λιγότερο από 8 ευρώ το μήνα. Καταλαβαίνεις ότι πρέπει να έχεις πολλά domains για να αρχίσει να συμφέρει να είσαι καταχωρητής χωρίς να υπολογίζουμε και το ετήσιο κόστος για άδεια χρήστης του λογισμικού που θα χρειάζεσαι για τη διαχείριση των domains ή του χρόνου που θα απαιτηθεί για να φτιάξεις δικό σου και να το αναβαθμίζεις όταν θα απαιτηθεί κάποια αλλαγή (π.χ. όπως για τελευταία φορά έγινε στις 25/08/2024). Και επίσης υπάρχουν και κάποιες υποχρεώσεις που μπορείς να τις διαβάσεις στο άρθρο 17 του ΦΕΚ που ανέβασα. Επίσης κάποιοι καταχωρητές παρέχουν API που μπορεί να συνδεθεί με οποιαδήποτε εφαρμογή ή ακόμα και WHMCS module για να έχεις την διαχείριση των domains (καταχωρήσεις, ανανεώσεις, αλλαγή στους nameservers, αλλαγή στα στοιχεία ιδιοκτήτη, κλπ) μέσα από δικό σου WHMCS. 2908-B-2024.pdf

Ναι συνεχίζεις κανονικά με τον τρόπο που εκδίδεις τώρα τα παραστατικά.

Έχει συμβεί ξανά στο παρελθόν μεταξύ Deutsche Telekom και Hetzner: http://web.archive.org/web/20170610010122/http://wiki.hetzner.de/index.php/Double_Paid_Traffic/en