ntp aus base konfigurieren nach abuse Meldung

peterle

peterle

Forenkasper
Moien, Moien,

ich habe da einige abuse Meldungen bekommen, daß mein ntpd Mist machen würde:
Code: 
You are running a public NTP server that participated a very large-scale at=
tack against a customer of ours today, generating UDP responses to spoofed =
requests with bogus timestamps that claimed to be from the attack target. Y=
our server was particularly active in the attack, sending a significant por=
tion of the attack traffic we saw.

Please consider reconfiguring your NTP server in one or more of these ways:

- Set your NTP installation to act as a client only. With ntpd, that can be=
done with "restrict default ignore" in /etc/ntp.conf; other servers should=
have a similar configuration option. A firewall rule to block UDP to the p=
ublic IP address on port 123 would also work for this. More information can=
be found here: https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp=
-template.html
- Adjust your firewall or NTP server configuration so that it only serves y=
our customers and does not respond to outside IP addresses=20
- Rate-limit responses to individual source IP addresses, silently discardi=
ng those that exceed a low number, such as one request per IP address per s=
econd
- Limit queries to TCP-only
- Ignore particularly unlikely queries, such as those representing dates fa=
r in the future or past
- Limit the size of allowed responses; today's were 440 bytes, which were v=
ery large

Example NTP responses from your host during this attack are given below. Ti=
mes are CST (UTC-6), and the date is 2013-12-26.

23:27:05.618460 IP (tos 0x0, ttl 51, id 13194, offset 0, flags [none], prot=
o UDP (17), length 468) XXX.XXX.XXX.XXX.123 > YYY.YYY.YYY.YYY.123: NTPv2, length=
440
        Reserved, Leap indicator: clock unsynchronized (192), Stratum 0, poll 3s, =
precision 42
        Root Delay: 6.001098, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000111
          Originator Timestamp: 1247507655.734990715 (2075/08/19 20:22:31)
          Receive Timestamp:    1.001877248 (2036/02/07 01:28:17)
          Transmit Timestamp:  0.000000000
            Originator - Receive Timestamp:  -1247507654.733113467
            Originator - Transmit Timestamp: -1247507655.734990715
        0x0000:  4500 01d4 338a 0000 3311 7d01 bc28 5a43  E...3...3.}..(ZC
        0x0010:  4a5b 74c7 007b 007b 01c0 db92 d700 032a  J[t..{.{.......*
        0x0020:  0006 0048 0000 0000 0000 0000 0000 0000  ...H............
        0x0030:  0000 01e0 4a5b 74c7 bc28 5a43 0000 0001  ....J[t..(ZC....
        0x0040:  007b 0702 0000 0000 0000 0000            .{..........

Nun könnte ich mir das mit einer Standardeinstellung des ntpd noch vorstellen, aber mit einem restrict default und nur einer Freigabe für localhost nicht mehr.

Trotzdem bekomme ich scheinbar weiter diese Meldungen.

Was sind denn Eure besten Ideen dazu - ich bin langsam ratlos.
 
Verwende OpenNTP. Diesen kannst du an ein beliebiges Interface heften z.B. localhost. Dann läuft er nur darauf.
 
Nein, ist es nicht. Die Attacke trifft im Moment praktisch alle, die ntpd laufen lassen. Egal ob FreeBSD, Linux oder Schlimmeres. Worldi nennt die Lösung, aber sie ist leider nicht perfekt. Statt der kompletten Monitor-Liste wird dann nur noch ein "geht nicht"-String zurückgegeben. Ich habe:

1. NTP in der /etc/ntp.conf frisiert:
Code: 
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0

disable monitor

2. Den Firewall-Hammer geschwungen. Port 123 eingehend geblockt:
Code: 
# NTP Sicherung (muss vor NAT)
$cmd add 30 allow udp from me to any 123 out via $lan_if uid root keep-state
$cmd add 40 deny udp from any to any 123
 
Habe ich das denn richtig verstanden, daß aktuell ein störungsfreier Betrieb eines offenen ntpd nicht möglich ist?
 
Dennoch, ist seit dem Patch Ruhe im Karton. Zumindest bei mir.
In STABLE 10 wurde die ntp.conf ebenfalls verändert ;)
http://svnweb.freebsd.org/base/stable/10/etc/ntp.conf?r1=256281&r2=259974

EDIT: hier nochmal zum Vergleich
VORHER
Code: 
                    /0  /1  /2  /3  /4  /5  /6  /7  /8  /9  /10
    Load Average

      Interface          Traffic              Peak                Total
            lo0  in      0.000 KB/s          0.019 KB/s          17.410 KB
                out    0.000 KB/s          0.019 KB/s          17.410 KB

            re0  in    33.560 KB/s        71.959 KB/s          913.252 MB
                out    1.048 MB/s          9.735 MB/s          56.784 GB
NACHHER
Code: 
                    /0  /1  /2  /3  /4  /5  /6  /7  /8  /9  /10
    Load Average

      Interface          Traffic              Peak                Total
            lo0  in      0.000 KB/s          0.000 KB/s            1.199 KB
                out    0.000 KB/s          0.000 KB/s            1.199 KB

            re0  in    27.499 KB/s        32.648 KB/s          51.816 MB
                out    0.169 KB/s          0.239 KB/s          137.789 KB
 
peterle schrieb:
Habe ich das denn richtig verstanden, daß aktuell ein störungsfreier Betrieb eines offenen ntpd nicht möglich ist?
Zum Vergrößern anklicken....
Ich würde sagen ja. Solange ntpd nicht auf Localhost begrenzt wird, wird er auch immer auf das Monitor-Kommando antworten. Schaltet man es ab, verringert sich der String nur so sehr, dass die Attacke sich de facto nicht mehr lohnt. Aber das dürfte den Kiddies egal sein, sie bomben dennoch weiter und sendest Pakete ans Ziel der Attacke. Angeblich gibt es einen ntpd, der gar nichts mehr sendet, aber die Version ist noch nicht in FreeBSD angekommen. Du könntest also manuell patchen oder dir mal OpenBSDs openntpd anschauen.
 
Das ist ja irgendwie alles frustrierend - den ntpd aus base bekommt man scheinbar ohne firewall Gehampel nicht von der ausegehenden Adresse genommen. Frei nach dem Motto von Reinhard Mey "Irgendwas lauscht irgendwo immer!"

Openntpd ist knackig und schlicht, aber so schlicht, daß man unter FreeBSD außer Aus- und Einschalten scheinbar nichts damit machen oder von außen kontrollieren kann.

Wie gehen denn eigentlich die Server im pool.ntp.org damit um, daß sie permanent mit solchem Mist beschäftigt werden?
 
Hier kann man das Drama schön sehen. Etwa 24h nach dem Setzen der Regel:
Code: 
00030    2273    172748 allow udp from me to any dst-port 123 out via re0 uid root keep-state
00040 3455549 124400316 deny udp from any to any dst-port 123
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben