Lan -początkujący

[marcintom]

ja siedzę od kilkunastu dni ale wydaje mi się że jednak jestem czymś zasypywany Jak mi nie wierzysz to mogę ci pokazać logi pakietów przychodzących no a poza tym to widać w ikonce statusowej połączenia eth0 no i jak sprawdzam ilość ściągniętych danych u mojego usługodawcy to znaczy przybywa ok 22MB /godz i to nie jest tak że coś idzie z max prędkością to jest tak że idzie cały czas a prędkość to dziesiętne części kb /s . Także argumentów jest wiele trzeba się tylko zastanowić czemu tak jest.

[@Sorror]

Czyli kolega niech siebie posniffuje powiedzmy przez godzinkę. Przetworzony rezultat nam tutaj wklei i wtedy na pewno się coś wymyśli

[marcintom]

Przedmówca wspominał o wklejeniu logów z ostatniej godziny - to mija się z celem to jest kilak sekund i juz widać że jestem bombardowany przez ARP

 

16:55:57.794322 arp who-has 10.1.205.185 tell 10.1.200.1
16:55:57.808535 arp who-has staticline22628.toya.net.pl tell staticline1592.toya.net.pl
16:55:58.113595 arp who-has 10.1.123.222 tell 10.1.120.1
16:55:58.121878 arp who-has staticline21796.toya.net.pl tell staticline1084.toya.net.pl
16:55:58.177593 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:58.179359 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:58.216549 arp who-has staticline23351.toya.net.pl tell staticline326.toya.net.pl
16:55:58.282880 arp who-has staticline1998.toya.net.pl tell staticline1847.toya.net.pl
16:55:58.401379 arp who-has 10.1.126.236 tell 10.1.120.1
16:55:58.413317 arp who-has staticline2442.toya.net.pl tell staticline2355.toya.net.pl
16:55:58.457720 arp who-has staticline1808.toya.net.pl tell staticline1592.toya.net.pl
16:55:58.499199 arp who-has staticline1979.toya.net.pl tell staticline1847.toya.net.pl
16:55:58.559302 arp who-has 10.1.180.128 tell 10.1.176.1
16:55:58.668329 arp who-has 10.1.142.192 tell 10.1.136.1
16:55:58.740362 arp who-has staticline1616.toya.net.pl tell staticline1592.toya.net.pl
16:55:58.831805 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:58.833581 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:58.869665 arp who-has 10.1.161.218 tell 10.1.160.1
16:55:58.907592 arp who-has staticline2442.toya.net.pl tell staticline2355.toya.net.pl
16:55:59.133688 arp who-has 10.1.189.138 tell 10.1.184.1
16:55:59.236563 arp who-has 172.16.245.242 tell 172.16.0.1
16:55:59.308653 arp who-has 10.1.142.25 tell 10.1.136.1
16:55:59.535177 arp who-has 10.1.134.31 tell 10.1.128.1
16:55:59.709171 arp who-has 10.1.178.229 tell 10.1.176.1
16:55:59.731686 arp who-has staticline22876.toya.net.pl tell staticline2101.toya.net.pl
16:55:59.841789 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 345
16:55:59.843575 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 345
16:55:59.845365 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:59.847215 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:55:59.937706 arp who-has 10.2.0.1 tell 10.2.0.2
16:55:59.968022 arp who-has 10.1.180.227 tell 10.1.176.1
16:56:00.357460 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:00.359203 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:00.568581 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:00.568928 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:00.699254 arp who-has 10.2.0.1 tell 10.2.0.2
16:56:00.793911 arp who-has 10.1.142.201 tell 10.1.136.1
16:56:00.838155 arp who-has staticline4334.toya.net.pl tell staticline326.toya.net.pl
16:56:00.839856 arp who-has staticline4335.toya.net.pl tell staticline326.toya.net.pl
16:56:00.846689 arp who-has staticline4336.toya.net.pl tell staticline326.toya.net.pl
16:56:00.861083 arp who-has staticline21743.toya.net.pl tell staticline326.toya.net.pl
16:56:00.862526 arp who-has staticline488.toya.net.pl tell staticline326.toya.net.pl
16:56:00.869083 arp who-has staticline22247.toya.net.pl tell staticline326.toya.net.pl
16:56:00.877024 arp who-has staticline4338.toya.net.pl tell staticline326.toya.net.pl
16:56:00.869083 arp who-has staticline22247.toya.net.pl tell staticline326.toya.net.pl
16:56:00.877024 arp who-has staticline4338.toya.net.pl tell staticline326.toya.net.pl
16:56:00.877703 arp who-has staticline22248.toya.net.pl tell staticline326.toya.net.pl
16:56:00.891377 arp who-has staticline4340.toya.net.pl tell staticline326.toya.net.pl
16:56:00.892804 arp who-has staticline4341.toya.net.pl tell staticline326.toya.net.pl
16:56:00.893716 arp who-has staticline495.toya.net.pl tell staticline326.toya.net.pl
16:56:00.894733 arp who-has staticline496.toya.net.pl tell staticline326.toya.net.pl
16:56:00.900970 arp who-has art.janter.net tell staticline326.toya.net.pl
16:56:00.901451 arp who-has renifer.toya.net.pl tell staticline326.toya.net.pl
16:56:00.908978 arp who-has staticline499.toya.net.pl tell staticline326.toya.net.pl
16:56:00.909658 arp who-has staticline500.toya.net.pl tell staticline326.toya.net.pl
16:56:00.917090 arp who-has staticline502.toya.net.pl tell staticline326.toya.net.pl
16:56:00.925548 arp who-has staticline503.toya.net.pl tell staticline326.toya.net.pl
16:56:00.932614 arp who-has staticline505.toya.net.pl tell staticline326.toya.net.pl
16:56:00.932871 arp who-has staticline506.toya.net.pl tell staticline326.toya.net.pl
16:56:00.937104 arp who-has 10.2.0.1 tell 10.2.0.2
16:56:00.940431 arp who-has smoczoos.toya.net.pl tell staticline326.toya.net.pl
16:56:00.947585 arp who-has 10.2.0.1 tell 10.2.0.2
16:56:00.948512 arp who-has jazgo.toya.net.pl tell staticline326.toya.net.pl
16:56:00.949191 arp who-has staticline21744.toya.net.pl tell staticline326.toya.net.pl
16:56:00.950077 arp who-has 10.1.182.35 tell 10.1.176.1
16:56:00.968693 arp who-has 10.1.160.40 tell 10.1.160.1
16:56:01.130332 arp who-has 10.1.123.222 tell 10.1.120.1
16:56:01.326001 arp who-has 10.1.162.221 tell 10.1.160.1
16:56:01.398846 arp who-has 10.1.153.77 tell 10.1.152.1
16:56:01.452511 arp who-has staticline21738.toya.net.pl tell staticline326.toya.net.pl
16:56:01.688583 arp who-has 10.1.162.72 tell 10.1.160.1
16:56:01.734098 arp who-has staticline1616.toya.net.pl tell staticline1592.toya.net.pl
16:56:01.797790 arp who-has staticline22277.toya.net.pl tell staticline1338.toya.net.pl
16:56:01.901480 arp who-has 10.1.158.19 tell 10.1.152.1
16:56:02.172029 arp who-has 10.1.153.77 tell 10.1.152.1
16:56:02.309833 arp who-has 10.1.164.180 tell 10.1.160.1
16:56:02.334852 arp who-has 10.1.190.211 tell 10.1.184.1
16:56:02.478132 arp who-has 10.1.161.205 tell 10.1.160.1
16:56:02.479582 arp who-has 10.1.180.59 tell 10.1.176.1
16:56:02.479842 arp who-has staticline22659.toya.net.pl tell staticline1592.toya.net.pl
16:56:02.489337 arp who-has 10.1.177.98 tell 10.1.176.1
16:56:02.544274 arp who-has 172.16.244.171 tell 172.16.0.1
16:56:02.564651 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 343
16:56:02.659157 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:02.660960 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:02.673516 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:02.675255 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:02.973851 arp who-has 10.1.180.227 tell 10.1.176.1
16:56:02.675255 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:02.973851 arp who-has 10.1.180.227 tell 10.1.176.1
16:56:03.178831 arp who-has 10.1.205.185 tell 10.1.200.1
16:56:03.260662 arp who-has 10.1.161.67 tell 10.1.160.1
16:56:03.308565 arp who-has 10.1.160.40 tell 10.1.160.1
16:56:03.331371 arp who-has 10.1.164.171 tell 10.1.160.1
16:56:03.602391 arp who-has 10.1.166.94 tell 10.1.160.1
16:56:03.792110 arp who-has renifer.toya.net.pl tell staticline326.toya.net.pl
16:56:03.798234 arp who-has 10.1.142.201 tell 10.1.136.1
16:56:03.806077 arp who-has staticline495.toya.net.pl tell staticline326.toya.net.pl
16:56:03.815130 arp who-has staticline4336.toya.net.pl tell staticline326.toya.net.pl
16:56:03.822794 arp who-has staticline21744.toya.net.pl tell staticline326.toya.net.pl
16:56:03.828796 arp who-has staticline505.toya.net.pl tell staticline326.toya.net.pl
16:56:03.837979 arp who-has staticline502.toya.net.pl tell staticline326.toya.net.pl
16:56:03.854416 arp who-has staticline21743.toya.net.pl tell staticline326.toya.net.pl
16:56:03.860010 arp who-has smoczoos.toya.net.pl tell staticline326.toya.net.pl
16:56:03.872401 arp who-has staticline503.toya.net.pl tell staticline326.toya.net.pl
16:56:03.883024 arp who-has staticline500.toya.net.pl tell staticline326.toya.net.pl
16:56:03.892187 arp who-has staticline488.toya.net.pl tell staticline326.toya.net.pl
16:56:03.899160 arp who-has staticline4335.toya.net.pl tell staticline326.toya.net.pl
16:56:03.901230 arp who-has staticline4341.toya.net.pl tell staticline326.toya.net.pl
16:56:03.906813 arp who-has jazgo.toya.net.pl tell staticline326.toya.net.pl
16:56:04.089917 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 343
16:56:04.298943 arp who-has 10.1.182.231 tell 10.1.176.1
16:56:04.438709 arp who-has 10.1.194.26 tell 10.1.192.1
16:56:04.447461 arp who-has staticline21738.toya.net.pl tell staticline326.toya.net.pl
16:56:04.573768 arp who-has 10.1.180.69 tell 10.1.176.1
16:56:04.576024 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 343
16:56:04.603510 arp who-has 10.1.162.72 tell 10.1.160.1
16:56:04.628345 arp who-has 10.2.0.1 tell 10.2.0.2
16:56:04.900029 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:04.904642 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:04.915129 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:04.916878 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:05.000958 arp who-has staticline22659.toya.net.pl tell staticline1592.toya.net.pl
16:56:05.274409 arp who-has 172.16.245.242 tell 172.16.0.1
16:56:05.327967 arp who-has 10.1.190.211 tell 10.1.184.1
16:56:05.346157 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:05.348004 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:05.534100 arp who-has 10.1.164.56 tell 10.1.160.1
16:56:05.605684 arp who-has 10.1.162.36 tell 10.1.160.1
16:56:05.708560 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:05.710333 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 311
16:56:06.098940 IP 10.2.0.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length: 343

[@Sorror]

To musiałby się ktoś jeszcze wypowiedzieć (e.g. Mynus ;-) ), czy blokada arp ma jakikolwiek sens...

[mounter]

Witam

Jak dla mnie, to to jest normalny ruch broadcastowy i nie ma sie czym przejmowac.

Jak masz firestartera to tam jest taka opcja o logowaniu tego rodzaju ruchy. Zaznacz na nie, i logi przestana rosnac. Jak nie masz firestartera to robisz to za pomoca iptables.

 

pozdrawiam

[@Sorror]

Jeśli w granicach 25 MB per h to raczej nie jest "zwykły" ruch broadcastowy, isn't? Choć być może i tak się zdarza, nie wiem, mówię w oparciu o własne doświadczenia. A tak w ogóle to input drop i po problemie.

[mounter]

Kiedys mialem taka glupia sytuacje, ze jakies dupki w lokalnej odpalily skaner portow w jakims trojanie. Skanowali broadcast w poszukiwaniu zainfekowanych hostow. Mialem firestartera i logowalem wszystko jak leci firestarter pieknie zajal czas proca do tego stopnia, ze ledwie mi mycha chodzila, nie dalo sie wlasciwie nic zrobic. (Ale mlody i glupi wtedy jeszcze byelm )

Tak wiec (gdyby zaistniala podobna sytuacja u kolegi) wydaje mi sie, ze:

Firestarter to nie jest zbyt szczesliwe narzedzie.

Wielkosc logow rosnie wprost proporcjonalnie do wielkosci sieci.

Masz racje i nie mozna tego nazwac "zwyklym" ruchem

 

Moze w skrawku logow bedzie cos, na podstawie czego da sie cos wywnioskowac?

[marcintom]

Hmmm dzięki za zainteresowanie problemem który w sumie narazie cały czas jest.

 

W związku z tym że właściwie do poniedziałku nie mogę skorzystać z tamtego kompa na którym występuje problem nie mogę sprawdzić czy któraś z podpowiedzi mi pomoże.

 

Aczkolwiek bardzo mnie zaintrygowała ta pewność eksperta sorror w pozytywnym znaczeniu.

 

Nie mogłem się domyśleć o co chodzi z tym input drop jednak po pogrzebaniu w sieci i przeczytaniu mana iptables chyba coś zaskoczylem.

 

Tzn i tu pytanie: czy chodzi o to że np po wpisaniu

iptables -A INPUT DROP

moj interfejs sieciowy nie będzie przyjmował datagramów przeznaczonych dla wielu kompów krótko mówiąc np z broadcasta. A jeżeli tak to czy nie będzie to tak że on je i tak odbierze a potem dopiero je zignoruje - "dropnie" - a licznik danych będzie nadal dodawał te MB do mojego konta u usługodawcy.

 

