PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : iptables oder named fehler ?



habbom
09.08.02, 18:49
Hi,
ich habe per iptables alles was reinkommt auf drop gesetzt, ok, sollte ich nicht machen, aber den Rest hab ich noch nicht so drauf, bin aber dabei das zu ändern.

Mein Home Netz:
Server 1:
Suse 7.3 als Router mit squid und squidgaurd als transparent, über eine isdn-flat 24 Stunden on
Server 2:
Suse 7.3 mit Samba, Named (cache only) , NFS, sendmail
Workstation 1: Suse 7.3
Workstation 2: W98
Workstation 3: W98

Auszug aus dem Logging:
Aug 9 17:07:36 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=207.xx.xxx.xx DST=213.xxx.xxx.xx LEN=355 TOS=0x00 PREC=0x00 TTL=44 ID=57047 PROTO=TCP SPT=80 DPT=1435 WINDOW=17520 RES=0x00 ACK PSH FIN URGP=0
Aug 9 17:07:36 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=207.xx.xxx.xx DST=213.xxx.xxx.xx LEN=355 TOS=0x00 PREC=0x00 TTL=44 ID=57047 PROTO=TCP SPT=80 DPT=1435 WINDOW=17520 RES=0x00 ACK PSH FIN URGP=0
Aug 9 17:08:08 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=223 TOS=0x00 PREC=0x00 TTL=246 ID=48312 PROTO=TCP SPT=80 DPT=13368 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0
Aug 9 17:08:08 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=223 TOS=0x00 PREC=0x00 TTL=246 ID=48312 PROTO=TCP SPT=80 DPT=13368 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0
Aug 9 17:08:24 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=183 TOS=0x00 PREC=0x00 TTL=246 ID=37237 PROTO=TCP SPT=80 DPT=13045 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0

und das geht jetzt den ganzen lieben langen Tag so.
laut RIPE ist 212.xxx.xxx.xx sowie einige andere Anfragen
inetnum: 0.0.0.0 - 255.255.255.255
netname: IANA-BLK
descr: The whole IPv4 address space
country: NL
admin-c: IANA1-RIPE
tech-c: IANA1-RIPE
status: ALLOCATED UNSPECIFIED
remarks: The country is really worldwide.

Ist das nun normal ??
Ich hab schon alle Workstations runter gefahren, aber die Abfragen gehen weiter.
Irgendwie hab ich das Gefühl, einen Fehler gemacht zu haben
laut nslookup sind das nameserveranfragen ??
aber forward only in der named.conf heißt doch cache only oder ?

meine named.conf
# /etc/named.conf
#
bind9/misc/options.

options {
directory "/var/named";
auth-nxdomain no;
forwarders {
212.6.64.232;
134.106.61.29;
212.6.64.161;
212.6.64.162;
};
forward only;
listen-on port 53 {
127.0.0.1;
192.168.2.5;
};
query-source port 53;
allow-query { 192.168.2/24; };
notify no;
};

zone "localhost" in {
type master;
file "named.localhost";
allow-update { none; };
};

zone "0.0.127.in-addr.arpa" in {
type master;
file "named.127.0.0";
allow-update { none; };
};

zone "2.168.192.in-addr.arpa" in {
type master;
file "named.192.168.2";
allow-query { localnets; };
allow-transfer { none; };
allow-update { none; };
notify no;
};

zone "home.pc" in {
type master;
file "named.home.pc";
allow-query { localnets; };
allow-transfer { none; };
notify no;
};

zone "." in {
type hint;
file "root.hint";
};


Hat jemend einen Tip, wo ich zur weiteren Suche ansetzen kann


Danke im Voraus und Gruß
Michael

ReSeT
09.08.02, 19:45
Hi!

Also laut Protokoll und Type of Service sind das auf jedenfall irgenwelche DNS Queries. Was genau kann ich Dir leider nicht sagen, da ich mich in Sachen DNS nicht so gut auskenne (schwieriges Thema, wie ich finde :D )

Greetz

habbom
09.08.02, 20:02
danke für die Antwort,

kann es eventuell daran liegen, daß ich auf meinem Router den internen Name Server eingetragen habe ?

wo sehe ich den Type of Service ?

Michael

Belkira
09.08.02, 22:19
Auszug aus dem Logging:
Aug 9 17:07:36 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=207.xx.xxx.xx DST=213.xxx.xxx.xx LEN=355 TOS=0x00 PREC=0x00 TTL=44 ID=57047 PROTO=TCP SPT=80 DPT=1435 WINDOW=17520 RES=0x00 ACK PSH FIN URGP=0

Eine Antwort von einem Webserver (Port 80).


Aug 9 17:07:36 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=207.xx.xxx.xx DST=213.xxx.xxx.xx LEN=355 TOS=0x00 PREC=0x00 TTL=44 ID=57047 PROTO=TCP SPT=80 DPT=1435 WINDOW=17520 RES=0x00 ACK PSH FIN URGP=0

Eine Antwort von einem Webserver (Port 80).


Aug 9 17:08:08 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=223 TOS=0x00 PREC=0x00 TTL=246 ID=48312 PROTO=TCP SPT=80 DPT=13368 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0

Eine Antwort von einem Webserver (Port 80).


Aug 9 17:08:08 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=223 TOS=0x00 PREC=0x00 TTL=246 ID=48312 PROTO=TCP SPT=80 DPT=13368 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0

Eine Antwort von einem Webserver (Port 80).


Aug 9 17:08:24 host kernel: BLOCK: TCP IN=ippp0 OUT= MAC= SRC=212.xxx.xxx.xx DST=213.xxx.xxx.xx LEN=183 TOS=0x00 PREC=0x00 TTL=246 ID=37237 PROTO=TCP SPT=80 DPT=13045 WINDOW=34752 RES=0x00 ACK PSH FIN URGP=0

Eine Antwort von einem Webserver (Port 80).


und das geht jetzt den ganzen lieben langen Tag so.
laut RIPE ist 212.xxx.xxx.xx sowie einige andere Anfragen

Warum RIPE? Versuch mal ARIN oder APNIC. Du hast die IP ja leider zensiert, sonst hätte ich abgefragt.

Jasper
09.08.02, 22:40
wie belkira bereits schrieb, sind das vermutlich antworten von einem webserver. in einem anderen thread schrieb ich mal was über die verwendung von icmp zur verhinderung von retransmissions.

tcp ist verbindungsorientiert, d.h. die pakete müssen bestätigt werden. werden sie es nicht, werden sie wiederholt gesendet. und je nach einstellung des tcp/ip-stacks kann das über einen recht langen zeitraum passieren.

wenn du also pakete verwirfst, weiss die gegenstelle nicht, ob paket angekommen oder nicht. die folge sind retransmissions und reretransmissions. gibst du stattdessen ein entsprechendes icmp-paket (port-unreach bspw.) oder tcp_reset zurück, kann der tcp/ip-stack der gegenseite reagieren und stellt darufhin in der regel die retransmissions ein.

also mach dir erstmal keine sorgen. wenn dein filter soweit steht implementierst du ordentliches error-handling und siehst dir das ganze nochmal an.

zu 'forward only': deine annahme ist korrekt.

-j

habbom
09.08.02, 22:57
Hi Belkira,
@zensiert
ich bin mir nie sicher ob hier IPs reingesetzt werden sollten
dummerweise habe ich die logdateien geleert
:mad:

aber seit etwa 18 Uhr (ortszeit) ist es wieder vorbei , merkwürdig, naja , als erstes denke ich immer an einen Fehler meinerseits

..aber danke für den Hinweis mit ARIN und APNIC, hat mich auf jeden fall weitergebracht, die letzten loggs waren aus Taiwan von einer Telefongesellschaft

..man lernt nie aus

dank und Gruß
Michael

habbom
10.08.02, 15:22
nachtrag

jetzt taucht in der logdatei auch mein Provider auf
spt 80 dpt 3792

:confused:

hat denn keiner eine Idee ?

Michael

Belkira
10.08.02, 18:05
jetzt taucht in der logdatei auch mein Provider auf
spt 80 dpt 3792

:confused:

hat denn keiner eine Idee ?

Was möchtest Du denn anderes hören, als ich bereits geschrieben hatte? :rolleyes:

TCP, Source Port 80, DPT = Dein Rechner, ACK bzw. ACK FIN, das sind doch aller Wahrscheinlichkeit nach Antwortpakete eines HTTP Servers.

Sehr gut möglich, daß Deine Firewall Mist baut.

habbom
11.08.02, 19:10
@Belkira
Du hast ja recht, das mit dem port war mir schon klar:rolleyes:

im mom bastel ich mal wieder an dem Script rum

Ich war der Meinung, daß einige leuts an dem Logeintrag sehen können, wo ich bei der Suche anfangen muß, bzw, worauf ich achten muß, aber dazu hab ich gerade einem anderen thread eröffnet

danke nochmal
Michael