Author Archives: Przemysław Sikora

Raspberry Pi jako Zabbix Proxy

Raspberry Pi zyskują co raz większą popularność, a to dzięki małej wielkości, dużym możliwościom i niskiej cenie. Przedstawię poniżej krótką instalację zabbixa-proxy, czyli „modułu” umożliwiającemu monitorowanie urządzeń umieszczonych wewnątrz naszej sieci bez dostępu po publicznym adresie IP. Przystępujemy więc do instalacji i wstępnej konfiguracji.

wget https://repo.zabbix.com/zabbix/4.2/raspbian/pool/main/z/zabbix-release/zabbix-release_4.2-2%2Bbuster_all.deb
dpkg -i zabbix-release_4.2-2+buster_all.deb
apt-get install zabbix-proxy-mysql

Następnym krokiem jest konfiguracja bazy danych.

mysql
create database zabbix character set utf8 collate utf8_bin;
grant all privileges on naszabazadanych.* to naszuzytkownik@localhost identified by 'naszetrudnehaslo';
quit
zcat /usr/share/zabbix-proxy-mysql/schema.sql.gz | mysql zabbix

Następnie musimy wyedytować plik konfiguracyjny tj. „/etc/zabbix/zabbix_proxy.conf” i ustawić następujące parametry:
– Server
– Hostname
– DBHost (domyślnie localhost)
– DBName
– DBUser
– DBPassword
– ProxyMody (0 aktywny-domyślnie, 1 pasywny)

Musimy pamiętać na końcu o uruchomieniu usługi i włączeniu autostartu.

systemctl enable zabbix-proxy
systemctl start zabbix-proxy

Oczywiście nie możemy zapomnieć o dodaniu proxy w samym Zabbix-ie 🙂

Przesyłanie logów Apache/Nginx do syslog-a za pomocą modułu imfile

Logi są często jedynym źródłem wiedzy na temat awarii, czy problemów z funkcjonowaniem urządzeń lub WWW. Gromadzenie logów w jednym centralnym miejscu ma parę zalet, między innymi lepsze zarządzanie, czy monitorowanie, a co najważniejsze często jest ostatnią szansą wytropienia złośliwego użytkownika lub włamywacza. Dlatego dobrą praktyką jest odsyłanie logów przez rsyslog na zewnętrzny serwer. Continue reading →

Category: WWW

Wielopoziomowa struktura folderów w Dovecot

Ostatnio nasz klient zgłosił problem w programie pocztowym, a mianowicie komunikat „…target mailbox doesn’t allow interior mailboxes” ? Występuje on czasami, gdy chcemy przenieść katalog z wiadomościami do innego katalogu. Okazało się, że wspomniany serwer, a dokładniej Dovecot działał na domyślnych ustawieniach, czyli korzystał z formatu mbox, gdzie domyślnie nie można zagnieżdżać folderów. Continue reading →

Wdrożenie Xen 4.6 na serwerze z CentOS 7

RedHat Enterprise Linux 7 jak sama nazwa mówi, należy do jednych z najbardziej popularnych dystrybucji Linuksa przeznaczonych do zastosowań w korporacjach i dużych firmach stawiających na jakość oraz wsparcie techniczne. Jej bezpłatnym odpowiednikiem jest CentOS, który zdobył szeroką rzeszę użytkowników pośród mniejszych podmiotów gospodarnych, którym zależy na jakości, ale bez wsparcie technicznego ze strony dostawcy. Wirtualizacja umożliwia mniejszym kosztem tworzyć zaawansowane środowiska, które mogą cechować się wysoką dostępnością i skalowalnością. Przedstawię instalację i wstępną konfigurację jednej z popularniejszych tj. Xen-a w wersji 4.6. Continue reading →

Bezpieczne ssh z autentykacją per USER/GRUPA

Od jakiegoś czasu co raz częściej dajemy dostęp do ssh tylko przy użyciu klucza prywatnego. Jest to wygodne, a zarazem bezpieczne. Istnieje do tego przydatna opcja w pliku konfiguracyjnym daemona ssh, mianowicie „PasswordAuthentication”. Osobiście mam tą opcję najczęściej ustawioną na „no”. Niestety czasem pojawiają się użytkownicy, którzy mają móc tylko wrzucać pliki po sftp i to z różnych maszyn/systemów. Okazuje się, że można ustawić domyślną metodę autentykacji oraz dla każdego użytkownika/grupy oddzielną. Przykładowo pozwalamy na autoryzację bez klucza – przy pomocy hasła użytkownikowi gargamel.