Oczywiście to tylko polemika bo nie mogę tego sprawdzić.

 

Jeżeli powyżej napisałem głupoty to proszę mnie bez wachania poprawić przyjmę każdę odp bo jestem początkujący.

 

A i jeszcze pytanie do mountera: Czy chodzi ci o te logi które umieściłem wyżej z tcpdumpa czy może jakieś inne logi? No i jeszcze jedno pytanko tzn to że wszystko chodzi bez zarzutów pod windom nie dyskryminuje przypadkiem skanowanie portów? - pytam bo nie wiem.

[@Sorror]

A dokładniej to

iptables -P INPUT DROP

 

Oraz:

iptables -P FORWARD DROP

 

Jeśli nie udostępniasz żadnych usłgug (apache etc) to możesz wrzucić standardową konfigurację:

#!/bin/sh 
iptables -P INPUT DROP 
iptables -P OUTPUT ACCEPT 
iptables -P FORWARD DROP 
iptables -A INPUT -i lo -j ACCEPT 
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT 
iptables -A INPUT -j LOG --log-prefix "FROM INPUT DROP "

 

A nawet jeśli udostępniasz, ale e.g. 1 usługę wystarczy zainteresować się --state NEW. Jeśli dalej będą działy się cuda spróbujemy czegoś ostrzejszego

 

 

A jeśli chodzi o:

No i jeszcze jedno pytanko tzn to że wszystko chodzi bez zarzutów pod windom nie dyskryminuje przypadkiem skanowanie portów? - pytam bo nie wiem.

 

to musisz się wyrazić jaśniej, nic nie rozumiem

[mounter]

Jesli chodzi o firewall to masz tu taki szybki, podstawowy

 

#! /bin/bash

iptables -F
iptables -t nat -F

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#lo ma specjalne prawa

iptables -A INPUT -i lo -j ACCEPT
iptables -A FORWARD -o lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -d twoje_ip  -j LOG --log-level debug --log-prefix "IPTABLES: " 

 

Ten firewall odrzuca wszystko co nie jest zainicjowane przez Ciebie albo nie zawiera sie w polaczenu i loguje tylko to co jest adresowane do twojej maszyny. (To oczywiscie tylko podstawa)

Ja sobie zmienilem linijke w /etc/syslog.conf

 #kern.*                                                 /dev/console
kern.*                                                  /var/log/console 

nie pamietam tylko, czy syslog sam sobie utworzy plik w /var/log/

i po tych logach przynajmniej mi jest wygodniej cos powiedziec. A nie pamietam czy/gdzie fedorka loguje takie zajscia.

 

Chcesz wiedziec wiecej poczytaj o iptables.

 

Caly czas zakladalem, ze twoje rosnace logi to ktores z /var/log/ , ale wspomniales cos o kontrolce eth0 i mam dziwne wrazenie, ze zobaczyles poprostu zliczenie ruchu na interfejsach czyli to co zobaczysz po wklepaniu

iptables -L -v 

w lancuchu INPUT

 Chain INPUT (policy DROP 534 packets, 173K bytes)

Przy intensywnym przegladaniu internetu prawdopodobienstwo tego ze osiagniesz tu 20M w ciagu godziny jest dosc duze. U mnie po spedzeniu dnia przy kompie potrafi byc ponad 700M

 

---- edit ----

hehe spoznilem sie troszke, bedziesz mial 2 przyklady

[marcintom]

więc tak po pieresze sprostowanie dla mounter'a :

 

moje rosnące dane wbrew pozorom nie pochodzą z iptables -L -v tam jest dość przyzwoicie np 54 kb out i 640kb input. ja po kliknięciu na ikonkę Połączenie sieciowe : eth0 widzę rosnące dane które do mnie przychodzą a w logach tcpdumpa widze ze to są pakiety z protokołu ARP pozatym dane przychodzą bo nalicza je licznik mojego usługodawcy i to drugie źródło wiedzy potwierdzające pierwsze.

 

Poza tym narazie pracuje jeszcze nad tym iptables bo widze że to chyba klucz do rozwiązania moich problemów aczkolwiek na początku jest ciężko wziąć wszystko pod uwagę tym bardziej że mam serwer www, ssh, ... więc narazie studiuję bo nie chcę wpisywać znaczków :] (_napewno_ → na pewno) ORT wezmę pod uwagę to co panowie tu napisali za co ogromne dzięki.

 

Kombinowałem z tym iptables, ale bez skutku.

 

Podczas studiowania nasunęło mi się takie pytanie. Jak to jest z tymi pakietami tzn iptables decyduje co zrobić z pakietem jak już go odbierze?? Bo przecież innaczej nie wie chyba czy on jest skierowany do mnie czy też może do innego komputera. No ale z drugiej strony caly czas mam tego windowsa i tam nie dostaje tyle tych pakietów. Jeżeli miał bym rację to właściwie ja już nie mam pojęcia co tu się u mnie dzieje.

 

Ktoś powiedział mi że być może mam źle ustwionego broadcasta. Hmmmmm

[mounter]

Ja po jakichs 10s tcpdumpa tez mam tego sporo. Pakiety, ktore wysniffuje tcpdump najczesciej przybieraja forme:

00:18:26.891325 arp who-has jakis_host_z_mojej_sieci tell moja_brama_do_internetu

jest ich duzo!!

 

czyli tlumaczac: brama pyta, jaki MAC ma host

na takie pytanie powinna sie pojawic odpowiedz

arp reply host is-at MAC

i tak dla kazdego hosta, ktory sie przez nia przedostaje. Urzadzenia, ktore dopuszczaja do siebie na podstawie maca tez beda o niego pytac.

Teraz musisz zrozumiec, ze kiedy snifujesz karta dziala w trybie promisc. Czyli slucha wszystkiego jak leci, bez wzgledu na to czy cos jest adresowane do Ciebie czy nie.

(to tak jakbys przysluchiwal sie rozmowie kilku osob. Slyszysz, mimo tego, ze nie mowia do Ciebie) Karta slucha ruchu broadcastowego. Ruch na broadcast nie jest zazwyczaj dla Ciebie niebezpieczny.

 

Teraz iptables:

Iptables nie ma za zadanie stwierdzac czy ruch jest skierowany do Ciebie czy do sasiada generalnie jesli jakis pakiet nie jest adresowany do Ciebie to iptables ma go gleboko w kodzie zrodlowym . Iptables sprawdza, czy pakiet do Ciebie zaadresowany jest legalny w mysl praw, ktore ustaliles. Akceptuje lub odrzuca. Komputer odbiera pakiet -> iptables go weryfikuje -> akceptuje albo dropuje -> komputer odpowiada na pakiet, albo nie. (to tak w skrocie)

 

pozatym dane przychodzą bo nalicza je licznik mojego usługodawcy

znaczy... naliczaja Cie za odebrane bity??

 

Odpal firewall i niech komp troche pochodzi. Dalej robsz

dmesg >> plik.log

i wklej nam tutaj troche tych logow

powinno tam byc mniej wiecej cos takiego:

IPTABLES: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:MAC SRC=jakis_ip DST=Twoj_ip LEN=229 TOS=0x00 PREC=0x00 TTL=128 ID=39909 PROTO=UDP SPT=138 DPT=138 LEN=209

 

pozdrawiam

[marcintom]

Hmmmm to bardzo dziwne ale po wykonaniu

dmesg > plik 

nie ma niczego o czym Pan napisał tzn to polecenie powiedziałbym zwraca bardziej specyfikacje mojego hardwaru niż to o co chodzi.

[@Sorror]

Ja proponuję jednak napisać skrypcik firewalla opartego na iptables i mieć problem z głowy Cóż, osobiście nigdy nie byłem zalewany przez isp żadnego rodzaju pakietami, może zależy to od specyficznej topologii sieci może od czegoś innego - w tej chwili to nieistotne, należy przede wszystkim pozbyć się problemu, a ewentualnie później zastanawiać się nad jego przyczyną.

[mounter]

Hmmmm to bardzo dziwne ale po wykonaniu

dmesg > plik 

nie ma niczego o czym Pan napisał tzn to polecenie powiedziałbym zwraca bardziej specyfikacje mojego hardwaru niż to o co chodzi.

Zgadza sie dmesg zwraca specyfikacje urzadzen. Ale jezeli zrobsz firewall tak jak Ci tu kolega i ja pokazalismy to bedzie pokazywal jeszcze logi. Twoje zadanie priorytetowe to zrobic FIREWALLA tak jak sorror mowi (sluchaj go bo dobrze gada) potem bedziemy szukac przyczyny, bo na razie jestesmy slepi i glusi. Wiesz ze cos przychodzi ale nie wiesz co. Te regulki z logowaniem pokaza nam co to takiego. Regulka kolegi pokaze caly ruch jaki sie odbywa przy twojej maszynie (broadcastowy i unicastowy) moja pokaze Ci tylko ruch unicastowy (czyli tylko to co jest adresowane do Ciebie)

 

Panimajesz??

 

I nie jedz mi per pan bo sie glupio czuje