BEWEIS>dhcp&iptables: es kann doch nicht sein, dass...

[pablovschby]

....ich alles droppe..... ich komme dann (logischerweise) nimmer mehr ins i-net, hab kein ssh...und co.......ABER EIN DHCP-REQUEST über port 67 & 68 funktioniert trotzdem???? erbitte rat...hier ist der beweis:[root@master1 etc]# init.d/iptables status
Tabelle: filter
Chain INPUT (policy DROP)
target prot opt source destination
REJECT tcp -- anywhere anywhere tcp dpt:auth flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy DROP)
target prot opt source destination
[root@master1 etc]# dhclient eth0
Internet Software Consortium DHCP Client V3.0pl1
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth0/00:00:b4:c6:ac:91
Sending on LPF/eth0/00:00:b4:c6:ac:91
Sending on Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 62.2.3.84
bound to 80.218.65.207 -- renewal in 2425 seconds.
[root@master1 etc]#
gruss&danke
pablo

[mamue]

Ich sehe nicht de Filterregeln. Wenn ich das aber recht verstehe, blockst Du tcp. DHCP verwendet aber udp, wenn ich mich nicht irre.

mamue

[pablovschby]

es sind keine regeln definiert ...............die udp-pakets müssten gedroptt werden, schau die doch bitte oben die zeilen an, wo ich "init./iptables status" eingegeben habe...
gruss

[Thomas]

DHCP ist dazu da um eine IP-Adresse zu beziehen. (Ok, das wussten wir ja schon alle...)
Jetzt überlegen wir mal: Nach dem Bootvorgang ist noch keine IP-Adresse zugewiesen, dafür ist nun der DHCP-Client zuständig. Da aber noch keine IP-Adresse für eine Übertragung vorhanden ist, muss der Request auf einer Ebene abgesetzt werden, auf der keine IP-Adresse nötig ist. Ich weiss nicht genau über DHCP-Requests Bescheid (siehe hierzu die RFCs), ich denke aber dass iptables keine keine Kontrolle über diese Daten (-schicht) hat (Ich schätze Layer 2).

Thomas.

[RapidMax]

Das steht im RFC 951 (http://www.ietf.org/rfc/rfc951.txt). Im Gegensatz zu RARP das tatsächlich über die Datalink-Schicht funktioniert und deshalb nicht an Routern vorbeikommt, setzt das BOOTP (und somit auch DHCP) auf UDP/IP auf.

Der Rechner weiss nun aber nicht, was für eine IP-Addresse er hat, darum schickt er ein Broadcast mit der Source-Addresse 0.0.0.0 und der Zieladdresse 255.255.255.255 an den Zielport UDP 67 los. Der DHCP-Server antwortet dann ebenfalls in einem Broadcast an Zielport 68 mit der entsprechenden IP-Addresse.

Gruss, Andy

[pablovschby]

nach dem Bootvorgang ist noch keine IP-Adresse zugewiesen, dafür ist nun der DHCP-Client zuständig. Da aber noch keine IP-Adresse für eine Übertragung vorhanden ist, muss der Request auf einer Ebene abgesetzt werden, auf der keine IP-Adresse nötig ist. Ich weiss nicht genau über DHCP-Requests Bescheid (siehe hierzu die RFCs), ich denke aber dass iptables keine keine Kontrolle über diese Daten (-schicht) hat (Ich schätze Layer 2). es tut mir leid...... aber auch pakete auf der data link layer-schicht werden NICHT DORT UNTEN PRODUZIERT..........sorry....

aber egal in welchem fall: der dhcp-client ..... hat einen prozess... dieser prozess produziert IM APPLICATION LAYER irgendwas.....schiebt das runter..... und aufm TRANSPORT-LAYER kriegt dieses paket PORT 67 (oder von mir aus 68, natürlich udp)...... ....so....also....egal......was nun ist.....das paket müsste GEDOPPT WERDEN...... egal welches protokoll es benutzt... es will ja ein paket schicken auf port 67 oder 68


dass bevor die iptables gestartet sind, dieses paket empfangen und geschickt werden kann, ist mir klar.... aber wieso geht ein dhcp-req....usw..... WENN DIE IPTABLES GESTARTET SIND???

ich bin eigentlich nicht "schwer von begriff".... aber wills nur GENAU WISSEN.... und es tut mir leid....aber in iptables geben wir auch für udp-pakete ports an..... was nichts anderes heisst, als dass wir auch udp-pakets auf port 67&68 erkennen und filtern können

udp arbeitet zwar nicht-verbindungsorientiert, also erstellt keine logische verbindung....... in der schule wollte man uns weismachen, dass udp nicht mal ports benutzt.... aber wieso kommt dann ein wolfgang barth und schreibt in sein "firewall-buch" regeln hin, die ein udp-paket auf port XY blocken....????????

erbitte genaue erklärung
gruss
pablo

[pablovschby]

ihr behauptet also....... kein transport layer..... seid ihr am träumen.... schaut euch mal das an.... es steht doch da KLIPP UND KLAR.... PPOORRTT 67!!!!!!!!!!!...... also wieso kein transport layer...?DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 62.2.3.84
DHCPREQUEST on eth0 to 255.255.255.255 port 67gruss

sorry, aber mit jeder erklärung, die ihr mir gebt, komm ich weniger draus.... das problem: ich bin informiert.... aber wahrscheinlich begreifft ihr einfach immer noch net, was ich wissen möchte, was mein problem ist......ich kann es gerne noch hundert mal schreiben:

ich bleibe hier.... bis ichs weiss......sorry..... ich will niemanden stören und bin bereit, tagelang zu lesen....

.......nur kann mir anscheinend keine sau hierzu eine (klare) antwort geben...... wenn ihr mich also loshaben wollt--> account sperren
gruss

[steve-bracket]

Naja, so aus dem Stand kann dir keiner eine konkrete 100%ige Antwort geben sondern halt nur Tipps. Immerhin ist keiner vor Ort um deine Situation zu analysieren und deine Sys-Config kennt auch keiner.

Mein Vorschlag ist einfach mal ALLES mitzuloggen. Nicht nur Critical oder Warn sondern ALLES das nicht durchgeht und ALLES das durchgeht.
Dafür sollte das System von allen anderen Komponenten die irgendwie Traffic verursachen getrennt sein. (sonst wird die Logfile-Analyse sehr aufwendig)
Bestehenden Logfiles sichern und neue (leere) Files anlegen.
Anhand der mitgeloggten Ereignisse kannst du dann besser überprüfen wo der Fehler liegt.

fG
Steve

[Thomas]

Ich habe mal ein wenig gesnifft und gesehen, dass es tatsächlich nicht über layer 2 geht, als Absender wird die IP 0.0.0.0 benutzt. Sender-Port ist UDP 68.
Hm, ich werde der Sache mal weiter nachgehen.

@ pablovschby:
Nicht unverschämt werden, keine weiteren Themen aufmachen....


Thomas.

[RapidMax]

@pablovschby:

cat Post | sed 's/\.\.*/./g' \
| sed 's/\([a-zA-Z]\)\.\([a-zA-Z]\)/\1 \2/g' \
| sed 's/!!*/!/g' \
| tr "[:upper:]" "[:lower:]"

Gruss, Andy

[pablovschby]

Original geschrieben von steve-bracket
Naja, so aus dem Stand kann dir keiner eine konkrete 100%ige Antwort geben sondern halt nur Tipps. Immerhin ist keiner vor Ort um deine Situation zu analysieren und deine Sys-Config kennt auch keiner. das ist gar nicht gemeint.......... das will ich auch nicht.....ihr versteht mich nach wie vor nicht....

was ich will ist das: JAWOHL, PABLOVSCHBY....du hast recht... dhcp geht über port 67.... der dhcp-request DÜRFTE NICHT FUNKTIONIEREN!!! über eine solche antwort wär ich natürlich froh....hier:
Ich habe mal ein wenig gesnifft und gesehen, dass es tatsächlich nicht über layer 2 geht, als Absender wird die IP 0.0.0.0 benutzt. Sender-Port ist UDP 68.
Hm, ich werde der Sache mal weiter nachgehen. ok, danke....
ich interpretiere dieses "quote" mal so: jawohl, dhcp-request geht über udp 68 und NICHT NUR über den layer 2....

.....tja...ich hoffe, ich habe das richtig interpretiert.....aber auf diese antwort warte ich hier schon seit etwa 1woche.... und selbst jetzt weiss ich s nich nicht genau...
Nicht unverschämt werden, keine weiteren Themen aufmachen.... das mit den themen ist übersichtssache....da kann man sich streiten....

und das mit dem unverschämt: gross/klein &dickschreiben.... ihr versteht mich einfach in vielen fällen falsch.....und dann schreib ich so....., was ich meine..., damit ihrs besser versteht...


nd auch das:
[root@master1 etc]# cat Post | sed 's/\.\.*/./g' | sed 's/\([a-zA-Z]\)\.\([a-zA-Z]\)/\1 \2/g' | sed 's/!!*/!/g' | tr "[:upper:]" "[:lower:]"
cat: Post: Datei oder Verzeichnis nicht gefunden
[root@master1 etc]#
Mein Vorschlag ist einfach mal ALLES mitzuloggen. Nicht nur Critical oder Warn sondern ALLES das nicht durchgeht und ALLES das durchgeht.
Dafür sollte das System von allen anderen Komponenten die irgendwie Traffic verursachen getrennt sein. (sonst wird die Logfile-Analyse sehr aufwendig)
Bestehenden Logfiles sichern und neue (leere) Files anlegen.
Anhand der mitgeloggten Ereignisse kannst du dann besser überprüfen wo der Fehler liegt. ich kenne mich in der therie der netzwerke, dienste und co gut aus, würd ich mal behaupten....aber in der praxis...naja...

ich weiss nicht, wie ich obenstehende sache machen sollte, sorry.... kenne zwar den "syslog"-daemon des linux, aber mehr als den namen weiss ich nicht pber den dienst.....

tatsache ist: (ich wär froh, wenn mir das irgendwann mal jemand hier 100ert prozentig sagen könnte)...dhcp läuft über port 67 udp...... dieser port wird GEDROPPT.... und trotzdem funzen die dhcp-requests........das ist eine tatsache....

dann könnte man sagen: ja, das ist unlogisch....woran das liegt, kann ich jetzt net sagen, aber ein dhcp-request dürfte NICHT FUNZEN.....

wenn mir das jemand schreibt, hätte ich endlich mal, was ich schon längst suche

aber da wir ja in unserer "freien welt" leben, könnt ihr auch weiterhin... sachen schreiben wie: die regel erlaubt dhcp, also komm nicht mit solchen sachen (die regel war auskommentiert...)

nix für ungut.... jeder macht fehler....nicht nur ich...
gruss

[pablovschby]

so.....also...ich denke, ich poste nochmals ein anderes script...
#!/bin/tcsh
echo "Filterregeln des MASTERCHAINS werden übernommen..."
#---------------------------
#Variablen:
set IPTABLES = /sbin/iptables
set p_high = 1024:65535 #unprivileged ports
set IF = eth0
set p_ssh = 1000:1023 #common ssh source ports
#---------------------------
#dyn. Kernel Parameter setzen:
echo 0 > /proc/sys/net/ipv4/ip_forward #2 > /dev/null #disable forward chain
echo 1 > /proc/sys/net/ipv4/tcp_syncookies #2> /dev/null #enable tcp-queries
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts #2> /dev/null
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses #2> /dev/null

#---------------------------
#REGELN:
#flush and default policy drop
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP
$IPTABLES -X
$IPTABLES -F


#lokale prozesse freischalten
$IPTABLES -A OUTPUT -o lo -j ACCEPT
$IPTABLES -A INPUT -i lo -j ACCEPTso...also....wird alles gedroppt?--->JAWOHL!
wird auch port 67 gedroppt?---->JAWOHL!
wird auch port 68 gedroppt?---->JAWOHL!
für udp und tcp?----->JAWOHL!
also löschst du defined-chains wie auch alle filterregeln und droppst alles stdardmässig?---->JAWOHLsoo................

und gott sprach, pablo soll bestraft werden mit einem unlogischem pc....und so wars...haha DHCP-REQUEST FUNKTIONIERT-.....
[root@master1 etc]# /home/pablo/flush
Filterregeln des MASTERCHAINS werden übernommen...
[root@master1 etc]# dhclient eth0
Internet Software Consortium DHCP Client V3.0pl1
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth0/00:00:b4:c6:ac:91
Sending on LPF/eth0/00:00:b4:c6:ac:91
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 62.2.3.84
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 62.2.3.84
bound to 217.162.226.151 -- renewal in 2465 seconds.
[root@master1 etc]#easy...gruss
pablo

[kehj]

Moin,

hast du mal geguckt, ob die von DHCP-Request erzeugten Pakete von iptables gezählt werden?

Mit iptables -L -n --verbose wird für jede Chain ausgegeben, wieviele Pakete von welcher Regel bearbeitet werden.
Mit der Option -Z kann man die Zähler auf Null setzen.
Also, Zähler-Reset und dann die DHCP-Anfrage starten. Mal gucken, was passiert ;)

Mein Gedanke ist folgender:

Wenn du eine Regel hast, die den DHCP-Verkehr zulässt, siehst du es so. (Ja, ich weiß, daß überall DROP steht)

[HangLoose]

moin moin

ich meine in irgendeiner mailingliste mal gelesen zu haben, das dhcp über ein raw socket läuft und iptables diese anfragen gar nicht zu sehen kriegt. sicher bin ich mir aber nicht, soll auch nur mal ein stichwort für google sein, mir fehlt die zeit dazu.


Gruß HL

[Jasper]

Original geschrieben von HangLoose

ich meine in irgendeiner mailingliste mal gelesen zu haben, das dhcp über ein raw socket läuft und iptables diese anfragen gar nicht zu sehen kriegt. sicher bin ich mir aber nicht, soll auch nur mal ein stichwort für google sein, mir fehlt die zeit dazu.


du hast vollkommen recht.
der dhcpd von ISC verwendet raw sockets für die kommunikation.
daten von/zu raw werden nicht von netfilter verarbeitet, d.h. sie gehen an netfilter vorbei.

dazu ging vor einiger zeit etwas auf der netfilter-ml rum. es dürfte nicht schwer sein, das zu finden.

-j

[pablovschby]

Original geschrieben von kehj
Moin,

hast du mal geguckt, ob die von DHCP-Request erzeugten Pakete von iptables gezählt werden?

Mit iptables -L -n --verbose wird für jede Chain ausgegeben, wieviele Pakete von welcher Regel bearbeitet werden.
Mit der Option -Z kann man die Zähler auf Null setzen.
Also, Zähler-Reset und dann die DHCP-Anfrage starten. Mal gucken, was passiert ;)

Mein Gedanke ist folgender:

Wenn du eine Regel hast, die den DHCP-Verkehr zulässt, siehst du es so. (Ja, ich weiß, daß überall DROP steht) dankdir vielmals für die paar tipps....habe das mal gemacht....so:
- vor eingabe "dhclient eth0" heissts überall 0 packets.....nach eingabe von "dhclient eth0" heissts:[root@master1 etc]# iptables -L -n --verbose
Chain INPUT (policy DROP 1 packets, 48 bytes)
pkts bytes target prot opt in out source destination
8 400 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
4 284 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:53 flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 dpts:1024:65535 flags:!0x16/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:443 dpts:1024:65535 flags:!0x16/0x02
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 flags:0x16/0x02 reject-with icmp-port-unreachable
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 dpts:1024:65535

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
8 400 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
4 220 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:443
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 dpts:1024:65535also.... 8mal auf loopback-interface, das sind ja eh auch lokale prozesse.....aber 4mal dns-port benützt.....easy
ich meine in irgendeiner mailingliste mal gelesen zu haben, das dhcp über ein raw socket läuft und iptables diese anfragen gar nicht zu sehen kriegt. sicher bin ich mir aber nicht, soll auch nur mal ein stichwort für google sein, mir fehlt die zeit dazu.ja...ok ich finde praktisch nix gscheits.über google
du hast vollkommen recht.
der dhcpd von ISC verwendet raw sockets für die kommunikation.
daten von/zu raw werden nicht von netfilter verarbeitet, d.h. sie gehen an netfilter vorbei. ....ok...danke....dhcp er raw....aber wie raw filtern mit iptables.....ich such mal...
gruss&danke
pablo

p.s.:
und raw-pakete gehen am netfilter vorbei,...ist das nicht gefährlich...? ein hacker könnte ja glatt einen client in en falsches netzwerk nehmen .... ihm ne falsche ip geben...usw

[Jasper]

Original geschrieben von pablovschby

p.s.:ist das nicht gefährlich...? ein hacker könnte ja glatt einen client in en falsches netzwerk nehmen .... ihm ne falsche ip geben...usw

die besonderheit ist ja, das der raw socket und netfilter auf ein und derselben maschine sein müssen. und raw sockets darf nur root erstellen, insofern ist da nichts gefährliches dran.

-j

[pablovschby]

Original geschrieben von Jasper
die besonderheit ist ja, das der raw socket und netfilter auf ein und derselben maschine sein müssen. und raw sockets darf nur root erstellen, insofern ist da nichts gefährliches dran.

-j sorry, aber das versteh ich nicht ganz..... ein raw-socket wird empfangen..... vom dhcp-server ... und das kann auch ein hacker sein...was ist daran nicht gefährlich?
gruss&danke

[pablovschby]

1. hab mein iptables deinstalliert.....habe jetzt das 1.2.8 drauf...dann...
2. habe ich den patch "raw.patch" von netfilter.org runtergeladen..... der durchsucht dann auch die raw-sockets, regeln anstatt mit "tcp" oder "udp" einfach mit "raw" ansteuern...

...ok...es steht aber nirgens, ... wie man das machen muss.....kennt ihr hierfür ev. eine gute anleitung ...?

wenn ich den patch einfach so ausführe kommen eetliche fehler (command not dound und co...)....ich nehme an, den patch muss man erst irgendwohin kopieren, oder...da steht aber dadrüber nirgens....was..
gruss&danke
pablo

[Jasper]

Original geschrieben von pablovschby
sorry, aber das versteh ich nicht ganz..... ein raw-socket wird empfangen..... vom dhcp-server ... und das kann auch ein hacker sein...was ist daran nicht gefährlich?
gruss&danke

nein, ein raw socket ist kein protokoll oder ähnliches. das ist einfach nur ein sockettyp.
die daten werden ganz normal per udp übertragen und das kann gefiltert werden.

mit raw sockets kann man nur den lokalen netfilter umgehen. um einen raw socket aber nutzen zu können, muss man root sein. wenn ich eh schon root ist, kann ich auch einfach den netfilter abschalten.

deshalb ist das kein sicherheitsproblem.

-j

[Jasper]

Original geschrieben von pablovschby
wenn ich den patch einfach so ausführe kommen eetliche fehler (command not dound und co...)....ich nehme an, den patch muss man erst irgendwohin kopieren, oder...da steht aber dadrüber nirgens....was..
gruss&danke
pablo

ein patch ist i.d.R. ein textfile, das die änderungen im quelltext beschreibt muss auf den quelltext angewandt werden. das tool dafür heisst 'patch'. es gibt IMHO ein patch howto.

-j

[pablovschby]

Original geschrieben von Jasper
nein, ein raw socket ist kein protokoll oder ähnliches. das ist einfach nur ein sockettyp.
die daten werden ganz normal per udp übertragen und das kann gefiltert werden.

mit raw sockets kann man nur den lokalen netfilter umgehen. um einen raw socket aber nutzen zu können, muss man root sein. wenn ich eh schon root ist, kann ich auch einfach den netfilter abschalten.

deshalb ist das kein sicherheitsproblem.

-j ok...also.....indemfall sind wir WIEDER AM ANFANG....

wo sind denn die udp-packets meines (oben aufgeführten) dhcp-requests...? jawohl...alles, was durchkam, waren die 4 packets auf port 53........aha....neue regel...

du bringst alles durcheinander...sorry..... wieso kommt nun der dhcp-request durch, wenn ich alles droppe...?????? erbitte antwort ..... (immer noch dasselbe, es wird immer dasselbe sein....) ...d u hast oben geradewegs wieder behauptet, dhcp lässt sich droppen...also benützt udp...und DAS KANN NICHT SEIN!!!!!

udp lässt sich droppen..... winsocket ist port & ip...
...was sind die raw-sockets...?

[pablovschby]

Original geschrieben von Jasper
ein patch ist i.d.R. ein textfile, das die änderungen im quelltext beschreibt muss auf den quelltext angewandt werden. das tool dafür heisst 'patch'. es gibt IMHO ein patch howto.

-j so......eben meine frage war ja, wo gibts ein patch-howto...auf www.netfilter.org hab ich nix gfefunden.......hier was mein linux meint, wenn ich den patch im verzeichnis des unkompilierten source-codes ausführe:
[root@master1 iptables-1.2.8]# raw.patch
bash: raw.patch: command not found
[root@master1 iptables-1.2.8]# ./raw.patch
diff: diff.exclude: Datei oder Verzeichnis nicht gefunden
./raw.patch: line 2: ---: command not found
./raw.patch: line 3: +++: command not found
./raw.patch: line 4: @@: command not found
./raw.patch: line 5: =: Datei oder Verzeichnis nicht gefunden
./raw.patch: line 8: +#define: command not found
diff: diff.exclude: Datei oder Verzeichnis nicht gefunden
./raw.patch: line 13: ---: command not found
./raw.patch: line 14: +++: command not found
./raw.patch: line 15: @@: command not found
./raw.patch: line 16: syntax error near unexpected token `('
./raw.patch: line 16: ` extern int ip_conntrack_protocol_register(struct ip_conntrack_protocol *proto);'gruss
pablo

[Jasper]

Original geschrieben von pablovschby
ok...also.....indemfall sind wir WIEDER AM ANFANG....

wo sind denn die udp-packets meines (oben aufgeführten) dhcp-requests...? jawohl...alles, was durchkam, waren die 4 packets auf port 53........aha....neue regel...

du bringst alles durcheinander...sorry..... wieso kommt nun der dhcp-request durch, wenn ich alles droppe...?????? erbitte antwort ..... (immer noch dasselbe, es wird immer dasselbe sein....) ...d u hast oben geradewegs wieder behauptet, dhcp lässt sich droppen...also benützt udp...und DAS KANN NICHT SEIN!!!!!

udp lässt sich droppen..... winsocket ist port & ip...
...was sind die raw-sockets...?

1. bringe ich nichts durcheinander
2. weiss ich was ich gesagt habe
3. hast du bereits die antwort auf dine frage

und jetzt nochmal ganz langsam:

du hast auf maschine X netfilter so konfiguriert, dass er alles droppen soll. auf dieser maschine startest du einen dhcpclient, um eine ip adresse von einem dhcp-server zu erhalten. dieser client muss als root gestartet werden weil er einen raw socket für die kommunikation öffnet. über diesen raw socket schickt der client den request per udp von port 68 and an 255.255.255.255 port 67 raus. die antwort kommt vom dhcp-server von port 67 an 255.255.255.255 port 68 (etwas vereinfacht).

der client empfängt diese über den raw socket und hat seine ip-adresse. nun ist ein raw socket ein spezieller socket, der alles an diesen port empfängt, unabhängig vom protokoll (tcp/udp/esp/etc.pp). raw sockets empfangen die daten VOR netfilter, d.h. netfilter ist wirkungslos.

da raw sockets aber nur ausschliesslich von root geöffnet werden können, ist das kein sicherheits problem.

hoffe das war jetzt endlich deutlich und ausführlich genug.

-j

[pablovschby]

ok...danke...ich habs begriffen...

diese pakete haben einen ip/tcp/udp-header...ist ja logisch....nach layer 2 werden sie ja vom progi abgeholt (in dem sinn, oder???)...... dieses progi UMGEHT den paketfilter tatsächlich...daher die root-rechte....

.....ausserdem: die raw-pakete lassen sich aber net filtern oder so, oder? höchstens loggen,...
???oder?
....auch mit dem besten patch der iptables nicht....oder? weil das ja vom aufbau des betriebssystems abhängig ist.....und nicht von iptables oder so....
gruss&danke
pablo

[mbo]

1.) zum Thema Patch:
benutze bitte Google richtig, bevor Du meckerst.
-> www.google.de
-> linux +patch +howto
-> http://www.google.de/search?q=linux+%2Bpatch+%2Bhowto&ie=UTF-8&oe=UTF-8&hl=de&btnG=Google+Suche&meta=lr%3Dlang_de
-> viele Ergebnisse

2.) iptables
es gab für mich viele Gründe, die iptables nicht benutzen zu wollen, unter anderem, weil ich nicht leiden kann, wenn jemand behauptet "ich denke, ich habe es gut gemacht", aber reine philosphie-frage.
ipchains zB dropte sämtliche DHCP-Offers. Ich gebe Dir in dem Punkt recht, daß ich nicht verstehen kann, warum dies net bei iptables funktioniert.
Und die Aussage, das es kein Sicherheitsrisiko ist, ist etwas einfach, auch die Begründung. Im Zweifelsfall ist es eine Sicherheitslücke, wenn man es nicht kontrollieren kann (zB UDP-Port für Monitordienst ), inwiefern man dieses Loch ausnutzen kann, bleibt die andere Frage.

3.) dieser Thread ist in einigen Bereichen sehr emotional geworden. Bedenkt bitte, was uns von Frauen unterscheidet ;)

schönen Dienstag noch
cu/2 iae

[pablovschby]

Original geschrieben von mbo
1.) zum Thema Patch:
benutze bitte Google richtig, bevor Du meckerst.
-> www.google.de
-> linux +patch +howto
-> http://www.google.de/search?q=linux+%2Bpatch+%2Bhowto&ie=UTF-8&oe=UTF-8&hl=de&btnG=Google+Suche&meta=lr%3Dlang_de
-> viele Ergebnisseso...
1. ich habe gar nirgens gemekert....ich habe geschrieben: "man findet keine nützlichen anleitungen" oder sowas.....und das ist wahr.....die links von dir (die suche) zielte leider auf etwas völlig anderes ab, als ich suchte.....da hast du glaubs einiges missverstanden.....

die suche nach den sachen, die ich oben erwähnte,.... bringt keine brauchbaren anleitungen oder beschreibungen hervor...

2.) iptables
es gab für mich viele Gründe, die iptables nicht benutzen zu wollen, unter anderem, weil ich nicht leiden kann, wenn jemand behauptet "ich denke, ich habe es gut gemacht", aber reine philosphie-frage.
ipchains zB dropte sämtliche DHCP-Offers. Ich gebe Dir in dem Punkt recht, daß ich nicht verstehen kann, warum dies net bei iptables funktioniert.
Und die Aussage, das es kein Sicherheitsrisiko ist, ist etwas einfach, auch die Begründung. Im Zweifelsfall ist es eine Sicherheitslücke, wenn man es nicht kontrollieren kann (zB UDP-Port für Monitordienst ), inwiefern man dieses Loch ausnutzen kann, bleibt die andere Frage. die aussage, dass es kein sich.rsiko ist, beruht darauf (und verlässt sich darauf, ....) dasses eben keine sich.risiko ist,.....und das ist ja schlimm.... das hat nix mehr mit sich.heit zu tun..
3.) dieser Thread ist in einigen Bereichen sehr emotional geworden. Bedenkt bitte, was uns von Frauen unterscheidet ;)

schönen Dienstag noch
cu/2 iae 1. da kennst du aber die falschen frauen

2. siehe anderer thread....

gruss&danke
pablo

[mbo]

Original geschrieben von pablovschby
so...
1. ich habe gar nirgens gemekert....ich habe geschrieben: "man findet keine nützlichen anleitungen" oder sowas.....und das ist wahr.....die links von dir (die suche) zielte leider auf etwas völlig anderes ab, als ich suchte.....da hast du glaubs einiges missverstanden.....

die suche nach den sachen, die ich oben erwähnte,.... bringt keine brauchbaren anleitungen oder beschreibungen hervor...
[/B]
Mitnichten!
Deine Aussage war eindeutig, daß Du keine Informationen über die Vorgehensweise / Anwendung des von Dir geladenen Patches findest. Dies Aussage ist unwahr.
Die Links, welche Du über die, zB von mir initialisierte Suche, Links von Google findest, beschreiben EINDEUTIG den Umstand / die Vorgehensweise des Patchen.
Da Du Dir dementsprechende Gedanken über iptables, DHCP-Offers und raw-socket machst, ging ich davon aus, daß Du die durch die Links von Google offerierten Information auf deine Problematik anwenden kannst.

cu/2 iae

[Jasper]

Original geschrieben von mbo

2.) iptables
es gab für mich viele Gründe, die iptables nicht benutzen zu wollen, unter anderem, weil ich nicht leiden kann, wenn jemand behauptet "ich denke, ich habe es gut gemacht", aber reine philosphie-frage.
ipchains zB dropte sämtliche DHCP-Offers. Ich gebe Dir in dem Punkt recht, daß ich nicht verstehen kann, warum dies net bei iptables funktioniert.
Und die Aussage, das es kein Sicherheitsrisiko ist, ist etwas einfach, auch die Begründung. Im Zweifelsfall ist es eine Sicherheitslücke, wenn man es nicht kontrollieren kann (zB UDP-Port für Monitordienst ), inwiefern man dieses Loch ausnutzen kann, bleibt die andere Frage.


AFAIK, droppt iptables das paket schon, aber die besonderheit bei raw sockets ist, dass eine kopie des paketes an den raw socket geht und das paket dann ganz normal durch den ip-stack geht. das müsste sich mittels einer logrule prüfen lassen.

ok, anderes beispiel:

ich sperre per iptables den port 2000, setzte einen sniffer auf port 2000 und schicke von remote ein paket an port 2000. ich sehe das paket im sniffer. ist das eine sicherheitslücke? ich meine nicht, weil ich nur als root den socket anlegen kann (mal mit lsof nachsehen, was für einen socket der sniffer anlegt). root könnte jede sicherheitssperre umgehen (wir lassen mal lids, rsbac, medusa, o.ä. aussen vor.)

insofern ist das IMHO kein risiko und keine lücke. es ist ja auch keine sicherheitslücke, dass root ALLE dateien lesen/schreiben/löschen kann.
wenn man die macht von root einschränken will, muss man zu lids, o.ä. greifen.

-j

[pablovschby]

AFAIK, droppt iptables das paket schon, aber die besonderheit bei raw sockets ist, dass eine kopie des paketes an den raw socket geht und das paket dann ganz normal durch den ip-stack geht. das müsste sich mittels einer logrule prüfen lassen.super...es droppt das original des pakets....die kopie aber, die an den "raw socket" geht, geht nicht mehr normal durch den ip-stack dann, oder...? das programm bekommt das selbst und läst das nach tcp/ip-headers auf.... wenn es "normal" durch den ip-stack gehen wüde, würde es ja gedroppt werden, oder..?
ok, anderes beispiel:

ich sperre per iptables den port 2000, setzte einen sniffer auf port 2000 und schicke von remote ein paket an port 2000. ich sehe das paket im sniffer. ist das eine sicherheitslücke? ich meine nicht, w-.also.... dies ist mir nun klaar....


aber welche progi's alle haben denn solche root-rechte? welche machen welche sockets...usw?? ich meine, das müsste doch dann genaustens bekannt sein, oder..?
gruss
pablo