Match User gargamel
PasswordAuthentication no

Pamiętajmy, żeby umieścić powyższy wpis na końcu pliku. Nie ma bowiem możliwości zakończenia/zamknięcia bloku specyficznych ustawień per user/grupa.
Inną sytuacją może być domyślne zezwalanie na logowanie bez klucza (po haśle) z wyjątkiem użytkownika admin.

Match User *,!admin
PasswordAuthentication yes

Oczywiście trzeba zrestartować daemona ssh po zapisaniu ustawień w pliku.

systemctl restart sshd

Jak wykorzystać SSH jako proste proxy?

Internet jest coraz bardziej powszechniejszym medium. Dostęp do niego nie stanowi już dla większość ludzi problemu. Powinno to nas cieszyć, z drugiej strony może prowadzić to coraz częstszych nadużyć i przestępstw komputerowych. Podstawą jest komunikacja szyfrowana SSL tj. https, imaps, smtps, „itps” :). Niestety nie każdy serwer oferuje bezpieczne połączenie. Co zrobić w takim przypadku? Jak żyć? Z pomocą przychodzi nam SSH, które oferuje dużo więcej niż tylko połączenie ze zdalnym serwerem i wydawanie poleceń w konsoli. Umożliwia ono tworzenie tunelu i proxy. Właśnie na proxy się dzisiaj skupię. Jest to proste rozwiązanie problemu korzystania np. ze stron bez https, gdzie musimy podawać login i hasło, a chcemy mieć pewność, że nie zostaną one przechwycone. Przystępujemy do konfiguracji. Wydajemy w konsoli na naszym komputerze następujące polecenie:

ssh -D numer_portu_powyżej_1024 nazwa_usera@adres_serwera_na_którym_mamy_konto_shell

Wpisujemy nasze hasło użytkownika. Do póki jesteśmy zalogowani, proxy jest dostępne. Następnie w przeglądarce ustawiamy proxy typu SOCKS w wersji 5 -> 127.0.0.1 i port taki sam jak ustawiliśmy komendą „ssh -D ….”. Po zapisaniu ustawień cały ruch z naszej przeglądarki powinien wychodzić przez nasz szyfrowany tunel SSH. Wyjątek mogą stanowić niektóre streamy lub filmy we flashu, które „idą” bezpośrednio.

Bezpieczny panel administracyjny WordPressa

WordPress należy do najpopularniejszych systemów zarządzania treścią zwanych powszechnie CMS. Zapewnienie bezpieczeństwa powinno być dla nas szczególnie ważne. Niestety wielu osoób zapomina o takich podstawowych aspektach jak dostęp do panelu zarządzania (wp-admin).

Niektórzy zmieniają url, ale wymaga to już pewnej wiedzy. Najlepiej jest wykorzystać poniższą „sztuczkę”. Wymaga ona jednak dostępu do konfiguracji vhosta na serwerze www. Prezentuję poniżej wpisy zarówno dla Nginx, jak i Apache w wersji 2.4.

location ~ ^/(wp-login\.php) {
include /etc/nginx/fastcgi_params;
fastcgi_index index.php;
fastcgi_pass unix:adres_naszego_socka;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
satisfy any;
allow ip_dozwolone_np_nasze;
deny all;
auth_basic "Folder chroniony hasłem";
auth_basic_user_file położenie_pliku_z_danymi_użytkownikami_i_hasłami;
}
Nginx
<Files "wp-login.php">
<RequireAny>
Require ip ip_dozwolone_np_nasze
AuthType Basic
AuthName "strona"
AuthBasicProvider file
AuthUserFile "położenie_pliku_z_danymi_użytkownikami_i_hasłami"
Require valid-user
</RequireAny>
</Files>
Apache

Na koniec oczywiście restart serwerów www 🙂

systemctl restart nginx

Nginx

systemctl restart httpd

Apache