Discussion:
[eisfair-64] Paket sshguard 0.9.0
(zu alt für eine Antwort)
Ansgar Püster
2020-07-03 15:54:12 UTC
Permalink
Hallo Sebastian,

dein Paket habe ich auf einem Testsystem installiert.
Einige Dinge sind mir aufgefallen:

1.) Datei /var/lib/sshguard/whitelist.conf

-- schnipp --

#----------------------------------------------------------------------------
# /var/lib/sshguard/whitelist.conf
# generated by /var/install/config.d/sshguard.sh
#
# Do not edit this file, edit /etc/config.d/sshguard
# Creation Date: 2020-07-02 Time: 17:31:31
#----------------------------------------------------------------------------
0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
172.16.0.0/12
192.168.0.0/16

-- schnipp --

Mir ist es nicht gelungen diese über /etc/config.d/sshguard
zu konfigurieren. Es sollte dokumentiert werden, dass sshguard
das aktuelle Netz, localnet, private Klasse A,B,C Netze nicht
überwacht.

2.) Skript /usr/lib/sshg-logtail

Das Skript enthält meines Erachtens einen heftigen Designfehler.
Beim /etc/init.d/sshguard start wird die komplette, ggf. sehr
alte Datei /var/log/messages via cat an die Prozessreihe von
sshguard übergeben. Auch alte log message werden ausgewertet.
Das führt ggf. zu einer sofortigen Attack Meldungen und damit
zu einem Blocking auf Grund dieser "uralten" log messages.

3.) Logging-Datei

Relevante auth.info und authpriv.info messages werden ausschließlich
in /var/log/messages erwartet. Es gibt derzeit keine Möglichkeit eine
andere Datei anzugeben.

Es sollte ggf. auch ein Hinweis erfolgen, dass ein Einsatz des
Paketes sshguard bei Systemen, die kein lokales Logging sondern
ausschließlich ein zentrales Logging auf einem Log-Server nutzen,
nicht funktionieren kann.

4.) Blocking Gründe

Auch Meldungen von proftpd und pure-ftpd werden ausgewertet und
führen dann ggf. zum blocking. Ich muss noch mal prüfen, was da
wirklich passiert.

5.) ssh port

Kann irgendwie konfiguriert werden, dass ssh auf einem Port
ungleich 22 läuft?

Ansonsten ein sehr interessantes Paket.
So weit erst mal.
Gruß,
Ansgar
Sebastian Ertz
2020-07-05 09:51:58 UTC
Permalink
Hallo Ansgar,

zu 1) WhiteList-Konfig kommt in der nÀchsten Version
zu 2) In der kommenden Version gefixt.
zu 3) LogDateien-Konfig kommt in der nÀchsten Version.
zu 4) SSHGuard blockt auch andere Vorkommnisse, siehe:
https://web.archive.org/web/20180218092827/https://www.sshguard.net/docs/reference/attack-signatures/
und
https://web.archive.org/web/20170226120409/http://www.sshguard.net/docs/reference/service-codes/
zu 5) Wenn eine IP-Adresse geblockt wird, verwirft der Server sofort ein
Paket von der Geblockten-IP-Adresse (Egal welcher Port). Eventuell werde
ich Port-Angaben konfigurierbar machen.

Die Doku muss ich noch ergÀnzen und erweitern ;)

Gruß
Sebastian
Ansgar Püster
2020-07-05 16:03:30 UTC
Permalink
Hallo Sebastian,

Danke für deine Antwort.
Post by Sebastian Ertz
Hallo Ansgar,
zu 1) WhiteList-Konfig kommt in der nächsten Version
zu 2) In der kommenden Version gefixt.
zu 3) LogDateien-Konfig kommt in der nächsten Version.
Sehr gut, wenn diese drei Punkte erweitert bzw. gelöst werden.
Post by Sebastian Ertz
https://web.archive.org/web/20180218092827/https://www.sshguard.net/docs/reference/attack-signatures/
und
https://web.archive.org/web/20170226120409/http://www.sshguard.net/docs/reference/service-codes/
In der Tat wird auch bei "Einbruchsversuchen" über FTP blockiert.
Post by Sebastian Ertz
zu 5) Wenn eine IP-Adresse geblockt wird, verwirft der Server sofort ein
Paket von der Geblockten-IP-Adresse (Egal welcher Port). Eventuell werde
ich Port-Angaben konfigurierbar machen.
Ja, das ist m.E. ein grundsätzliches Problem, auf das ich auch
gekommen bin. sshguard blockiert den Server total!
Nicht mal ein ping (ICMP ECHO_REQUEST) wird noch beantwortet.
Ich halte ein solches Verhalten (totale Blockade durch ein
Paket mit Namen sshguard) für fragwürdig.

Habe gerade mal mit ipset "hash:ip,port" geübt. Bin aber zu
keinem vernünftigen Ergabnis gekommen. iptables und insbesondere
ipset ist mir halt fremd.

Im Paket rsyslogd nutze ich nftables um die sog. allowed sender
zu konfigurieren und damit den rsyslogd vor überflutenden
Meldungen zu sichern.
Post by Sebastian Ertz
Die Doku muss ich noch ergänzen und erweitern ;)
Super ... ich lese gerne Korrektur.

Gruß,
Ansgar
Marcus Röckrath
2020-07-05 17:24:30 UTC
Permalink
Hallo Ansgar,
Post by Ansgar Püster
Ja, das ist m.E. ein grundsätzliches Problem, auf das ich auch
gekommen bin. sshguard blockiert den Server total!
Nicht mal ein ping (ICMP ECHO_REQUEST) wird noch beantwortet.
Ich halte ein solches Verhalten (totale Blockade durch ein
Paket mit Namen sshguard) für fragwürdig.
Wenn ein böser Bube einen bestimmten Port angreift, macht es doch Sinn, denn
dann auch für alle zu blocken, oder soll der dann den nächsten Port
"belagern"?

Laut Homepage ist die Beobachtung weiterer Ports erst im Laufeder
Entwicklung hinzugekommen, also ar es ursprünglich wohl doch eher ein
reiner ssh-Blocker.
--
Gruß Marcus
[eisfair-Team]
Ansgar Püster
2020-07-05 18:13:25 UTC
Permalink
Hallo,
Post by Sebastian Ertz
Hallo Ansgar,
Post by Ansgar Püster
Ja, das ist m.E. ein grundsätzliches Problem, auf das ich auch
gekommen bin. sshguard blockiert den Server total!
Nicht mal ein ping (ICMP ECHO_REQUEST) wird noch beantwortet.
Ich halte ein solches Verhalten (totale Blockade durch ein
Paket mit Namen sshguard) für fragwürdig.
Wenn ein böser Bube einen bestimmten Port angreift, macht es doch Sinn, denn
dann auch für alle zu blocken, oder soll der dann den nächsten Port
"belagern"?
Nun, das ist eine Frage der funktionalen Anforderung.
Bei einem sshguard würde ich die Absicherung vor ungewünschten
ssh-Verbindungen erwarten. Nun gut, wenn auch noch ftp überwacht
wird, so ist das ggf. sinnvoll, da auch dort u.A. mit Usernamen
und Passwörtern gearbeitet wird. Zu den überwachten Mail-Teilen
kann ich mangels Know-How nichts sagen.

Wenn eine Totalblockade gesetzt wird, so muss das m.E. deutlichst
dokumentiert werden.
Post by Sebastian Ertz
Laut Homepage ist die Beobachtung weiterer Ports erst im Laufeder
Entwicklung hinzugekommen, also ar es ursprünglich wohl doch eher ein
reiner ssh-Blocker.
Meines Erachtens ist das eine Frage der Implementierung des
Block-Mechanismus. Schränkt man z.B. die entsprechende iptables-
Regel via multiport Angabe auf 21,22 oder andere, konfigurierbare
Ports ein, so blockt sshguard halt ftp und ssh, aber auch nur das.

Aber, wir gesagt, wenn klar ist, dass eine Totalblockade gewünscht
ist, so sollte das natürlich so bleiben.

So weit erst mal.
Gruß,
Ansgar
Marcus Röckrath
2020-07-05 18:49:49 UTC
Permalink
Hallo Ansgar,
Post by Ansgar Püster
Post by Marcus Röckrath
Laut Homepage ist die Beobachtung weiterer Ports erst im Laufeder
Entwicklung hinzugekommen, also ar es ursprünglich wohl doch eher ein
reiner ssh-Blocker.
Meines Erachtens ist das eine Frage der Implementierung des
Block-Mechanismus. Schränkt man z.B. die entsprechende iptables-
Regel via multiport Angabe auf 21,22 oder andere, konfigurierbare
Ports ein, so blockt sshguard halt ftp und ssh, aber auch nur das.
Ich habe mich auf der Seite nicht genauer eingelesen, ob man den Umfang der
Port-Blockade konfigurieren kann.
--
Gruß Marcus
[eisfair-Team]
Ansgar Püster
2020-07-06 06:57:19 UTC
Permalink
Moin Marcus,
Post by Sebastian Ertz
Hallo Ansgar,
Post by Ansgar Püster
Post by Marcus Röckrath
Laut Homepage ist die Beobachtung weiterer Ports erst im Laufeder
Entwicklung hinzugekommen, also ar es ursprünglich wohl doch eher ein
reiner ssh-Blocker.
Es werden übrigens keine Ports überwacht, sondern Meldungen in
einem Log analysiert. Siehe
https://web.archive.org/web/20180218092827/https://www.sshguard.net/docs/reference/attack-signatures/
Post by Sebastian Ertz
Post by Ansgar Püster
Meines Erachtens ist das eine Frage der Implementierung des
Block-Mechanismus. Schränkt man z.B. die entsprechende iptables-
Regel via multiport Angabe auf 21,22 oder andere, konfigurierbare
Ports ein, so blockt sshguard halt ftp und ssh, aber auch nur das.
Ich habe mich auf der Seite nicht genauer eingelesen, ob man den Umfang der
Port-Blockade konfigurieren kann.
Das kann man ziemlich frei bestimmen. Sebastian blockiert (DROP)
derzeit alle Pakete der IP Adresse von der die Attacke gekommen
ist. Ich habe die entsprechende Stelle, an der die iptables Regel
erstellt wird mal abgeändert:

/usr/sbin/iptables -w -A INPUT -m multiport -p tcp --destination-ports
21,22 -m set --match-set "$IPSET_NAME" src -m comment --comment "DROP"
-j DROP

Dann werden "nur" noch tcp-Pakete auf Port 21 und 22 blockiert (DROP).

Aber, wir gesagt, wenn klar ist, dass eine Totalblockade gewünscht
ist, so sollte das natürlich so bleiben.

So weit erst mal.
Gruß,
Ansgar
Sebastian Ertz
2020-07-06 09:43:23 UTC
Permalink
Hallo Ansgar,

ich kann deine Problematik verstehen. Habe gestern ein wenig rumprobiert
wie man die Ports in der Eisfair-Konfig-Schicht am besten umsetzt und
bin leider zu keiner Zufriedenstellendem Design gekommen. Weil man
mÃŒsste auch die Protokolle konfigurierbar machen.

1. Idee:
SSHGUARD_PORT_ALL='no'

SSHGUARD_PORT_N='zahl'

SSHGUARD_PORT_1_ACTIVE='yes'
SSHGUARD_PORT_1_PROTOCOL='tcp'
SSHGUARD_PORT_1_PORT='21'

SSHGUARD_PORT_2_ACTIVE='yes'
SSHGUARD_PORT_2_PROTOCOL='tcp'
SSHGUARD_PORT_2_PORT='22'

SSHGUARD_PORT_3_ACTIVE='yes'
SSHGUARD_PORT_3_PROTOCOL='udp'
SSHGUARD_PORT_3_PORT='5060'

usw.

Aber dies könnte zu einer verdammt langen Liste fÌhren. Und verwirrend
fÃŒr "normale"-Eisfair Nutzer sein.


2. Idee:
Standard:
SSHGUARD_CUSTOM_IPTABLES='' # Optionaler Parameter

VerÀndert (fÌr Profis):
SSHGUARD_CUSTOM_IPTABLES='-m multiport -p tcp --destination-ports 21,22'
# Optionaler Parameter


3. Idee:
Standard:
SSHGUARD_IPTABLES_N='0'

VerÀndert (fÌr Profis):
SSHGUARD_IPTABLES_N='2'

SSHGUARD_IPTABLES_1_ACTIVE='yes'
SSHGUARD_IPTABLES_1_PARA='-m multiport -p tcp --destination-ports
21,22'

