Anzeige

 [IPSec] Unbekannte Server spammen /var/log/auth.log zu


Bratkartoffel

gebratene Kartoffel
Premium-User
#1
Servus,

habe seit ein paar Tage dutzende Einträge wie diese im Logbuch:

Code:
Jan  7 11:51:56 hades pluto[1552]: "iris"[2399] xxx.xxx.42.4 #2401: next payload type of ISAKMP Identification Payload has an unknown value: 217
Jan  7 11:51:56 hades pluto[1552]: "iris"[2399] xxx.xxx.42.4 #2401: probable authentication failure (mismatch of preshared secrets?): malformed payload in packet
Jan  7 11:51:56 hades pluto[1552]: | payload malformed after IV
Jan  7 11:51:56 hades pluto[1552]: |   49 f4 cd 8e  fd e9 94 74  11 3d 4c d0  03 16 c4 2f
Jan  7 11:51:56 hades pluto[1552]: |   d0 5a c5 7c
Jan  7 11:51:56 hades pluto[1552]: "iris"[2399] xxx.xxx.42.4 #2401: sending notification PAYLOAD_MALFORMED to xxx.xxx.42.4:500
oder

Code:
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring unknown Vendor ID payload [01528bbbc00696121849ab9a1c5b2a5100000001]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000009]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: received Vendor ID payload [RFC 3947] meth=109, but port floating is off
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port floating is off
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring Vendor ID payload [FRAGMENTATION]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring Vendor ID payload [Vid-Initial-Contact]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: ignoring Vendor ID payload [IKE CGA version 1]
Jan  7 11:02:57 hades pluto[1552]: packet from xxx.xxx.150.210:38981: af+type of ISAKMP Oakley attribute has an unknown value: 16384
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: responding to Main Mode from unknown peer xxx.xxx.150.210
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: OAKLEY_DES_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: no acceptable Oakley Transform
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210 #2396: sending notification NO_PROPOSAL_CHOSEN to xxx.xxx.150.210:38981
Jan  7 11:02:57 hades pluto[1552]: "iris"[2394] xxx.xxx.150.210: deleting connection "iris" instance with peer xxx.xxx.150.210 {isakmp=#0/ipsec=#0}
Das was mir am meisten Sorgen dabei macht, ist dass die IP's nicht zu meinen Servern gehören und IPSec somit eigentlich nicht aktiv sein sollte.
Versucht hier jemand ein DoS auf meinen IPSec Dienst? Der Hostname "iris" gehört einem Server von mir, nur die IP's die die Verbindung versuchen stimmen nicht.

Grüße,
BK
 

olqs

Erfahrenes Mitglied
#2
Schonmal mit whois nachgesehen wem die Quell IP gehört?

Entweder ists jemand der seinen Server falsch konfiguriert hat, oder jemand der probiert eine der Lücken in den Ipsec Implementierungen auszunutzen. Gibt ja immer wieder Lücken bei Strong-/Openswan, Cisco, ...
Jeder offene Serverport zieht Leute an, die testen ob du auch auf nem aktuellen Patchstand bist. :)

Sonst siehts eigentlich nicht schlecht aus. Der andere probiert die Verbindung, wird aber abgewiesen. Also "works as expected" :)

Falls der Besitzer der Quell IP nicht in ner Geschäftsbeziehung mit dir/euch steht, dann mal eine Mail an die abuse Adresse schicken. Vielleicht hilfts was.
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#3
Hi,

Danke für deine Antwort.

Hab schon per whois nachgeschaut, die IP's kommen aus Netzen die sicher nichts mit uns zu tun haben. Eine abuse-Mail werde ich mal aufsetzen, bezweifle aber dass ich da erhört werde. (Meine Erfahung: abuse@ ist ne Pipe auf /dev/null ;))

Dass er abgewiesen wird ist gut, aber mir wärs lieber er würde (da ich für die Gegen-IP keinen PSK hinterlegt habe) den Handshake schon früher, bzw. mit weniger Meldungen abbrechen. plutodebug=none hab ich schon gesetzt, kann ich Ausgabe etwas weiter minimieren?

Wie siehts bei sowas mit der Load aus? Ist der Handshake aufwendig? Lässt sich so ein DoS auf meine Server fahren?

Grüße,
BK
 

olqs

Erfahrenes Mitglied
#4
Ja, das normale Antwortverhalten auf eine abuse Mail ist: nix :)

Ob und wie man den Spam im Log verhindern kann, weiß ich hier leider nicht. Mache Ipsec hauptsächlich mit Cisco Geräten, nur zuhause habe ich eine Verbindung zwischen zwei strongswan Endpunkten stehen und da reichts wenns geht.

Ob das deinem Server schon Load technisch was ausmacht, kommt immer auf die Hardware drauf an und die Masse an. Ich würd hier die DoS gefahr allerdings eher gering einschätzen.
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#5
Hi,

so, konnte das Problem über den abuse-Kontakt klären. Hetzner reagierte darauf sogar und leitete die Info / Anfrage an den Kunden weiter.

Grüße,
BK
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#6
Hi,

leider ist das Problem doch noch nicht ganz behoben.
Der Ursprung des "Problems" liegt beim NTP-Pool Projekt (pool.ntp.org), wo meine Server hinterlegt sind. Wenn ein anderer Server sich per NTP die Zeit holen will, versuchen die meisten eine IPSec Verbindung zu mir.

Da ich gerne weiter meine Server für das Projekt zur Verfügung stellen würde, wollte ich per iptables die ungültigen Abfragen rausfiltern und nur IPSec Anfragen von meinen Servern annehmen. Folgender Ansatz:

Bash:
IPTABLES='/sbin/iptables'

#####################################
# block invalid ipsec requests
#####################################

# add chain
${IPTABLES} -N IPSEC

# allow hos1
${IPTABLES} -A IPSEC -s host1 -j ACCEPT

# allow host2
${IPTABLES} -A IPSEC -s host2 -j ACCEPT

# fail all other sources
${IPTABLES} -A IPSEC -j REJECT

# add chain to input
${IPTABLES} -A INPUT -p udp --dport isakmp -j IPSEC
Jedoch kappen mir die obigen Regeln nicht nur die anderen Server, sondern gleich alle IPSec Verbindungs-versuche:

Bash:
[root@iris:~] iptables -nvL INPUT
Chain INPUT (policy ACCEPT 108K packets, 8814K bytes)
 pkts bytes target     prot opt in     out     source               destination
   10  3456 IPSEC      udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:500

[root@iris:~] iptables -nvL IPSEC
Chain IPSEC (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       91.12x.xxx.xxx       0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       91.12x.xxx.xxx       0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       176.13.xxx.xxx      0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       127.0.1.1            0.0.0.0/0
   10  3456 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable
Warum greifen hier die ACCEPT Regeln nicht?

Grüße,
BK
 

Bratkartoffel

gebratene Kartoffel
Premium-User
#8
Hi,

Schande über mein Haupt... Ich hatte ne Änderung in der ipsec.conf gemacht, dadurch haben die Server nicht mal mehr versucht eine IPSec Verbindung aufzubauen, da ich hier nen Fehler drinnen hatte.

Nachdem ich die Config gefixt hatte, wurde wieder eine IPSec Verbindung versucht und somit griffen dann auch die iptables Regeln.

Grüße,
BK
 
Anzeige
Anzeige