ErrLogin HTTP

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

ErrLogin HTTP

Beitrag von Jirka »

Hallo,

1781VA, Firmware 9.24.0443

Konfig:
Zugriffsrechte -> Von einer WAN-Schnittstelle -> HTTP -> nicht erlaubt
Ports -> HTTP -> 80
IP-Router -> Maskierung -> Port-Forwarding-Tabelle:
Aktiv: ja
Anfangs-/Endport: 80
Gegenstelle: leer und damit für beide Gegenstellen aktiv
Adresse: IP-Adresse des Webservers im entsprechenden lokalen Netz
Map-Port: 0
Protokoll: TCP
WAN-Adresse: 0.0.0.0

Frage: Wie kommen die nachfolgenden Einträge zustande?

Code: Alles auswählen

> ls st/conf/ev                                                               
                                                                              
Idx.  System-time           Event      Access IP-Address      Info1  Info2    
======------------------------------------------------------------------------
0b    02/24/2019 06:53:13   ErrLogin   HTTP   58.218.56.102                   
0c    02/24/2019 05:24:24   ErrLogin   HTTP   58.218.56.102                   
0d    02/23/2019 05:09:40   ErrLogin   HTTP   58.218.56.102                   
0e    02/23/2019 03:58:20   UplFailTo  Telnet 85.13.152.100   [0002] Firmware 
0f    02/23/2019 03:56:34   FwUplStart Telnet 85.13.152.100                   
10    02/23/2019 03:54:13   ErrLogin   HTTP   58.218.56.102                   
11    02/22/2019 10:42:54   ErrLogin   HTTP   217.7.102.170                   
12    02/21/2019 00:26:34   ErrLogin   HTTP   217.7.102.170                   
13    02/19/2019 15:00:30   ErrLogin   HTTP   222.186.138.11                  
14    02/19/2019 12:39:51   ErrLogin   HTTP   222.186.138.11                  
15    02/19/2019 11:04:38   ErrLogin   HTTP   222.186.138.11                  
16    02/18/2019 15:02:00   ErrLogin   HTTP   218.60.67.79                    
17    02/16/2019 15:19:41   ErrLogin   HTTP   218.60.67.79                    
18    02/16/2019 13:08:31   ErrLogin   HTTP   185.181.9.121                   
19    02/16/2019 12:53:23   ErrLogin   HTTP   185.181.9.121                   
1a    02/16/2019 05:46:29   ErrLogin   HTTP   221.229.162.245                 
Im Syslog steht das Gleiche (nur mit etwas anderen Zeiten, vermutlich wird die eine Zeit korrigiert, die andere nicht):

Code: Alles auswählen

2369       2019-02-24 06:53:17    AUTHPRIV  Alarm      Login from 58.218.56.102 via HTTP failed
Wenn ich auf das Gerät per HTTPS zugreife und ein falsches Passwort eingebe, steht ein Eintrag mit HTTPS drin, das kann also nicht sein. (Für HTTPS wird nicht der Standardport verwendet, weil darüber auch von extern auf das Gerät zugegriffen wird und der Port 443 natürlich wieder auf den Webserver weitergeleitet wird.)

Vielen Dank und viele Grüße,
Jirka
Zuletzt geändert von Jirka am 25 Feb 2019, 15:35, insgesamt 1-mal geändert.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: ErrLogin HTTP

Beitrag von backslash »

Hi Jirka,

ist denn die Gegenstelle, über die die Anfrage reinkommt, überhaupt maskiert? Ein Portforwarding funktioniert nur auf maskierten (WAN-) Gegenstellen...

Achtung: Das Maskierungsflag in der Routing-Tabelle bezieht sich immer auf die (WAN-) Gegenstelle - und da ist das erste Vorkommen in der Routing-Tabelle ausschlaggebend. Wenn du zwar an der Default-Route die Maskierungsoption gesetzt hast, dann aber eine weitere Route zur gleichen Gegenstelle eingetragen und dort die Option nicht gesetzt hast, dann ist die Gegenstelle unmaskiert...

Gruß
Backslash
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: ErrLogin HTTP

Beitrag von Jirka »

Hallo Backslash,

erst mal vielen Dank für Deine Ideen, aber beide (WAN-)Gegenstellen sind maskiert. Eindeutig. Über die von Dir beschriebenen "Eigenheiten" des Maskierungsflags in der Routing-Tabelle weiß ich Bescheid.

Wo sehe ich denn, über welche Gegenstelle die Anfrage reinkommt? Wohl nur in einem entsprechenden Trace, oder?

Irgendwie habe ich keine Ideen, wie es dazu kommen kann.
Ansonsten ist nur noch eine VPN-Gegenstelle, aber die verbindet nur LAN-LAN (über einen anderen LANCOM, also das ist auch alles ok).

Viele Grüße,
Jirka
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Re: ErrLogin HTTP

Beitrag von backslash »

Hi Jirka,

bei einer 9.24 fällt es mir schwer, einen Trace zu benennen - außer dem Ethernet- VDSL-Data- oder VPN-Packet-Trace - jenachdem, von wo die Anfrage kommt. In der 10.20 gäbe es wenigstens den IPv4-Host-Trace, der alles mitschneidet, was an das LANCOM selbst gerichtet ist.

Aber wie ist eigentlich das zu verstehen:
Wenn ich auf das Gerät per HTTPS zugreife und ein falsches Passwort eingebe, steht ein Eintrag mit HTTPS drin, das kann also nicht sein.
Kommst du da vom LAN? Ist die Firmware, die du gerade nutzt, mal wieder eine, in der Zugriff vom LAN auf die Maskierungsadresse gefolgt vom einem Portforwarding nicht funktioniert? Oder hast du das vom WAN aus getestet? Falls du letzteres getan hast, dann stimmt doch was mit der Maskierung der WAN-Verbindungen nicht...

