Into.the.Void.

Lately the amount of spam with russian encoding/charset that I was getting had increased significantly. Spamassassin’s configuration options “ok_locales” and “ok_languages” were not enough because I didn’t want to whitelist some language, but I just wanted to blacklist some.

So the solution for my problems was the addition of the following lines in the configuration of spamassassin:

header LOCAL_CHARSET_RUSSIAN Subject:raw =~/\=\?koi8-r\?/i
score LOCAL_CHARSET_RUSSIAN 7
describe LOCAL_CHARSET_RUSSIAN Contains russian charset that is not acceptable

If you want to add even more charsets:

header LOCAL_CHARSET_BLOCKED Subject:raw =~/\=\?(koi8-r|windows-1251)\?/i
score LOCAL_CHARSET_BLOCKED 5
describe LOCAL_CHARSET_BLOCKED Contains charsets that are not acceptable

Be VERY careful with these rules if you place them in the global config (/etc/spamassassin/local.cf) because if any of your users are getting emails in russian those emails will be probably marked as spam!!

Filed by kargig at 13:27 under Internet
Tags: charset, email, russian, spam, spamassassin
2 Comments | 13,621 views

Χρησιμοποιώντας πριν 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,292 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,822 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,263 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,331 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

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,220 views