Αρχείο κατηγορίας Development

OpenXS: ένα open-source exploit scanner για τους servers μου

Το 2025 η Way to the Web Ltd έκλεισε, και μαζί της σταμάτησε να υποστηρίζεται και το cxs (ConfigServer eXploit Scanner) – ένα εργαλείο που χρησιμοποιούσα χρόνια στους servers που διαχειρίζομαι. Το cxs συνδύαζε heuristic ανίχνευση exploits, virus scanning μέσω ClamAV, και ένα hook στο CSF firewall που έμπαζε αυτόματο ban σε IPs πίσω από κακόβουλα uploads. Ήταν proprietary και obfuscated, και πλέον χωρίς καν το licensing server του να λειτουργεί.

Αντί να ψάξω για κάποιον commercial αντικαταστάτη, αποφάσισα να φτιάξω κάτι δικό μου, ανοιχτού κώδικα. Έτσι ξεκίνησε το OpenXS.

Τι είναι

Η βασική ιδέα του OpenXS δεν είναι να φτιάξει από το μηδέν έναν ακόμα scanner, αλλά να λειτουργήσει σαν ένα harness γύρω από ήδη υπάρχοντα, ενεργά συντηρούμενα open-source projects – YARA (μέσω ενός fork του php-malware-finder), ClamAV, maldet, CSF – δίνοντάς τους ένα κοινό UX, ενιαίο reporting, quarantine και management, αντί να ζει το καθένα ξεχωριστά με το δικό του interface. Ένα Python daemon κρατάει compiled στη μνήμη το YARA ruleset και απαντάει σε scan requests μέσω ενός Unix socket, ώστε ένα upload να μην πληρώνει το κόστος αναμεταγλώττισης σε κάθε request.

Τι κάνει

  • YARA-based ανίχνευση obfuscated PHP, webshells και known exploit patterns
  • ClamAV και maldet (Linux Malware Detect) σαν επιπλέον, ανεξάρτητοι detectors
  • version checks (WordPress core, Composer packages, pending apt security updates)
  • file integrity monitoring με SHA-256 baseline σε configurable λίστα σημαντικών αρχείων
  • ανίχνευση “unknown core file” – ένα αρχείο κάτω από wp-admin/wp-includes που δεν ανήκει καθόλου στην επίσημη διανομή της εγκατεστημένης WordPress έκδοσης, ξεχωρίζοντας ένα απλό leftover από ένα upgrade που δεν ολοκληρώθηκε καθαρά από κάτι πραγματικά απροσδόκητο
  • “repair” ενέργεια που αντικαθιστά ένα modified γνωστό αρχείο (WordPress core/plugin, Composer package, Drupal core) με το official pristine περιεχόμενό του, με backup πρώτα στο quarantine
  • database content scan – σαρώνει το ίδιο το περιεχόμενο της βάσης (WordPress, Joomla/Mambo, Drupal 7) με το ίδιο YARA ruleset, για compromises που ζουν εξ ολοκλήρου μέσα στη βάση χωρίς να αγγίζουν ποτέ ένα αρχείο
  • real-time upload blocking μέσω mod_security, πριν καν αποδεχτεί ο web server το αρχείο
  • αυτόματο CSF ban σε IPs πίσω από confirmed κακόβουλα uploads
  • Webmin module για dashboard, scan history, quarantine management και εγκατάσταση με ένα κλικ

Που βρίσκεται τώρα

Το project είναι ακόμα σε πρώιμο στάδιο, αλλά τρέχει ήδη σε παραγωγή σε αρκετούς από τους servers που διαχειρίζομαι. Ο κώδικας είναι MIT licensed και δημόσιος στο GitHub:

https://github.com/mrpc/OpenXS

Αν διαχειρίζεστε κι εσείς Linux web hosting servers και ψάχνατε αντικαταστάτη για το cxs (ή απλά σας ενδιαφέρει το θέμα), ρίξτε μια ματιά – issues, feedback και pull requests είναι πάντα καλοδεχούμενα.

Το Chrome κάνει αυτόματο redirect σε https για όλα τα .dev domains

Επειδή έχασα πολύ χρόνο προσπαθόντας να καταλάβω τι γίνεται, αποφάσισα να το μοιραστώ.

Για το local development, χρησιμοποιώ virtual machines που τρέχουν με vagrant. Για να δουλέψω σε αυτά, στήνω ψεύτικα hosts (στο αρχείο htaccess) του τύπου “project.dev” ή “project.test”  και με αυτό τον τρόπο κάνω όλες τις δοκιμές μου εδώ και αρκετό καιρό.

Σήμερα λοιπόν προσπάθησα να ανοίξω ένα τέτοιο vm, έστω το “project.dev” και διαπίστωσα ότι δε φόρτωνε με τίποτα γιατί ο Chrome έκανε αυτόματα redirect στο https://project.dev – το οποίο δεν έπαιζε χωρίς certificate.

Αφού έχασα αρκετό χρόνο νομίζοντας ότι κάτι δεν πήγαινε καλά με το vm, τελικά βρήκα την αιτία εδώ: Chrome 63 forces .dev domains to HTTPS via preloaded HSTS.

Ο τρόπος που το κάνει είναι ότι έχει περάσει το .dev eTLD σε μια λίστα που έρχεται προφορτωμένη με τον Chrome με γνωστά site που χρησιμοποιούν το HSTS header (υπάρχει εδώ).

Η λύση που προτείνουν στο άρθρο που διάβασα είναι να αλλάξουν όλα τα vm και να χρησιμοποιούν άλλο eTLD (όπως π.χ. το .test που προανέφερα).

Happy coding

NetBeans Day Athens 2016

Στις 26 Αυγούστου θα πραγματοποιηθεί στην Αθήνα ημερίδα σχετικά με το NetBeans.

Για όσους δε γνωρίζουν, το NetBeans είναι ένα φανταστικό IDE, αρχικά για Java, αλλά αργότερα έγινε εξαιρετική επιλογή και για Web Development – είναι ένα πολύ δυνατό εργαλείο για προγραμματισμό σε PHP, αλλά και javascript, html5 κλπ.  Υποστηρίζει όλες τις σύγχρονες βιβλιοθήκες, έχει ένα μεγάλο οικοσύστημα με plugins για συνεργασία με εξωτερικά εργαλεία (Bug trackers, version control systems, continuous integration systems κλπ) και φυσικά είναι open source.

Προφανώς θα είμαι εκεί, είναι μια ευκαιρία μεταξύ των άλλων για γνωριμία με ανθρώπους που μιλάμε εδώ και κάποια χρόνια στην κοινότητα του Netbeans (εδώ και κάποια χρόνια συμμετέχω σταθερά στην ομάδα NetCat που κάνει όλο το testing του NetBeans).

Παραθέτω την ανακοίνωση. Για περισσότερες πληροφορίες και δήλωση συμμετοχής κάντε κλικ εδώ.

Οι ημερίδες NetBeans λαμβάνουν χώρα σε διάφορες χώρες ανά τον κόσμο, από το JavaOne2014, όπου συνελήφθη η ιδέα. Πρόκειται για θέματα που αφορούν το NetBeans IDE και την πλατφόρμα NetBeans Rich Client, καθώς και τη γλώσσα προγραμματισμού Java (αλλά και άλλες γλώσσες που υποστηρίζονται από το NetBeans).

Η Κοινότητα του NetBeans σε συνεργασία με τον Κόμβο Καινοτομίας και Επιχειρηματικότητας της Τεχνόπολης Δήμου Αθηναίων, σας προσκαλούν στις 26 Αυγούστου σε μια ελεύθερη εκδήλωση σχετικά με το NetBeans IDE και την πλατφόρμα NetBeans Rich Client. Θα έχετε την ευκαιρία να ενημερωθείτε για τις τελευταίες εξελίξεις σχετικά με το NetBeans IDE και την πλατφόρμα NetBeans από ειδικούς του χώρου.

Ημερήσια διάταξη:

9:00-9:30: Εγγραφές, καφές

9:30-10:00: Welcome and NetBeans roadmap (Geertjan Wielenga: NetBeans Product Manager, Oracle)

10:00-11:30: Oracle JET – workshop (Geertjan Wielenga: NetBeans Product Manager, Oracle)

11:30-12:00: NetBeans and Java 9 support (Geertjan Wielenga)

12:00-13:00: Μεσημεριανό διάλειμμα

13:00-14:30: Developing mixed Java/Groovy projects with Gradle using Netbeans – workshop (Κώστας Σαϊδής: Niovity)

14:30-15:15: WildFly and Openshift plugins for NetBeans – workshop (Emmanuel Hugonnet: RedHat)

15:15-15:30: Διάλειμμα

15:30-16:15: Othelo game using NetBeans, Swing and Artificial Intelligence (ΔημήτριοςΜενδρινός)

16:15-17:00: Converting a Swing application to JavaFX and Dukescript – workshop (ΓιάννηςΚωστάρας)

16:45-17:30: NetBeans for PHP developers; real world examples (Αλέξης Διακογιάννης)

Εγκατάσταση πολλών εκδόσεων της php στον ίδιο server

php1Έχω ένα dedicated server στον οποίο τρέχω PHP 5.2, για λόγους συμβατότητας με κάποιες παλιές εφαρμογές. Πλέον όμως αυτή η έκδοση είναι ξεπερασμένη, οπότε έψαχνα να βρω μια λύση ώστε να τρέχω διαφορετικές εκδόσεις της PHP ανάλογα με το site.

Το cpanel/whm έχει πολύ ωραία εργαλεία για την αυτόματη εγκατάσταση της έκδοσης που θέλουμε και τα κάνει όλα να φαίνονται πολύ εύκολα, αλλά δυστυχώς επιτρέπει μόνο μια PHP έκδοση. Παρ’  όλα αυτά, σε πολλές hosting εταιρείες με cPanel, οι χρήστες μπορούν να αλλάζουν εκδόσεις της php μέσα από απλές εντολές στο .htaccess. Πως γίνεται αυτό;

Ψάχνοντας λίγο είδα ότι μπορείς ουσιαστικά να τρέξεις όσες διαφορετικές εκδόσεις της PHP θέλεις, αν την τρέχεις μέσω suPHP, CGI ή FastCGI. Ο server έτσι κι αλλιώς είναι στημένος με suPHP για λόγους ασφαλείας, οπότε τα πράγματα από εκεί και πέρα είναι σχετικά εύκολα.

Η ιδέα είναι ότι εγκαθιστούμε την κάθε έκδοση σε δικό της directory, και μετά για κάθε account λέμε ποια έκδοση της php θέλουμε να τρέξει, ή αν δεν το διευκρινίσουμε, τρέχει την default του cpanel (αν δεν το πειράξουμε και αυτό).

Ας πούμε λοιπόν ότι έχουμε στο server την 5.2.κάτι και θέλουμε να περάσουμε και την 5.5.3. Μέσω ssh κάνουμε login ως root και δίνουμε:

# cd /usr/src
# wget http://gr2.php.net/distributions/php-5.5.3.tar.gz
# tar xfz php-5.5.3.tar.gz
# cd php-5.5.3

Με άλλα λόγια, κατεβάζουμε το release που θέλουμε στο φάκελο /usr/src και το αποσυμπιέζουμε. Όλα τα αρχεία περνάνε στο φάκελο /usr/src/php-5.5.3.

Τώρα δίνουμε κάτι σαν:

# ./configure \
 --enable-bcmath \
 --enable-calendar \
 --enable-exif \
 --enable-ftp \
 --enable-gd-native-ttf \
 --enable-libxml \
 --enable-mbstring \
 --enable-pdo=shared \
 --enable-soap \
 --enable-sockets \
 --prefix=/opt/php55 \
 --with-bz2 \
 --with-config-file-path=/opt/php55/lib \
 --with-config-file-scan-dir=/opt/php55/lib/php.ini.d \
 --with-curl=/opt/curlssl/ \
 --with-freetype-dir=/usr \
 --with-gd \
 --with-gettext \
 --with-imap=/opt/php_with_imap_client/ \
 --with-imap-ssl=/usr \
 --with-jpeg-dir=/usr \
 --with-kerberos \
 --with-libxml-dir=/opt/xml2 \
 --with-libxml-dir=/opt/xml2/ \
 --with-mcrypt=/opt/libmcrypt/ \
 --with-mysql=/usr/ --with-libdir=lib64 \
 --with-mysql-sock=/var/lib/mysql/mysql.sock \
 --with-mysqli=/usr/bin/mysql_config \
 --with-openssl=/usr \
 --with-openssl-dir=/usr \
 --with-pcre-regex=/opt/pcre \
 --with-pdo-mysql=shared \
 --with-pdo-sqlite=shared \
 --with-png-dir=/usr \
 --with-pspell \
 --with-xpm-dir=/usr \
 --with-zlib \
 --with-zlib-dir=/usr

για να ορίσουμε το configuration με το οποίο θα γίνει η εγκατάσταση της php. Προφανώς αυτό το προσαρμόζει ο καθένας στα μέτρα του, οι διάφοροι παράμετροι ορίζουν ποια extensions της php θέλουμε να εγκαταστήσουμε κ.λ.π. Στις δικές μου επιλογές έχω ορίσει ότι η εγκατάσταση θα γίνει στον φάκελο /opt/php55.

Όταν ολοκληρωθεί η διαδικασία, υποθέτοντας ότι όλα πήγαν καλά, δίνουμε:

# make

και μετά

# make install

Αν πάλι όλα πάνε καλά, έχουμε εγκαταστήσει τη νέα έκδοση της php στον κατάλογο /opt/php55.

Τώρα πρέπει να ρυθμίσουμε το αρχείο php.ini για αυτή την έκδοση. Ένα γρήγορο configuration είναι αυτό:

# cp php.ini-production /opt/php55/lib/php.ini

που αντιγράφει τις default ρυθμίσεις. Αν θέλουμε επιπλέον αλλαγές, μπορούμε να τις κάνουμε πειράζοντας αυτό το αρχείο:

# vi /opt/php55/lib/php.ini

Επόμενο βήμα είναι να ορίσουμε την php 5.5. σαν handler στο suPHP και στον apache. Δίνουμε:

# vi /opt/suphp/etc/suphp.conf

Προς το τέλος θα δείτε κάτι σαν:

application/x-httpd-php5="php:/usr/bin/php"

Ακριβώς κάτω από αυτό προσθέτουμε:

application/x-httpd-php55="php:/opt/php55/bin/php-cgi"

Αποθηκεύουμε, και πηγαίνουμε να επεξεργαστούμε και το configuration του apache

# vi /etc/httpd/conf/php.conf

Πάλι, κάπου προς το τέλος θα βρούμε κάτι σαν:  suPHP_AddHandler application/x-httpd-php5. Κάτω από αυτό, προσθέτουμε το:

suPHP_AddHandler application/x-httpd-php55

