• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] logfiles laufen voll

gropiuskalle

gropiuskalle

Guru
Tach!

Ich habe hier neuerdings tonnenweise Meldungen in meinen logs, die ich nicht so richtig deuten kann. Hier mal ein Ausschnitt:

Code: 
6 TOS=0x00 PREC=0x00 TTL=118 ID=9715 DF PROTO=TCP SPT=57409 DPT=4662 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405AC0402080A001A797100000000)                                           
[ 8597.027714] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=89.131.110.185 DST=85.179.43.136 LEN=91 TOS=0x00 PREC=0x00 TTL=117 ID=55630 PROTO=ICMP TYPE=3 CODE=3 [SRC=85.179.43.136 DST=192.168.2.100 LEN=63 TOS=0x00 PREC=0x00 TTL=50 ID=0 DF PROTO=UDP SPT=65325 DPT=60072 LEN=43 ]                                                                                        
[ 8602.601254] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=187.90.188.249 DST=85.179.43.136 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=1311 DF PROTO=TCP SPT=2875 DPT=6881 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (020405B401010402)                                                     
[ 8603.125202] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=83.10.196.92 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=118 ID=13844 PROTO=UDP SPT=24747 DPT=6881 LEN=109            
[ 8611.632500] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=187.90.188.249 DST=85.179.43.136 LEN=48 TOS=0x00 PREC=0x00 TTL=115 ID=2347 DF PROTO=TCP SPT=2875 DPT=6881 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (020405B401010402)                                                     
[ 8620.969761] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=59.92.161.165 DST=85.179.43.136 LEN=95 TOS=0x00 PREC=0x00 TTL=118 ID=19203 PROTO=UDP SPT=34551 DPT=6881 LEN=75             
[ 8632.500811] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=189.15.108.0 DST=85.179.43.136 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=49707 DF PROTO=TCP SPT=42533 DPT=6881 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405140402080A00FC68C60000000001030305)                               
[ 8639.142285] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=119.237.58.90 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=117 ID=13747 PROTO=UDP SPT=9466 DPT=6881 LEN=109            
[ 8647.442303] npviewer.bin[11220]: segfault at ff99cd48 ip ff99cd48 sp bffe660c error 14  
[ 8653.099131] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=67.173.57.58 DST=85.179.43.136 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=5465 DF PROTO=TCP SPT=2757 DPT=6881 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402)                                                       
[ 8659.090656] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=213.191.15.133 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=117 ID=30339 PROTO=UDP SPT=7913 DPT=6881 LEN=109           
[ 8670.967689] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=91.97.0.68 DST=85.179.43.136 LEN=48 TOS=0x00 PREC=0x00 TTL=120 ID=17584 DF PROTO=TCP SPT=62542 DPT=6881 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (0204057801010402)                                                        
[ 8679.097063] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=203.138.29.227 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=113 ID=26642 PROTO=UDP SPT=61924 DPT=6881 LEN=109          
[ 8698.971854] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=79.117.60.156 DST=85.179.43.136 LEN=52 TOS=0x00 PREC=0x00 TTL=121 ID=24809 DF PROTO=TCP SPT=3146 DPT=6881 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405480103030301010402)                                             
[ 8699.113884] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=83.240.1.142 DST=85.179.43.136 LEN=95 TOS=0x00 PREC=0x00 TTL=117 ID=48442 PROTO=UDP SPT=25883 DPT=6881 LEN=75              
[ 8712.239973] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=89.238.168.9 DST=85.179.43.136 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=48123 DF PROTO=TCP SPT=15134 DPT=60208 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A83E31D4D0000000001030307)                              
[ 8718.568993] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=123.185.247.136 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=114 ID=4657 PROTO=UDP SPT=7982 DPT=6881 LEN=109           
[ 8740.714529] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=151.32.227.70 DST=85.179.43.136 LEN=129 TOS=0x00 PREC=0x00 TTL=118 ID=23059 PROTO=UDP SPT=18996 DPT=6881 LEN=109           
[ 8743.977020] SFW2-INext-DROP-DEFLT IN=dsl0 OUT= MAC= SRC=70.55.142.4 DST=85.179.43.136 LEN=48 TOS=0x00 PREC=0x00 TTL=118 ID=28263 DF PROTO=TCP SPT=4308 DPT=6881 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC01010402)

