Into.the.Void.

Χρησιμοποιώντας πριν 2 μέρες το νέο σύστημα ηλεκτρονικής κράτησης εισητηρίων του ΟΣΕ αντιμετώπισα το εξής παράδοξο. Μετά την επικύρωση της πιστωτικής μου κάρτας και αφού είχα δώσει και τα ονόματα των συνεπιβατών μου, το σύστημα μου ζητούσε να δώσω μια “μυστική φράση-κλειδί” που θα την ήξερα μόνο εγώ και ο ελεγκτής των εισητηρίων. Αδυνατούσα να καταλάβω που χρειάζεται αυτό και έτσι την επόμενη μέρα το απόγευμα (στις 18:00) έστειλα ένα email στην διεύθυνση που αναφέρει το website ζητώντας πληροφορίες για το κλειδί.

Το email μου:

Καλησπέρα

καταρχήν συγχαρητήρια για το σύστημα online κράτησης εισητηρίων. Ήταν κάτι που χρειαζόταν εδώ και χρόνια.

Έχω μια απορία όμως, ποιά είναι η λογική πίσω από την χρήση “μυστικής φράσης-κλειδί” ? Εφόσον το εισητήριό μου αναφέρει επάνω τον κωδικό του, έχει το ονομά μου και θα έχω και εγώ ταυτότητα επάνω μου…τι επιπλέον προσθέτει στην ασφάλεια του ΟΣΕ αυτή η φράση ?

Με τιμή,

Στις 21:50 (!!!!) την ίδια μέρα πήρα την εξής απάντηση:

Καλησπέρα,

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

Κατ’ αυτό τον τρόπο μπορείτε να εξασφαλίσετε την αγορά σας σε περίπτωση που κάποιος αντιγράψει το εισιτήριο σας ή το τυπώσει (πράγμα καθόλου δύσκολο *) και ανεβεί στο τρένο προσποιούμενος ότι είστε εσείς. Στην περίπτωση αυτή αν και οι δύο δεν φέρετε ταυτότητα ή πιστωτική κάρτα, μόνο ο μυστικός κωδικός μπορεί να ξεδιαλύνει την κατάσταση, ο οποίος κωδικός βρίσκεται τυπωμένος μόνο στην λίστα που έχει ο ελεγκτής.

* το παρόν σύστημα έχει σχεδιαστεί με την λογική ότι κάποιοι και θα τυπώσουν εισιτήρια 3ων πέρα από τα δικά τους και θα προσπαθήσουν να τα χρησιμοποιήσουν, και ότι κάποιοι άλλοι θα τα φωτοτυπήσουν / Photoshop-άρουν. Οπότε το “τί πληροφορία είναι μοιρασμένη σε ποιο έγγραφο” είναι πολύ προσεκτικά σχεδιασμένο.

Σε κάθε περίπτωση, η εισαγωγή του “μυστικού κλειδιού” είναι προαιρετική για την αγορά του εισιτηρίου.

Με εκτίμηση,

Δεν θα σχολιάσω την εξήγηση που πήρα, αλλά το γεγονός πως κάποιος από το δημόσιο τομέα μου απάντησε σε email την ίδια μέρα και μάλιστα βράδυ. Εκπληκτικό!

Filed by kargig at 11:05 under Greek,Privacy
Tags: Ελλάδα, κλειδί, ΟΣΕ, τραίνο, ΤΡΑΙΝΟΣΕ, τρένο, φράση
17 Comments | 14,353 views

A sample config for PPPoE clients connecting to a Cisco BRAS. The following example uses Stateless Address Autoconfiguration (SLAAC) to provide an IPv6 /64 subnet to clients on their PPP interface and DHCPv6 for Prefix Delegation in order to provide to a /56 subnet to them.