SSHGUARD_IPTABLES_2_ACTIVE='yes'
SSHGUARD_IPTABLES_2_PARA='-m multiport -p udp --destination-ports
5060,10000-20000'


4. Idee:
SSHGUARD_PORTS_TCP='21,22'
SSHGUARD_PORTS_UDP='5060,10000-20000'
SSHGUARD_PORTS_xxx
..
(siehe /etc/protocols)


5. Idee: (Hier wird eine eigene Chain "SSHGuard" erzeugt, die auf die
Source-IP-Adresse des ipset "SSHGuard" dann Pakete DROPt)
SSHGUARD_IPTABLES_INPUT='yes' # Optionaler Parameter
yes = /usr/sbin/iptables -w -A INPUT -j SSHGuard
no = (Nichts wird gemacht, der user muss sich selbst drum kÃŒmmern)


1-4: wird glaub ich zu Komplex
5: Der User muss sich selbst drum kÃŒmmern wann das Paket an die Chain
"SSHGuard" gesendet wird

Hast du eventuell eine bessere Idee?

Gruß
Sebastian
Ansgar Püster
2020-07-06 15:30:12 UTC
Permalink
Hallo Sebastian,
Post by Sebastian Ertz
Hallo Ansgar,
[...]
Post by Sebastian Ertz
SSHGUARD_PORTS_TCP='21,22'
SSHGUARD_PORTS_UDP='5060,10000-20000'
SSHGUARD_PORTS_xxx
[...]
Post by Sebastian Ertz
Hast du eventuell eine bessere Idee?
Ich finde deine Idee 4. gut, würde sie aber etwas erweitern
bzw. verändern.

SSHGUARD_BLOCK_ALL yes/no

bei
SSHGUARD_BLOCK_ALL='yes'
Verhalten wie bisher

bei
SSHGUARD_BLOCK_ALL='no'
SSHGUARD_PORTS_TCP='21,22'
SSHGUARD_PORTS_UDP='5060,10000:20000'
Aufbau der entsprechenden iptables multiport Angabe.

(iptables "versteht" hier nicht 10000-20000 sondern
benötigt eine Angabe 10000:20000).

Falls du Hilfe beim Bau des regulären Ausdrucks für
SSHGUARD_PORTS_TCP/SSHGUARD_PORTS_UDP brauchst, einfach
melden.

Ich habe heute mit einem ehemaligen Kollegen gesprochen, der
zum sog. Tiger Team meines ehemaligen Arbeitgebers gehört hat.
Er ist absoluter "alle Pakete der attakierenden IP DROPPEN" Fan.

Gruß,
Ansgar
Marcus Röckrath
2020-07-06 18:31:21 UTC
Permalink
Hallo ansgar,
Post by Ansgar Püster
Ich habe heute mit einem ehemaligen Kollegen gesprochen, der
zum sog. Tiger Team meines ehemaligen Arbeitgebers gehört hat.
Er ist absoluter "alle Pakete der attakierenden IP DROPPEN" Fan.
So hatte ich mich auch schon geäußert.

Wirst du von einem Host attakiert, wieso sollte man ihm dann noch die Chance
geben, seinen Unsinn auf anderen Ports weiter zu probieren.

Falls er nur auf einem Port geblockt war, ist kaum anzunehmen, dass er bei
weiteren Versuchen auf anden Ports plötzlich dies zu Recht darf.
--
Gruß Marcus
[eisfair-Team]
Sebastian Ertz
2020-07-11 08:27:48 UTC
Permalink
Hallo,

habe soeben eine neue Version v0.9.1 SSHGuard auf pack-eis.de
hochgeladen.
Sobald es Freigeschaltet wurde wÃŒrde ich mich ÃŒber Feedback freuen.

Danke
Sebastian
Ansgar Püster
2020-07-22 17:34:46 UTC
Permalink
Hallo Sebastian,

habe gerade v0.9.1 SSHGuard installiert.

Ich werde versuchen am Wochenende "verschärft" zu testen.
Falls mir etwas auffällt, so melde ich mich in einem
neuen Thread.

Gruß,
Ansgar
Post by Ansgar Püster
Hallo,
habe soeben eine neue Version v0.9.1 SSHGuard auf pack-eis.de
hochgeladen.
Sobald es Freigeschaltet wurde würde ich mich über Feedback freuen.
Danke
Sebastian
Loading...