PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Bei angriff blockade der ip?



Seiten : [1] 2

WarEagle
29.12.04, 08:18
Hi,

ich bin nach der Backdoor nun ein wenig gesund paranoid geworden und schaue viel mehr in die Logs.
Seit einigen Tagen scheinen verschiedene Leute auf meinen Server zu wollen, ich habe ständig einträge wie:

auth.log:Dec 29 04:33:40 p15091678 sshd[14286]: Failed password for root from 211.185.xxx.xxx port 52953 ssh2

da drin.
Und zwar inzwischen fast hundert am Tag.

"Eigentlich" kann nix passieren, da ssh bei mir keinen zugriff für root und keinen nur mit Kennwort erlaubt, ich möchte aber doch auf nummer sicher gehen und wenn sowas mehrfahc vorkommt, z.b. 3mal von derselben IP in der Stunde, dass diese IP dann vorrübergehend (z.b. 2h) blockiert wird (z.b. in /etc/hosts.deny aufgenommen).

Leider fehlt mir ein wenig der Ansatz, wo ich sowas einbauen könnte.
Aktuell habe ich logcheck am laufen, aber ich wüßte nicht, wo ich ansetzen müßte um sowas wie ich wollte einzubauen.
Ist das denn überhaupt möglich?

Gruß

Torsten

phoenix22
29.12.04, 09:45
Portsentry sollte das können:
http://linux.cudeso.be/linuxdoc/portsentry.php

WarEagle
29.12.04, 10:06
Portsentry sollte das können:
http://linux.cudeso.be/linuxdoc/portsentry.php
So wie ich das lese kann der "nur" Ports aufmachen und schauen wer denn da scannt.
Aber ich will ja quasi ein beliebiges Event abfragen.

phoenix22
29.12.04, 10:15
Aber ich will ja quasi ein beliebiges Event abfragen.

Sorry, aber die Aussage ist einfach unpräzise, ich kann so mit dem Satz nichts anfangen.

Die Zugriffe auf deinen Server erfolgen nunmal über Ports. Und soweit ich weiß, kann Portsentry bei zu vielen Anfragen von einer IP auf einem bestimmten oder verschiedenen Ports die IP blacklisten. Damit solltest du genau das erreichen, was du im ersten Post angesprochen hast.

WarEagle
29.12.04, 10:26
Nein Portsentry macht eigene Ports auf, also z.b. 10, 20, 30 und schaut dann ob auf diese Ports zugegriffen wird.
Da ich aber z.B. 22 bereits durch ssh belegt habe würde er Zugriffe darauf nicht mitbekommen, er kann also keine Angriffe, sondern lediglich Portscans erkennen.
Insofern hilft es mir nicht weiter.

Ich möchte einzelne Events, einzelne Geschehnisse die in Logs geschrieben werden auswerten.

Russel-Athletic
29.12.04, 11:01
Sowas kann man doch mit nem Script, was in den Logdateien (letzte Zeile) nachguckt, ob sie sich verändert hat und ob die IP 3 mal gleich ist und dann nen entsprechenden Eintrag macht.

WarEagle
29.12.04, 11:14
Sowas kann man doch mit nem Script, was in den Logdateien (letzte Zeile) nachguckt, ob sie sich verändert hat und ob die IP 3 mal gleich ist und dann nen entsprechenden Eintrag macht.
Ja, und dann noch ein Script, dass die hosts.deny wieder entsperrt, ein Script noch was dann auch dafür sorgt, dass alle scripte laufen etc.
Gehen tuts, keine Frage, habe auch schon drüber nachgedacht, aber wenns was fertiges gibt, ist mir das lieber, weil das dann schon erprobt ist.

cane
29.12.04, 15:35
Könnte sein das snort_inline das kann...

mfg
cane

