Remélem erre gondoltál: 14:20:11.886622 IP suliszerver.sulinet.hu.52593 > bud02s21-in-f14.1e100.net.https: Flags [.], ack 498, win 6152, length 0 14:20:11.888121 IP suliszerver.sulinet.hu.49671 > 33676d41.educatio.hu.http: Flags [P.], seq 0:674, ack 2244, win 258, length 674: HTTP: GET /webresources/Layout/images/std-loader.gif HTTP/1.1 14:20:11.888270 IP suliszerver.sulinet.hu.49678 > 33676d41.educatio.hu.http: Flags [.], ack 466566, win 1233, length 0 14:20:11.888619 IP suliszerver.sulinet.hu.49694 > 104.19.199.151.https: Flags [P.], seq 301:386, ack 4036, win 257, length 85 14:20:11.890471 IP bud02s25-in-f3.1e100.net.https > suliszerver.sulinet.hu.55146: Flags [.], ack 171, win 284, length 0 14:20:11.891825 IP 33676d41.educatio.hu.http > suliszerver.sulinet.hu.49678: Flags [.], seq 466566:467866, ack 2189, win 276, length 1300: HTTP 14:20:11.892029 IP 33676d41.educatio.hu.http > suliszerver.sulinet.hu.49678: Flags [.], seq 467866:469166, ack 2189, win 276, length 1300: HTTP 14:20:11.892034 IP 33676d41.educatio.hu.http > suliszerver.sulinet.hu.49678: Flags [.], seq 469166:470466, ack 2189, win 276, length 1300: HTTP 14:20:11.892040 IP 33676d41.educatio.hu.http > suliszerver.sulinet.hu.49678: Flags [.], seq 470466:471766, ack 2189, win 276, length 1300: HTTP
Mivel nyilvános a lista, ezért kiszedtem a fontosabb részeket belőle, de ilyenek vannak benne. Olyan ip címek, amik a logban, itt nincsenek. Itt a syslog-nak ugyanerre az időszeletre eső része. A "kulsoip" a mi ip címünk, ezért ezt is kicseréltem a szövegben. Oct 17 14:20:11 sentinel kernel: [58876.585156] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.176 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5599 PROTO=TCP SPT=80 DPT=60574 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.585367] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5599 PROTO=TCP SPT=80 DPT=34514 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.585706] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5599 PROTO=TCP SPT=80 DPT=34516 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.585909] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5599 PROTO=TCP SPT=80 DPT=34520 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.586328] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5599 PROTO=TCP SPT=80 DPT=34518 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.586541] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5601 PROTO=TCP SPT=80 DPT=34522 WINDOW=347 RES=0x00 RST URGP=0 Oct 17 14:20:11 sentinel kernel: [58876.586830] be=> IN=enp1s0 OUT= MAC=09:ab:6e:99:4c:23:7c:ad:74:b0:0a:be:08:00 SRC=23.6.112.186 DST=kulsoip LEN=40 TOS=0x00 PREC=0x00 TTL=254 ID=5601 PROTO=TCP SPT=80 DPT=34524 WINDOW=347 RES=0x00 RST URGP=0 Na most egy kicsit mégjobban megkavarodtam, mert most látom, hogy a logban IN=enp1s0 szerepel, ami a szerver belső lába. A MAC address viszont érdekes, mert az első 6-os csoport az tényleg ennek a kártyának a macaddresse, de a többi nem tudom mi. Találtam egy ilyen sort is, ami gyakran ismétlődik: Oct 17 15:14:24 sentinel kernel: [62129.725241] be=> IN=enp3s1 OUT= MAC=ff:ff:ff:ff:ff:ff:6c:3b:6b:36:fa:d3:08:00 SRC=10.1.3.1 DST=255.255.255.255 LEN=134 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34517 DPT=5678 LEN=114 A 10.1.3.1 az egyik TP-LINK wi-fi routerünk ip címe, az enp3s1, meg a tűzfalam külső lába. A router mögül broadcastolna valaki? Fehér Sándor <[email protected]> ezt írta (időpont: 2018. okt. 17., Sze, 14:56): > Ez az iptables szekció teljesen rendben van. > tcpdump kimenet esetleg még segíthetne ha tudod küldeni vhogy. > > 2018. 10. 17. 14:52 keltezéssel, József Venczel írta: > > Megnéztem. Mind a tshark, mind a tcpdump csak olyan csomagokat tartalmaz, > ami külső ip címről belsőre megy, vagy fordítva. Olyat egyet se, hogy > közvetlenül a szerverem/átjáróm belső vagy külső lábát címezné. > Mindkettővel csak a külső lábra érkező csomagokat kapkodtam le. > > Az ide vonatkozó (INPUT) tűzfalszabályok így néznek ki: > > $IPTABLES --policy INPUT DROP > > $IPTABLES -A INPUT -i lo -j ACCEPT > > $IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > $IPTABLES -A INPUT -j LOG --log-prefix "be=> " --log-level 7 > > Előtte persze törölve van minden táblából és láncból az összes szabály. > Alapértelmezetten tehát mindent dob. > A lokális, tehát gépen belüli (127.0.0.1) forgalmat nyilván engedem. > Ezután pedig csak a folyamatban lévő kapcsolatokat engedem. > > A kérdéses csomagok biztos, hogy erre jönnek, mert mindegyik bejegyzésében > szerepel a "be=> " string. A logokban niincs olyan bejegyzés, amiben a > "<=ki " vagy az "=at= " szerepelne. Ezek az OUTPUT és a FORWARD láncokat > jelölik. > > Eddig azt hittem ez így jó. > > Mit csinálok rosszul? > Ha ez nem DOS, akkor mi? > > Üdv, > Venczel József > > Fehér Sándor <[email protected]> ezt írta (időpont: > 2018. okt. 17., Sze, 14:11): > >> Ha ddos támadásod van, az rendre az input láncon lesz, mert a >> szolgáltatásod a publikus ip-n van. /portforward esetén is, de akkor persze >> a routeren logolod/ >> Ha tényleges ddos volna, szerintem megsínylené a szolgáltatásod, mivel >> tutira lehalna a sok kérés miatt. >> Jó volna egy tcpdump és/vagy wireshark annak kiderítésére, hogy mik azok >> a gyanús csomagok. >> >> Ha iptablesed van, a ddos védelmet rate limit modullal tudod megoldani, >> vagyis 1 másodperc alatt csak kb 30 kapcsolódást engedsz a többit dobod. >> Ezt persze majd neked kell behangolni, hogy mennyi az ideális, a 30 csak >> példának okáért van. >> A ddos mellé szoktam icmp rate limitet is csinálni, mert aki komolyan >> nyomja a ddos-t, az icmp is tuti megpróbálja. >> vpsnél mindennapos a ddos támadás(szerverplexnél vagyok), mikrotikre van >> BEVÁLT megoldásom, ha érdekel. >> >> 2018. 10. 17. 14:02 keltezéssel, József Venczel írta: >> >> Szia! >> >> Húha, akkor nagyon nem értek valamit... :( >> >> Igen, jól értelmezed. >> >> A válaszok nem a FORWARD láncra kellene, hogy kerüljenek? >> Mert ezek az INPUT láncon jönnek. >> És miért különböző célportokra jönnek? Miért nem a 80-asra, vagy a >> 443-asra? >> >> Bocs, ha hülyeségeket kérdezek! >> Eddig azt hittem értem mit csinálok... :( >> de akkor most már nem értem az egészet. >> >> Üdv, >> Venczel József >> >> Veres Sándor <[email protected]> ezt írta (időpont: >> 2018. okt. 17., Sze, 13:45): >> >>> Szia! >>> >>> 2018. 10. 17. 13:09 keltezéssel, József Venczel írta: >>> > Van egy tűzfalam. Úgy állítottam be, hogy alapból mindent tiltok, csak >>> > azt engedem, amit én akarok, ez meg csak a webes forgalom, de az is >>> > csak a kliensek felől irányuló kérések alapján. >>> > Tehát, ha már kiépült kapcsolathoz tartozik, akkor jöhet, egyébként >>> > meg naplózom és DROP. >>> > Valahol, régebben olvastam, hogy ezt így érdemes csinálni és lehet, >>> > hogy tényleg... >>> > >>> > Épp a szervereim központi naplózását próbálom megoldani, amikor arra >>> > lettem figyelmes, hogy a tűzfal syslog-jában van egy csomó, különböző >>> > ip címekről jövő csomag. Mind 40 bájtos és mindegyik forrásportja a >>> > 80-as és a 443-as port, a DPT (1-65565) változó. Mindegyik célcíme a >>> > tűzfalam publikus lába. >>> > >>> > És itt jön az első kérdés: anno nem kértem semmilyen portnyitást a >>> > tűzfalra. Akkor ezek a csomagok hogyan érnek el hozzám? Nem kéne már a >>> > NIIF vagy KIFÜ vagy nemtomki tűzfalán fennakadniuk? >>> >>> >>> Ha jól értelmezem ez a szervered egy átjáró, amely NAT-ol is. Akkor ezek >>> a csomagok szerintem a klienseidtől induló kérésekre érkezett válasz >>> csomagok, amelyeknek a forrás portja természetesen 80 és 443, mivel a >>> klienseid ezeket "címezték meg". >>> >>> Veres Sándor >>> >>> >>> _______________________________________________ >>> Techinfo mailing list >>> [email protected] >>> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo >>> Illemtan: http://www.szag.hu/illemtan.html >>> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >>> >> >> >> _______________________________________________ >> Techinfo mailing [email protected] >> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo >> Illemtan: http://www.szag.hu/illemtan.html >> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >> >> >> -- >> >> _______________________________________________ >> Techinfo mailing list >> [email protected] >> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo >> Illemtan: http://www.szag.hu/illemtan.html >> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >> > > > _______________________________________________ > Techinfo mailing [email protected] > Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ > > > _______________________________________________ > Techinfo mailing list > [email protected] > Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ >
_______________________________________________ Techinfo mailing list [email protected] Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
