Hogyan kezeljük a "Possible attack detected. This action has been logged." hibaüzenetet az ISPConfig kezelőpanelünkben

botond küldte be 2021. 03. 23., k – 09:19 időpontban
Hogyan kezeljük a "Possible attack detected. This action has been logged." hibaüzenetet az ISPConfig kezelőpanelünkben | Linuxportál

Tartalom

 

Bevezető

Az ISPConfig különféle védelmi rendszereket alkalmaz, hogy biztonságos legyen, többek között az IDS (Intrusion Detection System) technológiát is. Előfordul azonban, hogy ennek a beállítása esetleg túl érzékeny, és minket is kitilt a kezelőpanelből. Ebben a kis hibaelhárítóban megnézzük, hogy mit tehetünk, ha az ISPConfig kezelőpanelünk nem enged be minket, hanem helyette kapunk egy "Possible attack detected. This action has been logged." hibaüzenetet.

 

 

A hibajelenség

Amikor betöltjük az ISPConfig kezelőpanelünk beléptető URL címét, akkor üres fehér képernyőn kapjuk a következő hibaüzenetet: "Possible attack detected. This action has been logged."

 

A megoldás

Az ISPConfig IDS beállításai túl érzékenyre vannak állítva, ezért előfordulhat, hogy saját magunkat is támadónak vél, de az is lehetséges, hogy valódi külső ISPConfig elleni támadási próbálkozások állnak a háttérben.

A kezelőpanel biztonsági beállításait a /usr/local/ispconfig/security/security_settings.ini fájlban találhatjuk, melynek eredeti tartalma a következő:

[permissions]
allow_shell_user=yes
admin_allow_server_config=superadmin
admin_allow_server_services=superadmin
admin_allow_server_ip=superadmin
admin_allow_remote_users=superadmin
admin_allow_system_config=superadmin
admin_allow_server_php=superadmin
admin_allow_langedit=superadmin
admin_allow_new_admin=superadmin
admin_allow_del_cpuser=superadmin
admin_allow_cpuser_group=superadmin
admin_allow_firewall_config=superadmin
admin_allow_osupdate=superadmin
remote_api_allowed=yes
password_reset_allowed=yes
session_regenerate_id=yes
reverse_proxy_panel_allowed=none

[ids]
ids_anon_enabled=yes
ids_anon_log_level=1
ids_anon_warn_level=15
ids_anon_block_level=20
ids_user_enabled=yes
ids_user_log_level=1
ids_user_warn_level=27
ids_user_block_level=30
ids_admin_enabled=no
ids_admin_log_level=1
ids_admin_warn_level=90
ids_admin_block_level=100
sql_scan_enabled=yes
sql_scan_action=warn
apache_directives_scan_enabled=yes
nginx_directives_scan_enabled=yes

[systemcheck]
security_admin_email=root@localhost
security_admin_email_subject=Security alert from server
warn_new_admin=yes
warn_passwd_change=no
warn_shadow_change=no
warn_group_change=no

Ebben középen találhatók az IDS beállításai. Ezek közül az első nyolc beállítással kell most foglalkoznunk:

  • ids_anon_enabled=yes
  • ids_anon_log_level=1
  • ids_anon_warn_level=15
  • ids_anon_block_level=20
  • ids_user_enabled=yes
  • ids_user_log_level=1
  • ids_user_warn_level=27
  • ids_user_block_level=30
A rendszer figyeli a gyanús tevékenységeket, és a /usr/local/ispconfig/interface/temp/ids.log naplófájlban gyűjti ezeket össze. Ha a pontszám eléri a log_level értékét, akkor az adott tevékenység bekerül a naplóba. Ha eléri a warn_level értéket, akkor figyelmeztet bennünket a felületen a "Monitor" főmenü "Áttekintés" almenüjében megjelenő listában a "The System-Log" sorában. Itt ha kinyitjuk a részleteket, akkor láthatjuk is az adatbázisban tárolt naplót is, ahol megjelennek az "PHP IDS Alert.Total impact: ..." kezdetű bejegyzésekben a probléma lehetséges okai. Ha pedig a pontozások elérik a block_level értéket, akkor kitilt a teljes rendszerből. Az "anon" részek hivatottak az ismeretlen (nem felhasználói eredetű) tevékenységek figyelését szabályozni, az "user" részek pedig a felhasználói tevékenységeket.

Itt két dolgot tehetünk: vagy megemeljük az "ids_anon_block_level" és az "ids_user_block_level" pontszámait akkorára, ahol már beenged minket a kezelőpanel, vagy egyszerűen kikapcsoljuk mintkét figyelő részt a "ids_anon_enabled=no" és az "ids_user_enabled=no" értékekre állításával.

Miután lementettük a fájlt, az ISPConfig kezelőpanel beenged. Ezután körülnézhetünk a fentebb is említett "Monitor" menü "System-Log" almenüjében, és ellenőrizhetjük, hogy mi okozta a kitiltást.

A kezelőpanel frissítésekor ez a konfigurációs fájl felülírásra kerül a frissítőcsomag által, ezért a verzió frissítés után újból el kell végezni ezeket a beállításokat.

 

 

Konklúzió

Természetesen előfordulhatnak másfajta kitiltások is, amik más hibaüzenetet adhatnak, de általánosságban az IDS jellegű biztonsági hibákat így tudjuk kezelni.

 

Kapcsolódó tartalom, hasznos linkek:

 

Címkék
hibaelhárítás
ISPConfig
web hoszting kezelopanel
IDS
biztonság
konfiguráció