13.2 ignoriert hosts.allow/deny

Stephan von Krawczynski

18 May 2015 18 May '15

09:31

Hallo, heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ... -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Show replies by date

Marcus Meissner

19 May 19 May

06:21

On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...

Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer... Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so. FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh" Ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Stephan von Krawczynski

06:46

On Tue, 19 May 2015 08:21:04 +0200 Marcus Meissner wrote:

...

On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Ciao, Marcus

DAS IST QUATSCH!!!! sshd ging bis 13.2 IMMER mit tcp wrapper. Unter 10.X gabs mal kurz eine Version die versehentlich ohne gebaut wurde, aber das wurde per Update behoben. Fail2ban ist _KEIN_ Ersatz dafuer, denn bei einer passenden Luecke im sshd brauchst Du u.U. nur einen Versuch um reinzukommen. Ein TCP-Wrapper hatte noch nie in seiner Geschichte eine Luecke (weil voellig primitiv). Daher schuetzt der IMMER. Wem nicht klar ist, dass der immanente Schutz eines eingebauten TCP-Wrappers immer sicherer ist als ein externer Filter ueber Firewall-Regeln die man separat starten muss, der versteht einfach nichts von Sicherheit, sorry. Bitte ueberleg Dir erst mal ein paar Grundsaetze zur Risiko-Bewertung. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Ingo

07:40

Am 19.05.2015 um 08:46 schrieb Stephan von Krawczynski:

...

On Tue, 19 May 2015 08:21:04 +0200 Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ... Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Ciao, Marcus DAS IST QUATSCH!!!!

sshd ging bis 13.2 IMMER mit tcp wrapper. Unter 10.X gabs mal kurz eine Version die versehentlich ohne gebaut wurde, aber das wurde per Update behoben. Fail2ban ist _KEIN_ Ersatz dafuer, denn bei einer passenden Luecke im sshd brauchst Du u.U. nur einen Versuch um reinzukommen. Ein TCP-Wrapper hatte noch nie in seiner Geschichte eine Luecke (weil voellig primitiv). Daher schuetzt der IMMER. Wem nicht klar ist, dass der immanente Schutz eines eingebauten TCP-Wrappers immer sicherer ist als ein externer Filter ueber Firewall-Regeln die man separat starten muss, der versteht einfach nichts von Sicherheit, sorry. Bitte ueberleg Dir erst mal ein paar Grundsaetze zur Risiko-Bewertung.

Das kann ich bestätigen ich benutze auch schon seit über 10 Jahren den TCP Wrapper auf Port 22 der nur entsprechende IPs durchlässt. Es wäre schade wenn so ein unkompliziertes System nun einfach so abgeschafft wird. Gruß Ingo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Dr. Werner Fink

08:46

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...

On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org - Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119 Und unter http://comments.gmane.org/gmane.linux.suse.general/348119: This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed. ... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später. Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Marcus Meissner

08:50

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 10:46:37AM +0200, Dr. Werner Fink wrote:

...

On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Jau. Da es etwas voreilig war, hab ich mal nen Bug aufgemacht das wir es temporaer noch erlauben koennten fuer die alten distros. Ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Marcus Meissner

08:51

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 10:50:01AM +0200, Marcus Meissner wrote:

...

On Tue, May 19, 2015 at 10:46:37AM +0200, Dr. Werner Fink wrote:

...
On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Jau.

Da es etwas voreilig war, hab ich mal nen Bug aufgemacht das wir es temporaer noch erlauben koennten fuer die alten distros.

https://bugzilla.suse.com/show_bug.cgi?id=931429 Ciao, Marcus -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Stephan von Krawczynski

09:13

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, 19 May 2015 10:46:37 +0200 "Dr. Werner Fink" wrote:

...

On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Offensichtlich haben die Script-Kiddies jetzt auch in dieser Hinsicht die Fuehrung uebernommen. Was mal ein gutes Sicherheitsfeature war wird zugunsten einer undurchsichtigen Option in einem proprietaeren Config-File eliminiert. Was fuer Nullen sind hier am Werk? Ich nenne das mal "grub2-ifizierung" von Linux. Es lebe das beliebig komplexe Config-File in allen Binaries mit moeglichst wenig gemeinsamen uebergreifenden Features. Der Hinweis auf "Match" soll ja wohl ein Witz sein.

...

Werner

-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

-- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Dr. Werner Fink

09:35

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 11:13:25AM +0200, Stephan von Krawczynski wrote:

...

On Tue, 19 May 2015 10:46:37 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Offensichtlich haben die Script-Kiddies jetzt auch in dieser Hinsicht die Fuehrung uebernommen. Was mal ein gutes Sicherheitsfeature war wird zugunsten einer undurchsichtigen Option in einem proprietaeren Config-File eliminiert. Was fuer Nullen sind hier am Werk? Ich nenne das mal "grub2-ifizierung" von Linux. Es lebe das beliebig komplexe Config-File in allen Binaries mit moeglichst wenig gemeinsamen uebergreifenden Features. Der Hinweis auf "Match" soll ja wohl ein Witz sein.

Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter. Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben: Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file. The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5). The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively. Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost. Werner -- Dr. Werner Fink -- Software Engineer Consultant SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) phone: +49-911-740-53-0, fax: +49-911-3206727, www.opensuse.org

Stephan von Krawczynski

10:04

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, 19 May 2015 11:35:31 +0200 "Dr. Werner Fink" wrote:

...

On Tue, May 19, 2015 at 11:13:25AM +0200, Stephan von Krawczynski wrote:

...
On Tue, 19 May 2015 10:46:37 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Offensichtlich haben die Script-Kiddies jetzt auch in dieser Hinsicht die Fuehrung uebernommen. Was mal ein gutes Sicherheitsfeature war wird zugunsten einer undurchsichtigen Option in einem proprietaeren Config-File eliminiert. Was fuer Nullen sind hier am Werk? Ich nenne das mal "grub2-ifizierung" von Linux. Es lebe das beliebig komplexe Config-File in allen Binaries mit moeglichst wenig gemeinsamen uebergreifenden Features. Der Hinweis auf "Match" soll ja wohl ein Witz sein.

Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter.

Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben:

Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

Werner

Es geht nicht um die Frage wie lange es irgendeine Option im sshd gibt. Es geht fundamental um die Frage ueber wieviele Orte im gesamten Dateisystem die sicherheitsrelevanten Einstellungen verteilt sind. Wenn ich 20 services habe die alle mit tcp wrapper laufen habe ich genau ein File mit 20 Eintraegen wo alle Zugriffsmoeglichkeiten geregelt sind. Wenn ich den hier praesentierten Weg gehe habe ich 20 Configfiles an zwanzig Orten mit mindestens 20 voellig verschiedenen Option-Keywords und nachfolgenden weiteren Optionen. Wem nicht einleuchtet dass das nicht der richtige Weg sein kann, dem ist echt nicht mehr zu helfen. Machen wir doch einfach den Test, schreib doch mal was in der jetzigen sshd-config notwendig ist um 20 IP-Adressen auf den sshd Port zu lassen und sonst keine. Im hosts.allow ist das genau eine Zeile. Zeig mir das jetzt mit "match":

...

-- Dr. Werner Fink -- Software Engineer Consultant SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) phone: +49-911-740-53-0, fax: +49-911-3206727, www.opensuse.org

Miro Borik

10:35

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

* Stephan von Krawczynski (skraw@ithnet.com), [19.May 2015, 12:04] *

...

On Tue, 19 May 2015 11:35:31 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 11:13:25AM +0200, Stephan von Krawczynski wrote:

...
On Tue, 19 May 2015 10:46:37 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 08:21:04AM +0200, Marcus Meissner wrote:

...
On Mon, May 18, 2015 at 11:31:36AM +0200, Stephan von Krawczynski wrote:

...
Hallo,

heute musste ich wiederum bei 13.2 Ungereimtheiten feststellen. Der sshd liefert Verbindungsversuche von unbekannten IPs obwohl hosts.allow/deny so gesetzt ist dass das gar nicht vorkommen duerfte. Geht in 13.2 eigentlich irgendwas noch richtig? Aber Hauptsache schnell starten ...

Hmm, unser ssh ist ohne TCP wrapper support gebaut, eigentlich schon immer...

Fuer boeswillige SSH Angriffe empfiehlt sich entweder ignorieren, oder zb im firewall ein recent Filter, oder fail2ban oder so.

FW_SERVICES_ACCEPT_EXT="0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh"

Sat May 17 22:31:29 UTC 2014 - crrodriguez@opensuse.org

- Remove tcpwrappers support now, This feature was removed in upstream code at the end of April and the underlying libraries are abandonware. See: http://comments.gmane.org/gmane.linux.suse.general/348119

Und unter http://comments.gmane.org/gmane.linux.suse.general/348119:

This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed.

... ist also völlig korrekt, das war mal im openssh, wird aber mit Sicherheit rausfliegen. Ob nun jetzt oder später.

Da hilft kein Geschimpfe und das hat auch nicht mit schnell starten und/oder systemd zu tun.

Offensichtlich haben die Script-Kiddies jetzt auch in dieser Hinsicht die Fuehrung uebernommen. Was mal ein gutes Sicherheitsfeature war wird zugunsten einer undurchsichtigen Option in einem proprietaeren Config-File eliminiert. Was fuer Nullen sind hier am Werk? Ich nenne das mal "grub2-ifizierung" von Linux. Es lebe das beliebig komplexe Config-File in allen Binaries mit moeglichst wenig gemeinsamen uebergreifenden Features. Der Hinweis auf "Match" soll ja wohl ein Witz sein.

Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter.

Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben:

Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

Werner

Es geht nicht um die Frage wie lange es irgendeine Option im sshd gibt. Es geht fundamental um die Frage ueber wieviele Orte im gesamten Dateisystem die sicherheitsrelevanten Einstellungen verteilt sind. Wenn ich 20 services habe die alle mit tcp wrapper laufen habe ich genau ein File mit 20 Eintraegen wo alle Zugriffsmoeglichkeiten geregelt sind. Wenn ich den hier praesentierten Weg gehe habe ich 20 Configfiles an zwanzig Orten mit mindestens 20 voellig verschiedenen Option-Keywords und nachfolgenden weiteren Optionen. Wem nicht einleuchtet dass das nicht der richtige Weg sein kann, dem ist echt nicht mehr zu helfen. Machen wir doch einfach den Test, schreib doch mal was in der jetzigen sshd-config notwendig ist um 20 IP-Adressen auf den sshd Port zu lassen und sonst keine. Im hosts.allow ist das genau eine Zeile. Zeig mir das jetzt mit "match":

...
-- Dr. Werner Fink -- Software Engineer Consultant SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) phone: +49-911-740-53-0, fax: +49-911-3206727, www.opensuse.org

-- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Hallo, genau. Was mache ich jetzt damit? sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW Gruß, -- Miro Borik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Dr. Werner Fink

11:06

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 12:35:57PM +0200, Miro Borik wrote:

...

* Stephan von Krawczynski (skraw@ithnet.com), [19.May 2015, 12:04] *

...
On Tue, 19 May 2015 11:35:31 +0200 "Dr. Werner Fink" wrote:

...
Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter.

Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben:

Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

...

...
Es geht nicht um die Frage wie lange es irgendeine Option im sshd gibt. Es geht fundamental um die Frage ueber wieviele Orte im gesamten Dateisystem die sicherheitsrelevanten Einstellungen verteilt sind. Wenn ich 20 services habe die alle mit tcp wrapper laufen habe ich genau ein File mit 20 Eintraegen wo alle Zugriffsmoeglichkeiten geregelt sind. Wenn ich den hier praesentierten Weg gehe habe ich 20 Configfiles an zwanzig Orten mit mindestens 20 voellig verschiedenen Option-Keywords und nachfolgenden weiteren Optionen. Wem nicht einleuchtet dass das nicht der richtige Weg sein kann, dem ist echt nicht mehr zu helfen. Machen wir doch einfach den Test, schreib doch mal was in der jetzigen sshd-config notwendig ist um 20 IP-Adressen auf den sshd Port zu lassen und sonst keine. Im hosts.allow ist das genau eine Zeile. Zeig mir das jetzt mit "match":

Das ist opensource, eventuell hilft es, einen (netten) request upstream zu versuchen. Oder ein Fork von openssh zu machen oder eben in den sauren Apfel zu beißen. Ersteres beinhaltet natürlich Pflege, falls mal ein Security-Problem auftaucht.

...

Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Stephan von Krawczynski

13:04

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, 19 May 2015 13:06:46 +0200 "Dr. Werner Fink" wrote:

...

On Tue, May 19, 2015 at 12:35:57PM +0200, Miro Borik wrote:

...
* Stephan von Krawczynski (skraw@ithnet.com), [19.May 2015, 12:04] *

...
On Tue, 19 May 2015 11:35:31 +0200 "Dr. Werner Fink" wrote:

...
Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter.

Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben:

Match Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, LocalAddress, LocalPort, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. “192.0.2.0/24” or “3ffe:ffff::/32”. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, “192.0.2.0/33” and “192.0.2.0/8” respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.

...
...
Es geht nicht um die Frage wie lange es irgendeine Option im sshd gibt. Es geht fundamental um die Frage ueber wieviele Orte im gesamten Dateisystem die sicherheitsrelevanten Einstellungen verteilt sind. Wenn ich 20 services habe die alle mit tcp wrapper laufen habe ich genau ein File mit 20 Eintraegen wo alle Zugriffsmoeglichkeiten geregelt sind. Wenn ich den hier praesentierten Weg gehe habe ich 20 Configfiles an zwanzig Orten mit mindestens 20 voellig verschiedenen Option-Keywords und nachfolgenden weiteren Optionen. Wem nicht einleuchtet dass das nicht der richtige Weg sein kann, dem ist echt nicht mehr zu helfen. Machen wir doch einfach den Test, schreib doch mal was in der jetzigen sshd-config notwendig ist um 20 IP-Adressen auf den sshd Port zu lassen und sonst keine. Im hosts.allow ist das genau eine Zeile. Zeig mir das jetzt mit "match":

Das ist opensource, eventuell hilft es, einen (netten) request upstream zu versuchen. Oder ein Fork von openssh zu machen oder eben in den sauren Apfel zu beißen. Ersteres beinhaltet natürlich Pflege, falls mal ein Security-Problem auftaucht.

Ok, damit ich das nochmal richtig verstehe: ihr nehmt _mein_ Geld fuer die Distribution (seit deutlich mehr als 10 Jahren), macht euch keine Gedanken was ihr da zusammenbraut, versucht auch nicht auf die schlimmsten Ausrutscher einzuwirken, aber ich soll es dann hinterher auch noch fuer euch wegarbeiten, damit ihr mir dann wieder die naechste Distribution verkaufen koennt mit der ich zufrieden bin? So in etwa? Ich glaub jetzts ists Zeit fuer debian. Was genau macht ihr eigentlich noch ausser einen Webserver mit Selbstbeweihraeucherung pflegen? Sorry, irgendjemand muss einfach mal klare Worte finden. Wenn keiner mehr bei SuSE ist der so einen Unsinn verhindert, dann bringt das alles wirklich nichts mehr. Es ist zwar schoen dass hier immer propagiert wird dass das ein Community-Vorgang waere, aber man sollte sich schon darueber im Klaren sein, dass es hier Leute gibt die Geld dafuer bekommen Community zu spielen und andere die ganz woanders auch dafuer arbeiten muessen. So wie ihr das macht kann man dieses Spiel nicht spielen. Man braucht Grundsaetze wo man hin will und was man verhindern muss, ihr habt scheins keines mehr von beiden, egal was zusammengebastelt wird auf dem Planeten, man macht einfach ein rpm draus und nennt es Linux. Was hier vorgeht hat eindeutig mehr mit Windows zu tun als mit Linux. Alles gut funktionierende und einfache ausbauen und ersetzen durch moeglichst staendig laufende Binaries, egal ob der Job den sie tun sollen schon fertig ist oder nicht (wickedd, systemd), voellig kranke und moeglichst lange Configs (grub2), EOL-Kernels (3.16.x), unausgegorene Filesysteme (BTRFS) denen man scheinbar kein /home anvertrauen kann, Oberflaechen (KDE) in denen kein Mensch Sprache oder Schriftgroesse aendern kann ohne drei Stunden Literatur zu waelzen. Aber Hauptsache die 1000 Laptops die damit installiert werden booten schnell, wen kuemmern die Millionen Internet-Server... Ihr seid dabei diese Distribution restlos kaputt zu machen und merkt es nicht mal, wo sind nur die guten Leute geblieben?

...

...
Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall

Wie startest Du mit der Firewall ein Binary?

...

Werner

-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Dr. Werner Fink

16:43

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 03:04:43PM +0200, Stephan von Krawczynski wrote:

...

Ok, damit ich das nochmal richtig verstehe: ihr nehmt _mein_ Geld fuer die Distribution (seit deutlich mehr als 10 Jahren), macht euch keine Gedanken was ihr da zusammenbraut, versucht auch nicht auf die schlimmsten Ausrutscher einzuwirken, aber ich soll es dann hinterher auch noch fuer euch wegarbeiten, damit ihr mir dann wieder die naechste Distribution verkaufen koennt mit der ich zufrieden bin? So in etwa? Ich glaub jetzts ists Zeit fuer debian. Was genau macht ihr eigentlich noch ausser einen Webserver mit Selbstbeweihraeucherung pflegen? Sorry, irgendjemand muss einfach mal klare Worte finden. Wenn keiner mehr bei SuSE ist der so einen Unsinn verhindert, dann bringt das alles wirklich nichts mehr. Es ist zwar schoen dass hier immer propagiert wird dass das ein Community-Vorgang waere, aber man sollte sich schon darueber im Klaren sein, dass es hier Leute gibt die Geld dafuer bekommen Community zu spielen und andere die ganz woanders auch dafuer arbeiten muessen. So wie ihr das macht kann man dieses Spiel nicht spielen. Man braucht Grundsaetze wo man hin will und was man verhindern muss, ihr habt scheins keines mehr von beiden, egal was zusammengebastelt wird auf dem Planeten, man macht einfach ein rpm draus und nennt es Linux. Was hier vorgeht hat eindeutig mehr mit Windows zu tun als mit Linux. Alles gut funktionierende und einfache ausbauen und ersetzen durch moeglichst staendig laufende Binaries, egal ob der Job den sie tun sollen schon fertig ist oder nicht (wickedd, systemd), voellig kranke und moeglichst lange Configs (grub2), EOL-Kernels (3.16.x), unausgegorene Filesysteme (BTRFS) denen man scheinbar kein /home anvertrauen kann, Oberflaechen (KDE) in denen kein Mensch Sprache oder Schriftgroesse aendern kann ohne drei Stunden Literatur zu waelzen. Aber Hauptsache die 1000 Laptops die damit installiert werden booten schnell, wen kuemmern die Millionen Internet-Server... Ihr seid dabei diese Distribution restlos kaputt zu machen und merkt es nicht mal, wo sind nur die guten Leute geblieben?

https://lwn.net/Articles/615173/ lesen. Ich kann zwar Deinen Ärger verstehen, nur das ist ein OpenSource Projekt. Es steht Dir frei mit daran *mit* zuarbeiten oder Debian zu benutzen. Du könnstest mittels osc ein checkout von openssh machen und den Patch unter http://sf.net/projects/mancha/files/misc/openssh-6.8p1-libwrap.diff mit in das Paket einpflegen.

...

...
...
Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall

Wie startest Du mit der Firewall ein Binary?

zypper se firewall -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Stephan von Krawczynski

17:43

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, 19 May 2015 18:43:12 +0200 "Dr. Werner Fink" wrote:

...

On Tue, May 19, 2015 at 03:04:43PM +0200, Stephan von Krawczynski wrote:

...
Ok, damit ich das nochmal richtig verstehe: ihr nehmt _mein_ Geld fuer die Distribution (seit deutlich mehr als 10 Jahren), macht euch keine Gedanken was ihr da zusammenbraut, versucht auch nicht auf die schlimmsten Ausrutscher einzuwirken, aber ich soll es dann hinterher auch noch fuer euch wegarbeiten, damit ihr mir dann wieder die naechste Distribution verkaufen koennt mit der ich zufrieden bin? So in etwa? Ich glaub jetzts ists Zeit fuer debian. Was genau macht ihr eigentlich noch ausser einen Webserver mit Selbstbeweihraeucherung pflegen? Sorry, irgendjemand muss einfach mal klare Worte finden. Wenn keiner mehr bei SuSE ist der so einen Unsinn verhindert, dann bringt das alles wirklich nichts mehr. Es ist zwar schoen dass hier immer propagiert wird dass das ein Community-Vorgang waere, aber man sollte sich schon darueber im Klaren sein, dass es hier Leute gibt die Geld dafuer bekommen Community zu spielen und andere die ganz woanders auch dafuer arbeiten muessen. So wie ihr das macht kann man dieses Spiel nicht spielen. Man braucht Grundsaetze wo man hin will und was man verhindern muss, ihr habt scheins keines mehr von beiden, egal was zusammengebastelt wird auf dem Planeten, man macht einfach ein rpm draus und nennt es Linux. Was hier vorgeht hat eindeutig mehr mit Windows zu tun als mit Linux. Alles gut funktionierende und einfache ausbauen und ersetzen durch moeglichst staendig laufende Binaries, egal ob der Job den sie tun sollen schon fertig ist oder nicht (wickedd, systemd), voellig kranke und moeglichst lange Configs (grub2), EOL-Kernels (3.16.x), unausgegorene Filesysteme (BTRFS) denen man scheinbar kein /home anvertrauen kann, Oberflaechen (KDE) in denen kein Mensch Sprache oder Schriftgroesse aendern kann ohne drei Stunden Literatur zu waelzen. Aber Hauptsache die 1000 Laptops die damit installiert werden booten schnell, wen kuemmern die Millionen Internet-Server... Ihr seid dabei diese Distribution restlos kaputt zu machen und merkt es nicht mal, wo sind nur die guten Leute geblieben?

https://lwn.net/Articles/615173/ lesen.

Ich kann zwar Deinen Ärger verstehen, nur das ist ein OpenSource Projekt. Es steht Dir frei mit daran *mit* zuarbeiten oder Debian zu benutzen. Du könnstest mittels osc ein checkout von openssh machen und den Patch unter

http://sf.net/projects/mancha/files/misc/openssh-6.8p1-libwrap.diff

mit in das Paket einpflegen.

Es geht wirklich nicht darum was ich tun koennte, es geht darum dass jemand der mehr Gewicht in solchen Diskussionen haben sollte (und dafuer bezahlt wird) Einfluss darauf nimmt dass keine Features die viele Leute benutzen _ausgebaut_ werden, weil heutige Maintainer zu jung sind und vergessen haben wofuer sie mal waren, selbst keine Server warten und genau deshalb keinen Bezug mehr zur Anwendungs-Realitaet des gewarteten Codes haben. Es geht also nicht darum _etwas_ zu tun, sondern zu verhindern, dass jemand etwas kaputtschrumpft. _Nichts tun_ ist das was ich verlange, und das sollte nicht ganz so schwer sein wie _hinterher_ ein bereits zerstoertes Projekt zu forken.

...

...
...
...
Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall

Wie startest Du mit der Firewall ein Binary?

zypper se firewall

Das ist keine Antwort. Wie startest Du einen /bin/mail basierend auf einem ankommenden IP-Paket von dem Du nur die Zieladresse (die eigene) kennst und von dem Du die Source IP wissen willst? Und bitte nicht indem man alle Pakete durch systemd, journalctl, fail2ban durchschickt... Und uebrigens: es fehlt noch die Antwort auf die Frage wie Du libwrap mit "match" abbildest fuer ca 20 Adressen. Die Diskussionsmethode alte Fragen unter den Tisch zu kehren funktioniert bei mir nicht. Genau dieselben Fragen haette jemand stellen muessen nachdem er das erste Configfile von Grub2 gesehen hat. Wieviel laenger ist die grub2-config im Vergleich zu grub(1) bei gleicher Funktion? Welchen Sinn macht dieser Code ueberhaupt?

...

-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Dr. Werner Fink

20 May 20 May

06:56

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Tue, May 19, 2015 at 07:43:46PM +0200, Stephan von Krawczynski wrote:

...

Es geht wirklich nicht darum was ich tun koennte, es geht darum dass jemand der mehr Gewicht in solchen Diskussionen haben sollte (und dafuer bezahlt wird) Einfluss darauf nimmt dass keine Features die viele Leute benutzen _ausgebaut_ werden, weil heutige Maintainer zu jung sind und vergessen haben wofuer sie mal waren, selbst keine Server warten und genau deshalb keinen Bezug mehr zur Anwendungs-Realitaet des gewarteten Codes haben. Es geht also nicht darum _etwas_ zu tun, sondern zu verhindern, dass jemand etwas kaputtschrumpft. _Nichts tun_ ist das was ich verlange, und das sollte nicht ganz so schwer sein wie _hinterher_ ein bereits zerstoertes Projekt zu forken.

Wer wird hier für was bezahlt? Und wie jung Cristian ist, aber hier rummeckern ist IMHO schlechter Stil. Zumindest ein Bugreport und/oder ein Submitrequest wäre nett gewesen.

...

...
...
...
...
Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall

Wie startest Du mit der Firewall ein Binary?

zypper se firewall

Das ist keine Antwort. Wie startest Du einen /bin/mail basierend auf einem ankommenden IP-Paket von dem Du nur die Zieladresse (die eigene) kennst und von dem Du die Source IP wissen willst? Und bitte nicht indem man alle Pakete durch systemd, journalctl, fail2ban durchschickt...

Und uebrigens: es fehlt noch die Antwort auf die Frage wie Du libwrap mit "match" abbildest fuer ca 20 Adressen. Die Diskussionsmethode alte Fragen unter den Tisch zu kehren funktioniert bei mir nicht. Genau dieselben Fragen haette jemand stellen muessen nachdem er das erste Configfile von Grub2 gesehen hat. Wieviel laenger ist die grub2-config im Vergleich zu grub(1) bei gleicher Funktion? Welchen Sinn macht dieser Code ueberhaupt?

Der tcpwrapper ist etwas out of date, Du darfst gerne mal den Autor Wietse Venema fragen. Mit einer Firewall wie der SuSEfirewall2 kann man TCP and UDP Ports und ICMP direkt für bestimmte Adressen und/oder Adressbereiche sperren, ohne das im Userspace dafür Programme gestartet werden. Immerhin bietet letzteres ein perfektes Ziel für eine DOS-Attacke. Auch logging ist mit einer Firewall problemlos möglich. -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Stephan von Krawczynski

08:28

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Wed, 20 May 2015 08:56:06 +0200 "Dr. Werner Fink" wrote:

...

On Tue, May 19, 2015 at 07:43:46PM +0200, Stephan von Krawczynski wrote:

...
Es geht wirklich nicht darum was ich tun koennte, es geht darum dass jemand der mehr Gewicht in solchen Diskussionen haben sollte (und dafuer bezahlt wird) Einfluss darauf nimmt dass keine Features die viele Leute benutzen _ausgebaut_ werden, weil heutige Maintainer zu jung sind und vergessen haben wofuer sie mal waren, selbst keine Server warten und genau deshalb keinen Bezug mehr zur Anwendungs-Realitaet des gewarteten Codes haben. Es geht also nicht darum _etwas_ zu tun, sondern zu verhindern, dass jemand etwas kaputtschrumpft. _Nichts tun_ ist das was ich verlange, und das sollte nicht ganz so schwer sein wie _hinterher_ ein bereits zerstoertes Projekt zu forken.

Wer wird hier für was bezahlt? Und wie jung Cristian ist, aber hier rummeckern ist IMHO schlechter Stil. Zumindest ein Bugreport und/oder ein Submitrequest wäre nett gewesen.

Irgendwie war meine Annahme dass Leute die fuer SuSE arbeiten auch von der Firma bezahlt werden. Und Da SuSE nichts anderes macht als eine Linux-Distribution und zusaetzliche Services verkaufen koennte man schon meinen dass das irgendwie zusammenhaengt...? Immer wenn jemand vom Stil einer Diskussion zu reden beginnt sind die Argumente ausgegangen.

...

...
...
...
...
...
Hallo,

genau. Was mache ich jetzt damit?

sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW

Firewall

Wie startest Du mit der Firewall ein Binary?

zypper se firewall

Das ist keine Antwort. Wie startest Du einen /bin/mail basierend auf einem ankommenden IP-Paket von dem Du nur die Zieladresse (die eigene) kennst und von dem Du die Source IP wissen willst? Und bitte nicht indem man alle Pakete durch systemd, journalctl, fail2ban durchschickt...

Und uebrigens: es fehlt noch die Antwort auf die Frage wie Du libwrap mit "match" abbildest fuer ca 20 Adressen. Die Diskussionsmethode alte Fragen unter den Tisch zu kehren funktioniert bei mir nicht. Genau dieselben Fragen haette jemand stellen muessen nachdem er das erste Configfile von Grub2 gesehen hat. Wieviel laenger ist die grub2-config im Vergleich zu grub(1) bei gleicher Funktion? Welchen Sinn macht dieser Code ueberhaupt?

Der tcpwrapper ist etwas out of date, Du darfst gerne mal den Autor Wietse Venema fragen. Mit einer Firewall wie der SuSEfirewall2 kann man TCP and UDP Ports und ICMP direkt für bestimmte Adressen und/oder Adressbereiche sperren, ohne das im Userspace dafür Programme gestartet werden. Immerhin bietet letzteres ein perfektes Ziel für eine DOS-Attacke. Auch logging ist mit einer Firewall problemlos möglich.

Auch die Autoren von Songs koennen den Sinn in ihren Werken manchmal nicht gut ergruenden. Der Autor ist kein Massstab. Man muss das Werk abstrakt betrachten. Eine Firewall ist in der Risikobetrachtung eine nachrangige Funktion im Hinblick auf aktive Services. Wenn diese (Services) selbst immanent keinerlei Schutzmechanismen mehr enthalten die exakt abbilden koennen was libwrap tut (immer noch kein entsprechendes Match-Konstrukt gesehen) hat sich die Sicherheitssituation eindeutig verschlechtert. Du verkaufst es hier als Feature dass eine Firewall keine Userspace Prozesse starten kann, aber die Realitaet ist dass es Anwendungen gab und gibt (wie wir gesehen haben) die das bei libwrap nutzen. Es spielt dabei keine Rolle ob das Ziel einer DoS-Attacke sein kann, denn es muss keines sein - je nach Einsatzfall. Damit entscheidet der Benutzer wie er das einsetzt. Jetzt kann er gar nichts mehr einsetzen weil die Funktion weg ist. Irgendwie habt ihr zugelassen dass aus dem Auto der Blinker ausgebaut wird weil der Konstrukteur der Meinung war man koennte auch mit der Hand winken. Ihr seid einen Riesenschritt zurueck in der Entwicklung gegangen und unfaehig/unwillig das zu verstehen. Euch ist ganz offensichtlich auch nicht klar dass Sicherheitsfeatures umso besser und sinnvoller sind je einfacher sie zu verstehen sind. Ich behaupte libwrap versteht jeder nach 3 Minuten Erklaerung. Und ich behaupte weiter mindestens 50% der allein in dieser Mailingliste anwesenden verstehen nicht wie die Firewall in Linux wirklich funktioniert und koennen deswegen auch keinerlei Luecken darin sehen. Und das hier ist sowas wie die Anwender-Elite. Das ist eigentlich kein Beinbruch, auch von Autos versteht nur die Haelfte der Fahrer (hoechstens) wie sie funktionieren, aber man hat einen fuer jeden verstaendlichen Weg gefunden sie zu benutzen. Eine Firewall kann das nicht, man braucht dazu immer ein gehoeriges Vorwissen. Ihr habt den ersten Grundsatz im Linux-Universum gebrochen: "Keep it simple". Ich denke der Mann hat schon darueber nachgedacht bevor er das gesagt hat... -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

Dr. Werner Fink

09:05

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Wed, May 20, 2015 at 10:28:37AM +0200, Stephan von Krawczynski wrote:

...

On Wed, 20 May 2015 08:56:06 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 07:43:46PM +0200, Stephan von Krawczynski wrote:

...
Es geht wirklich nicht darum was ich tun koennte, es geht darum dass jemand der mehr Gewicht in solchen Diskussionen haben sollte (und dafuer bezahlt wird) Einfluss darauf nimmt dass keine Features die viele Leute benutzen _ausgebaut_ werden, weil heutige Maintainer zu jung sind und vergessen haben wofuer sie mal waren, selbst keine Server warten und genau deshalb keinen Bezug mehr zur Anwendungs-Realitaet des gewarteten Codes haben. Es geht also nicht darum _etwas_ zu tun, sondern zu verhindern, dass jemand etwas kaputtschrumpft. _Nichts tun_ ist das was ich verlange, und das sollte nicht ganz so schwer sein wie _hinterher_ ein bereits zerstoertes Projekt zu forken.

Wer wird hier für was bezahlt? Und wie jung Cristian ist, aber hier rummeckern ist IMHO schlechter Stil. Zumindest ein Bugreport und/oder ein Submitrequest wäre nett gewesen.

Irgendwie war meine Annahme dass Leute die fuer SuSE arbeiten auch von der Firma bezahlt werden. Und Da SuSE nichts anderes macht als eine Linux-Distribution und zusaetzliche Services verkaufen koennte man schon meinen dass das irgendwie zusammenhaengt...? Immer wenn jemand vom Stil einer Diskussion zu reden beginnt sind die Argumente ausgegangen.

Hmmm ... also openSUSE ist keine SLES und die Zeiten wo SUSE direkt CD oder DVD verkauft konnte und davon alles finanziert hatte, sind lange vorbei. Inzwischen macht das ein selbstständiger Fachbuchverlag und von jeder verkauften Version bekommt das openSUSE Projekt eine Spende. Und langsam habe ich keine Lust mehr auf Deine Diskussion.

...

...
Der tcpwrapper ist etwas out of date, Du darfst gerne mal den Autor Wietse Venema fragen. Mit einer Firewall wie der SuSEfirewall2 kann man TCP and UDP Ports und ICMP direkt für bestimmte Adressen und/oder Adressbereiche sperren, ohne das im Userspace dafür Programme gestartet werden. Immerhin bietet letzteres ein perfektes Ziel für eine DOS-Attacke. Auch logging ist mit einer Firewall problemlos möglich.

Auch die Autoren von Songs koennen den Sinn in ihren Werken manchmal nicht gut ergruenden. Der Autor ist kein Massstab. Man muss das Werk abstrakt betrachten. Eine Firewall ist in der Risikobetrachtung eine nachrangige Funktion im Hinblick auf aktive Services. Wenn diese (Services) selbst immanent keinerlei Schutzmechanismen mehr enthalten die exakt abbilden koennen was libwrap tut (immer noch kein entsprechendes Match-Konstrukt gesehen) hat sich die Sicherheitssituation eindeutig verschlechtert. Du verkaufst es hier als Feature dass eine Firewall keine Userspace Prozesse starten kann, aber die Realitaet ist dass es Anwendungen gab und gibt (wie wir gesehen haben) die das bei libwrap nutzen. Es spielt dabei keine Rolle ob das Ziel einer DoS-Attacke sein kann, denn es muss keines sein - je nach Einsatzfall. Damit entscheidet der Benutzer wie er das einsetzt. Jetzt kann er gar nichts mehr einsetzen weil die Funktion weg ist. Irgendwie habt ihr zugelassen dass aus dem Auto der Blinker ausgebaut wird weil der Konstrukteur der Meinung war man koennte auch mit der Hand winken. Ihr seid einen Riesenschritt zurueck in der Entwicklung gegangen und unfaehig/unwillig das zu verstehen. Euch ist ganz offensichtlich auch nicht klar dass Sicherheitsfeatures umso besser und sinnvoller sind je einfacher sie zu verstehen sind. Ich behaupte libwrap versteht jeder nach 3 Minuten Erklaerung. Und ich behaupte weiter mindestens 50% der allein in dieser Mailingliste anwesenden verstehen nicht wie die Firewall in Linux wirklich funktioniert und koennen deswegen auch keinerlei Luecken darin sehen. Und das hier ist sowas wie die Anwender-Elite. Das ist eigentlich kein Beinbruch, auch von Autos versteht nur die Haelfte der Fahrer (hoechstens) wie sie funktionieren, aber man hat einen fuer jeden verstaendlichen Weg gefunden sie zu benutzen. Eine Firewall kann das nicht, man braucht dazu immer ein gehoeriges Vorwissen. Ihr habt den ersten Grundsatz im Linux-Universum gebrochen: "Keep it simple". Ich denke der Mann hat schon darueber nachgedacht bevor er das gesagt hat...

