eigenen Internetserver gg. Angriffe schützen

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

eigenen Internetserver gg. Angriffe schützen

Beitrag von netchamber » 27.02.2005 17:04:25

Hallo!

Ich habe seit kurzem einen meiner Rechner mit dyndns online. Im Moment läuft immer nur kurzzeitig im Testbetrieb. Ich gucke mir in regelmäßigen Abständen die Logdateien an, um Angriffe frühzeitig zu entdecken.
Heute habe ich gesehen, dass sich der nicht vorhandene Benutzer "test" vom Rechner 211.115.88.55 per ssh versucht hat auf meinem Rechner anzumelden. Ein nmap Portscan hat folgendes ergeben

Code: Alles auswählen

PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
53/tcp   open     domain
80/tcp   open     http
111/tcp  open     rpcbind
515/tcp  filtered printer
3306/tcp open     mysql
4444/tcp filtered krb524
6000/tcp open     X11
Außerdem habe ich noch whois verwendet, um etwas über den "Angreifer" zu erfahren
query: 211.115.88.55

# ENGLISH

KRNIC is not a ISP but a National Internet Registry similar to APNIC.
The followings are information of the organization that is using the IPv4 address.

IPv4 Address : 211.115.88.0-211.115.88.255
Network Name : KIDC-INFRA
Connect ISP Name : KIDC
Connect Date : 20040325
Registration Date : 20040715

[ Organization Information ]
Organization ID : ORG137200
Org Name : KOREAINTERNETDATACENTERInc.
State : Seoul
Address : KIDC 261-1, Nonhyun-dong, Kangnam-ku
Zip Code : 135-010

[ Admin Contact Information]
Name : IP Administrator
Org Name : KOREAINTERNETDATACENTERInc.
State : Seoul
Address : KIDC 261-1, Nonhyun-dong, Kangnam-ku
Zip Code : 135-010
Phone : +82-2-2086-2924
Fax : +82-2-2086-2929
E-Mail : support@kidc.net

[ Technical Contact Information ]
Name : IP manager
Org Name : KOREAINTERNETDATACENTERInc.
State : Seoul
Address : KIDC 261-1, Nonhyun-dong, Kangnam-ku
Zip Code : 135-010
Phone : +82-2-2086-2924
Fax : +82-2-2086-2929
E-Mail : ip@kidc.net

--------------------------------------------------------------------------------

If the above contacts are not reachable, please see the following ISP contacts
for further information or network abuse.

[ ISP IPv4 Admin Contact Information ]
Name : IP Administrator
Phone : +82-2-2086-2924
Fax : +82-2-2086-2929
E-Mail : support@kidc.net

[ ISP IPv4 Tech Contact Information ]
Name : IP manager
Phone : +82-2-2086-2924
Fax : +82-2-2086-2929
E-Mail : ip@kidc.net

[ ISP Network Abuse Contact Information ]
Name : Network Abuse
Phone : +82-2-2086-2918
Fax : +82-2-2086-2929
E-Mail : security@kidc.net
Was kann ich tun, um
(1) so viel Informationen wie möglich über einen potentiellen Angreifer zu erfahren und
(2) mich gegen ähnliche Test ssh Logins zur Wehr zu setzen?
Zuletzt geändert von netchamber am 27.02.2005 21:39:47, insgesamt 1-mal geändert.
danke im voraus!

Benutzeravatar
monotek
Beiträge: 227
Registriert: 20.07.2004 15:25:11
Wohnort: dresden

Beitrag von monotek » 27.02.2005 17:08:46

da brauchste dir keine sorgen machen.
sperr doch einfach den ssh port, wenn von außen eh keiner zugriff haben soll...

Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

Beitrag von netchamber » 27.02.2005 21:39:08

Hallo!

Ich habe mit iptables eingestellt, dass man von außen nur Zugriff auf ssh und den apache Webserver hat

Code: Alles auswählen

#! /bin/sh

# alle Regeln loeschen
iptables -F
iptables -t nat -F

#---------------------------------------------------------------------
# ssh zugriff von aussen erlauben
#---------------------------------------------------------------------
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT

#---------------------------------------------------------------------
# webserver zugriff von aussen erlauben
#---------------------------------------------------------------------
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT

#---------------------------------------------------------------------
# kommentare entfernen, wenn rechner als druckerserver fungieren soll
#---------------------------------------------------------------------
# iptables -A INPUT -p tcp --dport 631 -j ACCEPT
# iptables -A INPUT -p udp --dport 631 -j ACCEPT
# iptables -A OUTPUT -p tcp --dport 631 -j ACCEPT
# iptables -A OUTPUT -p udp --dport 631 -j ACCEPT
#---------------------------------------------------------------------

# Server soll auf "ping" reagieren
iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -i ppp0 -p icmp --icmp-type destination-unreachable -j ACCEPT

iptables -N block
iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
iptables -A block -j DROP

