Archiv verlassen und diese Seite im Standarddesign anzeigen : wie kann ich die ports stealthen(lmule) ?
hi,
wie kann ich die ports für emule stealthen? habe bei der firewall
#################eigene ergänzung#emule###################################
FW_SERVICES_EXT_TCP="4661 4662 4665 4666"
FW_SERVICES_UDP="4665 4666"
################################################## ##########################################
eingetragen. klappt auch alles. beim portscan sind die ports (bei verbindung mit lmule) offen aber bei nichtbenutzung von lmule closed,und nicht stealthed.
bitte mehr infos denn so wird das nix
was möchtest du denn wissen,um mir weiterhelfen zu können? die ports meiner firewall sind "versteckt" (stealthed). wenn ich im internet bin ist mein port 80 trotzdem stealthed. der lmule port ist "nur" closed, und wenn ich lmule starte, ist er offen. das möchte ich,wenn es geht ändern. ich habe mir schon nen wolf gesucht,aber leider nichts gefunden. man iptables überfordert mich noch.
Seh ich des richtig, dass das nene Auszu auf ner Suse Firewall (2) ist ??
MfG Markus
Schreib doch in Dein Script einfach DROP stat REJECT ...
ja ist susefirewall 2. mal eben "drop":) . heute nicht mehr.probier morgen aus.danke erstmal. melde mich wieder.
ab inne heia..
*grübel*
ich verstehe nicht ganz, was das eigentlich bringen soll :confused:
Worin besteht der Vorteil einen port zu "verstecken", anstatt ihn zu blocken?
die fw lässt anfragen an diese Ports durch -> wenn emule gestartet ist, sind sie offen sonst sind sie closed da ja nichts darauf lauscht.
>wenn ich im internet bin ist mein port 80 trotzdem stealthed
Surfen hat nichts mit deinem Port 80 zu tun, der ist für einen lokalen Webserver.
vg
Also, was mal 100% sicher ist, ist, dass dir das
FW_SERVICES_EXT_TCP="4661 4662 4665 4666"
FW_SERVICES_UDP="4665 4666" mal gar nicht bringt, was du willst !
Des weiteren kann ich mir nicht vorstellen, dass iptables (also auch die SuseFirewall2, welche auf Iptables aufbaut) überhaupt "stealthen" kann. Iptables verarbeiten ja letztendlich nur Pakete. Es wird geschaut ob eine gewisse Regel auf ein bestimmtes Datenpaket zutrifft und führt, sofern vorhanden, selbige Regel auf das Paket aus. Deshalb auch "Paketfilter". Iptbales können aber nicht viel mehr, als
=> ACCEPT
=> DROP
=> Weiterleiten, masqueraden, und andere "Kleinigkeiten".
Es wäre mir vollkommen neu, wenn man mit Iptables Ports "verstecken" könnte !!
MfG Markus
Ps: Sowas mag mit speziellen Programmen gehen, aber meiner Ansicht nach nicht mit IPtables.
PPs: @ N.D.: "Hiroshima '45, Tschernobyl '86, Windows '95 " Das ist ein SCH*ISS Spruch !!!!!!!!!!!!!
@Da.Bull
wenn du die abgelehnten pakete dropst, werden sie einfach fallengelassen. das ist dann der sogenannte *stealth-modus*. unsichtbar in dem sinne bist du dann aber noch lange nicht. das ganze ist mehr ein marketinggag der personal firewall hersteller.
ps:
mal gar nicht bringt, was du willst !
wenn emule auf dem firewallrechner läuft, ist das so schon richtig.
Gruß HL
was hat "Port verstecken" mit "Pakete droppen'" zu tun ???
FW_SERVICES_EXT_TCP="4661 4662 4665 4666"
FW_SERVICES_UDP="4665 4666" Dazu sagte ich: Dassist nicht, was er will ! Da diese 2 Zeilen ja dafür da sind, Pakete auf diesen Ports zu akzeptieren. (alles andere wäre ja sinnlos, weil emule sonst ja keine Verbindungen aufbauen könnte).
wenn emule auf dem firewallrechner läuft, ist das so schon richtig. Dagegen habe ich doch gar nichts gesagt !
MfG Markus
Und dass auch für ihn "droppen" und "stealthen" nciht das selbe ist, siehste du ja an "closed,und nicht stealthed". Er will die Ports also offen aber nicht sichtbar. Und das ist mit Iptables nicht möglich !
was hat "Port verstecken" mit "Pakete droppen'" zu tun ???
wenn du dropst, werden die pakete still und leise fallengelassen. für den sender der pakete bist du *unsichtbar*, da keine antwort kommt.
bei einem reject wird ein "port nicht erreichbar" etc. versandt und der sender der pakete weiß damit => der host ist zwar erreichbar, auf dem jeweiligen port lauscht kein dienst.
Dazu sagte ich: Dassist nicht, was er will ! Da diese 2 Zeilen ja dafür da sind, Pakete auf diesen Ports zu akzeptieren. (alles andere wäre ja sinnlos, weil emule sonst ja keine Verbindungen aufbauen könnte).
in dem punkt hab ich dich anscheinend falsch verstanden.
Und dass auch für ihn "droppen" und "stealthen" nciht das selbe ist, siehste du ja an "closed,und nicht stealthed". Er will die Ports also offen aber nicht sichtbar. Und das ist mit Iptables nicht möglich !
wie gesagt, wenn du drop einsetzt, zeigt dir so ein online-scanner ein "stealth" an, bei reject dagegen ein closed.
Gruß HL
k dann hab ich jetzt auch verstanden, was "stealthen" ist !
Man lernt eben nie aus ;)
MfG Markus
Stormbringer
08.05.03, 20:55
Ist dazu denn nicht Punkt 26 der FW2 gedacht?
# 26.)
# Do you want to REJECT packets instead of DROPing?
#
# DROPing (which is the default) will make portscans and attacks much
# slower, as no replies to the packets will be sent. REJECTing means, that
# for every illegal packet, a connection reject packet is sent to the
# sender.
#
# Choice: "yes" or "no", if not set defaults to "no"
#
FW_REJECT="no"
Gruß
@Da.Bull
Man lernt eben nie aus ;)
wem sagst du das ;)
@Stormbringer
ja eigentlich schon.
Gruß HL
"stealth" gehört in die Kategorie Schlangen Öl aka "Jeden Tag steht ein Dummer auf".
Das Droppen aller Pakete ist "sinnbefreit" und verursacht idR mehr Schaden als Nutzen. Beispiele dafür gibts mehr als genug: GMX, Intel, etc. (Mögliche Auswirkungen z. B. nicht Erreichbarkeit, erhöhter Traffik)
Im Gegensatz zu weitläufiger Meinung ist man mit einem Droppen auch nicht "unsichtbar", siehe mach man icmp
Original geschrieben von Jinto
Im Gegensatz zu weitläufiger Meinung ist man mit einem Droppen auch nicht "unsichtbar", siehe mach man icmp
So ist es. Mit dem Droppen von Paketen/Datagrammen kann man heutzutage allerhöchstens noch einem Script-Kiddie vorgaukeln, dass auf der IP, die die Pakete droppt, kein Rechner läuft. Ein ernsthafter Angreifer wird dagegen ziemlich schnell erkennen, dass der Host existiert und sogar ein Paketfilter darauf läuft.
Pakete/Datagramme droppen (Stealth) = Schmarrn.
Eleganter ist es, Anfragen für TCP mit einem TCP-Reset und Anfragen für UDP mit einem ICMP-Destination-Unreachable zu beantworten. Wenn man es dann ganz genau machen will, dann kann man noch ein bisserl am TTL-Feld rumbasteln, bevor die Anfragen rejected werden.
Harry
Da hast Du schon recht Jinto...
Gabs z.B. in der c´t schon rege Diskussionen drüber ob es richtig ist zu droppen...
Aber zumindest ist man für die große Masse unsichtbar;)
mfg
cane
ehrlich gesagt bin ich jetzt noch verwirrter als vorher. ....TTL-Feld....ICMP-Destination.... .
also,wenn ich es richtig verstanden habe, ist es egal,ob "stealthed" oder nicht(ausser vielleicht bei skript-kiddies).
ich dachte, dass der port dann abgesicherter wäre.
wenn der port für emule erreichbar ist, woher weiss die firewall,ob das paket auch wirklich von emule ist?
moin moin
ehrlich gesagt bin ich jetzt noch verwirrter als vorher. ....TTL-Feld....ICMP-Destination....
TTL => time to live, imho kannst du anhand dieser zahl erkennen, um was für ein BS es sich beim absender handelt. 64 = linux, 120 = win
also,wenn ich es richtig verstanden habe, ist es egal,ob "stealthed" oder nicht(ausser vielleicht bei skript-kiddies). ich dachte, dass der port dann abgesicherter wäre.
im prinzip ist drop und reject dasselbe. mit dem unterschied, das der absender bei einem reject eine ICMP-fehlermeldung bekommt und bei einem drop das paket einfach fallen gelassen wird. *dicht* ist der port bei beiden methoden. ausserdem gibt es noch fälle, in denen kein reject verwendet werden soll.
wenn der port für emule erreichbar ist, woher weiss die firewall,ob das paket auch wirklich von emule ist?
das kommt drauf an. wenn es ein antwortpaket ist, was zu einer von dir gestarteten verbindung gehört, dann weiß iptables anhand einer *tabelle*, das das paket zu dieser verbindung gehört. das ganze nennt sich connection tracking.
Gruß HL
muchaz graziaz @all
mal wieder weitergeholfen.
Original geschrieben von HangLoose
TTL => time to live, imho kannst du anhand dieser zahl erkennen, um was für ein BS es sich beim absender handelt. 64 = linux, 120 = win die TTL dient _nicht_ der Erkennung des OS, sondern zur Vermeidung ewig kreisender Pakete im Netz (sozusagen ein Verfallsdatum). Das man damit u. U. das OS identifizieren kann ist Zufall.
ausserdem gibt es noch fälle, in denen kein reject verwendet werden soll. Die aber deutlich in der unterzahl sind (derzeit fällt mir sogar nur eine einzige Regel ein, auf die das zutrifft), generell sollte REJECT die erste Wahl sein. DROP wird IMO in 99% der Fälle aus fehlender Kenntnis eigesetzt bzw. durch Marketing herangzüchtetes falsches "Wissen"
moin
kann mal jemand Jinto die schreibrechte entziehen ;):D
die TTL dient _nicht_ der Erkennung des OS, sondern zur Vermeidung ewig kreisender Pakete im Netz (sozusagen ein Verfallsdatum). Das man damit u. U. das OS identifizieren kann ist Zufall.
das die *erkennung des OS* nicht der zweck der ttl ist, war mir schon klar ;). ich meinte nur irgendwo mal gelesen zu haben, das man anhand der ttl das OS erkennen könnte.
Die aber deutlich in der unterzahl sind (derzeit fällt mir sogar nur eine einzige Regel ein, auf die das zutrifft)
im RFC 1122 steht das genauer drin. zum beispiel:
+ eine icmp-nachricht unbekannten typs trifft ein. paket wird verworfen.
+ eine icmp-fehlernachricht trifft ein. paket wird verworfen, da es sonst zu einer endlosschleife kommen würde.
+ ein paket besteht aus einem fragment, das nicht den beginn eines datagramms darstellt
...
Gruß HL
Original geschrieben von HangLoose
kann mal jemand Jinto die schreibrechte entziehen ;):D
Hör ich da ne Drohung? :eek: :D
das die *erkennung des OS* nicht der zweck der ttl ist, war mir schon klar ;). ich meinte nur irgendwo mal gelesen zu haben, das man anhand der ttl das OS erkennen könnte. Ja, aber in der von dir genannten RFC kannst du nachlesen, dass die TTL setzbar sein muss :-D
im RFC 1122 steht das genauer drin. zum beispiel:
+ eine icmp-nachricht unbekannten typs trifft ein. paket wird verworfen.
+ eine icmp-fehlernachricht trifft ein. paket wird verworfen, da es sonst zu einer endlosschleife kommen würde.
Ja, ICMPs waren die Regel an die ich dachte. Das Verwerfen Fehlerhafter bzw. falscher ICMPs könnte dem Kernel überlassen, da er alle ICMP Regeln bereits implementiert haben sollte. :eek:
+ ein paket besteht aus einem fragment, das nicht den beginn eines datagramms darstellt Damit hab ich jetzt ein Problem, ich weiss leider nicht welche Art von Paket du damit meinst.
Hör ich da ne Drohung? :eek: :D
du weißt schon wie ich das meine ;)
=> "Wer ist online?", hm mist Jinto hat schon wieder den thread am wickel, in dem ich grade gepostet habe. das kann ja wieder nur einen hinter die löffel geben :D:D:D
Gruß HL
pablovschby
14.05.03, 23:02
nur hierzu noch kurz was:
also,wenn ich es richtig verstanden habe, ist es egal,ob "stealthed" oder nicht(ausser vielleicht bei skript-kiddies).
ich dachte, dass der port dann abgesicherter wäre. wie schon 100mal erwähnt, ist die sache ja net sicherer, wenn sie gedroppt wird....aber natürlich: schneller....
also meiner ansicht nach würde ich das rejecten von unnötigen paketen als überflüssig bezeichnen, weil es ja dem client, der bspweise auf port 80 auf den server zugreifen darf wie auch allen anderen, die den server rechtsmässig nützen, *******egal sein kann.....ob jetzt da einer eine antwort auf nen ping bekommt....tja......
es kostet klar weniger rechenleistung, ein paket fallen zu lassen nach empfang als ein paket noch zu beantworten
das einzige, was sinn machen würde, wäre natülich das rejecten mit einer TTL von 120 bei einer linux-station....das wär natürlich wiederum schlau....
die TTL dient _nicht_ der Erkennung des OS, sondern zur Vermeidung ewig kreisender Pakete im Netz (sozusagen ein Verfallsdatum). Das man damit u. U. das OS identifizieren kann ist Zufall. dass die TTL nicht dazu dient, das os zu identifizieren, ist ja wohl klar...!!!!!! hier ist es genau, wie du sagst, ein zufall, dass bei linux die TTL 60 und bei wiun die TTL 120 ist....und daraus kann man durchaus schliessen (wenn auch sehr unsicher), welches bs der pc benützt....
gruss
pablo
pablovschby
14.05.03, 23:09
eine icmp-fehlernachricht trifft ein. paket wird verworfen, da es sonst zu einer endlosschleife kommen würde.die aussage hier sagt: icmp-pakete sollte man besser verwerfen...
Ja, ICMPs waren die Regel an die ich dachte. Das Verwerfen Fehlerhafter bzw. falscher ICMPs könnte dem Kernel überlassen, da er alle ICMP Regeln bereits implementiert haben sollte. hier das gegenteil..?
was ist nun besser? kann es nun beim verwerfen oder beim rejecten eines icmp-paketes zu einer endlosschleife kommen...?
gruss&danke
pablo
Original geschrieben von pablovschby
nur hierzu noch kurz was: wie schon 100mal erwähnt, ist die sache ja net sicherer, wenn sie gedroppt wird....aber natürlich: schneller.... Schneller? Für wen? Je nach verwendetem OS tritt nämlich das Gegenteil ein, weil auf beiden seiten "schlaue" Leute saßen die meinten auf einen Teil nicht bzw. falsch implemeniteren zu müssen.
also meiner ansicht nach würde ich das rejecten von unnötigen paketen als überflüssig bezeichnen, weil es ja dem client, der bspweise auf port 80 auf den server zugreifen darf wie auch allen anderen, die den server rechtsmässig nützen, *******egal sein kann.....ob jetzt da einer eine antwort auf nen ping bekommt....tja...... Wer redet hier von Ping? Es ist schlichtweg eine Verkrüppelung des Protokolls, und es gibt ja auch schließlich gute Gründe warum man sich daran halten sollte.
- Der wichtigste (IMO) wäre ja erstmal es ist so definiert und hält sich dementsprechend daran. Wenn man das nicht will, muss man sich eben sein eigenes Netz aufmachen oder eben schauen, dass sein "Verbesserungsvorschlag" als Standard umgesetzt wird.
- geringer Traffik
- geringere Antwortzeit (ident-Anfragen)
es kostet klar weniger rechenleistung, ein paket fallen zu lassen nach empfang als ein paket noch zu beantworten Es kostet klar weniger Rechenzeit einmal die Antwort zu verweigern, als 5 unnötige Pakete anzunehmen und zu verwerfen.
das einzige, was sinn machen würde, wäre natülich das rejecten mit einer TTL von 120 bei einer linux-station Ich dachte es wäre klar für was die TTL steht?
die aussage hier sagt: icmp-pakete sollte man besser verwerfen... Nein, die Aussage war:keine Antwort auf ICMP-Fehlernachrichten
hier das gegenteil..? Nein, wo habe ich das gegenteil geschriebn? Ließ bitte auch die angegebene RFC, vielelicht wirds dann deutlicher.
Lord_Pinhead
17.05.03, 11:24
Original geschrieben von HangLoose
120 = win
Kleine Berichtigung zu 120, in wirklichkeit ist es 128, den Verlust bekommt man durch die Hops über die Router, die muss man noch draufzählen. Must nur einen Traceroute auf die IP machen und die Hops dazu addieren. Aber man kann nur bedingt das OS damit herausfinden da in Windows und Linux/Unix Server die TTL setzbar ist und ein Admin das auch tun sollte, Client Windows Rechner bedürfen ein Extra Programm wie DFÜ-Speed. Frühere Scanner die eine OS Detection Funktion hatten nutzten nur die TTL erkennung, NMap macht schon andere Tests.
@marriman
Kannst du mit aktivierter Firewall rauspingen? Wenn ja welcher eintrag ist dafür zuständig, ICMP_EXT und ICMP_INT sind bei mir beide auf yes, kann aber trotzdem nicht Pingen oder angepingt werden :confused:
Wäre cool wenn du mir nen Tip geben könntest.
MFG
Lord Pinhead
moin moin
zu deinem firewall-prob. ich denke mal du verwendest die von suse. ziemlich am ende vom script gibt es die option ping ext oder so ähnlich. die mußt du auf yes setzen.
Gruß HL
Lord_Pinhead
02.06.03, 19:53
Oh ja, ich blindfisch. OK, dachte mit dem ICPM wäre es erledigt. OK, sollte mal meine Brille aufsetzten :D
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.