Error while loading shared libraries: on Fedora 24

I got this error message:

smbclient: error while loading shared libraries: cannot open shared object file: No such file or directory

a couple of time when I was installing Fedora 24 and this is just a short post on how I managed to get around it


Here's the first time I got it:

[root@fedora]# smbclient -L //
smbclient: error while loading shared libraries: cannot open shared object file: No such file or directory

Second time it happend to me I was not able to start control center and when I started it from command line I got this:

gnome-control-center: error while loading shared libraries: cannot open shared object file: No such file or directory

Details from the system:

[root@fedora]# rpm -qa | grep libwbclient

[root@fedora]# cat /etc/fedora-release 
Fedora release 24 (Twenty Four)

Here's an example output from my system. libwbclient and Fedora release.

How to fix:

update-alternatives --install /usr/lib64/ /usr/lib64/samba/wbclient/ 10

And tehn it works OK:

[root@fedora]# smbclient -L //
Enter root's password:

Modsecurity configuration with base rules on Centos 7.2 and Apache

Finally I made base rules from modsecurity CRS (Core Rule Set) to work with Apache on CentOS 7 install (previous steps here). Here's some notes based on that install:

How to:

Note I'm performing all the changes as root becuse I constant sudo is giving me a headache :)

Configuration template (modsecuirty.conf-recommended) is provided with modsecurity installation package. I've unpacked it during installation in this direcotory /root/modsecurity-2.9.1. You can just copy that file to a directory where you keep your apache config to get you started:

cp /root/modsecurity-2.9.1/modsecuirty.conf-recommended /etc/httpd/conf.d/modsecuirty.conf

First thing that I did was restarting httpd and I got this error:

httpd[3070]: Could not open unicode map file "/etc/httpd/conf.d/unicode.mapping": No such file or directory

unicode.mapping file is also included in modsecurity installation directory. I just copied it over to /etc/httpd/conf.d/

cp /root/modsecurity-2.9.1/unicode.mapping /etc/httpd/conf.d/

After that change modsecurity and apache are starting up.

I'm leaving the configuration as default for now with modsecurity in detection mode (don't want to block anything yet):

SecRuleEngine DetectionOnly

(from modsecurity.conf)

So that was the first part. Now I had to get to rules in place.

Adding OWASP ModSecurity Core Rule Set (CRS):

Core Rule Set can be downloaded from CSR github project

Get the link from the page and download it:


and unpack it:

tar -zxvf 2.2.9.tar.gz -C /root/

you will get you rules in /root/owasp-modsecurity-crs-2.2.9

I've placed it like this just to have a chance to look around it before I put it in some more reasonable place.

mv /root/owasp-modsecurity-crs-2.2.9 /etc/httpd/conf.d/crs

So the destination directory I choose for my crs config files is /etc/httpd/conf.d/crs

Rules are located in 4 directories:


I didn't have a chance to look closely at the specific rules. I can only judge by the names of the directories that there are: base rules, experimental (so might be extra cautios when using these), optional (some special features) and slr (special rules provided by SpiderLabs).

I'm going to implement base rules first and then look closely at other.

I'm going to use activated_rules directory to manage my active rules.

cd /etc/httpd/conf.d/crs
mv modsecurity_crs_10_setup.conf.example modsecurity_crs_10_setup.conf
ln -s /etc/httpd/conf.d/crs/modsecurity_crs_10_setup.conf activated_rules/modsecurity_crs_10_setup.conf

So the basic idea is to get configuration that you want to be active sym linked to activated_rules directory.

So for this I found this one lined in README that did the trick for basic rules:

for f in `ls base_rules/` ; do ln -s /etc/httpd/conf.d/crs/base_rules/$f activated_rules/$f ; done

After that this is how your activated_rules directory should look like:

# ls -al activated_rules/
razem 8
drwxr-xr-x. 2 root root 4096 03-29 23:40 .
drwxr-xr-x. 9 root root 4096 03-30 01:33 ..
lrwxrwxrwx. 1 root root   63 03-18 11:04 -> /etc/httpd/conf.d/crs/base_rules/
lrwxrwxrwx. 1 root root   61 03-18 11:04 -> /etc/httpd/conf.d/crs/base_rules/
lrwxrwxrwx. 1 root root   68 03-18 11:04 -> /etc/httpd/conf.d/crs/base_rules/
lrwxrwxrwx. 1 root root   61 03-18 11:04 -> /etc/httpd/conf.d/crs/base_rules/
lrwxrwxrwx. 1 root root   69 03-18 11:04 -> /etc/httpd/conf.d/crs/base_rules/
lrwxrwxrwx. 1 root root   51 03-18 11:03 modsecurity_crs_10_setup.conf -> /etc/httpd/conf.d/crs/modsecurity_crs_10_setup.conf
lrwxrwxrwx. 1 root root   76 03-18 11:04 modsecurity_crs_20_protocol_violations.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_20_protocol_violations.conf
lrwxrwxrwx. 1 root root   75 03-18 11:04 modsecurity_crs_21_protocol_anomalies.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_21_protocol_anomalies.conf
lrwxrwxrwx. 1 root root   71 03-18 11:04 modsecurity_crs_23_request_limits.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_23_request_limits.conf
lrwxrwxrwx. 1 root root   68 03-18 11:04 modsecurity_crs_30_http_policy.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_30_http_policy.conf
lrwxrwxrwx. 1 root root   67 03-18 11:04 modsecurity_crs_35_bad_robots.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_35_bad_robots.conf
lrwxrwxrwx. 1 root root   72 03-18 11:04 modsecurity_crs_40_generic_attacks.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_40_generic_attacks.conf
lrwxrwxrwx. 1 root root   78 03-18 11:04 modsecurity_crs_41_sql_injection_attacks.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_41_sql_injection_attacks.conf
lrwxrwxrwx. 1 root root   68 03-18 11:04 modsecurity_crs_41_xss_attacks.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_41_xss_attacks.conf
lrwxrwxrwx. 1 root root   71 03-18 11:04 modsecurity_crs_42_tight_security.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_42_tight_security.conf
lrwxrwxrwx. 1 root root   64 03-18 11:04 modsecurity_crs_45_trojans.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_45_trojans.conf
lrwxrwxrwx. 1 root root   74 03-18 11:04 modsecurity_crs_47_common_exceptions.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_47_common_exceptions.conf
lrwxrwxrwx. 1 root root   81 03-18 11:04 modsecurity_crs_48_local_exceptions.conf.example -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_48_local_exceptions.conf.example
lrwxrwxrwx. 1 root root   73 03-18 11:04 modsecurity_crs_49_inbound_blocking.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_49_inbound_blocking.conf
lrwxrwxrwx. 1 root root   65 03-18 11:04 modsecurity_crs_50_outbound.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_50_outbound.conf
lrwxrwxrwx. 1 root root   74 03-18 11:04 modsecurity_crs_59_outbound_blocking.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_59_outbound_blocking.conf
lrwxrwxrwx. 1 root root   68 03-18 11:04 modsecurity_crs_60_correlation.conf -> /etc/httpd/conf.d/crs/base_rules/modsecurity_crs_60_correlation.conf

The last thing to do is to make apache read configuration from this directory and for this we need to add this line on the bottom of httpd.conf:

IncludeOptional conf.d/crs/activated_rules/*.conf

and restart apache:

systemctl restart httpd

Next step is to test this setup and generate some events.

Installing ModSecurity 2.9.1 on CentOS 7.2 with Apache

Below I'm sharing some notes on modsecurity installation on my CentOS 7.2 server with apache.

Where to get ModSecurity

I got it from ModSecurity github page and to be precise from here.


and upack:

tar -zxvf modsecurity-2.9.1.tar.gz -C .

Wiki on github is suggesting to run first.

I had to install this packages first:

yum install autoconf automake libtool

It also installed gcc as a dependency and I was able to run

I had to install this packages to run: ./configure

yum install libcurl libcurl-devel httpd-devel pcre pcre-devel libxml2-devel libxml2

apr packages where installed as dependecies.

And I was able to run:





make install

After that I got my modsecurity module in the right place:

# ls -al /usr/lib64/httpd/modules/
-r-xr-xr-x. 1 root root 2421149 03-17 22:30 /usr/lib64/httpd/modules/

To get it enabled (it runs as a apache module) I've created a file in:


and added this line:

LoadModule security2_module modules/

in it and restarted httpd service.

This is an example output in httpd error_log just after restarting httpd service:

[Thu Mar 17 22:42:59.400335 2016] [:notice] [pid 54933] ModSecurity for Apache/2.9.1 ( configured.
[Thu Mar 17 22:42:59.400343 2016] [:notice] [pid 54933] ModSecurity: APR compiled version="1.4.8"; loaded version="1.4.8"
[Thu Mar 17 22:42:59.400348 2016] [:notice] [pid 54933] ModSecurity: PCRE compiled version="8.32 "; loaded version="8.32 2012-11-30"
[Thu Mar 17 22:42:59.400352 2016] [:notice] [pid 54933] ModSecurity: LIBXML compiled version="2.9.1"
[Thu Mar 17 22:42:59.400354 2016] [:notice] [pid 54933] ModSecurity: Status engine is currently disabled, enable it by set SecStatusEngine to On.

The last entry is saying that the engine is disabled. I'll work on getting it on later :)

Sending USSD codes with curl on ZTE MF823 modem

I have ZTE MF823 LTE modem and it's been working really well in my home network for a while now but recently I've changed my network provider and to have my "internets" really cheep I need to send an USSD code every month (special offer expires every 30 days). That gave me idea for a small script that would check if the promo is active and if not then it would send out USSD code automaticly.

ZTE MF823 inteface:

Here's some information I was able to get about ZTE MF823 interface.

So if someone feels particullary interesting what's sitting inside it you can log in to it using telnet:


login: root

password: zte9x15

so if someone is interested what's behind the scenes there is an option to do that. I looked in there a couple of times but decided to first focus on what I needed to do.

The configuration that I need (including sending USSD codes) can be done using web interface so I went straight to Google Chrome Developer Tools and this is what I managed to find.

All the changes are done with POST to this URL:

I've also saw that Referer in the header was mandatory for the changes to work:

-H 'Referer:'

I've left some additional things (like Host in the header and compressed) just to be on the safe side (didn't have enouth time for testing).

Actions are controlled by setting parameters to a right value. More about parameters and values later.

My modem is working in LTE Only mode and can't send USSD codes in this mode so fist I need to switch it to WCDMA or auto but I decided that I want to have more control so I'm switching to WCDMA.

First disconnect:

curl -s '' -H 'Host:' -H 'Referer:' --compressed --data 'goformId=DISCONNECT_NETWORK' 

setting goformId=DISCONNECT_NETWORK will disconect the network.

Change mode:

curl -s '' -H 'Host:' -H 'Referer:' --compressed --data 'goformId=SET_BEARER_PREFERENCE&BearerPreference=Only_WCDMA'

So here I'm changing connection from "LTE Only" to "WCDMA Only". Other possible options for my modem are: Only_LTE Only_WCDMA Only_GSM NETWORK_auto So to get this parameters telnet access was very handly. Found this on some website (in cyrylic) that parameters are located in /usr/bin/zte* files and that's where I found these options. In /usr/bin/zte_wan_nwinfor

And to connect again:

curl -s '' -H 'Host:' -H 'Referer:' --compressed --data 'goformId=CONNECT_NETWORK'

Now my modem is ready to send USSDs. And here comes a moment when it becomes ugly because when I was testing this I found out that my operator has a kind of USSD DDoS protection and if you send to many codes you'll get a ban (for a while). That's why this doesn't look very nice (yet):

curl -s -0 "" -H "Host:" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0" -H "Accept: application/json, text/javascript, */*; q=0.01" -H "Accept-Language: en-US,en;q=0.5" --compressed -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" -H "X-Requested-With: XMLHttpRequest" -H "Referer:" -H "Connection: keep-alive" -H "Pragma: no-cache" -H "Cache-Control: no-cache" --data "isTest=false&goformId=USSD_PROCESS&USSD_operator=ussd_send&USSD_send_number=*111*480*3"%"23&notCallback=true"