Κάνουμε και ένα restart στον apache και είμαστε έτοιμοι (στο centos δίνουμε # service httpd restart).

Τώρα, σε όποιο site θέλουμε να τρέξουμε τη νέα έκδοση της php, κάνουμε μια επεξεργασία στο .htaccess και προσθέτουμε πάνω – πάνω αυτή τη γραμμή:

AddHandler application/x-httpd-php55 .php

και πλέον το site θα τρέχει με τη νέα έκδοση της php.

Το επόμενο βήμα είναι βασικά να κάνουμε το αντίστροφο, η default έκδοση να είναι η 5.5 και κάποια site να μπορούν προαιρετικά να γυρίσουν στην 5.2, αλλά νομίζω ότι αυτό ήταν αρκετό για σήμερα 😀

pcre.backtrack_limit

Σε ένα από τα project που δουλεύω, έχω φτιάξει ένα μικρό parser για τα templates. Ουσιαστικά έχει διάφορα conditions (π.χ. ISHOME αν είναι η αρχική σελίδα, REGISTERED αν ο χρήστης έχει κάνει login κλπ). Αυτά τρέχουν με regular expressions απλά και γρήγορα.

Όλα δούλευαν ρολόι, μέχρι που σε κάποιο template ένα από τα regular expression σταμάτησε να δουλεύει, χωρίς όμως κάποιο notice, warning ή error. Μάλιστα αυτό γίνονταν μόνο στο laptop μου και όχι στον desktop υπολογιστή.

Μετά από λίγο σκάλισμα, αποφάσισα να τρέξω την preg_last_error() ώστε να δω αν υπάρχει κάποιο λάθος που για κάποιο λόγο δεν εμφανίζεται στα warnings της php. Και είχα δίκιο, η εντολή μου επέστρεφε την τιμή 2 που ισούται με το PREG_BACKTRACK_LIMIT_ERROR, κάτι που δεν μου είχε ξανατύχει.

Ψάχνοντας λίγο ακόμα, βρήκα την ρύθμιση pcre.backtrack_limit που υπάρχει από την PHP 5.2, και στις τελευταίες εκδόσεις η προεπιλογή είναι 1000000, αλλά πριν την 5.3.7 ήταν το ένα δέκατο (100000).

Στο συγκεκριμένο template που έτρεχα, είχα ένα πολύ μεγάλο κομμάτι html κώδικα μέσα σε ένα tag [ISHOME][/ISHOME]. Επειδή ήταν πολύ μεγάλο, αυτό το συγκεκριμένο όριο χτυπούσε και σταματούσε την εκτέλεση του regular expression, χωρίς όμως να χτυπάει ο υπόλοιπος κώδικας. Και ο λόγος που γίνονταν μόνο στο laptop είναι ότι έτρεχα πιο παλιά έκδοση της php.

Η λύση βέβαια ήταν κάτι τόσο απλό:

ini_set('pcre.backtrack_limit', '1000000');

και για να έχω και τη συνείδηση μου ήσυχη, το έκανα τελικά κάπως έτσι:

$backtrack_limit = ini_get('pcre.backtrack_limit');
 if ($backtrack_limit < 1000000){
 ini_set('pcre.backtrack_limit', '1000000'); 
 }
// εδώ μπήκε ο κώδικας με τα regular expressions
ini_set('pcre.backtrack_limit', $backtrack_limit);

Αν ποτέ αντιμετωπίσετε κάτι ανάλογο, αυτή είναι μια λύση.

PHP Tips – Freestuff Tutorial

FreeStuff.grΣε όλα τα site για προγραμματιστές είναι δημοφιλή τα άρθρα του τύπου “10 συμβουλές για να κάνετε τον κώδικα σας πιο γρήγορο / πιο ασφαλή” κ.λ.π. Σκέφτηκα να κάνω κάτι τέτοιο για το freestuff.gr, με απλά tips που μπορεί να φανούν χρήσιμα σε κάποιους. Έτσι μάζεψα μερικές συμβουλές που έρχονται κυρίως από προσωπική εμπειρία, πιθανόν σε κάποια από αυτά να υπάρχει και αντίλογος, αλλά ακόμα και έτσι μπορεί να γίνουν αφορμή για συζήτηση.

Διαβάστε το βοήθημα στο  Freestuff.gr: PHP Tips.