ipv6 unicast-routing
ipv6 general-prefix ISP-PREFIX 2001:DB8:BBBB::/48
ipv6 cef
ipv6 dhcp pool v6dhcppool
prefix-delegation pool v6prefixpool2
dns-server 2001:DB8:DDDD::1
dns-server 2001:DB8:EEEE::1
sip address 2001:DB8:CCCC::1
sip domain-name ipv6-test.example.com
Interface FastEthernet0/0.100
[ snip ]
ipv6 address ISP-PREFIX ::1:0:0:0:1/64
ipv6 enable
ipv6 mtu 1492
ipv6 nd reachable-time 30
ipv6 nd ra-interval 10
ipv6 nd ra-lifetime 3600
ipv6 nd prefix 2001:DB8:AAAA:2222::/64 86400 3600 off-link
ipv6 nd other-config-flag
ipv6 dhcp server v6dhcppool
!
Interface Virtual-Template1
[ snip ]
ipv6 unnumbered FastEthernet0/0.100
ipv6 enable
ipv6 mtu 1480
ipv6 nd reachable-time 30
ipv6 nd ra-interval 10
ipv6 nd ra-lifetime 3600
ipv6 nd prefix default infinite infinite off-link
ipv6 nd prefix 2001:DB8:BBBB:CCCC::/64 86400 3600 off-link
no ipv6 nd suppress-ra
ipv6 nd other-config-flag
ipv6 dhcp server v6dhcppool
peer default ipv6 pool v6prefixpool2
!
ipv6 local pool v6prefixpool 2001:DB8:9999:8800::/56 64
ipv6 local pool v6prefixpool2 2001:DB8:8888::/48 56

As the above config is just an example it uses the appropriate address space that IPv6 provides for examples, 2001:db8::/32

Hope it helps someone…

Filed by kargig at 23:25 under Internet,IPv6,Networking
Tags: bras, Cisco, DHCPv6, ipv6, PPP, Prefix Delegation, slaac, Stateless Address Autoconfiguration
No Comments | 10,842 views

Some months ago (exactly 4 actually) I had posted that void.gr was then accessible over IPv6. Today void.gr is accessible over native IPv6 thanks to my hosting provider, Leaseweb.

About a year ago I had asked Leaseweb for IPv6 support and their reply wasn’t very promising. It seemed that they weren’t really looking forward to providing IPv6 for their dedicated server clients yet. Today though I thought I should ask again, even if IPv6 support for their dedicated servers is still not referenced anywhere. And I got lucky! They offered me a /64.

So void.gr is from now accessible over IPv6 at 2001:1af8:4100:a000:4::131.

Accessing my server over IPv6 from my home’s native IPv6 connection, thanks to OTE providing beta IPv6 access to subscribers, seems a bit faster than accessing it via IPv4. Ping times are usually 4-5ms better. Looks like IPv6 connections are not that crowded as IPv4 are 🙂

The setup is pretty straightforward. Even if Debian Wiki is not very clear about how to setup IPv6, here’s what you have to do if you, like me, have a server with a native IPv6 connection.

# vi /etc/network/interfaces
auto eth0
iface eth0 inet static
    address 85.17.162.131
    netmask 255.255.255.0
    gateway 85.17.162.254
    network 85.17.162.0
    broadcast 85.17.162.255
iface eth0 inet6 static
    address 2001:1af8:4100:a000:4::131
    netmask 64
    gateway 2001:1AF8:4100:A000::1

Then of course you need to edit your Apache configuration to add the IPv6 vhosts.

P.S. I am still waiting an answer as to whether I can manage the reverse delegation of the IPv6 address space Leasweb gave me since I can’t do that from the control panel. I’ll post any updates on the ticket when I have some news…

Filed by kargig at 22:23 under Internet,IPv6,Linux,Networking
Tags: debian, hosting, Internet, ipv6, Linux, Networking
No Comments | 6,285 views

For the past 1,5 years I’ve been messing (again) a lot with IPv6. The first time I started looking at the protocol was back in 2002-2003 when I was working at the Network Operations Center of my university. I had set up a couple of links between routers and tried various connectivity experiments mainly using some Cisco routers and Linux boxes. This time I started looking at it more seriously, mainly because I wanted to add support for it on the xDSL Linux-based routers/CPEs the company I currently work for produces. (GENNET, yes I know that the company’s website is UGLY…or worse than that…).

The task wasn’t easy, lots of backporting and fixing on both kernel-space and user-space had to be done. Luckily my colleagues were very helpful when I needed them. I have to say though that the main obstacle on working on it were not the technical difficulties but trying to convince our management that they had to give me time to work on it. It took a while (months…) to convince them but the end result is that all our models are now IPv6 capable. I am pretty glad that our product is referenced at the website of the first Greek ISP to start experimenting with IPv6 (Gennet OxyGen on ipv6.ote.gr). Being presented on the same page as the Cisco and the AVM CPEs is not bad at all!

