Proxmox Mail Gateway – Gelen maillerin içerisindeki URL’leri VirusTotal.com ile kontrol etme

Opensource Mail Gateway ürünü olan proxmox mailgateway’in(PMG) kendi içerisinde bir çok filtreleme katmanı bulunuyor. Bunlara ek olarak bir çok ücretli mail gateway yazılımında dahi bulunmayan bir entegrasyonu hep birlikte yapalım. Bunun için PMG’nin Custom Check Interface özelliğinden faydalanacağiz.

Öncelikle;

virustotal üyeliği açarak api yönlendirmelerini takip edip üyeliğimize ait bir api key almamız gerekmektedir. virustotal’e sorgu atarken bu api keyden faydalanacağız.

Önemli Not: virustotal free üyelikde günde 500 sorguya kadar izin vermektedir. premium fiyatları dolar bazlı olduğundan ve astarı yüzünü geçtiğinden şöyle bir çözüm ürettim.

bir url’i virustotal’e sorguladıktan sonra sonucunu proxmox içerisinde yer alan postgres db’ye yazdım. ve aynı url tekrar geldiğinde son 7 gün içerisinde sorgulamışsam, tekrar virustotal’den sorgulamadım yerel db’imde yer alan sonuçları referans aldım.

/etc/pmg/pmg.conf dosyasında admin bölümünde custom check’i enable edelim.

section: admin
    custom_check 1

Custom check interface bash scriptini default ayarlarda “/usr/local/bin/pmg-custom-check” path’ine yazmamız gerekiyor. İsterseniz bu path’i de değiştirebilirsiniz. Burada oluşturduğumuz bir bash script ile asıl işi yapacak olan python dosyasını çağıracağız.

Bash script dosyamız ile /home/pmg-custom-check.py yolundaki python dosyamızı çağırıyoruz. “echo "$python_sonuc" satırında python dosyamızdan aldığımız yanıtı proxmox’a geri gönderiyoruz.

python dosyamız;

Wazuh Tüm Syslog’ları Arşivlemek

Wazuh default’ta tüm logları saklamıyor. Logları alıyor>Eşleştiği bir kural var ise işliyor ve discover ekranında gösteriyor, eşleştiği bir kural yok ise logu uçuruyor. Logları saklaması için global configin altında bulunan “<logall>no</logall>” ayarını ” yes” yapmak gerekir. Bu durumda aşağıdaki dosyaya tüm logları yazacaktır.

<logall>yes</logall> şeklinde değiştirirsek; topladığı tüm logları /var/ossec/logs/archives/YIL/AY/*.log dosyasına yazacaktır.

Eğer logları json formatında saklamak istersek;
<logall_json>no </logall_json> ayarını yes olarak güncellemek gerekir. bu durumda logları aşağıdaki dosyada saklayacaktır.

/var/ossec/logs/archives/YIL/AY/*.json

Tabi her iki ayarı değiştirdikten sonra wazuh manager servisini restart etmemiz gerekir.

systemctl restart wazuh-manager

Frappe Bench Fonksiyonun Test Edilmesi

Bir python fonksiyonu yazdınız ve bench altında nasıl çalışacağını test etmek istiyorsunuz. Bu durumda aşağıdaki syntax kullanılarak fonksiyonu çağırabilirsiniz.

tabi bench komutunun çalışabilmesi için frappe-bench dizini altında olmalısınız.

"bench --site siteadi execute fonksiyon yolu"
Örn;
"bench --site erp.sirketim.com execute erpnext.modules.hr.doctypes.events.benimfonksiyonum"

Frappe Bench “Can’t connect to (‘127.0.0.1’, 8000)” Sorunu

Zaman zaman bench restart edildiğinde gunicorn servislerini durduramıyor. Bu nedenle gunicorn servisleri restart olamıyor ve uygulama yanıt vermemeye başlıyor.
Bu senaryoda web.error.log dosyasında gunicorn’un start edilemediğine dair logları görebilirsiniz.

==> web.error.log <==
[2023-11-17 10:44:20 +0300] [377891] [ERROR] Can't connect to ('127.0.0.1', 8000)
[2023-11-17 10:44:21 +0300] [377939] [INFO] Starting gunicorn 20.1.0
[2023-11-17 10:44:21 +0300] [377939] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2023-11-17 10:44:21 +0300] [377939] [ERROR] Retrying in 1 second.
[2023-11-17 10:44:22 +0300] [377939] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2023-11-17 10:44:22 +0300] [377939] [ERROR] Retrying in 1 second.

Çözüm;

Gunicorn servislerini zorla stop ettirmek ve bench’i tekrar başlatmak gerekiyor.

ps -A | grep gunicorn komutuyla çalışan gunicorn servislerinin pidleri alınabilir.
sudo kill pid1 pid2 pid3 komutuyla servisler zorla durdurulur(Zaman zaman işe yaramıyor killall ve pkill komutları ile de denenebilir.)
ps -A | grep gunicorn komutuyla servislerin durup durmadığı kontrol edilir.
bench restart komutu ile bench yeniden başlatılır.