PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : keine antwort beim Portscann



Kernel-Error
17.12.02, 17:57
Hi!

Ich möchte, das meine Maschine bei einem Portscann nicht antwortet.

Stelle mir das so vor:

Rechner (mit scanner und der ip 192.168.0.1) frage port 10 an, port 20, port 30 und bekommt dann keine Antwort mehr.

Ich brauche also etwas, was erkennt wie oft eine ip in einem bestimmten Zeitraum anfragen an meine Ports stellt und die dann einfach ignoriert, richtig?

Wie mache ich das am besten?


MFG




:ugly: Kernel Error :ugly:

geronet
17.12.02, 18:05
Das geht entweder mit fwlogwatch oder snort.

Grüsse, Stefan

Kernel-Error
17.12.02, 18:11
Aha...

Danke, und wie? Mit snort wäre interessant.

Des andere kenn ich nicht...

MFG


:ugly: Kernel Error :ugly:

HangLoose
17.12.02, 18:34
hi

für snort sind mir dafür 2 möglichkeiten bekannt.

Using "Flexible Response" to make Snort an "Active" IDS
The overview mentioned that Snort was a passive IDS by default. However, the developers of Snort have added a compile time option to make Snort react to alerts it fines. This option is called "Flexible Response". Note: this option is still considered developmental and in the testing stages. Use with caution. If you already have snort installed and running without this option, you will have to recompile Snort to add it. To enable this feature, when you run the configure script ( UNIX only) use "./configure --enable-flexresp". You will also have to compile and install the Libnet package which can be downloaded from: http://www.packetfactory.net before compiling and installing snort.


The "Flexible Response" option can be used to disconnect or drop the route of the source address of the offender. By adding rules to the current rules file, there are several nifty ways to disconnect from the offender. The simplest is sending a reset packet to just kill the connection. ICMP unreachable packets can also be sent to the offender along with the reset packet to make it look like our host is not online. We can even send packets to kill all current connections that Snort has flagged.
Even though this option is still in the testing stages, it is easy to see it's potential value. Firstly, we don't have to rely on 3rd party tools to cause Snort to react to alerts it finds. Secondly, the options are more flexible then with the Guardian tool. However there is some drawbacks to using this option and the Guardian tool. An attacker could be spoofing the IP address to make it look as if the packets are coming from internal hosts or trusted hosts. This could disable the Snort box's connection to important hosts like it's DNS server for instance. If you use this option, make sure you tell Snort in the configuration file or in your ipchains rule set to ignore or accept packets coming from these hosts. Also be sure to have a good way of alerting yourself of snort "alerts" by email or setting up a paging system.

außerdem gibt es bei snort noch die möglichkeit des blockens mittels react. dafür mußt du eine rule erstellen, die einen portscan erkennt, bspw.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN synscan portscan"; id: 39426; flags: SF;reference:arachnids,441; classtype:attempted-recon; sid:630; rev:1; react: block;)

siehe auch => http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.3.24


übrigens kannst du die *antworten* deiner firewall auch von REJECT auf DROP setzen. dein paketfilter antwortet dann nicht, sondern läßt die anfragen einfach fallen. über sinn und unsinn von DROP streiten sich übrigens die gelehrten ;)


Gruß HL

Jinto
17.12.02, 19:36
Hangloose, dass ich das so nicht stehen lassen kann war dir wohl klar :)

Das es schlecht ist, alles zu droppen steht ausser Frage. Was passiert wenn alles verworfen wird, kann man alleine schon anhand der immer wieder kommenden Fragen zu GMX, etc. sehen. Wenn ich die Administratoren als übereifrig bezeichne, schmeichle ich ihnen noch ;)

Das automatische ändern von Regeln hat auch schon mehr als einmal dazugeführt, dass lokal kein Internet vorhanden und sogar (je nach Aufbau) das Intranet nicht mehr verfügbar war. :D

@kernel-error
was willst du damit bezwecken?

HangLoose
17.12.02, 19:46
Hi Jinto


Hangloose, dass ich das so nicht stehen lassen kann war dir wohl klar :)

da hätte ich meinen A.... drauf verwettet :D

ich persönlich nutze auch REJECT, was auch ein verdienst deiner überzeugungsarbeit ist ;)


Das automatische ändern von Regeln hat auch schon mehr als einmal dazugeführt, dass lokal kein Internet vorhanden und sogar (je nach Aufbau) das Intranet nicht mehr verfügbar war

zumindest das blocken mittels react ändert keine regeln des paketfilters. dafür hätte snort bei mir gar nicht die nötigen rechte. es gibt aber ein tool namens guardian für snort, das genau sowas macht => es generiert dynamisch iptables regeln.


Gruß HL