Also hier gilt wohl eher "Keep it simple as possible", aber wie gesagt, openSUSE ist ein community project. Wenn Du Änderungen haben willst, dann bemühe zumindest den Bugzilla, Danke. Wenn Du yast2-firewall für zu kompliziert hälst, dann mache Bitte Vorschläge via Fate (https://features.opensuse.org/). -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Stephan von Krawczynski

09:25

New subject: [opensuse-de] 13.2 ignoriert hosts.allow/deny

On Wed, 20 May 2015 11:05:18 +0200 "Dr. Werner Fink" wrote:

...

On Wed, May 20, 2015 at 10:28:37AM +0200, Stephan von Krawczynski wrote:

...
On Wed, 20 May 2015 08:56:06 +0200 "Dr. Werner Fink" wrote:

...
On Tue, May 19, 2015 at 07:43:46PM +0200, Stephan von Krawczynski wrote:

...
Es geht wirklich nicht darum was ich tun koennte, es geht darum dass jemand der mehr Gewicht in solchen Diskussionen haben sollte (und dafuer bezahlt wird) Einfluss darauf nimmt dass keine Features die viele Leute benutzen _ausgebaut_ werden, weil heutige Maintainer zu jung sind und vergessen haben wofuer sie mal waren, selbst keine Server warten und genau deshalb keinen Bezug mehr zur Anwendungs-Realitaet des gewarteten Codes haben. Es geht also nicht darum _etwas_ zu tun, sondern zu verhindern, dass jemand etwas kaputtschrumpft. _Nichts tun_ ist das was ich verlange, und das sollte nicht ganz so schwer sein wie _hinterher_ ein bereits zerstoertes Projekt zu forken.

Wer wird hier für was bezahlt? Und wie jung Cristian ist, aber hier rummeckern ist IMHO schlechter Stil. Zumindest ein Bugreport und/oder ein Submitrequest wäre nett gewesen.

Irgendwie war meine Annahme dass Leute die fuer SuSE arbeiten auch von der Firma bezahlt werden. Und Da SuSE nichts anderes macht als eine Linux-Distribution und zusaetzliche Services verkaufen koennte man schon meinen dass das irgendwie zusammenhaengt...? Immer wenn jemand vom Stil einer Diskussion zu reden beginnt sind die Argumente ausgegangen.

Hmmm ... also openSUSE ist keine SLES und die Zeiten wo SUSE direkt CD oder DVD verkauft konnte und davon alles finanziert hatte, sind lange vorbei. Inzwischen macht das ein selbstständiger Fachbuchverlag und von jeder verkauften Version bekommt das openSUSE Projekt eine Spende. Und langsam habe ich keine Lust mehr auf Deine Diskussion.

...
...
Der tcpwrapper ist etwas out of date, Du darfst gerne mal den Autor Wietse Venema fragen. Mit einer Firewall wie der SuSEfirewall2 kann man TCP and UDP Ports und ICMP direkt für bestimmte Adressen und/oder Adressbereiche sperren, ohne das im Userspace dafür Programme gestartet werden. Immerhin bietet letzteres ein perfektes Ziel für eine DOS-Attacke. Auch logging ist mit einer Firewall problemlos möglich.

Auch die Autoren von Songs koennen den Sinn in ihren Werken manchmal nicht gut ergruenden. Der Autor ist kein Massstab. Man muss das Werk abstrakt betrachten. Eine Firewall ist in der Risikobetrachtung eine nachrangige Funktion im Hinblick auf aktive Services. Wenn diese (Services) selbst immanent keinerlei Schutzmechanismen mehr enthalten die exakt abbilden koennen was libwrap tut (immer noch kein entsprechendes Match-Konstrukt gesehen) hat sich die Sicherheitssituation eindeutig verschlechtert. Du verkaufst es hier als Feature dass eine Firewall keine Userspace Prozesse starten kann, aber die Realitaet ist dass es Anwendungen gab und gibt (wie wir gesehen haben) die das bei libwrap nutzen. Es spielt dabei keine Rolle ob das Ziel einer DoS-Attacke sein kann, denn es muss keines sein - je nach Einsatzfall. Damit entscheidet der Benutzer wie er das einsetzt. Jetzt kann er gar nichts mehr einsetzen weil die Funktion weg ist. Irgendwie habt ihr zugelassen dass aus dem Auto der Blinker ausgebaut wird weil der Konstrukteur der Meinung war man koennte auch mit der Hand winken. Ihr seid einen Riesenschritt zurueck in der Entwicklung gegangen und unfaehig/unwillig das zu verstehen. Euch ist ganz offensichtlich auch nicht klar dass Sicherheitsfeatures umso besser und sinnvoller sind je einfacher sie zu verstehen sind. Ich behaupte libwrap versteht jeder nach 3 Minuten Erklaerung. Und ich behaupte weiter mindestens 50% der allein in dieser Mailingliste anwesenden verstehen nicht wie die Firewall in Linux wirklich funktioniert und koennen deswegen auch keinerlei Luecken darin sehen. Und das hier ist sowas wie die Anwender-Elite. Das ist eigentlich kein Beinbruch, auch von Autos versteht nur die Haelfte der Fahrer (hoechstens) wie sie funktionieren, aber man hat einen fuer jeden verstaendlichen Weg gefunden sie zu benutzen. Eine Firewall kann das nicht, man braucht dazu immer ein gehoeriges Vorwissen. Ihr habt den ersten Grundsatz im Linux-Universum gebrochen: "Keep it simple". Ich denke der Mann hat schon darueber nachgedacht bevor er das gesagt hat...

Also hier gilt wohl eher "Keep it simple as possible", aber wie gesagt, openSUSE ist ein community project. Wenn Du Änderungen haben willst, dann bemühe zumindest den Bugzilla, Danke. Wenn Du yast2-firewall für zu kompliziert hälst, dann mache Bitte Vorschläge via Fate (https://features.opensuse.org/).

-- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

Abschliessend zu diesem Thread stelle ich fest: keine Antwort auf die Frage wie libwrap durch neue Config-Konstrukte ersetzt werden soll. Niemand ist verantwortlich, wir wuenschen keine weiteren Fragen zu Themen die uns ein Jahr lang selbst nicht aufgefallen sind. Danke. -- MfG, Stephan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org

3263

Age (days ago)

3265

Last active (days ago)

List overview

Download

18 comments

5 participants

participants (5)

Dr. Werner Fink
Ingo
Marcus Meissner
Miro Borik
Stephan von Krawczynski