Neue Einträge erscheinen alle paar Sekunden. Meine Firewall-Einstellungen sehen so aus:

Code: 
hoppers:~ # iptables-save                                                        
# Generated by iptables-save v1.4.4 on Fri Nov 27 16:41:29 2009                            
*raw                                                                                       
:PREROUTING ACCEPT [575972:80555441]                                                       
:OUTPUT ACCEPT [643228:207629276]                                                          
-A PREROUTING -i lo -j NOTRACK                                                             
-A OUTPUT -o lo -j NOTRACK                                                                 
COMMIT                                                                                     
# Completed on Fri Nov 27 16:41:29 2009                                                    
# Generated by iptables-save v1.4.4 on Fri Nov 27 16:41:29 2009                            
*filter                                                                                    
:INPUT DROP [0:0]                                                                          
:FORWARD DROP [0:0]                                                                        
:OUTPUT ACCEPT [332:26900]                                                                 
:forward_ext - [0:0]                                                                       
:input_ext - [0:0]                                                                         
:reject_func - [0:0]                                                                       
-A INPUT -i lo -j ACCEPT                                                                   
-A INPUT -m state --state ESTABLISHED -j ACCEPT                                            
-A INPUT -p icmp -m state --state RELATED -j ACCEPT                                        
-A INPUT -i dsl0 -j input_ext                                                              
-A INPUT -i eth0 -j input_ext                                                              
-A INPUT -i vboxnet0 -j input_ext                                                          
-A INPUT -j input_ext                                                                      
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options                                                                          
-A INPUT -j DROP                                                                           
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "SFW2-FWD-ILL-ROUTING " --log-tcp-options --log-ip-options                                                                      
-A OUTPUT -o lo -j ACCEPT                                                                  
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT                               
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-OUT-ERROR " --log-tcp-options --log-ip-options                                                                             
-A input_ext -m pkttype --pkt-type broadcast -j DROP                                       
-A input_ext -p icmp -m icmp --icmp-type 4 -j ACCEPT                                       
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A input_ext -p tcp -m limit --limit 3/min -m tcp --dport 4662 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-ACC-TCP " --log-tcp-options --log-ip-options
-A input_ext -p tcp -m tcp --dport 4662 -j ACCEPT
-A input_ext -p udp -m udp --dport 4665 -j ACCEPT
-A input_ext -p udp -m udp --dport 65325 -j ACCEPT
-A input_ext -m pkttype --pkt-type multicast -j DROP
-A input_ext -m pkttype --pkt-type broadcast -j DROP
-A input_ext -p tcp -m limit --limit 3/min -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p icmp -m limit --limit 3/min -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -p udp -m limit --limit 3/min -m state --state NEW -j LOG --log-prefix "SFW2-INext-DROP-DEFLT " --log-tcp-options --log-ip-options
-A input_ext -j DROP
-A reject_func -p tcp -j REJECT --reject-with tcp-reset
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
-A reject_func -j REJECT --reject-with icmp-proto-unreachable
COMMIT
# Completed on Fri Nov 27 16:41:29 2009

In diesem Zusammenhang steht vielleicht, dass ich meine Firewall heute aus irgendwelchen rätselhaften Gründen down vorfand und deshalb neu startete. Hat jemand einen Tipp für mich?
 
A

Anonymous

Gast
sieht mir verdächtig nach Azureus aus, zb mal hier lesen.
http://board.protecus.de/t20542.htm
ist wohl nicht zu ändern wenn man ständig neue IPs vom Provider zugewiesen bekommt, dann muss man den aufgewirbelten Staub vom Vorgänger immer noch mitschlucken.

robi
 
OP
gropiuskalle

gropiuskalle

Guru
Hier laufen aMule und KTorrent, und dass das darüber generiert wird, habe ich mir fast schon gedacht - jedoch läuft beides bei mir recht regelmäßig und dennoch sind mir diese Meldungen, erst recht nicht in dieser Masse, jemals aufgefallen.

Ich mache mir deswegen jetzt keine Sorgen oder so, aber das ganze macht die logs doch irgendwie recht unübersichtlich.

Edit: ah, jetzt kapiere ich - mein IP-Vorgänger ist daran gewissermaßen schuld. :)
 
framp

framp

Moderator
Teammitglied
Disconnect vom ISP und reconnect löst i.d.R. Dein Problem - dann bist Du die Altlasten Deines IP Vorgängers los ;-)
 
S

spoensche

Moderator
Teammitglied
framp schrieb:
Disconnect vom ISP und reconnect löst i.d.R. Dein Problem - dann bist Du die Altlasten Deines IP Vorgängers los ;-)
Zum Vergrößern anklicken....

Ich würde da nicht unbedingt von Altlasten ausgehen. Ich hab mal eine whois Anfrage abgesetzt. Die Antwort und die Beschreibung der Domain (Autonomous System) lässt bei mir die Alarm glocken leuten, auch wenn die Adresse des Inhabers angegeben ist.

Ich persönlich kenne keine bzw. habe ich noch nichts von einer Ya.com Internet Factory (registriert in Spanien) gehört oder gelesen.

Normalerweise werden bei einem IP wechsels die Verbindungen gekappt und neue Verbindungen bei einer Neuzuweisung nicht weitergeleitet.


PS:

Mag sein das es meinerseits ein wenig Paranoid ist, aber Vorsicht ist besser als Nachsicht, zu mal es bei einigen ISP' s aufgrund einer Lücke möglich war auf den Rechner des nachbarn zuzugreifen. Port 6881 ist zwar für Azureus/Vuze bekannt, aber das werden sich auch andere zu nutzen machen können um Anwender in Sicherheit zu wiegen.
 
OP
gropiuskalle

gropiuskalle

Guru
Also ich habe jetzt gerade drei mal reconnected und die Meldungen verschwinden (stattdessen erhalte ich "dhcpcd[1827]: eth0: timed out" am laufenden Meter, das war vorher auch nicht so...), warum mich allerdings irgendwelche spanischen Kisten anpingen, ist mir jetzt auch nicht klar. Kurz vorher trudelten diese Meldungen im Abstand von wenigen Sekunden hier ein. Kommt mir schon ein wenig spanisch vor (no pun intended), und dass sich 'ne Firewall einfach mal so von selber abknipst, ist ja wohl auch eher ungewöhnlich.

Ich behalte das mal im Auge. Falls jemand Anregungen parat hat - immer her damit.

Oh... jetzt gerade sehe ich, dass die Meldungen wieder erscheinen... Was nun? Hilft da so was wie fail2ban weiter?

Update: An irgendwelchen aMule-Ports scheint es wohl nicht zu liegen - die sind vorerst geschlossen (und auch sonstige p2p-Sachen abgeschaltet), nach einem reboot erscheinen die Meldungen wie gehabt. Falls irgendwelche Konfigurationen, logfiles oder was auch immer interessant sein könnten, sagt es mir. So langsam nervt das ganze.
 
A

Anonymous

Gast
Um da mal die Licht ins Dunkel zu bringen damit die "hoch paranoiden" ;) auch wieder ruig schlafen zu können, verlassen wir mal das Internet und spielen das mal an einem anderem Beispiel durch.
dämliches Beispiel schrieb:
  • *** Mietwohnung: der Mieter hat jede Menge Kataloge von allen möglichen Firmen aboniert weil er eben da viel und regelmäßig einkauft. Es kommt also regelmäßig mit der Post einen Haufen "gewollter Werbung"

    *** Dieser Mieter zieht jetzt aus, und du ziehst dort ein.

    *** Aus welchen Gründen auch immer hat der Vormieter seine ganzen Abos nicht gekündigt, umgemeldet oder beendet, na vielleicht ist er auch plötzlich und unerwartet gestorben.

    *** Die Abos laufen also weiter und landen jetzt als "nicht gewollte Werbung" in deinem Briefkasten.

    *** Du nimmst sie einfach und wirfst sie in die Papiertonne, notierst aber vorher noch den Absender und das Datum

    *** Jetzt brauchst du dich nicht wundern, wenn 14 Tage später und immer regelmäßig so weiter von dieser Firma der nächste Katalog kommt, oder die nächste Aufforderung doch entlich mal was zu kaufen.

    *** So lange du nicht reagierst, in dem du zb die Annahme solcher Post verweigerst so das es der Absender mitbekommt, oder ihm anderswie mit teilst das der Addressat hier nicht mehr existent ist, geht das unentlich so weiter und wird eventuell noch schlimmer

    *** irgendwann sind in den Postwurfsendungen, die du jetzt schon regelmäßig täglich ungelesen in den Papierkontainer wirfst, aber auch Aufforderungen zum direkten reagieren darin. Da du aber nicht darauf reagierst könnte der Absender denken die Postwurfsendung ist verloren gegangen und sie nocheinmal losschicken, oder dich noch 10 Mal daran erinnern, das ein Angebot nur noch wenige Tage gültig ist, und du dich jetzt schnell entschließen müsstest.

    *** Jetzt bringt es aber gar nichts, wenn du mit der Liste in der du täglich fein säuberlich notiert hast was du alles ungelesen weggeschnissen hast, zur Verbraucherzentrale rennst.

    *** Und desshalb die Wohnung wechseln kann ja wohl auch nicht die optimale Lösung sein.