iptables -A INPUT -j block
iptables -A FORWARD -j block

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Ich möchte aber etwas über die Leute erfahren können, die sich versuchen per ssh bei mir unerlaubter weise versuchen einzuloggen. Was kann ich abgesehen von dem Portscan, der sowieso nur kurzzeitig möglich ist (Neueinwahl - andere IP) noch machen???
danke im voraus!

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 27.02.2005 21:45:47

nichts, es kann sogar sein bzw ist sogar wahrscheinlich, daß du den Rechner eines ahnungslosen Internetbenutzer gescannt hast, dessen System selber mißbraucht wurde.

Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

Beitrag von netchamber » 27.02.2005 21:57:19

Hallo!

Dankeschön, auch wenn das natürlich etwas ernüchternt ist.
danke im voraus!

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 27.02.2005 22:02:00

ist leider so, du brauchst dir ja nur die Portliste anschauen

Code: Alles auswählen

PORT     STATE    SERVICE 
21/tcp   open     ftp 
22/tcp   open     ssh 
53/tcp   open     domain 
80/tcp   open     http 
111/tcp  open     rpcbind 
515/tcp  filtered printer 
3306/tcp open     mysql 
4444/tcp filtered krb524 
6000/tcp open     X11
Ich glaube nicht, daß ein Hacker sein eigenes System so freizügig anderen Angreifern presentiert

Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

Beitrag von netchamber » 27.02.2005 22:05:43

Hallo!

Da kannst du Recht haben. Ich habe mich vor kurzem ein bisschen mit DoS beschäftigt, um zu vermeiden, dass mein Rechner ein weiteres Opfer davon wird. Reicht eine Firewall, wie die o.g. dafür aus? Wie könnte ich mich schützen, um flooding / spamming Attacken abzuwehren? Der Rechner würde bei sowas vermutlich schnell in die Knie gehen ..
danke im voraus!

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 27.02.2005 22:41:14

ich habe noch so einen synflood-check drinnen:

Code: Alles auswählen

  iptables -N synflood-check
  iptables -A synflood-check -m limit --limit $SYNLIMIT --limit-burst $SYNLIMITBURST -j RETURN
  iptables -A synflood-check -j issynflood

Code: Alles auswählen

  iptables -A INPUT  -p tcp --syn -j synflood-check
  iptables -A INPUT  -p tcp ! --syn -m state --state NEW -j hasnosynflag
  iptables -A INPUT  -m state --state INVALID -j isinvalid


Benutzeravatar
monotek
Beiträge: 227
Registriert: 20.07.2004 15:25:11
Wohnort: dresden

Beitrag von monotek » 28.02.2005 15:26:33

mal davon abgesehn, dass es sowieso relativ unwahrscheinlich ist das ein "hacker" sich die mühe macht, nen privat pc anzugreifen...

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.02.2005 15:33:25

monotek hat geschrieben:mal davon abgesehn, dass es sowieso relativ unwahrscheinlich ist das ein "hacker" sich die mühe macht, nen privat pc anzugreifen...
sollen wir jetzt ein Schild "privat: Zutritt verboten" auf unsere Kisten hängen :?

Benutzeravatar
Maikel
Beiträge: 1267
Registriert: 13.04.2004 15:39:25
Wohnort: Gelsenkirchen
Kontaktdaten:

Beitrag von Maikel » 28.02.2005 16:13:22

monotek hat geschrieben:mal davon abgesehn, dass es sowieso relativ unwahrscheinlich ist das ein "hacker" sich die mühe macht, nen privat pc anzugreifen...
Was ihr so als "hacker" bezeichnet sind wohl "Cracker" die genau wissen was für ein System sie knacken wollen. Sprich, die wissen schon welche Rechner sie wofür brauchen können.

Aber gms hat schon Recht mit seinem Schild.
So nen Script Kiddie der blöde das Netz scannt um mal zu gucken was danach mit Tool XY gemacht werden kann unterscheidet nicht zwischen wichtigen Server oder HomePC. Die sind doch eh nicht in der Lage das zu unterscheiden...
Cheers, Maikel
------------
BGLUG
------------
Linus Torvalds:
"Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)"

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 28.02.2005 17:04:50

aafd
Zuletzt geändert von meandtheshell am 28.05.2007 19:19:16, insgesamt 1-mal geändert.

Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

Beitrag von netchamber » 28.02.2005 17:41:29

Hallo!

Um mal zurück zu meinem Server zu kommen .. 8) Ich habe in meiner /var/log/auth.log Einträge gefunden, die ich nicht ganz nachvollziehen kann ...
Feb 28 00:09:01 Minilinux CRON[8026]: (pam_unix) session closed for user root
Feb 28 00:17:01 Minilinux CRON[8042]: (pam_unix) session opened for user root by (uid=0)
Feb 28 00:17:01 Minilinux CRON[8042]: (pam_unix) session closed for user root
Feb 28 00:39:01 Minilinux CRON[8064]: (pam_unix) session opened for user root by (uid=0)
Feb 28 00:39:02 Minilinux CRON[8064]: (pam_unix) session closed for user root
Feb 28 01:09:01 Minilinux CRON[8099]: (pam_unix) session opened for user root by (uid=0)
Feb 28 01:09:02 Minilinux CRON[8099]: (pam_unix) session closed for user root
Feb 28 01:17:01 Minilinux CRON[8115]: (pam_unix) session opened for user root by (uid=0)
Feb 28 01:17:01 Minilinux CRON[8115]: (pam_unix) session closed for user root
Feb 28 01:39:01 Minilinux CRON[8137]: (pam_unix) session opened for user root by (uid=0)
Feb 28 01:39:02 Minilinux CRON[8137]: (pam_unix) session closed for user root
Feb 28 02:09:01 Minilinux CRON[8172]: (pam_unix) session opened for user root by (uid=0)
Feb 28 02:09:02 Minilinux CRON[8172]: (pam_unix) session closed for user root
Feb 28 02:17:01 Minilinux CRON[8188]: (pam_unix) session opened for user root by (uid=0)
Feb 28 02:17:01 Minilinux CRON[8188]: (pam_unix) session closed for user root
Feb 28 02:39:01 Minilinux CRON[8210]: (pam_unix) session opened for user root by (uid=0)
Feb 28 02:39:01 Minilinux CRON[8210]: (pam_unix) session closed for user root
Können diese Login Anfragen (?) wirklich von cron kommen? Warum dauern die Sessions immer nur rund eine Sekunde?
danke im voraus!

Benutzeravatar
roland
Beiträge: 159
Registriert: 24.08.2004 14:41:41
Wohnort: 754xx
Kontaktdaten:

Beitrag von roland » 28.02.2005 17:56:03

meandtheshell hat geschrieben: es wäre interessant einmal was zu programmieren, das nicht ausschließlich defensiv agiert wenn sich ein böser bube am system zu schaffen machen will ...
Und woran machst Du fest, ob ein Paket böse oder gut ist? Wie willst Du feststellen, ob das Paket tatsächlich von dem Server kommt, der im Paketkopf drinsteht?

Das klappt so nicht. Wie so etwas ausgeht, kann man prima an Honeypots sehen, die niemand mehr einsetzt, weil darauf niemand mehr reinfällt, sondern höchstens noch gelangweilt damit rumspielt.

roland

Benutzeravatar
meandtheshell
Beiträge: 4054
Registriert: 14.01.2005 17:51:30

Beitrag von meandtheshell » 28.02.2005 18:00:34

Und woran machst Du fest, ob ein Paket böse oder gut ist?
das habe ich nicht gemeint - es ging eher um intrusion detection und das handeln danach

Benutzeravatar
roland
Beiträge: 159
Registriert: 24.08.2004 14:41:41
Wohnort: 754xx
Kontaktdaten:

Beitrag von roland » 28.02.2005 18:07:56

Ah, also wenn der böse Bube schon im Zimmer steht. Dann hatte ich Dich mißverstanden, 'schuldigung.

Aber auch nach dem Eindringen wird es schwierig sein, die Quelle der Angriffe sauber auszumachen. Stichwort botnets. Oder gekapterte WLANs :?

Du kannst natürlich den Angreifer mit falschen Passwörtern und leckeren Dateien vollstopfen, aber was hast Du davon? Der nächste Cracker steht schon vor der Tür und Du hast nur Bandbreite verbraten. Und die ganze Vorgehensweise hilft nur gegen aktive Angriffe, nicht gegen passive, wie z.B. Viren.

roland

Benutzeravatar
netchamber
Beiträge: 28
Registriert: 13.08.2003 07:22:47

Beitrag von netchamber » 28.02.2005 19:34:35

Hallo!

Euer Thema hat nichts mit meinem Problem zu tun. Deshalb wäre es nett, ihr würdet es in einem anderen Thread diskutieren. Kann noch jeman etwas zu meinem Problem sagen? (siehe http://debianforum.de/forum/viewtopic.p ... c&start=12 )
danke im voraus!

Benutzeravatar
Maikel
Beiträge: 1267
Registriert: 13.04.2004 15:39:25
Wohnort: Gelsenkirchen
Kontaktdaten:

Beitrag von Maikel » 28.02.2005 19:53:40

Warum sollen die nicht von CRON kommen?
Sie kommen immer zu den gleichen Zeiten, dauern immer gleich lang (ne Sek ist doch OK um ne Session zu öffnen.

Aber du solltest doch wissen ob du nen cronjob laufen hast oder nicht.
Cheers, Maikel
------------
BGLUG
------------
Linus Torvalds:
"Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)"

gms
Beiträge: 7798
Registriert: 26.11.2004 20:08:38
Lizenz eigener Beiträge: MIT Lizenz

Beitrag von gms » 28.02.2005 20:08:13

netchamber hat geschrieben:Warum dauern die Sessions immer nur rund eine Sekunde?
Bei mir wird immer 17 nach der vollen Stunde in /etc/cron.hourly nachgeschaut ob sich dort ein Job befindet. Dieser Vorgang ist bei mir sogar innerhalb der gleichen Sekunde abgeschlossen.

Antworten