Gruß
Backslash
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: ErrLogin HTTP

Beitrag von Jirka »

Hallo Backslash,
backslash hat geschrieben: 26 Feb 2019, 11:19bei einer 9.24 fällt es mir schwer, einen Trace zu benennen - außer dem Ethernet- VDSL-Data- oder VPN-Packet-Trace - jenachdem, von wo die Anfrage kommt.
also VPN schließe ich eigentlich aus, weil das eine klassische LAN(COM)-LAN(COM)-Kopplung ist, wo in der SA auch wirklich nur die beiden lokalen Intranets drin stehen. Bleibt also nur die VDSL-WAN-Verbindung und die Ethernet-WAN-Verbindung.
backslash hat geschrieben: 26 Feb 2019, 11:19Aber wie ist eigentlich das zu verstehen:
Wenn ich auf das Gerät per HTTPS zugreife und ein falsches Passwort eingebe, steht ein Eintrag mit HTTPS drin, das kann also nicht sein.
Das war ein Test, um Zugriffe per HTTPS als Ursache für diesen Fehlereintrag auszuschließen (bzw. genauer diese Fehlereinträge).
Hintergrund: Bei manchen Sachen nimmt man es bei LANCOM nicht ganz so genau bzw. ist nicht alles ganz sauber implementiert. Wenn man weiß, dass das so ist und wo das so ist, dann kann ich damit aber gut leben. Beispiel: Das Gerät (siehe auch im Code-Fenster ganz oben) holt sich per Cron-Job samstags um 03:56 Uhr eine Firmware per HTTP ("LoadFirmware"). Zwar läuft der Cron-Job vielleicht als "virtuelle" Telnet-Session, das Gerät lädt die Firmware aber per HTTP. Folglich sollte nach meinem Empfinden da auch HTTP stehen, tut es aber nicht. Denn der Firmware-Upload, der da scheitert, scheitert ja auf HTTP und nicht auf Telnet. Aber, so schrieb ein hier im Forum genauso engagierter Mitarbeiter wie Du, das ist wohl nicht so einfach zu ändern. Von daher: OK! Zurück zum Thema: Nun könnte es ja sein, dass LANCOM HTTPS und HTTP in eine Kategorie namens HTTP packt. D. h. wenn ich per HTTPS auf das Gerät zugreife und versuche mich mit falschen Passwort einzuloggen, dann steht da HTTP. Dem ist aber nicht so, denn dieser Test hat ergeben, dass dann HTTPS dort steht. Folglich kann man das also wohl ausschließen. Und so war das zu verstehen.
backslash hat geschrieben: 26 Feb 2019, 11:19Kommst du da vom LAN?
Nein, von WAN-Seite.
backslash hat geschrieben: 26 Feb 2019, 11:19Ist die Firmware, die du gerade nutzt, mal wieder eine, in der Zugriff vom LAN auf die Maskierungsadresse gefolgt vom einem Portforwarding nicht funktioniert? Oder hast du das vom WAN aus getestet?
Ich habe das von WAN-Seite getestet.
Ich gebe im Browser https:// gefolgt von der festen IP-Adresse der VDSL-Verbindung und : Port ein und gebe ein falsches Passwort ein, im Eventlog steht dann:

Code: Alles auswählen

02    02/26/2019 13:05:47   ErrLogin          HTTPS        217.230.176.5
(Eintrag Nr. 01 ist meine aktuelle SSH-Session)
Da steht HTTPS.
backslash hat geschrieben: 26 Feb 2019, 11:19Falls du letzteres getan hast, dann stimmt doch was mit der Maskierung der WAN-Verbindungen nicht...
Hier bitte die Routing-Tabelle (anonymisiert ist nur das XY):

Code: Alles auswählen

root@XY-Zentrale:/Setup/IP-Router/IP-Routing-Table                                                                    
> l                                                                                                                   
                                                                                                                      
IP-Address      IP-Netmask      Rtg-tag Peer-or-IP    Distance Masquerade Active Comment                              
========================================------------------------------------------------------------------------------
192.168.1.254   255.255.255.255 1       JREIMER       0        No         Yes    VPN-Client JReimer                   
192.168.178.1   255.255.255.255 1       KABEL_D       0        on         Yes    zur FRITZ!Box von KDG                
192.168.2.0     255.255.255.0   1       XY-LAGER      0        No         Yes    VPN-Verbindung zum Lager             
192.168.3.0     255.255.255.0   1       XY-HOME       0        No         Yes                                         
192.168.4.0     255.255.255.0   1       XY-WOELMSDORF 0        No         Yes                                         
192.168.0.0     255.255.0.0     0       0.0.0.0       0        No         Yes    block private networks: 192.168.x.y  
172.16.0.0      255.240.0.0     0       0.0.0.0       0        No         Yes    block private networks: 172.16-31.x.y
10.0.0.0        255.0.0.0       0       0.0.0.0       0        No         Yes    block private network: 10.x.y.z      
224.0.0.0       224.0.0.0       0       0.0.0.0       0        No         Yes    block multicasts: 224-255.x.y.z      
255.255.255.255 0.0.0.0         12      EASYBELL      0        on         Yes    explizit ueber EASYBELL              
255.255.255.255 0.0.0.0         11      KABEL_D       0        on         Yes    explizit ueber Kabel_D               
255.255.255.255 0.0.0.0         0       KABEL_D       0        on         Yes    Defaultroute                         
Vielen Dank und viele Grüße,
Jirka
Antworten