Hi * Daniel Schmatz schrieb:

...

Von: Thomas Widmann [mailto:thomas.widmann@icn.siemens.de]

* Daniel Schmatz schrieb:

...

Ich habe auf der IP 195.202.171.67 einen Suse 7.3 Server mit folgenden Services laufen:

[schnipp]

...

09/26/2002 15:25:05.53 Port Scan attack !!! 195.202.171.67:34997 195.202.171.72:113 TCP

[schnipp]

...

Was könnte die Ursache dafür sein?

Deine sendmail config !

Welcher Eintrag? Machts sinn ihn zu verändern?

AFAIK: define(`confTO_IDENT', `0')dnl und dann /etc/sendmail.cf neu erstellen (m4). ciao Thomas

Hallo, On Thu, 26 Sep 2002, Adalbert Michelic wrote:

- Blockiere ausgehende Anfragen von Dir an dport 113 per reject (Nicht per deny, sonst kannst Du jedesmal einen 30 sec Timeout abwarten):

iptables -A OUTPUT -p tcp --dport ident -j REJECT

Waren das nicht eingehende Connections? Naja, egal, ich hab hier: iptables -A INPUT -i ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset iptables -A OUTPUT -o ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset Dazu aus man iptables: ==== Finally, the option tcp-reset can be used on rules which only match the TCP protocol: this causes a TCP RST packet to be sent back. This is mainly useful for blocking ident probes which frequently occur when sending mail to broken mail hosts (which won't accept your mail otherwise). ==== Aeh, das Interface sollte man per Variable setzen ;) -dnh -- Ich denke mir mal das es so etwas wie Intelligenz gibt. Und diese zu nutzen ist doch keine Schande oder? [WoKo in dag°]

Von: Peter Blancke [mailto:blancke@gmx.de] On Fri, Sep 27, 2002 at 00:49:12 +0200, David Haller wrote:

...

On Thu, 26 Sep 2002, Adalbert Michelic wrote:

...

- Blockiere ausgehende Anfragen von Dir an dport 113 per reject (Nicht per deny, sonst kannst Du jedesmal einen 30 sec Timeout abwarten):

iptables -A OUTPUT -p tcp --dport ident -j REJECT

Waren das nicht eingehende Connections? Naja, egal, ich hab hier:

iptables -A INPUT -i ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset iptables -A OUTPUT -o ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset

Nein. Die eingehenden Port-113-Boesewichter ;-) muessen auf dem Kundenserver, der sich da beschwert, abgewiesen werden. Aber auf den hat er vielleicht keinen Zugriff.

Er soll aber grundsaetzlich verhindern, dass ueberhaupt Ident-Abfragen seines Servers nach draussen gehen. Also ist es schon korrekt, dass er diese Abfragen gleich im eigenen Ausgang verhindert.

Ich wuerde allerdings die Interfacebezeichnung (ppp0 oder ippp0 oder was auch immer) mit dazunehmen, im eigenen Netz ist das naemlich durchaus sinnvoll, die Ident-Dinger drinzulassen, also sollen sie nur nach "draussen" geblockt werden.

Frage: Wenn es diese Abfragen gibt, haben sie sicher einen Sinn - welchen? Sollte man sinnvolle Fragen nicht lassen? Daniel

Hallo, On Fri, 27 Sep 2002, Peter Blancke wrote:

On Fri, Sep 27, 2002 at 00:49:12 +0200, David Haller wrote:

...

On Thu, 26 Sep 2002, Adalbert Michelic wrote:

...

- Blockiere ausgehende Anfragen von Dir an dport 113 per reject (Nicht per deny, sonst kannst Du jedesmal einen 30 sec Timeout abwarten):

iptables -A OUTPUT -p tcp --dport ident -j REJECT

Waren das nicht eingehende Connections? Naja, egal, ich hab hier:

iptables -A INPUT -i ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset iptables -A OUTPUT -o ppp0 -p tcp --dport 113 \ -j REJECT --reject-with tcp-reset

Nein. Die eingehenden Port-113-Boesewichter ;-) muessen auf dem Kundenserver, der sich da beschwert, abgewiesen werden. Aber auf den hat er vielleicht keinen Zugriff.

Er soll aber grundsaetzlich verhindern, dass ueberhaupt Ident-Abfragen seines Servers nach draussen gehen. Also ist es schon korrekt, dass er diese Abfragen gleich im eigenen Ausgang verhindert.

*huh* Verhindern obige Rules nicht eben das? "Alles was in Richtung TCP/port 113 auf ppp0 reinkommt: REJECT (with reset)" "Alles was in Richtung TCP/port 113 auf ppp0 rausgeht: REJECT (with reset)"

Ich wuerde allerdings die Interfacebezeichnung (ppp0 oder ippp0 oder was auch immer) mit dazunehmen, im eigenen Netz ist das naemlich durchaus sinnvoll, die Ident-Dinger drinzulassen, also sollen sie nur nach "draussen" geblockt werden.

Jepp. s.o. Is drin :)

...

Aeh, das Interface sollte man per Variable setzen ;)

Klar. Und noch viel mehr Dinger. Am Anfang solcher Skripte stehen ein paar Zeilen mit Variablen, darunter kommt eine dicke Linie und darunter hat niemand nie und nimmer nie nicht mehr etwas verloren.

Jep. Nur sind die Variablennamen nicht immer gleich "schluessig" ;) Daher hab ich sie expandiert... Ich hab zwar konkret nur ein $IPT statt "/usr/local/sbin/iptables", aber bei mir laeuft jedes Byte, das die FW auch nur im entferntesten interessieren koennte via ppp0, nur deshalb ist das bei mir noch nicht in einer Variablen gelandet... Ansonsten ist mein script (so hoffe ich) weitgehendst portabel (musste aber "schon laengst" mal ueberarbeitet werden, scripttechnisch, nicht wg. der Regeln (da kenne ich sowieso nur "meine" wichtigen ;), ein Ansatz habe ich schon seit laengerem "brachliegen"... Das "Framework" (also der (geplante) Mechanismus, wie ich das ganze "verteile"/"konfiguriere"), das mag ich nach wie vor... Leider ist das "aktuelle", "mal eben" zusammengehackte (init-)script zu gut, so dass ich bisher nicht ueber einen Ansatz hinausgekommen bin... Hm... Sollen wir mal ne "OpenFirewall"[1] AG/SIG o.ae. gruenden? -dnh [1] *snigger* -- 133: Linux Das Windows98 unter den Unixen. (Heiko Schlichting)