So the important part for me in this long nudle was:


After this is sent web UI is sending this:

curl -s "$(date +s)" -H 'Host:' -H 'Referer:'

every second. This is not exactly what the modem is sending but modified a bit version that I'm sending (date is in Epoch BTW).

So at first I was woundering what it was and I think it's getting status of the USSD code (if there's an answer or not or a status from operator). Sample answers: {"ussd_write_flag":"15"} - waiting for answer. So this is not bad but we have to wait a bit longer. {"ussd_write_flag":"16"} - answer ready

And once I got: {"ussd_write_flag":"4"} - This is timeout. I was getting this when I sent a lot of requests.

Once we get flag 16 we can read the answer from the operator. This is the way to do it:

curl -s "$(date +%s)" -H 'Host:' -H 'Referer:'

The response should look similar to this:


Not going to pretend what ussd_action mean. USSD DCS 72 is encoding of the message. 72 means UCS-2. I got it to more readable format with this:

curl -s "$(date +%s)" -H 'Host:' -H 'Referer:' | sed -r 's/.+ussd_data":"([0-9a-fA-F]+)"}/\1/; s/0{2}//g' | xxd -r -p

Getting the USSD answer from the modem, then getting HEX that's after ussd_data, removing 00 and converting hex to some "real" chars with xxd :)

So mine is saying:

Usluga wlaczona 0 Wyjscie

That means that I'm good for now and should check the status tomorrow :)

Installing i3 window manager on Raspbian Jessie Lite

I've decided to put some graphical interface on my raspbery pi just in case (most of the time I'm using it over ssh). I've looked at DWM but it requires compiling every time a change needs to be made and I didn't want to put so much tow on my raspberry (or maybe I didn't have enought patience). Then I talked with friends and someone mantioned i3. It looked promissing.

How to:

Installation would have been pretty straight forward but I kind of missed that xserver wasn't a dependency for i3 and it took me a moment to realize that I'm missing something.

But here's what you need to do to get it running:

aptitude install xserver-xorg xserver-xorg-video-fbdev xinit
aptitude install i3

You might also want to install some terminal emulator.

aptitude install rxvt-unicode

When the installation is complete just type:


If you are starting i3 for the first time (without /etc/i3/config) configuration wizzard will be started (i3-config-wizard). It will get you through basic config in a few easy steps.

Starting terminal: $mod + enter

Exiting i3: $mod + shift + e

You can find more information on how to use i3 in i3 userguide