Out of this process I learned quite a lot on IPv6, so when Dimitris Kalamaras, the editor of the new Greek Linux magazine Linux Inside, asked me to write an article for the first issue of the new magazine, there wasn’t actually a choice. I would write about IPv6, and so I did. I had written articles in the past for another Greek Linux Magazine called LinuxFormat, which was an adaptation of the English one. I’ve put the pdfs of my previous articles at my blog under Presentations/Articles.

My article is about the history if Internet Protocols (IPv4, IPv6), which were the needs that drove IPv6 development and a small intro to some of the changes that the new protocol brings to our life. There is also some information on how to connect using tunnels and so on. The article serves just as an introduction to IPv6, if there’s feedback I will write something more extended and maybe more technical. The timing of the article couldn’t be any better, magazine was out in the streets on 02 February 2011 and IANA pool run out of IPv4 addresses on 03 February 2011. Just perfect!

I will publish the pdf of the article along with my other articles on magazines/newspapers after a couple of months have passed, just to be fair with the magazine’s publishing company. Until then, go buy the magazine, there are many interesting and original articles inside it.

Filed by kargig at 13:47 under Internet,IPv6,Linux,Networking
Tags: article, ipv6, Linux, linux inside, magazine, Networking, publication, router
5 Comments | 8,353 views

During the past few weeks I’ve noticed increased brute forcing activity on various servers that I manage and run Plesk Panel. Most of the entries look like this:

189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:19 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:21 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:21 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:23 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [30/Jan/2011:07:14:23 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852

The side effect of all these attacks is increased server load.

Since I already have ossec monitoring these servers the solution was quite simple. I just added a couple more rules to ossec in order to stop these attacks.

Two steps are necessary to stop these attacks:
1) Add plesk panel https log to monitor list in /var/ossec/etc/ossec.conf

  <localfile>
    <log_format>apache</log_format>
    <location>/opt/psa/admin/logs/httpsd_access_log</location>
  </localfile> 

  <localfile>
    <log_format>apache</log_format>
    <location>/opt/psa/admin/logs/httpsd_error_log</location>
  </localfile>

2) Create some custom rules to block (and notify me) of these attacks.

<rule id="100144" level="1">
    <if_sid>31100</if_sid>
    <id>200</id>
    <url>/login_up.php3</url>
    <description>Plesk Login.</description>
  </rule>

<rule id="100145" level="12" frequency="3" timeframe="60">
    <if_matched_sid>100144</if_matched_sid>
    <same_source_ip />
    <description>Attack on plesk panel.</description>
    <group>attack,</group>
  </rule>

That’s it. Ossec now monitors these files and blocks through iptables any attacks with active-response.

Example notification mail:

Received From: foo->/opt/psa/admin/logs/httpsd_access_log
Rule: 100146 fired (level 12) -> "Attack on plesk."
Portion of the log(s):

189.205.227.115 - - [02/Feb/2011:20:19:56 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [02/Feb/2011:20:19:55 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852
189.205.227.115 - - [02/Feb/2011:20:19:54 +0100] "GET /login_up.php3?passwd=setup&login_locale=default&login_name=admin HTTP/1.1" 200 5852

Filed by kargig at 22:03 under Internet,Linux
Tags: apache, brute force, https, iptables, Linux, log, monitor, notify, ossec, plesk, security
2 Comments | 10,245 views

The pet-project of GrRBL,which is an IP-based blacklist, The Greek Spammers Email Addresses Blacklist, previously described at a previous post of mine, has grown to 400++ verified addresses of Greek spammers.

From now on, apart from the usual rsync access to anyone who asks for it, there will be a public link on the web with a PGP/GPG signed list of the spammers for anyone to get. The public link will not update as often as the list from rsync, probably once or twice per month is enough.

For anyone who wants to read a bit more: http://grrbl.void.gr/#email_blacklist.

Direct link to the signed Greek Spammers Email Addresses Blacklist.

Don’t forget to read the disclaimer and to submit greek spam at GrRBL Submission.

Filed by kargig at 20:01 under Greek,Internet,Linux,Networking,Privacy
Tags: blacklist, gpg, Greek, grrbl, spam, spammers
No Comments | 7,457 views

phpMyAdmin is a great tool but a constant headache (xss, sql injections,etc) as well. Every now and then there are new security holes discovered that need to be fixed ASAP. On the other hand, Plesk doesn’t seem to follow these security fixes, so if you want to keep yourself a bit more secure than Plesk thinks you should be, then you have to upgrade phpMyAdmin by your self. This procedure isn’t very straightforward due to the way Plesk uses PMA so I’ll post here some notes/guidelines on how to achieve that.

My notes are based on Plesk 8.6, so I am sure newer Plesk versions are way easier to upgrade than this.

Step 1: Download new phpMyAdmin
# wget http://downloads.sourceforge.net/project/phpmyadmin/phpMyAdmin/3.3.8/phpMyAdmin-3.3.8-all-languages.tar.gz
Step 2: Extract into /opt/psa/admin/htdocs/domains/databases/

# mv phpMyAdmin-3.3.8-all-languages.tar.gz /opt/psa/admin/htdocs/domains/databases/
# cd /opt/psa/admin/htdocs/domains/databases/
# tar zxf phpMyAdmin-3.3.8-all-languages.tar.gz

Step 3: Rename old PMA and symlink the new

# mv phpMyAdmin phpMyAdmin.old
# ln -sf phpMyAdmin-3.3.8-all-languages phpMyAdmin

Step 4: Copy old config file
This step depends on your old PMA version. Since my version was 2.8.2.4 I had to:
#cp phpMyAdmin.old/libraries/config.default.php phpMyAdmin/config.inc.php
If you have newer versions of PMA just do:
#cp phpMyAdmin.old/config.inc.php phpMyAdmin/config.inc.php
Step 5: Edit necessary files
Substep a: edit phpMyAdmin/libraries/session.inc.php
When the first comment block finishes and before line 14: if (! defined('PHPMYADMIN')) {
add the following snippet:

// Close Plesk's session.
$proxy_session_id = session_id();
@session_write_close();
unset($_SESSION);

Substep b: edit phpMyAdmin/libraries/common.inc.php around line 190 and change:

    'error_handler',
    'PMA_PHP_SELF',
    'variables_whitelist',
    'key'
);

to

'error_handler',
    'PMA_PHP_SELF',
    'variables_whitelist',
    'key',
    // from Plesk
    'PHP_SELF',
    'db_host',
    'db_port',
    'db_user',
    'db_pass',
    'db_name'
);

!! Mind the “,” after ‘key’ !!

That’s about it…you should now be able to use your new PMA version through Plesk.

Filed by kargig at 20:49 under Internet,Linux,Networking
Tags: config, debian, phpmyadmin, plesk, PMA, security, sql injection, vhost, xss
8 Comments | 15,793 views

Since Leaseweb, the hosting company where void.gr’s server is located, isn’t yet ready to provide native IPv6 to dedicated servers, I decided not to wait for them any longer and to set up an IPv6 tunnel to tunnelbroker.net so that I make void.gr accessible over IPv6.

Setting up the tunnel is extremely easy. Having the following in my /etc/rc.conf does the trick:

ip tunnel add he-ipv6 mode sit remote 216.66.84.46 local 85.17.162.131 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f14:e0a::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6
ip addr add 2001:470:1f15:e0a::1/64 dev eth2

Yes, I know I could have used some of debian’s config files for these parameters…Oh and you “ifconfig” users, time to give up using that ancient tool, it’s time you learn how to use “ip”.

So for you people who have IPv6 connectivity, just try it. The current IP of void.gr is 2001:470:1f15:e0a::1. Ping6 it 🙂

Time is ticking away…bye bye IPv4: http://ipv6.he.net/statistics/

Filed by kargig at 21:02 under Internet,Linux,Networking
Tags: debian, ipv4, ipv6, Linux, Networking, tunnel, tunnelbroker, tunnelbroker.net, void, void.gr
2 Comments | 8,524 views

3 days ago, after a Debian(squeeze/sid) upgrade on my laptop some programs started not to open. Specifically, pidgin and google-chrome were crashing while trying to open them. When I started them from a terminal the output was this:

kargig@laptop:~%pidgin
[1]    3853 abort      pidgin
kargig@laptop:~%google-chrome
[1]    3882 abort      google-chrome

The first thing I checked was the updated packages, whether there was some culprit.
The upgraded packages included among others:

[UPGRADE] libk5crypto3 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libkrb5-3 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libkrb5support0 1.8.3+dfsg-1 -> 1.8.3+dfsg-2
[UPGRADE] libnspr4-0d 4.8.4-2 -> 4.8.6-1
[UPGRADE] libnss3-1d 3.12.6-3 -> 3.12.8-1
[UPGRADE] linux-base 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-headers-2.6.32-5-686-bigmem 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-headers-2.6.32-5-common 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-image-2.6.32-5-686-bigmem 2.6.32-23 -> 2.6.32-25
[UPGRADE] linux-libc-dev 2.6.32-23 -> 2.6.32-25
[UPGRADE] xserver-xorg-video-intel 2:2.9.1-4 -> 2:2.12.0+shadow-2

My first point of checking was the xserver-xorg-video package. I started searching the Debian bug tracking system for references of crashes with abort. Nothing. Then I tried to check the other “suspicious” packages with abort crash reports on the bug tracker…still nothing.
It was time for strace.

kargig@laptop:~%strace pidgin
...
[snip]
...
open("/usr/lib/nss/libfreebl3.so", O_RDONLY) = 14
read(14, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\30\0\0004\0\0\0"..., 512) = 512
fstat64(14, {st_mode=S_IFREG|0644, st_size=253328, ...}) = 0
mmap2(NULL, 268988, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 14, 0) = 0xb58e3000
mmap2(0xb5920000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 14, 0x3d) = 0xb5920000
mmap2(0xb5921000, 15036, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb5921000
close(14)                               = 0
open("/etc/ld.so.cache", O_RDONLY)      = 14
fstat64(14, {st_mode=S_IFREG|0644, st_size=79200, ...}) = 0
mmap2(NULL, 79200, PROT_READ, MAP_PRIVATE, 14, 0) = 0xb5ab7000
close(14)                               = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/swiftfox/libnspr4.so", O_RDONLY) = 14
read(14, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0P\227\0\0004\0\0\0"..., 512) = 512
fstat64(14, {st_mode=S_IFREG|0755, st_size=251136, ...}) = 0
close(14)                               = 0
munmap(0xb5ab7000, 79200)               = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(4027, 4027, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---
+++ killed by SIGABRT +++
[1]    4026 abort      strace pidgin

What immediately caught my eye was this line inside the output:
open("/usr/lib/swiftfox/libnspr4.so", O_RDONLY) = 14
I have a 3rd party package called swiftfox installed, but why was pidgin trying to use this package’s library instead of the system one ?

# ldconfig -p | grep nspr4
ldconfig -p | grep nspr4
  libnspr4.so.0d (libc6) => /usr/lib/libnspr4.so.0d
  libnspr4.so (libc6) => /usr/lib/swiftfox/libnspr4.so
  libnspr4.so (libc6) => /usr/lib/libnspr4.so

So the system package libnspr4-0d has installed its files in /usr/lib/libnspr4.so.0d and has also placed a symlink from /usr/lib/libnspr4.so to /usr/lib/libnspr4.so.0d. For some reason though the /usr/lib/swiftfox/libnspr4.so appears before /usr/lib/libnspr4.so in the cache output for the libnspr4.so library.
Checking out /etc/ld.so.conf.d/ directory, there was a moz.conf file containing the path “/usr/lib/swiftfox/“.
An “ldconfig -v” confirmed the finding:

/usr/local/lib:
/usr/lib/swiftfox:
        libnssckbi.so -> libnssckbi.so
        libssl3.so -> libssl3.so
        libsqlite3.so -> libsqlite3.so
        libnssutil3.so -> libnssutil3.so
        libnss3.so -> libnss3.so
        libnspr4.so -> libnspr4.so
        libsmime3.so -> libsmime3.so
        libmozjs.so -> libmozjs.so
        libsoftokn3.so -> libsoftokn3.so
        libplc4.so -> libplc4.so
        libxul.so -> libxul.so
        libplds4.so -> libplds4.so
        libxpcom.so -> libxpcom.so
        libnssdbm3.so -> libnssdbm3.so
        libfreebl3.so -> libfreebl3.so
/lib:
        libnss_compat.so.2 -> libnss_compat-2.11.2.so
        libselinux.so.1 -> libselinux.so.1
...
[snip]
...

Moving /usr/lib/swiftfox/libnspr4.so to some other location allowed applications like pidgin and google-chrome to start normally (and swiftfox still runs properly).

I guess that was my punishment for using 3rd party packages on Debian…

*UPDATE 23/11/2010*
Google chrome was crashing with some https:// sites with SIGABRT. After further investigation I had to delete /usr/lib/swiftfox/libnssutil3.so as well.

Filed by kargig at 19:39 under Linux
Tags: abort, crash, debian, google-chrome, ldconfig, libraries, Linux, pidgin, SIGABRT, strace, swiftfox
2 Comments | 9,861 views

Plesk is surely not ready for IPv6. Despite that fact, many people – me included, have the DNS records of their favorite domains managed by Plesk and still want to be able to add some IPv6 records to those.

Some time ago I had posted on my twitter account a link to another blog that had a “hackish way” to add AAAA records to Plesk. I have written a slightly more elegant shell script (to be run by root only) than the one provided by experimentalworks.

First of all you _need_ to alter dns_recs table of the psa database to allow AAAA records:

# mysql -u admin -p psa 
mysql> alter table dns_recs modify column type enum('NS','A','AAAA','CNAME','MX','PTR','TXT','SRV','master','none') NOT NULL default 'A'; 

Then download my plesk-AAAA.sh script and use it like the following example.

To add www.foobar.gr to point to 2001:db8:1001::1

Usage: ./plesk-AAAA.sh [zone serial]
#./plesk-AAAA.sh foobar.gr www 2001:db8:1001::1
#./plesk-AAAA.sh foobar.gr ipv6 2001:db8:1001::1 12

Known bug/feature:
If you add a record without adding a serial, for the soa record, at the end, it will add the serial of the domain in the form:

YYYYMMDD10

So if you add two ipv6 hosts in the same day for the same domain you _have_ to manually add a serial >10 for the second host (and so forth).

For the ones who don’t like downloading but would like to see the script source, here it is:

  1 #!/bin/sh
  2 
  3 usage () {
  4         echo "Usage: $0 <domain> <hostname> <v6 IP> [zone serial]"
  5         echo "Usage: $0 foobar.gr www 2001:db8:1001::1"
  6         exit 1
  7 }
  8 
  9 if [ $# -lt 3 ]; then
 10         usage
 11 fi
 12 DOMAIN=$1
 13 HOSTNAME=$2
 14 v6IP=$3
 15 INPUT_SERIAL=${4:-10}
 16 FULLHOST="$2.$1."
 17 
 18 ADMIN_PASS=`cat /etc/psa/.psa.shadow`
 19 MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
 20 PRODUCT_ROOT_D=`grep PRODUCT_ROOT_D /etc/psa/psa.conf | awk '{print $2}'`
 21 SERIAL=`date +%Y%m%d${INPUT_SERIAL}`
 22 mysql="${MYSQL_BIN_D}/mysql -N -uadmin -p${ADMIN_PASS} psa"
 23 
 24 query1="SELECT dns_zone_id FROM dns_recs where host like \"$DOMAIN%\" LIMIT 0,1"
 25 ZONE_ID=`echo "$query1" | $mysql`
 26 echo "ZONE_ID=$ZONE_ID"
 27 query2="INSERT INTO dns_recs (displayHost, host, displayVal, val, type, dns_zone_id) VALUES ('$FULLHOST', '$FULLHOST', '$v6IP', '$v6IP', 'AAAA',$ZONE_ID)"
 28 echo "$query2" | $mysql
 29 
 30 query3="UPDATE dns_zone SET serial=\"$SERIAL\" WHERE id=$ZONE_ID LIMIT 1;"
 31 echo "$query3" | $mysql
 32 
 33 echo "REBUILDING zone file for $DOMAIN"
 34 $PRODUCT_ROOT_D/admin/sbin/dnsmng update $DOMAIN

The script has been tested with bash and zsh. I have no idea whether it works under any other shells.
The script probably won’t delete your databases, but…use it at your own risk 🙂 I hope someone finds it useful.

Filed by kargig at 20:10 under Internet,Linux,Networking
Tags: aaaa, aaaa record, bash, dns, ipv6, Linux, Networking, plesk, script, shell, zsh
2 Comments | 8,353 views

Lately I was given a task of moving some websites/webservices from real boxes to some VMs. Most of the sites were Joomla! applications so moving the installation was quite easy, tar files, check configuration.php for db username/pass/etc and dump the database on the old server and then copy these to the VM. Restore files, import database, minor path changes to configuration.php… that’s about it.

But then it was time to move an “eclass” application. Specifically it was an installation of Open eClass, a web based e-learning software created by Greek Academic Network. So I copied the files, found the configuration file with database credentials, dumped the db and moved it to the VM. The site came up but it was not functioning properly. Course material was missing from the website, but I could certainly see the files on the file system. I dumped the database again and re-imported it. Nothing, the site refused to work as expected. I went back to the original machine and shut down mysql to start it with “–skip-grant-tables” since I didn’t have the root mysql password. MySQL came up, I logged in as root and I typed: “show databases;”

Oh the horror!!!!
I couldn’t believe my eyes…in front of me there were more than 200 databases with the names of courses of the e-elearning platform! I shut down mysqld and restarted it normally. Then I logged in as the “eclass” user and issued the following:
show grants for eclass@localhost;
The output:

| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, CREATE TEMPORARY TABLES, LOCK TABLES ON *.* TO 'eclass'@'localhost' IDENTIFIED BY PASSWORD 'XX' | 
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, CREATE TEMPORARY TABLES, LOCK TABLES ON `eclassdb`.* TO 'eclass'@'localhost'  |

I immediately started thinking that someone had _really_ fucked up the installation. I went to Open eClass website and tried to search for documentation on installation instructions. I downloaded a pdf and I read between the installation instructions:

A “username” and a “password” for MySQL with database creation rights.

.
Okie..let’s translate that to simple english, it needs a ‘root’ mysql account renamed to something else.

I am not a web developer, I do not even consider myself a developer, but this setup makes no sense for me. Who and why decided that it would be a good idea to have a web application’s mysql user being able to create new databases ? Is this application only to be installed on a machine of its own ? If so, it’s such a waste of resources. I can understand the complexity and the extra time that a well designed and correctly normalized database requires, but this isn’t an excuse when creating software to be distributed and widely used by lots of people, especially universities. I can’t judge the application, it actually looks quite useful, but it’s setup certainly has design problems that need to be solved.

And finally, what “if” there is some security hole in the application (sql injections anyone?) and a malicious user starts dropping databases other than the ones belonging to eclass ? Who’s to blame for that ?

My advice to anyone running this application is to have it as isolated as possible from the rest of his infrastructure. Possibly in a virtual machine of its own. And there should be a warning about it on the website.

P.S. Looking at the credits, it seems that I know in person some of its developers, and that makes it ever harder to blog about what I faced. I’ll certainly ask them about this web application the next time I meet them though.

Filed by kargig at 11:05 under Internet,Linux
Tags: database, design, eclass, mysql, openeclass, security, sql injection, virtual machine, web application, website
7 Comments | 16,067 views

This post is about a friend who had a faulty (firmware bug) hard disk replaced by Seagate…

A few months ago she bought a Seagate Barracuda 7200.11 500 GB loaded with firmware SD15. This specific firmware is known to be buggy and Seagate has provided a firmware upgrade for them, but of course she had no idea about that bug. Everything was OK until one day, suddenly, the BIOS couldn’t detect the disk. It didn’t take her long to find out the cause of the problem…

After several failed attempts to upgrade her firmware following the instructions placed at Seagate’s site she decided to send her disk to Greek companies that specialized on data recovery. One of them broke the seals of her disk but failed(!!) to do anything else. The other companies, asked a serious amount of money, 200-1000 Euros(!!!) in order to handle her case/take a preliminary look at the disk.

Fed up with those companies she finally decided to contact Seagate herself and she was given instructions via telephone to complete the online application form for technical support and data recovery.

The very next day, a courier took her disk, delivered it to Seagate Labs at Amsterdam and within a week, she had her disk brought back, totally repaired, with all her data intact(!!). Everything was free and her data was saved.

So the next time you have a hard disk problem, especially if it is a Seagate disk, contact Seagate before contacting these “specialized data recovery companies”. sigh.

Filed by kargig at 11:06 under General,Greek,Internet
Tags: barracuda 7200.11, bios, bug, crash, data recovery, firmware sd15, hard disk, recovery, sd15, seagate
4 Comments | 7,338 views

It’s been exactly 6 years (!) since I started this blog: http://www.void.gr/kargig/blog/2004/07/18/hey-ho-lets-go/…

Too bad I don’t have as much free time as I had in the past to post about interesting things. It’s a also a time for a redesign…I think I have the same theme for more than 5 years…

Anyway, GrRBL got redesigned yesterday by Christine and now there’s also a submission form for those who prefer it over forwarding emails. I also merged my other Greek spammers email addresses blacklist with lists by a couple of friends (postmasters) and now the list contains over 300 unique, verified, spammer addresses. This list is not yet public but if you are interested to use it and test it, give me a shout and I’ll give you access.

Filed by kargig at 12:42 under General,Linux,Networking
Tags: anniversary, blacklist, blog, Greek, grrbl, rbl, redesign, spam, void, wordpress
2 Comments | 6,720 views

A friend’s site was recently hit by the massive infections/hacks on Dreamhost‘s servers, so I decided to do some scanning on some servers that I administrate for base64_decode references.

The simple command I used to find suspect files was:
# find . -name \*.php -exec grep -l "eval(base64_decode" {} \;

The results could be sorted in just 2 categories. Malware and stupidity. There was no base64_decode reference that did something useful in any possible way.

The best malware I found was a slightly modified version of the c99 php shell on a hacked joomla installation (the site has been hacked multiple times but the client insists on just re-installing the same joomla installation over and over and always wonders how the hell do they find him and hack him…oh well). c99 is impressive though…excellent work. I won’t post the c99 shell here…google it, you can even find infected sites running it and you can “play” with them if you like…

And now comes the good part, stupidity.
My favorite php code containing a base64_decode reference that I found:

$hash  = 'aW5jbHVkZSgnLi4vLi';
$hash .= '4vaW5jX2NvbmYvY29u';
$hash .= 'Zi5pbmMucGhwJyk7aW';
$hash .= '5jbHVkZSgnLi4vLi4v';
$hash .= 'aW5jX2xpYi9kZWZhdW';
$hash .= 'x0LmluYy5waHAnKTtl';
$hash .= 'Y2hvICRwaHB3Y21zWy';
$hash .= 'd2ZXJzaW9uJ107';
eval(base64_decode($hash));

Let’s see what this little diamond does:

% base64 -d 
aW5jbHVkZSgnLi4vLi4vaW5jX2NvbmYvY29uZi5pbmMucGhwJyk7aW5jbHVkZSgnLi4vLi4vaW5jX2xpYi9kZWZhdWx0LmluYy5waHAnKTtlY2hvICRwaHB3Y21zWyd2ZXJzaW9uJ107
include('../../inc_conf/conf.inc.php');include('../../inc_lib/default.inc.php');echo $phpwcms['version'];

So this guy used a series of strings which all of them together create a base64 encoded string in order to prevent someone from changing the version tag of his software. That’s not software, that’s crapware. Hiding the code where the version string appears ? That’s how you protect your software ? COME OOOOON….

Filed by kargig at 01:36 under Internet,Linux,Privacy
Tags: base64_decode, crapware, hack, joomla, Linux, malware, php
No Comments | 8,011 views

GrRBL
In the beginning of the year I announced my RBL for Greek spam emails. The blacklist is growing larger by the day, thanks to some really kind people forwarding me their Greek spam emails, and has reached more than 120 IP addresses of verified Greek spammers.This alone though is not enough.

Why
Some spammers use their aDSL lines which have dynamic IPs to send their massive email “newsletters”. These people are split into 2 sub-categories. The ones that use their own PC as an SMTP server and the ones who use their ISP’s mail server as SMTP. I’ve tried to complain to some of their ISPs…some replied back saying that they were willing to look into the issue (but did nothing at all in the end) and others did not even reply to me. For both sub-categories, GrRBL is ineffective since I can’t add dynamic IPs in the blacklist nor can I add the IPs of the email servers of those major Greek ISPs.

Another category of spammers is the one that uses their gmail/yahoo accounts to send their emails. GrRBL is ineffective for this category as well since I can’t add gmail/yahoo to the blacklist…

What
So there was no alternative but to gather all those email addresses of these 2 categories above and add them to a new blacklist, one that will contain email addresses. I use this blacklist with my spamassassin configuration to eliminate Greek spam that GrRBL can’t. Each time I receive (or someone forwards me) a new Greek spam, I add the “From:” email address to this new blacklist. This new blacklist grows far more aggressively than GrRBL since it’s a lot easier to gather the data and already has more than 140 addresses.

Distribution
There are two available formats of the blacklist, one ready for use by spamassassin and another one with clear formatting ready to be used even by SMTPs to drop these spam emails without even touching your inbox.
The blacklist is currently only distributed to a group of well trusted people and it is available only through rsync with a username/password.

I don’t want to make the list completely public yet, but if you are interested you can request it at the contact email of GrRBL and I will reply to you about accessing it.

Sidenote
If you need a good tool to check a host again some RBLs, adnsrblcheck by Yiorgos Adamopoulos is the way to go (and it includes GrRBL!)

Filed by kargig at 23:15 under Linux,Networking
Tags: blacklist, email, Greek, greek spam, grrbl, Internet, Linux, Networking, spam, spamassassin
3 Comments | 18,392 views