`kk
29.12.04, 16:16
Verbiete doch erstmal Logins als Root.

PermitRootLogin No

cane
29.12.04, 17:44
"Eigentlich" kann nix passieren, da ssh bei mir keinen zugriff für root und keinen nur mit Kennwort erlaubt

Hat er schon ;)

Mich interessiert eine mögliche Lösung aber auch - ich bin selbst auf der Suche...

mfg
cane

Jinto
29.12.04, 18:04
IIRC kann snort sowas, aber auch mit logwatch o. ä. sollte sowas realisierbar sein.

Automatisierstes sperren von IPs halte ich für gefährlich und würde es nicht einsetzen. Eher eine Info (mail, oder wie auch immer) an den Admin, danach manuelles entscheiden.

cane
29.12.04, 18:49
Automatisierstes sperren von IPs halte ich für gefährlich und würde es nicht einsetzen. Eher eine Info (mail, oder wie auch immer) an den Admin, danach manuelles entscheiden.

Hallo Jinto,

der Admin bin ja ich ;) Und bei den hunderten von Angriffsversuchen jedesmal eine Email zu lesen halte ich für nicht besonders sinnvoll...

Die Chance das ich mich selber aussperre weil der Vorbesitzer einer DialIn-IP versucht hat sich einzuloggen ist doch sehr gering.

Am wichtigsten ist es meiner Meinung nach den sshd auf einem anderen Port lauschen zu lassen - das spart eine Menge Logs...

mfg
cane

WarEagle
29.12.04, 19:13
Automatisierstes sperren von IPs halte ich für gefährlich und würde es nicht einsetzen. Eher eine Info (mail, oder wie auch immer) an den Admin, danach manuelles entscheiden.
Ich weiß das es gefährlich ist, daher ja auch die Frage obs was fertiges gibt :)
ich denke aber ein tmp-bann von 30-120min wäre da noch zu verkraften.

Jinto
29.12.04, 23:29
der Admin bin ja ich ;) Und bei den hunderten von Angriffsversuchen jedesmal eine Email zu lesen halte ich für nicht besonders sinnvoll...na nicht bei jedem einzelnen versuch, aber nach x versuchen (setze für x einen beliebigen Schwellenwert, der dir gefällt).
Weiss nicht wie es dir geht, aber bei mir kam es schon mehr als einmal vor, dass ich mehr als einen Versuch zum einloggen gebraucht habe. Manchmal ist sogar dreimal zu wenig....

Nein, ich will keine 2 Stunden warten, bis ich mich wieder einloggen kann. Soviel vertrauen hab ich gegenüber meinem sshd schon noch, dass er nicht jeden reinlässt.



Die Chance das ich mich selber aussperre weil der Vorbesitzer einer DialIn-IP versucht hat sich einzuloggen ist doch sehr gering.Darum geht es nur zweitrangig, automatisches Sperren kann dich u. U. blitzschnell aus dem Netzkatapultieren (besonders bei einer Fehlkonfiguration)


Am wichtigsten ist es meiner Meinung nach den sshd auf einem anderen Port lauschen zu lassen - das spart eine Menge Logs...Security bei Obscurity ist zwecklos.

Frage mich manchmal, ob es kein automatisches Tool gibt, welches prüft welcher Dienst tatsächlich läuft (sollte nicht gerade schwer sein, soetwas zu implementieren). BTW kennt jemand vielleicht grad so ein Tool bzw. weiss ob es soetwas gibt?

cane
30.12.04, 00:24
Weiss nicht wie es dir geht, aber bei mir kam es schon mehr als einmal vor, dass ich mehr als einen Versuch zum einloggen gebraucht habe. Manchmal ist sogar dreimal zu wenig....
[QUOTE]
Ja, vor allem vor der zweiten Tasse ;)
[QUOTE=Jinto]
Darum geht es nur zweitrangig, automatisches Sperren kann dich u. U. blitzschnell aus dem Netzkatapultieren (besonders bei einer Fehlkonfiguration)
Security bei Obscurity ist zwecklos.

Zwecklos ja aber verkleinert die Logs ;)



Frage mich manchmal, ob es kein automatisches Tool gibt, welches prüft welcher Dienst tatsächlich läuft (sollte nicht gerade schwer sein, soetwas zu implementieren). BTW kennt jemand vielleicht grad so ein Tool bzw. weiss ob es soetwas gibt?

Wie meinst Du das? Vielleicht erkennt Nessus Deamons unabhängig vom Port...

mfg
cane

Harkan
30.12.04, 02:34
die Frage obs was fertiges gibt

KLICK (http://www.cipherdyne.org/)

Sehr gut konfigurierbares IDS, welches auch die SNORT Regeln implementiert hat.



# Detection for tcp syn, fin, null, and xmas scans as well as udp scans.
# Detection of many signature rules from the snort intrusion detection system.
# Forensics mode iptables logfile analysis (useful as a forensics tool for extracting scan information from old iptables logfiles).
# Passive operating system fingerprinting via tcp syn packets. Two different fingerprinting strategies are supported; a re-implementation of p0f that strictly uses iptables log messages (requires the --log-tcp-options command line switch), and a TOS-based strategy.
# Email alerts that contain tcp/udp/icmp scan characteristics, reverse dns and whois information, snort rule matches, remote OS guess information, and more.
# Content-based alerts for buffer overflow attacks, suspicious application commands, and other suspect traffic through the use of the iptables string match extension and fwsnort.
# Icmp type and code header field validation.
# Configurable scan thresholds and danger level assignments.
# Iptables ruleset parsing to verify "default drop" policy stance.
# IP/network danger level auto-assignment (can be used to ignore or automatically escalate danger levels for certain networks).
# DShield alerts.
# Auto-blocking of scanning IP addresses via iptables and/or tcpwrappers based on scan danger level. (This is NOT enabled by default.)
# Status mode that displays a summary of current scan information with associated packet counts, iptables chains, and danger levels.

Roger Wilco
30.12.04, 12:30
KLICK (http://www.cipherdyne.org/)
KLACK (http://linux.newald.de/new_design/login_check.html)

Quelle: http://www.rootforum.de/forum/viewtopic.php?t=31784

rasi
31.12.04, 12:04
hallo

also s'kann sein dass ich jetzt totalen muell schreibe ABER:
kann man net mit iptables und den module --limit sowas machen

gruessla
rasi
:eek: *duckundweg*

Jinto
31.12.04, 14:30
Wie meinst Du das? Vielleicht erkennt Nessus Deamons unabhängig vom Port...AFAIK nicht.

Ich stelle mir so ein Script extrem simpel vor:
1. Scanne alle(!) Ports
2. Connecte zu jedem offenenen Port
2.a Wird login abgefragt -> mögl. Kandidaten telnet,ftp, ssh (ja ssh erfordert verschl. verbindung)
2b best. Kommando -> mögl. Kandidaten smtp,http
2c ...

phoenix22
31.12.04, 14:54
Nmap kann das auf jeden Fall

Jinto
31.12.04, 16:05
Stimmt, ich habs mir grad angesehen. Man sollte hin und wieder mal schauen welches Features ein Programm noch so mitbringt (und die deutsche manpage kennt das Kommando nichtmal).

Danke für die Info

Jinto
31.12.04, 16:21
Da ich jetzt grade im Bezug zu $subject einiges gelesen hab, hier noch eine Webseite zu einem entsprechenden Skript: http://linux.newald.de/new_design/login_check.html

PS: Empfehlung für die, die dieses Skript meinen einsetzen zu müssen: Füllt die Variable IPs die nicht gesperrt werden sollen mit sinnvollen Werten!

WarEagle
31.12.04, 16:21
hallo

also s'kann sein dass ich jetzt totalen muell schreibe ABER:
kann man net mit iptables und den module --limit sowas machen

gruessla
rasi
:eek: *duckundweg*
Kann durchaus sein, will ich nicht ausschließen... aaaaaber, das ist ein woody-rechner also noch kernel 2.4 und da ists mit iptables noch nicht so schön.


Das Programm oben ist ja genau für den Zweck geschrieben worden, will ich mir am Montag gleich mal anschauen, danke für den Tipp.

pablovschby
01.01.05, 16:34
Darum geht es nur zweitrangig, automatisches Sperren kann dich u. U. blitzschnell aus dem Netzkatapultieren (besonders bei einer Fehlkonfiguration)Kannst du uns das bitte erläutern?

Wieso ohne Fehlkonfiguration?
Wieso mit?
:confused:

IT-Low
01.01.05, 17:33
Kannst du uns das bitte erläutern?

Er meint wahrscheinlich, dass der Angreifer einfach z. B. mit den IP-Adressen (Spoofing) deines DNS-Servers angreift und dich damit "abklemmt". Weitere Möglichkeiten sind beliebig.

pat12
11.05.05, 15:14
Hier meine Lösung für die SSH atacken.

# SSH Spezialrule
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-pre
fix "SSH_brute_force "
iptables -A INPUT -i eth0 -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Somit ist nach ein paar Versuchen endefeuer.
Zudem würde ich dir empfehlen das du den SSH Port nich auf 22 laufen lässt.

steve-e
20.06.05, 15:47
@pat12

Hab das recent-modul geladen, aber es scheint keine Wirkung zu haben. Ich kann mich so oft einloggen wie ich möcht, es passiert nichts.
Nicht einmal in einem Log taucht etwas auf.

Könntest du mir desweiteren kurz erklären was die Option --name bedeutet? In den Manpages konnte ich es irgendwie nicht finden.

DerAufgeklUser
14.06.08, 12:19
@pat12: Das haut so nicht hin, da du grundsätzlich jeden Verbindungsaufbau durchlässt und die dritte Regel auch bereits aufgebaute Verbindungen betrifft. Wenn ich mich nicht irre, sollte das bewirken, dass du, wenn du eingeloggt bist nach vier Paketen eine Minute warten musst, bis du dann, dank --rttl, weiterarbeiten kannst.

So würde das jedenfalls mehr Sinn machen:

iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -m recent --name SSH --rcheck --seconds 60 --hitcount 4 -j LOG --log-prefix "SSH_brute_force"
iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -m recent --name SSH --rcheck --seconds 60 --hitcount 4 -j DROP
iptables -A INPUT -p tcp --dport 22 --syn -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT


So begrenzt du nur die Anzahl neuer Verbindungen, die Anzahl der eigentlichen Loginversuche pro Verbindungsaufbau müssen von ssh geblockt werden. Per default bricht ssh nach drei Versuchen die Verbindung ab.
Was ich nicht weiß, ist ob man die zum Beispiel auf 1 runtersetzen kann. Meines Wissens nach nicht. Bitte korrigiert mich!
Wen dem wirklich so sein sollte, kannst du --hitcount auf 1 setzen, dann hast du pro Minute drei Versuche.

@steve-e: --name gehört zu recent und bewirkt, dass die Regel eine eigene Tabelle für die IPs bekommt:

man iptables:
--name name
Specify the list to use for the commands. If no name is given then ’DEFAULT’ will be used.


EDIT: Öhm... ganz schön alt der Thread. Naja, macht nichts, vielleicht hilfts trotzdem jemandem.

rudi_m
15.06.08, 02:47
In einem der letzten Linux Magazine (oder Linux Magazin Sepzial?) war genau beschrieben wie man den sshd patchen kann um fehlgeschlagene logins zu bestrafen.
Keine Ahnung wie man jetzt am besten danach sucht - falls ich die Ausgabe noch finde poste ich es spaeter.

DerAufgeklUser
15.06.08, 14:47
"MaxAuthTries <Anzahl>" in der sshd_config dient genau diesem Zweck.
Ich war mir da erst nicht so sicher, weil ich, als ich die zum Testen mal auf 1 setzte immernoch zwei Versuche hatte. Keine Ahnung warum, aber jetzt funktioniert es wie erwartet.

Mit fail2ban lässt sich außerdem eine beliebige Anzahl fehlgeschlagener Loginversuche mit einer beliebig langen Sperrzeit für die IP bestrafen.