Brute-force támadás kivédése

Linux-kezdő

Sziasztok,

szeretném megkérdezni, hogy hogy lehetne beállítani egy Debian alatt, hogy ha valaki elhibázza a kódot (erőből szeretne betörni), x szer, akkor y ideig blokkolja az IP-jét? A Legjobb lenne valami általánosságban tudná figyelni a rendszert egy program (mindenütt Debian alatt, ahol jelszót kér a rendszer pl: SAMBA, PHPadmin, MySQL, SSH, FTP stb....), vagy már indulásnak az is elég lenne, ha bizonyos "kedvenc" támadási helyeknél tiltana le a rendszer pl: SSH.

Sőt, az is érdekes lehetne, hogy ha erről tudna küldeni egy e-mailt a rendszer.

Előre is köszönöm a segítségeteket!

KALMI

  • 22998 megtekintés

( KeeF | 2013. 05. 31., p – 00:42 )

szerintem a 'fail2ban'-t keresed. mindazokat tudja amit felsoroltal. alapbol csak az ssh-t figyeli az auth.log-ban.

( elod v | 2013. 05. 31., p – 05:53 )

Egy jó jelszópolitika sok bajtól megvéd.

a tökéletes biztonság az hogy ha nem is tárolsz semmi adatot csak a ramban fut minden és természetesen soha nem kapcsolod be a gépet.
de tovább megyek. ne is használj gépet és akkor nincs aggodalom :D

de fail2ban a javaslatom nekem is.
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/

A denyhost az csak az ssh-t figyeli alapbol, de tud blokkolni mindent ( ssh login probalkozas alapjan )

A fail2ban meg szinte barmit megeszik ha megkered a servicet hogy szepen mondja a fail2ban-nek hogy mi a baja, ( ersd.: ertelmes logformatumut tud elmezni fuggetlenul a szolgaltatastol http,ssh,mysql,ftp, akarmi )

Szoval mivel jobb? Talan egyszerubb konfiguralni, de amugy meg rosszabb.

( elod v | 2013. 05. 31., p – 15:24 )

Hát nem tudom, mintha senki sem látna csak fail2ban-t maga előtt...

Snort-ot nem használ senki?

Csak az SSH-ra van nagyon egyszerű megoldás. Lekapcsolod a jelszavas belépést és csak key-el fogadod el, illetve ha egy-két felhasználós rendszerről van szó, akkor magyar felhasználónevet használsz jó password-al.

Rengetegen jönnek felém is, engem nem zavar hogy próbálkoznak és töltik a logot. Bejönni úgysem fognak, pedig van egy pár felhasználó whitelist-en.

( hg2ebh | 2013. 05. 31., p – 15:35 )

SSH-hoz a /etc/hosts.allow-ba:

sshd: 1.1.1.1/19 # elso IP tartomany
sshd: 2.2.2.2/24 # masodik IP tartomany
sshd: 9.9.9.9/23 # sokadig IP tartomany
sshd: .hu # .hu -ra feloldhato egyeb host
sshd: ALL: DENY # minden mas mehet levesbe

A felsorolt IP tartományokból és a .hu reverse fqdn-re feloldható IP címekről beenged az SSH, minden mást elhajt.
Ez nem véd hazai IP-ről indított bruteforce ellen, csak alapból kizár egy nagycsomó külföldi IP-t.

Ha jól értem a modul "geoip-t /xtables-addon" valahogyan felteszem, akkor kiadom ezt az utasítást "iptables -A INPUT -m geoip ! --src-cc HU -j DROP", akkor minden nem Magyarországról érkező emberke alapból ki lesz tiltva?
Sőt kérnék egy kis segítséget, hogy a " geoip-t /xtables-addon "-t hogyan lehetne fel tenni Debian alá. Köszi :)

Jól érted. Persze az eredmény csak annyira lesz pontos, amennyire a geoip adatbázis pontos a legenerálása pillanatában. Nekem nem okozott még problémát, mert nincs nagy mozgás már országok között a kiosztott IPv4-es címtartományokban, de azért a fontosabb helyekről nem árt tesztelni.

http://sourceforge.net/projects/xtables-addons/
- a kernelednek megfelelő verziót letöltöd és kicsomagolod
- az INSTALL file minden lépést tartalmaz.

Bocsi, lehet, hogy mindent tartalmaz, de nem sikerül a helyes telepítésre rávennem. :((( Ezért szeretnék kérni extra segítséget, Ezer köszönet!
---
$ ./configure
$ make
# make install
---
Ezt lefuttatom, akkor sikeresen le fut a ./configure parancs, de a make és a make install hibával leáll.:(

Próbáltam így is, de így a rendszer nem tudja kezelni a függőségeket :(

Hiba:
---
# sudo apt-get install -f
Csomaglisták olvasása... Kész
Függőségi fa építése
Állapot adatok olvasása... Kész
Függőségek javítása... sikertelen.
Az alábbi csomagoknak teljesítetlen függőségei vannak:
xtables-addons-dkms : Függ ettől: xtables-addons-common (>= 2.2) de az nincs telepítve
Függ ettől: dkms (>= 2.1.0.0) de az nincs telepítve
E: Hiba, a pkgProblemResolver::Resolve töréseket generált, ezt visszafogott csomagok okozhatják.
E: Nem lehet javítani a függőségeket
----

"hogy lehetne beállítani egy Debian alatt"
"iptables v1.4.8"
"xtables-addons-dkms : Függ ettől: xtables-addons-common (>= 2.2) de az nincs telepítve"
Pontosan mit is használsz? Mert a te rendszereden 2.2-nél magasabb verziójú xtables-addons-common csomagot követel meg az xtables-addons-dkms, viszont a jelenleg stabil Wheezyben lévőben az 1.42 a minimum, míg a jelenleg testing állapotú Jessie is 1.42-t kér. Csak az unstable-ben van 2.2-es követelménye az xtables-addons-dkms-nek. Ez pedig a nevében hordozza, hogy nem kizárt, hogy problémák merülhetnek fel vele.

Ehhez képest az alábbi hozzászólásodban az iptables verziója 1.4.8, miközben az unstable-ben 1.4.18 van, a testingben és a stable-ben 1.4.14, és csak a Squeeze tartalmazott 1.4.8-as verziót. Az a sejtésem, hogy eléggé össze van keveredve a rendszered, van komponens Squeeze-ből (6.0), és Sidből is, és lehet hogy a maradék Wheezy (7.0) vagy Jessie. (Persze ha van ok rá, lehet ilyet csinálni, de vannak korlátai. Viszont nem vagyok benne biztos, hogy te valóban ilyen hibrid rendszert szerettél volna.)

"de így a rendszer nem tudja kezelni a függőségeket"
Már hogyne tudná! Ha teljesíthetetlen függőség van, akkor ott vélhetőleg valami nem kerek a repositoryk megadásánál, vagy egyszerűen az unstable pillanatnyilag ilyen állapotban leledzik. Vagy ahogy írja a hibaüzenet, holdban lévő függő csomag is lehet oka. Vagy az előbb említett dolog. Nem csak emiatt, de érdemes lenne a kiválasztott release-re upgrade-elni a teljes rendszert.

 
Lássuk, hogy is megy ez, tényleg egyetlen sor az egész: 


root@debian:~# apt-get install xtables-addons-dkms
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libisc84 libisccc80 liblwres80 libxml2 sgml-base xml-core
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  binutils cpp cpp-4.6 cpp-4.7 dkms fakeroot gcc gcc-4.6 gcc-4.6-base gcc-4.7 libc-dev-bin libc6-dev libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 linux-headers-3.2.0-4-686-pae
  linux-headers-3.2.0-4-common linux-headers-686-pae linux-kbuild-3.2 linux-libc-dev make manpages-dev menu xtables-addons-common
Suggested packages:
  binutils-doc cpp-doc gcc-4.6-locales gcc-4.7-locales gcc-multilib autoconf automake1.9 libtool flex bison gdb gcc-doc gcc-4.6-multilib libmudflap0-4.6-dev gcc-4.6-doc libgcc1-dbg libgomp1-dbg
  libquadmath0-dbg libmudflap0-dbg binutils-gold gcc-4.7-multilib libmudflap0-4.7-dev gcc-4.7-doc libitm1-dbg libcloog-ppl0 libppl-c2 libppl7 glibc-doc make-doc menu-l10n gksu kdebase-bin
  kdebase-runtime ktsuss sux libtext-csv-xs-perl
Recommended packages:
  linux-headers-generic linux-headers
The following NEW packages will be installed:
  binutils cpp cpp-4.6 cpp-4.7 dkms fakeroot gcc gcc-4.6 gcc-4.6-base gcc-4.7 libc-dev-bin libc6-dev libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 linux-headers-3.2.0-4-686-pae
  linux-headers-3.2.0-4-common linux-headers-686-pae linux-kbuild-3.2 linux-libc-dev make manpages-dev menu xtables-addons-common xtables-addons-dkms
0 upgraded, 28 newly installed, 0 to remove and 0 not upgraded.
Need to get 44.7 MB of archives.
After this operation, 129 MB of additional disk space will be used.
Do you want to continue [Y/n]?
...
...
Setting up xtables-addons-dkms (1.42-2) ...
Loading new xtables-addons-1.42 DKMS files...
First Installation: checking all kernels...
Building only for 3.2.0-4-686-pae
Building initial module for 3.2.0-4-686-pae
Done.
...
...
xt_geoip.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/3.2.0-4-686-pae/updates/dkms/
...
...
depmod.......

DKMS: install completed.
Processing triggers for menu ...
root@debian:~#

 
Ennyi az xtables-addons. És már meg is van a geoip modul az iptables számára: 


root@debian:~# iptables -A INPUT -m geoip ! --src-cc HU -j DROP
Could not open /usr/share/xt_geoip/LE/HU.iv4: No such file or directory
iptables v1.4.14: Could not read geoip database
root@debian:~#

 
Miután hozzáadod az adatbázist is, működni fog rendesen.

Igen valóban sikerült ezek szerint valamit kavarnom.

A rendszerem:

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.7 (squeeze)
Release: 6.0.7
Codename: squeeze
---

A problémám ott kezdődött, hogy ha simán lefuttatom a "apt-get install xtables-addons-dkms" parancsot, akkor ez az eredményem:
---
# apt-get install xtables-addons-dkms
Csomaglisták olvasása... Kész
Függőségi fa építése
Állapot adatok olvasása... Kész
E: Az alábbi csomag nem található: xtables-addons-dkms
---
Ezért utána kerestem (xtables-addons-dkms) és ezt találtam:
http://packages.debian.org/unstable/main/xtables-addons-dkms

Itt hozzáadtam a "/etc/apt/sources.list" telepítő csomaghoz a "deb http://ftp.de.debian.org/debian sid main ", ami ezek szerint nem "squeeze", hanem "sid", amit eddig nem vettem figyelembe...:(. Természetesen ezek után lefutott már a "apt-get install xtables-addons-dkms" parancs, de ezek szerint hibásan, amit be is küldtem...

Kérdésem, hogy mit kellene változtatnom "squeeze" telepítő csomagban "/etc/apt/sources.list", hogy a telepítés rendben lefusson és ne kavarjam össze a rendszereket, mivel ahogyan látom csak "wheezy" verzió elérhető "squezze" nem?

Előre is nagyon köszönöm a segítségedet, egyre jobban kezdem érteni, hogy mit csinálok :) Bár, ha ezt megoldottuk, akkor a következő kérdésem lesz, hogy hogyan lehet az össze kavart rendszeremet helyre rakni ;)!

"Release: 6.0.7"
"A problémám ott kezdődött, hogy ha simán lefuttatom a "apt-get install xtables-addons-dkms" parancsot, akkor ez az eredményem"
A Squeeze-ben még nem volt xtables-addons-dkms csomag, és mivel nem írtad, az aktuális stabil kiadást feltételeztem.

"ha ezt megoldottuk, akkor a következő kérdésem lesz, hogy hogyan lehet az össze kavart rendszeremet helyre rakni"
"Kérdésem, hogy mit kellene változtatnom "squeeze" telepítő csomagban "/etc/apt/sources.list", hogy a telepítés rendben lefusson és ne kavarjam össze a rendszereket"
Azt javasolnám, hogy uninstalláld a Sidből feltelepült xtables-addons-dkms csomagot, és mindazokat, amelyeket magával húzott függőségként, majd a sources.list-ben csere minden wheezy-re, ezután upgrade-eld a teljes rendszert, és végül tedd fel onnan a xtables-addons-dkms csomagot. Ezzel nem mellesleg lesz egy stable rendszered.

Ha valamiért egyelőre ragaszkodsz a Squeeze-hez, akkor először töröld a Sidből származó xtables-addons-dkms csomagot és az esetleg vele felment függőségeket, írd vissza a sources.list bejegyzéseit squeeze-re, majd a module-assistant és az xtables-addons-common csomagokat tedd fel. Utóbbi leírásában ott van a kiadandó parancs. A végén pedig előáll és települ a modulokat tartalmazó xtables-addons-modules-`uname -r` csomag.

Nagyából értem elvileg meg is csináltam egy Squeeze és egy wheezy rendszeren is. Az eredmény mind a kettőn egy forma lett:
---
# iptables -A INPUT -m geoip ! --src-cc HU -j DROP
Could not open /usr/share/xt_geoip/LE/HU.iv4: No such file or directory
iptables v1.4.14: Could not read geoip database

---

iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
---

Szerintem valami csak el maradt még, mert valahol látnom kellene a korlátozást, vagy nem "-L"-el kell lekérdeznem :)

Üdv.

KALMI

A geoip adatbázist nem szállítja a Debian csomagként, tehát a telepített dolgok között nem fogod megtalálni, neked kell gondoskodnod róla. Az MaxMind oldaláról töltheted le az GeoLite adatbázisokat. Az iptables geoip moduljának működéséhez elég az, amit a modullal szállított egyszerű script letölt. Az addons telepítése után: 


# /usr/lib/xtables-addons/xt_geoip_dl
# mkdir /usr/share/xt_geoip
# cat GeoIP*.csv | /usr/lib/xtables-addons/xt_geoip_build -D /usr/share/xt_geoip

A jelenlegi adatbázis szerint így néznek ki a számok: 


# grep -c HU GeoIPCountryWhois.csv
404
# wc -l GeoIPCountryWhois.csv
81216 GeoIPCountryWhois.csv
#

Ezek nem olyan vészesen nagy értékek, nyilván van CPU-igénye, de okosan elhelyezve nem kell lényeges teljesítménycsökkenéssel számolni. És nyilván nem is az összes csomagot kell geoip segítségével ellenőrizni.

"nem jobb fixen betölteni azt a 404 sort"
A geoip adatbázist betöltöd (nem a CSV-ben keres a kernel), és a netfilter keretein belül azon nézel egyezést.

"mint minden ellenőrzendő csomagot átfuttatni a targeten?"
De éppen ezt próbáltam jelezni, hogy nem minden csomagot kellene egy ilyen ellenőrzésen átfuttatni, hanem értelmes szabályrendszert kell kialakítani. Tehát pl. stateful tűzfal esetén TCP-nél a NEW állapotú SYN csomagokra, a többire felesleges.

Persze akár tehetnéd azt is, hogy a geoip adatbázisból manuálisan gyártasz egy külön láncot vagy IP setet, ahelyett hogy a geoip modult használnád. Ezek egymáshoz viszonyított teljesítményigényét meg lehetne mérni, de ha nincs túl sok új kapcsolat, nem lesz érezhető a geoip esetleges lassabb volta.

konkrétan arra gondoltam, hogy egy SIP proxyt védenék vele, külföldről jövő csomagoktól.
(abban a reményben, hogy az itthonról jövő kísérletek - némi hatósági ráhatással - előfizetőhöz köthetők)

nyilván egy külön chain-be lenne irányítva a sip.proxy udp/5060-ra irányuló csomag, de
itt minden csomagot forrás szerint kell vizsgálni (OK, csak INVITE-t kéne, de feltételezem gyorsabb a forrást ellenőrizni, mint belenézni a csomagba)
Szóval arra gondoltam, hogy a firewall gyorsabban végigfut 4-500 soron, minthogy a külön target lefusson rá.

Elvileg feltelepítettem az addon-t, de ez a hiba előjött, ami azt sejteti, hogy valamit csak nem jól csináltam. Több gépen is megnéztem és hasonló az eredmény. Egy olyan kérésem lenne, hogy az addon install lépéseit leírnád köszi!

---
~# iptables -A INPUT -m geoip ! --src-cc HU -j DROP
iptables v1.4.8: Couldn't load match `geoip':/lib/xtables/libipt_geoip.so: cannot open shared object file: No such file or directory

Try `iptables -h' or 'iptables --help' for more information.
----

KALMI

Kb. Értem, és valóban egy jó 5let...:) a "/etc/hosts.allow" tartalmát beszúrnád nekem, hogy egyértelműbb legyen a dolog és nehogy kizárjam magam :)

U.I.
Amúgy a tiltott cím tartományból érkezők próbálkozásai naplózásra kerülnek, vagy azzal végkép nem foglalkozik a server?

geoip adatbázis: többé-kevésbé pontos adatbázisa annak, hogy melyik címtartományt melyik szolgáltatónak osztották ki. Pl. 80.99.219.0/24 a magyar UPC-nél van, ha ebből a tartományból jön kérés, akkor az jó eséllyel Magyarország területéről jött.

hosts.allow: a gép IP-jének reverse DNS-e .hu -ra végződik-e. A fentebbi UPC-s példánál maradva a 80.99.219.136 reverse DNS-e catv-80-99-219-136.catv.broadband.hu, tehát engedélyezett lenne. Viszont a világ bármelyik géptermében lehet olyan szervered, aminek .hu-ra végződik a reverse, ez valójában nem terület alapú szűrés, inkább olyasmi, hogy "a magyaroknak köze van hozzá".

Arra mindkettő jó, hogy a kínai, román, koreai és török próbálkozásokat távol tartsd, ha egyébként nem akarsz szolgáltatni ezekbe az országokba. De ahogy írták is, mindkettő adhat fals eredményt, ezért legalább a fontos ügyfeleket ellenőrizni kell az élesítés előtt.

Természetesen, mint ahogy az említett geoip alkalmazásánál is lehet ilyen. De azért reméljük, hogy ilyet mindenki ezt a kérdést is megfontolva implementál, és nem gondolkodás nélkül másolja le a fenti példát az 1.1.1.1/19-től a .hu-ig.

Vagy van egy vagy több stabil ugródeszkája, amely(ek) IP-i a megfelelő reverse DNS bejegyzésekkel bírnak; vagy van VPN-je a gépre vagy megfelelő IP-vel rendelkező hálózatba; vagy egyszerűen van helyettese, aki meg tudja oldani a megadott korlátozások között a problémát stb.

Nem a hosts.allow az egyetlen módszer, viszont megfontolásra érdemes. Ötleteket vetettünk fel, a konkrét megvalósítás az adott eset és helyzet függvénye.

( gthomas | 2013. 06. 05., sze – 05:51 )

Csak adalék, hogy a törési tempó csökkenjen:
# /etc/rc.local
# IP-nként percenként csak 3 kapcsolódást enged
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

GT

Nem feltétlen csökken, az IP könnyen változtatható. Elég ha van egyetlen proxy szerverhez hozzáférése a támadónak, akkor máris percenként 6 kapcsolódási lehetősége van. Aki ilyesmire gondol, az viszont már nem egyetlen proxyval fog játszadozni.

Szóval ez is csak olyan, ami a szárnyait próbálgató Pistike ellen még megvéd, de komolyabb támadótól nem.

( zx81 v | 2013. 06. 05., sze – 07:31 )

portsentry-t senki nem hozta fel a listába, pedig az is elég korrekt holmi.
---
debian stable

( nagysa v | 2013. 06. 05., sze – 08:26 )

Én már sok sok évvel ezelőtt elvágtam a gordiuszi csomót.
A szervereken openvpn van telepítve és a nem publikus szolgáltatások csak azon keresztül érhetőek el. A tűzfalban csak a nyilvános szolgáltatásra szánt portok vannak engedélyezve.

Igaz így is játszom a fail2ban-nal imap stb. esetén.

( dash | 2013. 06. 05., sze – 15:25 )

Leragadtatok a recent match-nél és a többi régóta létező dolognál. Azóta sok-sok nyalánkság került pl. az xtables-addonsba. :-)

----------
[GB ≠ GiB] [MB ≠ MiB] [kB ≠ kiB] [1000 ≠ 1024] [Giga ≠ gram] [Mega ≠ milli] [Kelvin ≠ kilo] [Byte ≠ bit]

( gyko v | 2013. 10. 28., h – 22:40 )

ez a geoip jó, mit szenvedtem anno a ripe adatbázisból whitelist készítéssel...
könyvjelzőt neki

( PtY | 2013. 10. 29., k – 20:00 )

Password auth none. Alap. Nincs olyan, hogy elhibázza a kódot. Ha nem azt kapja vissza a paraszt, hogy rossz user/jelszó, hanem azt, hogy no publickey, nem is fog próbálkozni többet, mert rájön, hogy esélytelen. És ezt már a robotjaik is tudják parse-olni.
--
PtY - www.onlinedemo.hu