Zum Vergrößern anklicken....
Nun würde ich gerne mal deine Firewalleinstellungen darauf hin untersuchen was da genau passiert ;) ;) ;)
warum kommt das hier bei dir scheinbar nicht zum tragen.
Code: 
-A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
glaub mir ich habs auch versucht, aber so oft arbeite ich an dieser Stelle auch nicht, meine Ahnung reicht hier derzeit nicht aus. :eek:ps:
Vielleicht kann jemand anders was dazu sagen.

robi
 
OP
gropiuskalle

gropiuskalle

Guru
Hm, das klingt allerdings alles sehr einleuchtend und so in der Richtung habe ich die IPTables-Regeln (mit denen ich mich vorher kaum beschäftigt habe) auch verstanden. Sorgen mache ich mir eigentlich nicht, für eine echte Attacke scheinen mir die Versuche dann doch zu unspezifisch (von allen möglichen Servern aus aller Welt) und v.a. zu niedrigfrequent.

Ich glaube, irgendwo in der /etc/sysconfig lässt sich das Logverhalten der IPTables konfigurieren, vielleicht stelle ich das einfach mal so um, dass diese Meldungen mir zumindest nicht laufend die logfiles zumüllen. Die von Dir am Ende gestellte Frage würde ich aber auch noch gerne aufklären... Grundsätzlich ist doch aber bezogen auf ein *tatsächliches* Angriffsszenario ein "drop" gewissermaßen sicherer als ein "reject", oder?

Danke schon mal für Deine Kommentare!
 
S

spoensche

Moderator
Teammitglied
@robi: :) ein wenig paranoid, nicht hoch paranoid. :) Das du dir Sorgen machst, ob ich ruhig schlafe ist ok, aber nicht nötig, da ich den Schlaf der gerechten schlafe. ;)

@gropiuskalle:
Das Logverhalten kannst du in /etc/sysconfig/SuSEfirewall2 oder per Yast->sysconfig editor ändern.
 
A

Anonymous

Gast
gropiuskalle schrieb:
Grundsätzlich ist doch aber bezogen auf ein *tatsächliches* Angriffsszenario ein "drop" gewissermaßen sicherer als ein "reject", oder?
Zum Vergrößern anklicken....
Grundsatzlich und einzeln betrachtet sind beide erstmal gleich. Der Unterschied liegt nur darin, was könnte ein potentieller Angreifer für Schlussfolgerungen daraus ziehen.

DROP -> da ist definitiv eine Firewall am Werk, oder das Paket ist verloren gegangen
REJECT -> da ist ein Port der aber für mich geschlossen ist, es könnte aber auch eine Firewall sein die mir das nur vorgaugelt.

Kommt was zurück, dann hätte er schon mal eine Möglichkeit gefunden zB nach absenden weitere solcher Pakete aus der IP-Sequenznummer irgendwelche weitere Rückschlüsse zu ziehen. ZB ob der Server derzeit im IP-Umfeld viel oder überhaupt nichts macht. Erhält er jetzt bei mehren Tests hintereinander fortlaufenden IP-Sequenznumern von deinem Rechner (weil sonst bei dir gerade nichts anderes im IP Umfeld läuft), dann hat er schonmal einen Rechner gefunden den er auch hervorragend nutzen kann um Atacken auf andere Rechner zu starten. Er attakiert einen anderen Rechner mit gefälschter Absenderadresse (deiner) und fragt dann deinen IP-Sequenzähler ab ob was von angegriffenen Rechner zurück gekommen ist. Der andere Angegriffene wird dann deine IP als Verusacher des Angriffes sehen.
Eventuell kann er jetzt bei dir auch mit weiteren Paketen und verschiedenen Flags, defekten Paketen, was weiß ich noch alles für Tricks, etwas spielen um herauszufinden ist es nun eine dumme Firewall, oder ist es ein hochintelligentes Firewallsystem, ist dort eventuell NAT oder ist es wirklich ein geschlossener Port oder lauscht dort ein Server der nur mich nicht bedienen will.
Ist es ein Server, der nur meine IP nicht bedient, dann kann man eventuell an bestimmten Verhalten noch mehr feststellen, zB welcher und welche Version.

