host.deny und tcpd

[red.iceman]

Hallo zusammen,

ich habe folgendes problem:
vor etwa 2 wochen wurde mein rechner aus dem internen netz gescannt (und zwar von der 192.168.1.2 und der 192.168.1.7). der scan wurde von portsentry erkannt und beide ip's in die host.deny eingetragen.
erhielt ich jedoch erneut, die meldung, dass beide rechner mich erneut gescannt haben und portsentry sie nun noch mal in die host.deny eingetragen hat, so dass diese jetzt wie folgt aussieht:

ALL: ALL
ALL: 192.168.1.2
ALL: 192.168.1.7
ALL: 192.168.1.2
ALL: 192.168.1.7

warum wurde die anfrage von beiden rechnern nicht vorher vom wrapper (tcpd) geblockt???


ri

[red.iceman]

weiss keiner was?? last euch von portsentry nicht verwirren... ;-)
letztlich laeuft es darauf hinaus, das in der host.deny ip's eingetragen sind und diese trotzdem noch einen portsscan versuchen koennen. warum? muesste nicht eigentlich der wrapper (tcpd) sagen: "ach, dich kenn ich doch - du musst draussen bleiben"?
in welcher reihenfolge arbeiten eigentlich die tools? bei mir laeuft ne firewall, portsentry und der tcpd. wenn jetzt eine anfrage kommt, reagiert dann erst der tcpd oder erst die firewall? kann man die reihenfolge eigentlich veraendern? mir waere:
tcpd, portsentry, firewall
am liebsten.

ri

[hmikux]

hi ,

wie kann dein rechner von den ip-adressen 192.168.x.x gescannt werden? dies sind doch priv. adressen, und werden doch ganrnicht im internet geroutet. oder irre ich mich da...????

[red.iceman]

mein rechner befindet sich aber in einem kleinen lokalen netzwerk. "scan" ist vielleicht nicht das richtige wort - die beiden rechner haben versucht, auf meinen port 137 und 138 zuzugreifen. an fuer sich kein problem, da dort eh kein dienst laeuft.
doch wundert mich einfach die tatsache, dass sie es ueberhaupt versuchen konnten, obwohl sie in der host.deny stehen.

ri

[Newbie2001]

villeicht stehen sie ja auch in der hosts.allow drin, dann bringts nich viel wenn sie auch in deny stehen.

[red.iceman]

kurz und knapp: nein.

ri

[Newbie2001]

naja versuchen könnne sie es immer, weil sie nach anderen win-computer in ihrer nähe suchen und da deren file-sharing programm auf den ports 137 und 138 zuhause ist, versuchen sie es halt einfach mal (in der Regel läuft bei Linux auf 137 und 138 samba). sind sie denn durchgekommen ?

[red.iceman]

nun ja, ob sie es koennen, sei mal dahin gestellt; jedenfalls tun sie es.
wie bereits erwaehnt, laeuft bei mir auf diesen ports nichts, so dass da auch niemand "durchkommen" kann.
ausserdem:
die firewall wuerde sie nicht durchlassen, portsentry _hat_ sie nicht durchgelassen und tcpd _sollte_ sie nicht durchlassen.
und letzteres ist genau das problem.

ri

[Newbie2001]

meines wissen kann man mit dem tcpd doch nur den zugriff auf services sperren und nicht auf ports, d.h. der tcpd kann keine ports sperren, hinter denen kein service läuft. für die port ebene ist eigentlich ne firewall zuständig.