Security Management

 View Only

IMPORTANT MODERATION NOTICE

This community is currently under full moderation, meaning  all posts will be reviewed before appearing in the community. Please expect a brief delay—there is no need to post multiple times. If your post is rejected, you'll receive an email outlining the reason(s). We've implemented full moderation to control spam. Thank you for your patience and participation.



  • 1.  ntp issue

    Posted 02-10-2014 13:42

    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


  • 2.  RE: ntp issue
    Best Answer

    Posted 02-10-2014 22:59

    @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/



  • 3.  RE: ntp issue

    Posted 02-11-2014 01:42

    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. 🙂



  • 4.  RE: ntp issue

    Posted 02-11-2014 06:48

    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!



  • 5.  RE: ntp issue

    Posted 02-11-2014 17:10

    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?

     



  • 6.  RE: ntp issue

    Posted 03-08-2014 02:32

    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!



  • 7.  RE: ntp issue

    Posted 03-08-2014 02:37

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



  • 8.  RE: ntp issue

    Posted 02-11-2014 17:58
    @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.