Hallo,
meine Firewall meldete mir Folgendes:
Outbound UDP packet
Local address,service is (0.0.0.0,Backdoor-g-1)
Remote address,service is (145.253.2.11,domain)
Process name is "C:\PROGRAMME\NETSCAPE\COMMUNICATOR\PROGRAM\NETSCAPE.EXE"
Soweit ich weiß, ist Backdoor doch auch der Name eines Trojaners, oder?
Mein NAV und AntiTrojan finden aber nichts Verdächtiges.
Gibt es einen (ungefährlichen) Service, der denselben Namen trägt?
Gruß,
Salzmann
Outbound UDP packet
Local address,service is (0.0.0.0,Backdoor-g-1)
Remote address,service is (145.253.2.11,domain)
Process name is
„C:\PROGRAMME\NETSCAPE\COMMUNICATOR\PROGRAM\NETSCAPE.EXE“
also du surfst ueber arcor und dein netscape hat gerade einen dns-lookup gemacht. dummerweise hat er dazu als source port die 1394 benutzt, was deine nicht wirklich intelligent konfigurierte personal firewall (ganz neu, was?) zu schreien gebracht hat. sowas habe ich von meine chefs, die „jetzt auch zone-alarm haben“ haeufiger…
joachim, der dass fuer absolut harmlos haelt…
Hallo und Danke für die Antwort,
also du surfst ueber arcor und dein netscape hat gerade einen
dns-lookup gemacht.
Dass dieser blockiert wurde hatte allerdings keine (spürbaren) Auswirkungen. Ist da etwas Überflüssiges blockiert worden?
dummerweise hat er dazu als source port
die 1394 benutzt, was deine nicht wirklich intelligent
konfigurierte personal firewall (ganz neu, was?) zu schreien
gebracht hat.
Ich schließe daraus, dass backdoor-g-1 für den Port 1394 steht, stimmt das?
Und woran würde ich den gleichnamigen Trojaner erkennen? Wäre es dann das ausführende Programm, welches den Namen tragen würde?
Dass die Firewall „nicht wirklich intelligent konfiguriert“ ist gebe ich selbstkritisch zu.
Danke jedenfalls schonmal!
Gruß,
Salzmann
Hallöchen
also du surfst ueber arcor und dein netscape hat gerade einen
dns-lookup gemacht.Dass dieser blockiert wurde hatte allerdings keine (spürbaren)
Auswirkungen. Ist da etwas Überflüssiges blockiert worden?
Wenn der dnslookup nicht über UDP funktioniert, dann wird nochmal über TCP angefragt. Somit bekommst Du auch keine spürbaren Auswirkungen mit.
Grüße
Martin
Re-Hallo,
Wenn der dnslookup nicht über UDP funktioniert, dann wird
nochmal über TCP angefragt. Somit bekommst Du auch keine
spürbaren Auswirkungen mit.
Dann ist entweder meine Firewall unzuverlässig oder es wurde doch nicht über TCP angefragt.
Denn der Service backdoor-g-1 ist im Regelwerk vor dem dnslookup eingetragen und blockiert demnach alles - egal, ob UDP oder TCP.
Gruß,
L’homme du sel
Wenn der dnslookup nicht über UDP funktioniert, dann wird
nochmal über TCP angefragt. Somit bekommst Du auch keine
spürbaren Auswirkungen mit.Dann ist entweder meine Firewall unzuverlässig oder es wurde
doch nicht über TCP angefragt.
Denn der Service backdoor-g-1 ist im Regelwerk vor dem
dnslookup eingetragen und blockiert demnach alles - egal, ob
UDP oder TCP.
ob tcp, ob udp, alles egal hier. die rule sprang ja nur auf den source port 1394 den dns-lookups an, und der ist beim naechsten versuch schon wieder anders. aber mal im ernst, ne rule, die trojaner fangen soll, und auch beim einschlaegigen port als source-port schreit, ist imho vollkommener schwachfug. source-ports variieren nun mal, und wenn’s dann zufaelligerweis mal einen von den ueblichen verdaechtigen trifft, gibts fehlalarm.
und ausserdem: explizit nach trojanern suchen bringt nix, es gibt zu viele. hinten ne deny-all rule ran und das erlauben, was man wirklich braucht…
just my 2 cents,
joachim
…
[Joachim beantwortet sehr gut eine Frage und zigt dabei mit links auf, wie dumm diese Blinke-„Firewall“-Programme doch sind als letzten Tip hat er folgendes parat:]
hinten ne deny-all rule ran
Warum nicht drop? Mit wild und unreflektiert eingesetzem deny verdirbt man sich wirklich eine Menge…
just my 2 cents,
Ich habe auch noch zwei…
joachim
Se „113“ bastian
[Joachim beantwortet sehr gut eine Frage und zigt dabei mit links auf, wie dumm diese Blinke-„Firewall“-Programme doch sind als letzten Tip hat er folgendes parat:]
danke fuer die blumen.
hinten ne deny-all rule ran
Warum nicht drop? Mit wild und unreflektiert eingesetzem deny
verdirbt man sich wirklich eine Menge…
was ist deiner meinung nach der unterschied? mit deny meine ich: packet wegschmeissen…
joachim
danke fuer die blumen.
Für Deine Beiträge immer gerne.
was ist deiner meinung nach der unterschied? mit deny meine
ich: packet wegschmeissen…
Eben.
Einer meiner Lieblinkslinks:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.h…
Also: Deny bringt keine zusätzliche Sicherheit, wohl aber zusätzliche Probleme.
Sebastian
Einer meiner Lieblinkslinks:
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.h…
Also: Deny bringt keine zusätzliche Sicherheit, wohl aber
zusätzliche Probleme.
nette seite. aber ueber die sache mit dem deny kann man streiten. haengt von der situation ab und macht bei uns keinen sinn.
nen reject zu schicken kostet bandbreite, und unsere firewalls (fuer die ich gluecklicherweise nicht verantwortlich bin, mein job ist direkt dahinter) gehen oft genug auf dem zahnfleisch…
und wenn ne verbindung nach vorne rausgeht (und einen ident ausloest), dann waere was _extrem_ schiefgelaufen…
joachim
„block in quick all - The packet matches and the search is over. The packet is expunged without a peep. There are no notices, no logs, no memorial service. Cake will not be served.“
http://www.obfuscation.org/ipf/ipf-howto.txt
nette seite.
Absolut.
aber ueber die sache mit dem deny kann man
streiten.
Das kann man zum Glück überall.
nen reject zu schicken kostet bandbreite,
Wenn die Gegenstelle es nicht hinbekommt eine Verbindung aufzubauen, versucht sie unter Umständen ein Retry. Das geht auch auf die Bandbreite…
und wenn ne verbindung nach vorne rausgeht (und einen ident
ausloest), dann waere was _extrem_ schiefgelaufen…
Das habe ich nicht ganz verstanden. Egal.
Einen ident-Request zu beantworten mag in vielen Fällen unerwünscht sein. Ihn in ein DROP (anstelle eines REJECT) laufen zu lassen ist eine Fehlkonfiguration erster Güte.
„Obfusciation“ als Sichrheitsmaßnahme? Security by obscurity? Eine ganz schlechte IDEE IMHO.
Sebastian
nen reject zu schicken kostet bandbreite,
Wenn die Gegenstelle es nicht hinbekommt eine Verbindung
aufzubauen, versucht sie unter Umständen ein Retry. Das geht
auch auf die Bandbreite…
ist richtig. nur werden beim portscannen im allg. keine connections aufgebaut und schon gar keine retries geschickt, oder? und die zahl der echten versuche auf den falschen ports eine verbindung aufzubauen ist bei uns vernachlaessigbar.
und wenn ne verbindung nach vorne rausgeht (und einen ident
ausloest), dann waere was _extrem_ schiefgelaufen…Das habe ich nicht ganz verstanden. Egal.
naja es gibt halt keine ausgehenden connections ueber diese firewalls, ueber die sich ein eventuell geschaedigter informieren koennte.
und ein reverse ident ist meiner meinung nach nix was freundlichkeit verdient.
Einen ident-Request zu beantworten mag in vielen Fällen
unerwünscht sein.
allerdings
Ihn in ein DROP (anstelle eines REJECT)
laufen zu lassen ist eine Fehlkonfiguration erster Güte.
wie schon gesagt, in anderen faellen schon, hier nicht. bei einer general purpose firewall fuer ein normales geschaeft, wo alles durchlaeuft, ist es sicher ein gebot der hoeflichkeit, den ident zumindest mit reject zu quittieren…
aber ueber solche feinheiten habe ich bei meiner zweiten antwort ehrlichgesagt nicht nachgedacht, was ich primaer ausdruecken wollte, war, dass der frager die firewall verkehrtherum aufzaeumt…
„Obfusciation“ als Sichrheitsmaßnahme? Security by obscurity?
Eine ganz schlechte IDEE IMHO.
die seite ist aber nett gemacht. und ipf steht nun ganz sicher nicht fuer security by obscurity - bsd style license, freier geht’s nimmer…
joachim
nen reject zu schicken kostet bandbreite,
Wenn die Gegenstelle es nicht hinbekommt eine Verbindung
aufzubauen, versucht sie unter Umständen ein Retry. Das geht
auch auf die Bandbreite…ist richtig. nur werden beim portscannen im allg. keine
connections aufgebaut
Das wird versucht.
und schon gar keine retries geschickt,
Das eher nicht.
und ein reverse ident ist meiner meinung nach nix was
freundlichkeit verdient.
Ein „gewisser“ Prozentsatz von FTP-Sevbern tut das. Vielleicht 20% der Newsserver tun das. Etwa 50% der SMTP-Server tun das, (aus eigener, sicherleich nicht representativer Statistik), und das ist gut so[tm]. 99% der irc-Server tun das.
Wenn Du meinst, Du willst das nicht beantworten, konfiguriere „REJECT“, mit DENY schadet man sich wirklich selbst.
„Mein FTP bleibt immer am Anfang eine Minute hängen“
Einen ident-Request zu beantworten mag in vielen Fällen
unerwünscht sein.
Ihn in ein DROP (anstelle eines REJECT)
laufen zu lassen ist eine Fehlkonfiguration erster Güte.wie schon gesagt, in anderen faellen schon, hier nicht.
Doch. Es gibt keinen vernünftigen Grund, Anfragen auf Port 113 zu DROPen, außer man will seine und seiner User Zeit vertrödeln.
aber ueber solche feinheiten habe ich bei meiner zweiten
antwort ehrlichgesagt nicht nachgedacht, was ich primaer
ausdruecken wollte, war, dass der frager die firewall
verkehrtherum aufzaeumt…
Da sind wir uns wohl einig.
„Obfusciation“ als Sichrheitsmaßnahme? Security by obscurity?
Eine ganz schlechte IDEE IMHO.die seite ist aber nett gemacht. und ipf steht nun ganz sicher
nicht fuer security by obscurity - bsd style license, freier
geht’s nimmer…
Mist. Ertappt. Vielleicht sollte ich mir angewöhnen, mehr als dir URL einer Seite zu lesen bevor ich mäkele.
Sebastian