Forum » Operacijski sistemi » IPTABLES in TCP flags problem
IPTABLES in TCP flags problem
Bojan xxxx ::
Živjo,
mi lahko kdo pojasni, kaj je najverjetneje uporabnik počel, da je takrat, ko je dostopal do WWW strani letel ven pri teh IPTABLES pravilih:
#### Cekiranje TCP flags
$IPTABLES -A INPUT -p tcp -j in_valid_tcp
$IPTABLES -A in_valid_tcp -m state --state INVALID -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ALL NONE -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,FIN FIN -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,PSH PSH -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,URG URG -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags SYN,FIN SYN,FIN -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags SYN,RST SYN,RST -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags FIN,RST FIN,RST -j log_drop
$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop
kar je potem v logfajlu sproduciralo tole:
Dec 15 10:05:31 [kernel] #### log_drop ####IN=eth0 OUT= MAC=xx:xx:xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=5125 PROTO=TCP SPT=47734 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0
(IP-je in MAC sem pobrisal ven ...)
Takih zadev je iz istega IP-ja kar nekaj, cca 20/dan, zadnje 3 dni.
Ima kdo kakšno idejo ... Naj se zaradi tega sekiram, naj dropnem vse, kar prihaja iz tega IP-ja, morda popravim pravila za IPTABLES ... ali naj preprosto pozabim na zadevo ????
mi lahko kdo pojasni, kaj je najverjetneje uporabnik počel, da je takrat, ko je dostopal do WWW strani letel ven pri teh IPTABLES pravilih:
#### Cekiranje TCP flags
$IPTABLES -A INPUT -p tcp -j in_valid_tcp
$IPTABLES -A in_valid_tcp -m state --state INVALID -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ALL NONE -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,FIN FIN -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,PSH PSH -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags ACK,URG URG -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags SYN,FIN SYN,FIN -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags SYN,RST SYN,RST -j log_drop
$IPTABLES -A in_valid_tcp -p tcp --tcp-flags FIN,RST FIN,RST -j log_drop
$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop
kar je potem v logfajlu sproduciralo tole:
Dec 15 10:05:31 [kernel] #### log_drop ####IN=eth0 OUT= MAC=xx:xx:xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xxx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=5125 PROTO=TCP SPT=47734 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0
(IP-je in MAC sem pobrisal ven ...)
Takih zadev je iz istega IP-ja kar nekaj, cca 20/dan, zadnje 3 dni.
Ima kdo kakšno idejo ... Naj se zaradi tega sekiram, naj dropnem vse, kar prihaja iz tega IP-ja, morda popravim pravila za IPTABLES ... ali naj preprosto pozabim na zadevo ????
Matri[X] ::
Kot vidis v logih, ti zapise paketek, ki ima ACK flag. Predvidevam, da se 3-way handshake, potreben za uspesno vzpostavitev TCP povezave, ne dokonca. Krivec za to je verjetno v zadnji vrstici "firewalla":
"$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop" .
Tukaj ti dropas vse, razen tiste TCP paketke, ki imajo SYN flag (new). Nastavit moras, da gredo skozi FW paketki, ki imajo "state" "established". Recimo:
"-m state --state RELATED,ESTABLISHED"
"$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop" .
Tukaj ti dropas vse, razen tiste TCP paketke, ki imajo SYN flag (new). Nastavit moras, da gredo skozi FW paketki, ki imajo "state" "established". Recimo:
"-m state --state RELATED,ESTABLISHED"
Bojan xxxx ::
Dobro jutro, malo dalj sem spal ... ampak ... je blo vredno !!!
Havla Matri[X], sem pogledal teorijo 3-way handshakinga:
1. (B) ==> [SYN] ==> (A)
2. (A) ==> [SYN / ACK] ==>(B)
3. (B) ==> [ACK] => (A)
Glede na 3-way handshaking in problematično vrstico z ! --syn -m state NEW -j DROP (log_drop) bi moral firewall zavrnit vse nove povezave do web serverja, kar pa ni res.
99.9% ljudi je neproblematično prišlo čez to pravilo. Hmmmm.
Preko tega pravila potem ne bi smela prit nobena nova povezava, kar pa v praksi ni delalo čisto tako. ??????
Edini možen odgovor, ki mi pade zdajle na pamet je, da IPTABLES po tem, ko je poslal SYN/ACK nazaj izvornemu pošiljatelju, novega paketka z ACK ne obravnava več kot NEW.
Havla Matri[X], sem pogledal teorijo 3-way handshakinga:
1. (B) ==> [SYN] ==> (A)
2. (A) ==> [SYN / ACK] ==>(B)
3. (B) ==> [ACK] => (A)
Glede na 3-way handshaking in problematično vrstico z ! --syn -m state NEW -j DROP (log_drop) bi moral firewall zavrnit vse nove povezave do web serverja, kar pa ni res.
99.9% ljudi je neproblematično prišlo čez to pravilo. Hmmmm.
Preko tega pravila potem ne bi smela prit nobena nova povezava, kar pa v praksi ni delalo čisto tako. ??????
Edini možen odgovor, ki mi pade zdajle na pamet je, da IPTABLES po tem, ko je poslal SYN/ACK nazaj izvornemu pošiljatelju, novega paketka z ACK ne obravnava več kot NEW.
Brane2 ::
A ne bi ti zaštartal recimo Ethereal na problematičnem firewallu in si pogledal, kaj se dejanjsko dogaja ? 
Se ti zdi možno, da je kak bug v kernelu (a laufaš kak nestabilen vanilla kernel ?) ?
IIRC, se kot "new" obravnava vsak paket TCP/IP povezave, ki ga v tej povezavi mašina prvič vidi.
To potem velja za prvi SYN in nič več. Vse ostalo ( naslednji SYN/ACK in ACK) je potem že pričakovano.
Lahko da se tu motim, vem pa, da je to razloženo v IPTABLES manpageih...
Če imaš slučajno Gentoo ali kaj podobnega, bodi pozoren na verzijo iptableov in verzijo kernela.
Pri obeh imej tazadnjo stabilno verzijo...
Se ti zdi možno, da je kak bug v kernelu (a laufaš kak nestabilen vanilla kernel ?) ?
IIRC, se kot "new" obravnava vsak paket TCP/IP povezave, ki ga v tej povezavi mašina prvič vidi.
To potem velja za prvi SYN in nič več. Vse ostalo ( naslednji SYN/ACK in ACK) je potem že pričakovano.
Lahko da se tu motim, vem pa, da je to razloženo v IPTABLES manpageih...
Če imaš slučajno Gentoo ali kaj podobnega, bodi pozoren na verzijo iptableov in verzijo kernela.
Pri obeh imej tazadnjo stabilno verzijo...
On the journey of life, I chose the psycho path.
Bojan xxxx ::
Yep !!! Gentoo 
All the way !!! 
gentoo-dev-sources ... 2.6.9.r1, kernel iz 2004.3 CD-ja.
Bom prečekiral še v Bugzilli ...
Glede tretjega (ACK) paketka ... se mi zdi, da bi ga moral obravnavat kot “ne NEW”. Apache logi, ki so polni uspešno vzpostavljenih povezav, dajo slutiti, da je temu tako.
Hmmm, Ethereal moram še emergat.To bi znalo mal trajat, ker je moj server(čič) samo en P200 :(((
Ravnikar sem ugotovil, da zna Ethereal delat tudi brez X. Juhuuuu !!!
Bom emergal in se naučil delat z Etherealom iz konzole, mogoče še kaj vmes vprašal, počakal, da se tisti človek iz tega IP-ja spet poskusi skonektat ... pa potem povem, kaj mi je padlo ven.
Hvala zaenkrat !!! I appreciate it a lot !!!
All the way !!! gentoo-dev-sources ... 2.6.9.r1, kernel iz 2004.3 CD-ja.
Bom prečekiral še v Bugzilli ...
Glede tretjega (ACK) paketka ... se mi zdi, da bi ga moral obravnavat kot “ne NEW”. Apache logi, ki so polni uspešno vzpostavljenih povezav, dajo slutiti, da je temu tako.
Hmmm, Ethereal moram še emergat.To bi znalo mal trajat, ker je moj server(čič) samo en P200 :(((
Ravnikar sem ugotovil, da zna Ethereal delat tudi brez X. Juhuuuu !!!
Bom emergal in se naučil delat z Etherealom iz konzole, mogoče še kaj vmes vprašal, počakal, da se tisti človek iz tega IP-ja spet poskusi skonektat ... pa potem povem, kaj mi je padlo ven.
Hvala zaenkrat !!! I appreciate it a lot !!!
Brane2 ::
Ja, pomagalo bi tudi, če bi ti log_drop chain izpisal, kaj v bistvu s paketom je narobe.
Mogoče bi lahko imel več sicer identičnih log_dropov (log_drop_1, log_drop_2 itd) in bi že v logu videl, zakaj je stvar zavrgla povzeavo...
Mogoče bi lahko imel več sicer identičnih log_dropov (log_drop_1, log_drop_2 itd) in bi že v logu videl, zakaj je stvar zavrgla povzeavo...
On the journey of life, I chose the psycho path.
Bojan xxxx ::
Preliminarne zadeve :)))
1) Prečekiral kernel 2.6.9-r1; zgleda OK
2) Skoraj 100% prepričan, da ni problem v 3-way handskakig; tretji ACK ni tretiran kot NEW.
Primerjal sem IPTABLES in APACHE logfajle in ... ZANIMIVO:
Iz istega IP-ja se je človek najprej uspel normalno skonektat in malo pobrskat po WWW strani, vse OK, Aapache logira 200. potem par minut nič potem pa spet identičen log z ACK TCP flagom na koncu (kot v prvem postu).
Pribljižno takole za isti (edini) problematičen IP:
Apache: (17:15)
xxx.xxx.xxx.xxx - - [16/Dec/2004:17:15:44 +0100] "GET xxxxx HTTP/1.1" 200 1551 "http://moj.web.naslov/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
IPTABLES: (17:17)
Dec 16 17:17:59 [kernel] #### log_drop ####IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=57596 PROTO=TCP SPT=49760 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0
(in tako še natanko 25X)
3) Na žalost se je takrat ethereal ravno z-emergal ... in še ni ničesar pribeležil :(((
S “command line” ukazom na ethereal sem pa malce v dilemi. Po eni strani bi imel rad čim manjši log file in bi zato rad zadevo omejil, po drugi strani pa ne vem, če bom tako zajel, to kar hočem.
#tethereal -a duration:68400 -i eth0 -d tcp.port==80,http -w teth-v1
Vprašanje je, če se tudi prvi paketek (če ima ali pa če res nima syn flaga) obravnava kot http???
Še tole. Morda kdo ve, kako bi se dalo ethereal omejit na en sam IP naslov; da bi bil log čim manjši ??? Verjetno se ne da, v manpagu nisem našel
1) Prečekiral kernel 2.6.9-r1; zgleda OK
2) Skoraj 100% prepričan, da ni problem v 3-way handskakig; tretji ACK ni tretiran kot NEW.
Primerjal sem IPTABLES in APACHE logfajle in ... ZANIMIVO:
Iz istega IP-ja se je človek najprej uspel normalno skonektat in malo pobrskat po WWW strani, vse OK, Aapache logira 200. potem par minut nič potem pa spet identičen log z ACK TCP flagom na koncu (kot v prvem postu).
Pribljižno takole za isti (edini) problematičen IP:
Apache: (17:15)
xxx.xxx.xxx.xxx - - [16/Dec/2004:17:15:44 +0100] "GET xxxxx HTTP/1.1" 200 1551 "http://moj.web.naslov/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
IPTABLES: (17:17)
Dec 16 17:17:59 [kernel] #### log_drop ####IN=eth0 OUT= MAC=xx:xx:xx SRC=xxx.xxx.xxx.xxx DST=xx.xxx.xxx.xxx LEN=40 TOS=0x00 PREC=0x00 TTL=51 ID=57596 PROTO=TCP SPT=49760 DPT=80 WINDOW=65535 RES=0x00 ACK URGP=0
(in tako še natanko 25X)
3) Na žalost se je takrat ethereal ravno z-emergal ... in še ni ničesar pribeležil :(((
S “command line” ukazom na ethereal sem pa malce v dilemi. Po eni strani bi imel rad čim manjši log file in bi zato rad zadevo omejil, po drugi strani pa ne vem, če bom tako zajel, to kar hočem.
#tethereal -a duration:68400 -i eth0 -d tcp.port==80,http -w teth-v1
Vprašanje je, če se tudi prvi paketek (če ima ali pa če res nima syn flaga) obravnava kot http???
Še tole. Morda kdo ve, kako bi se dalo ethereal omejit na en sam IP naslov; da bi bil log čim manjši ??? Verjetno se ne da, v manpagu nisem našel
Bojan xxxx ::
Aha, našel. Da tistemu, ki bo čez 5 let tole bral ne bo treba brskat po gori man-pages. Etheral se da omejit na razne IP-je takole:
# thethereal -a duration:1000 -i eth0 -d tcp.port==80,http src host xxx.xxx.xxx.xxx -w teth-v2
Poleg magičnega src host IP1 and IP2 and IPn pozna tethereal še eno goro drugih filtrov (# man tcpdump); strela, te filtri so pa res močna zadeva.
BTW: Medtem, ko sem se ukvarjal z drugimi stvarmi, sem popušil že dve priložnosti, da bi z Etherealom izvedel kaj več o DROP misteriji.
Predlog ob Brane2 je dal lepe rezultate: Človek iz xxx.xxx.xxx.xxx IP-ja leti ven pri pravilu:
$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop_8
Da tistemu, ki bo čez 5 let tole bral ne bo treba brskat po gori man-pages. Etheral se da omejit na razne IP-je takole:# thethereal -a duration:1000 -i eth0 -d tcp.port==80,http src host xxx.xxx.xxx.xxx -w teth-v2
Poleg magičnega src host IP1 and IP2 and IPn pozna tethereal še eno goro drugih filtrov (# man tcpdump); strela, te filtri so pa res močna zadeva.
BTW: Medtem, ko sem se ukvarjal z drugimi stvarmi, sem popušil že dve priložnosti, da bi z Etherealom izvedel kaj več o DROP misteriji.
Predlog ob Brane2 je dal lepe rezultate: Človek iz xxx.xxx.xxx.xxx IP-ja leti ven pri pravilu:
$IPTABLES -A in_valid_tcp -p tcp ! --syn -m state --state NEW -j log_drop_8
Zgodovina sprememb…
- spremenil: Bojan xxxx ()
SasoS ::
Moram reči da je precej težko debugirat takole na daljavo...
V glavnem...tisti rule ! --syn -m state --state NEW na bi deloval nekako tako: samo vsak PRVI paket ki pride v system dobi oznako NEW - od trojnega handshaka se pravi samo prvi syn paket, kar je točno to kar ta rule dropa - izpusti vse nove pakete ki nimajo SYN bita. ACK torej nikoli ne sme imeti NEW oznake ker mora VEDNO biti že del aktivne povezave. Zato me čudi zakaj bi ti dropal pakete tu.
edit: sem še enkrat prebral cel thread pa se mi mogoče malo svita kje bi lahko bil problem. Namreč...praviš da povezava pri prvem poskusu deluje, potem je nekaj časa idle, potem jo pa vrže ven. To mi smrdi na timeout v conntrack tabeli - Pri prvem dostopu se kreira vnos, vsi nadaljni ACKji se tretirajo kot ESTABLISHED, uporabnik potem nekaj časa čaka, potem spet nekaj naredi a se medtem ta povezava izbriše iz conntrack tabele tako da je naslednji ACK spet NEW (ker ga ni v tabeli). Načeloma so po defaultu te timeouti nastavljeni kar na visoko vrednost (5 dni za ESTABLISHED povezave!) tako da ne bi smelo prihajat do tega. Predlagam tudi branje http://kalamazoolinux.org/presentations...
V glavnem...tisti rule ! --syn -m state --state NEW na bi deloval nekako tako: samo vsak PRVI paket ki pride v system dobi oznako NEW - od trojnega handshaka se pravi samo prvi syn paket, kar je točno to kar ta rule dropa - izpusti vse nove pakete ki nimajo SYN bita. ACK torej nikoli ne sme imeti NEW oznake ker mora VEDNO biti že del aktivne povezave. Zato me čudi zakaj bi ti dropal pakete tu.
edit: sem še enkrat prebral cel thread pa se mi mogoče malo svita kje bi lahko bil problem. Namreč...praviš da povezava pri prvem poskusu deluje, potem je nekaj časa idle, potem jo pa vrže ven. To mi smrdi na timeout v conntrack tabeli - Pri prvem dostopu se kreira vnos, vsi nadaljni ACKji se tretirajo kot ESTABLISHED, uporabnik potem nekaj časa čaka, potem spet nekaj naredi a se medtem ta povezava izbriše iz conntrack tabele tako da je naslednji ACK spet NEW (ker ga ni v tabeli). Načeloma so po defaultu te timeouti nastavljeni kar na visoko vrednost (5 dni za ESTABLISHED povezave!) tako da ne bi smelo prihajat do tega. Predlagam tudi branje http://kalamazoolinux.org/presentations...
Zgodovina sprememb…
- spremenilo: SasoS ()
Bojan xxxx ::
Thanx, sem prebral članek. Se mi zdi, da s timeouti ne bi smelo bit problem:
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established je nastavljen na 432000, kar znese natanko 5 dni.
To bi moralo biti OK.
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established je nastavljen na 432000, kar znese natanko 5 dni.
To bi moralo biti OK.
Bojan xxxx ::
Imam pa tudi frišne podatke.
Ethereal pred kakšno minuto izpljunil svoje.
Zajem sem mu omejil na:
Nisem omejil na port 80, da ne bi slučajno izpustil česa pomembnega ... Torej pobiral vse iz xxx.xxx.xxx.xxx IP-ja. In ena stvar mi je padla v oči, ZANIMIVO.
Najprej nič, potem moj server odgovori na xxx IP z SYN, ACK, torej z drugim korakom handshakinga.
Prvi korak handshakinga je moral prit od nekje drugje in ne iz xxx IP-ja.
ZELO ČUDNO !!!
To se je spet zgodilo cca 2 minuti za tem, ko je nekdo iz tega IP-ja pregledal WEB stran. Dostopal je očitno povsem OK, ker Apache logfile vrne kodo 304; torej OK ... ampak uporablja “local copy” WEB strani (ker se ta od njegovega zadnjega obiska pač ni spremenila).
Ethereal pred kakšno minuto izpljunil svoje.
Zajem sem mu omejil na:
- IP dostopajočega (xxx.xxx.xxx.xxx)
- LAN IP mojega serverja
- moj WAN IP
Nisem omejil na port 80, da ne bi slučajno izpustil česa pomembnega ... Torej pobiral vse iz xxx.xxx.xxx.xxx IP-ja. In ena stvar mi je padla v oči, ZANIMIVO.
Najprej nič, potem moj server odgovori na xxx IP z SYN, ACK, torej z drugim korakom handshakinga.
Prvi korak handshakinga je moral prit od nekje drugje in ne iz xxx IP-ja.
ZELO ČUDNO !!!
To se je spet zgodilo cca 2 minuti za tem, ko je nekdo iz tega IP-ja pregledal WEB stran. Dostopal je očitno povsem OK, ker Apache logfile vrne kodo 304; torej OK ... ampak uporablja “local copy” WEB strani (ker se ta od njegovega zadnjega obiska pač ni spremenila).
Brane2 ::
Je možno, da je tip za narobe nastavljenim firewallom ?
Tudi ne vidim, kako bi ti lahko poslal kaj s povsem drugega naslova tako da mu ti pošiljaš handshake na drugi naslov.
A je možno, da prvega dela handshakea tvoje Ethereal enostavno ne vidi ?
A pri drugih povezavah ga vidiš ?
Tudi ne vidim, kako bi ti lahko poslal kaj s povsem drugega naslova tako da mu ti pošiljaš handshake na drugi naslov.
A je možno, da prvega dela handshakea tvoje Ethereal enostavno ne vidi ?
A pri drugih povezavah ga vidiš ?
On the journey of life, I chose the psycho path.
Bojan xxxx ::
Prečekiral, Ethereal drugače vidi vse tri korake, SYN, SYN/ACK, ACK. To zgleda OK.
Pojma nimam kako, ampak glede na omejitev IP-jev vidim, da je moj server prvi, ki pošlje nazaj SYN/ACK.
Ja, zdaj sem Etherealu rekel, naj pač naslednjih nekaj ur beleži vse; za razliko od prej sem omejil le -d tcp.port==80,http.
Je pa povsem možno, da je (so) za čudno nastavljenim firewallom. V bistvu je to inštitucija. IP je 80.246.106.4. Whois bo vse povedal.
Tam delajo neki študenti od moje punce. V bistvu sva jim poslala maile, naj si pogledajo web page. Od nikjer drugje nobenih problemov, razen iz njihovega IP-ja.
Mah, mam jih polhn kufr.
Pojma nimam kako, ampak glede na omejitev IP-jev vidim, da je moj server prvi, ki pošlje nazaj SYN/ACK.
Ja, zdaj sem Etherealu rekel, naj pač naslednjih nekaj ur beleži vse; za razliko od prej sem omejil le -d tcp.port==80,http.
Je pa povsem možno, da je (so) za čudno nastavljenim firewallom. V bistvu je to inštitucija. IP je 80.246.106.4. Whois bo vse povedal.
Tam delajo neki študenti od moje punce. V bistvu sva jim poslala maile, naj si pogledajo web page. Od nikjer drugje nobenih problemov, razen iz njihovega IP-ja.
Mah, mam jih polhn kufr.
SasoS ::
A si ziher da ko gledaš promet gledaš tako input kot output? Vem da v tcpdump moraš nastaviti pač da ti gledat dst port 80 in src port 80...
Bojan xxxx ::
V tcpdump sem src in dst port pustil pri miru, omejil sem le na src host.
Glihkar sem ugotovil, da je izginotje prvega SYN handshaka iz Ethereal logfajla posledica mojega taypota. Zatipkal sem se pri src host mojega WAN IP-ja. Logično. Damn.
Ko sem rekel, da Ethereal vidi pa sem gledal včerajšnje loge.
No ... sej, zdaj sem pa napisal scrip. Ta pa nima več taypotov.
Misliom, da je edini možen odgovor, da imajo oni kaj napačno skonfigurirano al pa da se tam kdo malce zafrkava al pa da so pijani. Upam, da me ne bodo tožili zaradi žaljive obdolžitve
Spustim do konca čez še tale Ethereal skript ... pa povem, kaj je ta zadeva izpljunila potem pa v IPTABLES lepo napišem kai takega kot:
iptabels -A INPUT -s 80.246 ... -j DROP
iptabels -A OUTPUT -s 80.246 ... -j DROP
To bi moralo parmanentno rešit problem.
Glihkar sem ugotovil, da je izginotje prvega SYN handshaka iz Ethereal logfajla posledica mojega taypota. Zatipkal sem se pri src host mojega WAN IP-ja. Logično. Damn.
Ko sem rekel, da Ethereal vidi pa sem gledal včerajšnje loge.
No ... sej, zdaj sem pa napisal scrip. Ta pa nima več taypotov.
Misliom, da je edini možen odgovor, da imajo oni kaj napačno skonfigurirano al pa da se tam kdo malce zafrkava al pa da so pijani. Upam, da me ne bodo tožili zaradi žaljive obdolžitve
Spustim do konca čez še tale Ethereal skript ... pa povem, kaj je ta zadeva izpljunila potem pa v IPTABLES lepo napišem kai takega kot:
iptabels -A INPUT -s 80.246 ... -j DROP
iptabels -A OUTPUT -s 80.246 ... -j DROP
To bi moralo parmanentno rešit problem.
Bojan xxxx ::
Evo, sem ustavil Ethereal pa je vse skupaj bolj prazno; ja ... so šli ljudje iz služb že domov.
Problem sem rešil tako, da vrstica v IPTABLES z –syn in NEW in DROP ostane. Kot vse kaže, vzrok problema ni na lokalnem serverju ampak na točno določenem IP naslovu. Najbrž je ostalih 99.9% uspelih povezav zadosten razlog za takšno mnenje.
S punco sva poslala ljudem, ki so na tem IP-ju še par prijaznih mailov v stilu, če so zadevo videli ... pa če imajo tudi na splošno probleme z dostopom do neta ... Ne bi se čudil, če bi nazaj prišlo kaj v stilu da .. ufffff, tale informacijska družba je pa too much, nikol nič ne dela ...
Vsem, ki ste s predlogi pomagali pri tejle zadevi: SasoS, Brane2 in Matri[X] pa FUL HVALA !!! I appreciate it a lot !!!
Če me pa pograbi volja do poganjanja Ethereala in ugotovim kaj novega, bom pa semle vsekakor napisal še vsaj en post.
Problem sem rešil tako, da vrstica v IPTABLES z –syn in NEW in DROP ostane. Kot vse kaže, vzrok problema ni na lokalnem serverju ampak na točno določenem IP naslovu. Najbrž je ostalih 99.9% uspelih povezav zadosten razlog za takšno mnenje.
S punco sva poslala ljudem, ki so na tem IP-ju še par prijaznih mailov v stilu, če so zadevo videli ... pa če imajo tudi na splošno probleme z dostopom do neta ... Ne bi se čudil, če bi nazaj prišlo kaj v stilu da .. ufffff, tale informacijska družba je pa too much, nikol nič ne dela ...
Vsem, ki ste s predlogi pomagali pri tejle zadevi: SasoS, Brane2 in Matri[X] pa FUL HVALA !!! I appreciate it a lot !!!
Če me pa pograbi volja do poganjanja Ethereala in ugotovim kaj novega, bom pa semle vsekakor napisal še vsaj en post.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | iptables problemOddelek: Operacijski sistemi | 2256 (2022) | poweroff |
| » | tun0 device?Oddelek: Operacijski sistemi | 1556 (1397) | poweroff |
| » | sshd - zakleni ip, po x neuspelih login-ihOddelek: Omrežja in internet | 1427 (1150) | SasoS |
| » | iptables problem z SSHOddelek: Omrežja in internet | 1916 (1770) | sverde21 |
| » | iptables skriptaOddelek: Omrežja in internet | 2120 (1900) | karafeka |