Kommt nichts zurück, weiß er ganz sicher, da ist "etwas" das meine Pakete verwirft, nicht mehr, aber auch nicht weniger. ;) Das eine Firewall nicht nur diesen einen Port bewacht, sollte damit klar sein, also würde er als nächstes auf einen anderen typischen Port weiter testen der in einer Firewall oft offen gelassen werden muss oder der anders bewacht wird . Oder zB irgendwo dort, wo zB in einer Distribution einen kleinen Leichtsinnsfehler in ihrem default Firewallkonzept hat, und dort eventuell ein Portbereich anders bewehrt wurde, dann wüsste er schon mal was da für eine Distribution drauf ist und das die Standardfirewall benutzt wird. Daraus ließen sich dann schon mal die wahrscheinlichen Versionen eventueller Server ableiten, usw usf.

Letztlich würde erst die Summe von Informationen von mehreren oder vielen solcher Tests eventuell ein Bild ergeben. Ein gezieltes Ausspähen könnte sich über Tage, Wochen ja Monate hinziehen, von verschiedenen IPs auf alle möglichen Ports .....
Bei dir ist es keine feste IP, wenn du also keine dyndns hast, müsste er relativ schnell zum einem Ergebnis kommen, "es geht was oder es geht nichts". Er hätte also keine Zeit sich unauffällig über einen langen Zeitraum die Informationen zu besorgen, sonst findet er den selben Rechner nicht mehr unter der selben IP, das würde seine Test Ergebnisse so verfälschen, das sie unbrauchbar sind.

robi
 
J

josef-wien

Ultimate Guru
robi schrieb:
warum kommt das hier bei dir scheinbar nicht zum tragen.
Code: 
 -A reject_func -p udp -j REJECT --reject-with icmp-port-unreachable
Zum Vergrößern anklicken....
Die Routine reject_func wird nirgends verwendet.

Wenn Du die Meldungen los sein willst, erstelle in /etc/sysconfig/scripts/SuSEfirewall2-custom (die Verwendung dieser Datei mußt Du in /etc/sysconfig/SuSEfirewall2 aktivieren) im Abschnitt fw_custom_before_denyall() eine oder mehrere Regeln (sprich: iptables-Befehle) mit dem Sprungziel DROP oder reject_func (je nachdem, was Du bevorzugst). Frage mich aber nicht um Details, ich betreibe nichts Server-Ähnliches.

Mein Vergleich ist kürzer (und er hinkt, wie es Vergleiche nun einmal tun): Wenn ein Einbrecher vor Deiner Tür steht, ist es besser, ihm klarzumachen, daß jemand zu Hause ist. Wenn ein lästiger Mitmensch vor Deiner Tür steht, ist es besser, so zu tun, als ob niemand zu Hause ist. Das Problem ist, daß Du nicht weißt, ob es ein Einbrecher oder ein lästiger Mitmensch ist.
 
OP
gropiuskalle

gropiuskalle

Guru
robi, Deine Ausführungen sind immer wieder höchst aufschlussreich, vielen Dank dafür!

Ich habe mich, wie gesagt, mit diesem Thema bislang eher vom Standpunkt des interessierten Nichtbetroffenen genähert, deshalb spekuliere ich jetzt mal: die Kisten pingen mich an, weil sie mich für den alten Inhaber dieser IP halten, die Pakete werden verworfen, weil mein System die nicht angefordert hat und auch kein Interesse am Austausch mit diesen servern hat, demzufolge werden sie gedropt, dass wiederum wird jeweils in den logs festgehalten.

Ich habe nochmal genauer nachgeschaut: diese Anfragen beginnen am 23. November, dem Tag, als ich diese SuSE installierte - dieses "früher war das nicht so" bezieht sich also auf mein altes System, die entsprechenden logs setzten nicht erst gestern ein, wie ich irrtümlich annahm. Ich vermute deshalb, dass schlicht das logverhalten unter meiner alten 11.0 anders war, die entsprechenden Anfragen aber schon vorher regelmäßig eintrudelten. Die Anzahl der die jeweiligen IPs betreffenden Anfragen ist über den Zeitraum seit der Installation fast immer im einstelligen Bereich:

Code: 
hoppers:~ # cat /var/log/firewall | grep 124.121.13.45 | wc
      1      21     200                                              
hoppers:~ # cat /var/log/firewall | grep 88.100.121.242 | wc
      7     189    1763                                               
hoppers:~ # cat /var/log/firewall | grep 95.225.56.78 | wc
      1      27     249
hoppers:~ # cat /var/log/firewall | grep 87.210.107.250 | wc
     14     378    3509

Sind jetzt nur Stichproben, aber das klingt eigentlich nicht so, als ob die besonders hartnäckig wären, sondern eben gemäß des Rücklaufs ihre Anfragen irgendwann einstellen - egal, ob die nun gedropt oder rejected werden, und allgemein (so interpretiere ich jedenfalls Deine Ausführungen) eignen sich wechselnde IPs nicht, um durch Langzeitscans irgendwann eine Lücke auszuspähen.

Meine IPTables-Kinfiguration ist auf default, müssten also nicht auch andere SuSE-Nutzer ganz ähnliche Beobachtungen machen? Bevor ich die von josef-wien vorgeschlagenen settings umsetze, würde ich das noch gerne beleuchten (übrigens, josef-wien: es geht hier tatsächlich nicht um etwas "server-ähnliches", sondern um einen stinknormalen home-Desktop :) ).
 
J

josef-wien

Ultimate Guru
gropiuskalle schrieb:
-A input_ext -p tcp -m tcp --dport 4662 -j ACCEPT
-A input_ext -p udp -m udp --dport 4665 -j ACCEPT
-A input_ext -p udp -m udp --dport 65325 -j ACCEPT
Zum Vergrößern anklicken....
Du läßt Zugriffe von außen zu, daher habe ich die Formulierung Server-Ähnliches verwendet.
 
A

Anonymous

Gast
gropiuskalle schrieb:
eignen sich wechselnde IPs nicht, um durch Langzeitscans irgendwann eine Lücke auszuspähen.
Zum Vergrößern anklicken....
Eignen :???: naja ehr weniger, man müsste viel mehr Arbeit hineinstecken und immer mehrere Rechner anscannen. Das würde länger dauern und die Wahrscheinlichkeit aufzufallen bevor man den Schlüssel zum einbrechen hat, ist damit viel größer.

Du bekommst ja nicht irgendwelche IP Adressen zugewiesen, sondern immer wieder welche aus dem selben Subnetz des selben Providers, meist von ein und dem selben Server zugewiesen. Damit besteht irgendwie eine virtuelle Nachbarschaft mit Kunden des selben Providers in deiner unmittelbaren Umgebung. Wenn dort in dieser Nachbarschaft mehrere sind, die das gleiche "Hobby" haben, wirst du öfter mal so eine Adresse beerben. Entweder du ignorierst das und sorgst dafür das die Logs nicht unermesslich groß werden, oder wenn es einzelne Ports sind die dich überhaupt nicht intressieren, dann kannst du die auch explizied vom Loging ausschließen oder einzeln anders behandeln. Ein Sicherheitsloch oder eine Angriffsfläche ist jedenfalls so noch lange nicht, ehr lästig und wenn man sowas einmal bemerkt hat, fällt es einem eben immer wieder mal auf.

robi
 
OP
gropiuskalle

gropiuskalle

Guru
Also ich würde mal sagen, ich lasse allzu spekulative Mutmaßungen mal ruhen und schalte die logs etwas leiser. Sollte mein System doch als Drohne für Attacken oder als Warez-Verteiler fungieren, gebe ich Bescheid, sobald meine Anwältin mir ein UMTS-fähiges Handy in die U-Haft geschmuggelt hat.

Ich danke allen Beteiligten für die lehrreichen Ausführungen und setze den thread auf [gelöst].
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben