Security

Dear colleagues,

As you know, there is a funny new joke with ntp servers: http://www.kb.cert.org/vuls/id/348126.

I'd like to prevent my junos equipment from participation in this movement. 🙂

The problem is I can't neither set restictions nor disable monlist from cli.

What to do?

Thanks a lot!

#ntpsecurityddos

@melnik

 

You'll want to create a firewall filter and apply it to the loopback interface.  This should be done for all devices regardless anyway as a sort of "best practices" approach.

 

If you're not familiar with RE filters, there's a Day One book here: http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/

Thank you so much for a hint! I've done it this way:

 

family inet {
    filter the-firewall {
        term accept-ntp-from-friends {
            from {
                source-prefix-list {
                    my-networks;
                }
                destination-prefix-list {
                    me;
                }
                protocol udp;
                destination-port ntp;
            }
            then {
                log;
                accept;
            }
        }
        term reject-ntp-from-strangers {
            from {
                destination-prefix-list {
                    me;
                }
                protocol udp;
                destination-port ntp;
            }
            then {
                log;
                discard;
            }
        }
        term accept-everything-else {
            then accept;
        }
    }
}

 

unit 300 {
    family inet {
        filter {
            input the-firewall;
        }
        address *.*.*.*/24;
    }
}

 

Alas, my equipment doesn't support the "input-list" option to have chains of filters on an interface, so I had to mix NTP-filtering rules and "accept-everything-else" in a single filter. But it works. 🙂

Hi, @melnik!

 

This is the way most people perform their RE filters, by using multiple terms in a single filter.

 

I'm not sure what unit 300 is in your example, but you generally apply RE filters to your loopback interface (lo0.0), even if you don't have an address assigned there (which you should for a variety of reasons).  This makes it easy to filter NTP from every interface, not just on an interface-by-interface basis.  What happens if you or someone else adds another public-facing circuit but forgets all about the firewall filter?

 

Good luck!

Not to hijack the thread but can you elaborate on the comment "even if you don't have an address assigned there (which you should for a variety of reasons)."

 

I've read this a few places and want to know the reason why.  Is is clearly documented somewhere are is there a best practice for what addressing to utilize for this?

 

It seems I encountered a new problem. Today I'm getting NTP-requests, but the firewall doesn't catch them and that's what I see in tcpdump when I'm filtering it by "port 123":

 

12:22:51.547147 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.550681 In IP [|ip]
12:22:51.551550 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.553032 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.553515 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.560009 In IP [|ip]
12:22:51.562513 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.564885 In IP [|ip]
12:22:51.568434 In IP [|ip]
12:22:51.572323 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.574330 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.578353 In IP [|ip]
12:22:51.584414 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.588401 In IP [|ip]
12:22:51.593470 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.599083 In IP [|ip]
12:22:51.599443 In IP [|ip]
12:22:51.602268 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.603248 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.604686 In IP [|ip]
12:22:51.606172 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.614160 In IP [|ip]
12:22:51.615223 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.622988 In IP [|ip]
12:22:51.624183 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.634638 In IP [|ip]
12:22:51.635491 Out IP truncated-ip - 336 bytes missing! 193.151.90.254.ntp > ddos-guard.net.http: NTPv2, Reserved, length 368
12:22:51.641621 In IP [|ip]

 

How to understand where are incoming packets coming from?

 

An "extensive" view of such packet looks this way:

 

12:27:12.137484 In
Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 16
Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
Device Interface Index Extension TLV #1, length 2, value: 132
Logical Interface Index Extension TLV #4, length 4, value: 70
-----original packet-----
00:07:0d:xx:xx:xx > 2c:21:72:xx:xx:xx, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 240, id 10382, offset 0, flags [none], proto: UDP (17), length: 40) [|ip]

 

00:07:0d:xx:xx:xx is a MAC-address of my uplink, so I understand that these packets are coming from the Internet, but why I can't see their source-address and why the firewall can't catch it?

 

Thank you very much for hints!

Oh, yes, applying the filter to lo0 was a good idea. Thank you, it helps. 🙂

@jspanitz

The idea is that you generally have diverse paths through which a device can be managed. Using a loop back address, you can access your device via the same IP through any path. If you don't use a loop back and the interface IP you're trying to use to manage your device goes down, you won't be able to manage your device until that interface comes back up (or until you remember another interface IP).

There are other reasons, too. OSPF router ID (which you should set explicitly anyway--primarily because an OSPF router ID isn't actually an IP address). iBGP peering. Various other protocols.

It's really a best practice that makes your life a LOT easier. But it is by no means a requirement.