NTP security
Hi, I've installed NTP daemon on my firewall (with sync to external machine) and on all internal machines (with sync to my firewall). I found that this had opend port 123/udp on my firewall, so now everybody from the net can use my machine as a server. I have nothing against this as long as this is secure. Is it ? If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). Best regards, Piotr Tarnowski --- Wirtualny Wymiar Festiwalu Reklamy TYTANY 2001 http://tytany.wp.pl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
In message [EMAIL PROTECTED], Jim Breton writes: On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: Actually we trap illegal packets like this one in I15lospoof.def. :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address :#: over a non-'lo' interface Double-check that against the original question: "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" Notice he said "_to_ 127.0.0.0/8" and not "_from_" which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question. Ummm, the kernel and every router and swtich on the market will drop 127.0.0.0/8 packets when they see them, unless they're on the lo interface. They're invalid packets. Similarly with 10.0.0.0/24, 192.168.0.0/16 and that other one in 160 something. There's no way to route such a packet to your machine, unless you're on some sort of point-to-point link that the attacker can just throw packets down. That may be a risk there, but I doubt it. Here's the relevant section from the kernel source (arp.c:656): /* * Check for bad requests for 127.x.x.x and requests for multicast * addresses. If this is one such, delete it. */ if (LOOPBACK(tip) || MULTICAST(tip)) goto out; If the kernel recieves an arp request for a 127.x.x.x address it never responds, so the connecting machine never gets a HW address to connect to. -- Ted Cabeen http://www.pobox.com/~secabeen [EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] "I have taken all knowledge to be my province." -F. Bacon [EMAIL PROTECTED] "Human kind cannot bear very much reality."-T.S.Eliot[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
Maybe use tcp wrappers? That's how I'd do it. -rishi On Sat, 10 Mar 2001, Jamie Heilman wrote: Piotr Tarnowski wrote: If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). To the best of my knowledge you can't natively (in the application) control access at the transport level, which is unfortunate. You can at the protocol level however. Get the NTP documentation and read about the authentication options and the access control options. To control access at the transport level you will have to use firewalling rules. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway."-Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
Hello "is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ?" On Sat, Mar 10, 2001 at 08:52:08AM -0600, Ted Cabeen wrote: Ummm, the kernel and every router and swtich on the market will drop 127.0.0.0/8 packets when they see them, unless they're on the lo interface. No. On many routers you have to specify *explicit* spoofing filters. AFAIK even on CISCO routers. * Check for bad requests for 127.x.x.x and requests for multicast * addresses. If this is one such, delete it. This seems irrelevant to me. As the attacker has per definition on the same network (else 127/8 IP would have to get routed) he could make an ARP request for the MAC on the victim's real IP and then send spoofed packets with the 127/8 as target IP and the just fetched MAC address for layer#2 transport. This would exploit the discussed "hole" without needing ARP requests at all. bye, -chrisitan- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: No. On many routers you have to specify *explicit* spoofing filters. AFAIK even on CISCO routers. Really? That's interesting. Does it ship with sensible defaults at the least? Can't tell. I'm not the cisco specialist, just saw many of our configurations where it was explicitly given. But nevertheless as there is no technical need to filter those bad addresses I would hold my statement for true just to be sure :-) -christian- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
Jamie Heilman wrote: So what is the most secure way of syncing time on a server ? Coupling your server directly to an atomic clock, or some other source of "hard" time, yeilds no network reliance at all, and is the most secure way. Using bug free software is the most secure way to synchronize over a network. ntpd could probably benefit from a good auditing as it is a reference implmentation and those tend to get a rather unwieldy code-base. (BIND being a prime example) See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable atomic clock radio receiver. It has a 3V inverted TTL RS-232 link that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Last I knew the ntp daemon knew how to talk to this guy. It's available as a board set or in cases with proper RS-232 signal levels, power supply, etc. I noticed that /etc/services has a tcp entry for ntp. Is there any way (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. Actually it isn't. A bi-directional link is usually needed, but it seams the latest version also supports connecting to a multicast network for broadcasting the current time or for receiving it. In this case there is an unknown amount of network lag between the transmitter and receiver. For most computers this isn't a problem as it's unlikely the lag will be over 500 ms. Most computers only need 1 second accuracy if that even. -- | Bryan Andersen | [EMAIL PROTECTED] | http://www.nerdvest.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NTP security
See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable atomic clock radio receiver. It has a 3V inverted TTL RS-232 link that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Thats pretty snazzy. Actually it isn't. A bi-directional link is usually needed, but it Ah I was making my observation based on that NTP seems to be designed around a connectionless protocol that structures itself in a tree-ish format, kinda like DNS, and that a connection based protocol would make the structure too unwieldy. Granted DNS does do some data transfer over TCP but its not generally needed during normal operation. At any rate, it couldn't be done without modifiing the code, and finding somebody else to peer with who also had a modified server. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NTP security
Hi, I've installed NTP daemon on my firewall (with sync to external machine) and on all internal machines (with sync to my firewall). I found that this had opend port 123/udp on my firewall, so now everybody from the net can use my machine as a server. I have nothing against this as long as this is secure. Is it ? If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). Best regards, Piotr Tarnowski --- Wirtualny Wymiar Festiwalu Reklamy TYTANY 2001 http://tytany.wp.pl
Re: NTP security
Piotr Tarnowski wrote: If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). To the best of my knowledge you can't natively (in the application) control access at the transport level, which is unfortunate. You can at the protocol level however. Get the NTP documentation and read about the authentication options and the access control options. To control access at the transport level you will have to use firewalling rules. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly
Re: 127.0.0.0/8 addresses from the network
In message [EMAIL PROTECTED], Jim Breton writes: On Fri, Mar 09, 2001 at 10:09:13PM -0600, Ted Cabeen wrote: Actually we trap illegal packets like this one in I15lospoof.def. :#: Deny and log all packets trying to come in from a 127.0.0.0/8 address :#: over a non-'lo' interface Double-check that against the original question: is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ? Notice he said _to_ 127.0.0.0/8 and not _from_ which is what I15lospoof.def blocks. I made the same mistake in my first post, then re-read his question. Ummm, the kernel and every router and swtich on the market will drop 127.0.0.0/8 packets when they see them, unless they're on the lo interface. They're invalid packets. Similarly with 10.0.0.0/24, 192.168.0.0/16 and that other one in 160 something. There's no way to route such a packet to your machine, unless you're on some sort of point-to-point link that the attacker can just throw packets down. That may be a risk there, but I doubt it. Here's the relevant section from the kernel source (arp.c:656): /* * Check for bad requests for 127.x.x.x and requests for multicast * addresses. If this is one such, delete it. */ if (LOOPBACK(tip) || MULTICAST(tip)) goto out; If the kernel recieves an arp request for a 127.x.x.x address it never responds, so the connecting machine never gets a HW address to connect to. -- Ted Cabeen http://www.pobox.com/~secabeen [EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED]
Re: NTP security
Maybe use tcp wrappers? That's how I'd do it. -rishi On Sat, 10 Mar 2001, Jamie Heilman wrote: Piotr Tarnowski wrote: If not can I limit allowed clients somehow ? (I noticed that DENY on ipchains to others than my reference external server limits ntptrace usage). To the best of my knowledge you can't natively (in the application) control access at the transport level, which is unfortunate. You can at the protocol level however. Get the NTP documentation and read about the authentication options and the access control options. To control access at the transport level you will have to use firewalling rules. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway.-Holly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
Hello is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ? On Sat, Mar 10, 2001 at 08:52:08AM -0600, Ted Cabeen wrote: Ummm, the kernel and every router and swtich on the market will drop 127.0.0.0/8 packets when they see them, unless they're on the lo interface. No. On many routers you have to specify *explicit* spoofing filters. AFAIK even on CISCO routers. * Check for bad requests for 127.x.x.x and requests for multicast * addresses. If this is one such, delete it. This seems irrelevant to me. As the attacker has per definition on the same network (else 127/8 IP would have to get routed) he could make an ARP request for the MAC on the victim's real IP and then send spoofed packets with the 127/8 as target IP and the just fetched MAC address for layer#2 transport. This would exploit the discussed hole without needing ARP requests at all. bye, -chrisitan- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified
Re: 127.0.0.0/8 addresses from the network
In message [EMAIL PROTECTED], Christian Hammers writes: Hello is debian protected beforeconnecting from remote hosts to address 127.0.0.0/8 ? On Sat, Mar 10, 2001 at 08:52:08AM -0600, Ted Cabeen wrote: Ummm, the kernel and every router and swtich on the market will drop 127.0.0.0/8 packets when they see them, unless they're on the lo interface. No. On many routers you have to specify *explicit* spoofing filters. AFAIK even on CISCO routers. Really? That's interesting. Does it ship with sensible defaults at the least? * Check for bad requests for 127.x.x.x and requests for multicast * addresses. If this is one such, delete it. This seems irrelevant to me. As the attacker has per definition on the same network (else 127/8 IP would have to get routed) he could make an ARP request for the MAC on the victim's real IP and then send spoofed packets with the 127/8 as target IP and the just fetched MAC address for layer#2 transport. This would exploit the discussed hole without needing ARP requests at all. True enough. Time to go back in the kernel... Here it is. From route.c:1134 if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr)) goto martian_source; if (daddr == 0x || (saddr == 0 daddr == 0)) goto brd_input; /* Accept zero addresses only to limited broadcast; * I even do not know to fix it or not. Waiting for complains :-) */ if (ZERONET(saddr)) goto martian_source; if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr)) goto martian_destination; This is part of the routing check for incoming packets. It should take care of the problem being discussed. :) (I haven't tested this section of the code, but it should prevent that kind of attack, I think) -- Ted Cabeen http://www.pobox.com/~secabeen [EMAIL PROTECTED] Check Website or Keyserver for PGP/GPG Key BA0349D2 [EMAIL PROTECTED] I have taken all knowledge to be my province. -F. Bacon [EMAIL PROTECTED] Human kind cannot bear very much reality.-T.S.Eliot[EMAIL PROTECTED]
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: No. On many routers you have to specify *explicit* spoofing filters. AFAIK even on CISCO routers. Really? That's interesting. Does it ship with sensible defaults at the least? Can't tell. I'm not the cisco specialist, just saw many of our configurations where it was explicitly given. But nevertheless as there is no technical need to filter those bad addresses I would hold my statement for true just to be sure :-) -christian- -- Christian HammersWESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet Security for ProfessionalsFax 0241/911879 WESTEND ist CISCO Systems Partner - Premium Certified
Re: 127.0.0.0/8 addresses from the network
On Sat, Mar 10, 2001 at 10:22:48AM -0600, Ted Cabeen wrote: if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr)) goto martian_destination; This is part of the routing check for incoming packets. It should take care of the problem being discussed. :) (I haven't tested this section of the code, but it should prevent that kind of attack, I think) It should yes, however see the recent thread on Bugtraq about this issue. Also since log_martians is not enabled by default (unless your distro does so, and afaict potato at least does not) you will never hear a word about these packets. Logging them would be nice. Even with log_martians enabled, it doesn't tell you anything about the packet other than src, dst, and iface. Further, I'm not sure the martian code would stop a packet from landing on an internal interface other than loopback (again see the Bugtraq discussion) which is why we should (and do) filter the destination addresses of incoming packets as well as the source addresses. Thanks.
Re: NTP security
Rishi L Khan wrote: Maybe use tcp wrappers? That's how I'd do it. Nope, ntpd doesn't link against libwrap and can't be run out of inetd. -- Jamie Heilman http://audible.transient.net/~jamie/ I was in love once -- a Sinclair ZX-81. People said, No, Holly, she's not for you. She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway. -Holly
Re: NTP security
So what is the most secure way of syncing time on a server ? Coupling your server directly to an atomic clock, or some other source of hard time, yeilds no network reliance at all, and is the most secure way. Using bug free software is the most secure way to synchronize over a network. ntpd could probably benefit from a good auditing as it is a reference implmentation and those tend to get a rather unwieldy code-base. (BIND being a prime example) I noticed that /etc/services has a tcp entry for ntp. Is there any way (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. -- Jamie Heilman http://audible.transient.net/~jamie/ Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution. -Sathington Willoughby
Re: NTP security
Jamie Heilman wrote: So what is the most secure way of syncing time on a server ? Coupling your server directly to an atomic clock, or some other source of hard time, yeilds no network reliance at all, and is the most secure way. Using bug free software is the most secure way to synchronize over a network. ntpd could probably benefit from a good auditing as it is a reference implmentation and those tend to get a rather unwieldy code-base. (BIND being a prime example) See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable atomic clock radio receiver. It has a 3V inverted TTL RS-232 link that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Last I knew the ntp daemon knew how to talk to this guy. It's available as a board set or in cases with proper RS-232 signal levels, power supply, etc. I noticed that /etc/services has a tcp entry for ntp. Is there any way (short of changing the code) to coax ntp to use tcp instead of udp ? No, UDP is intrinsic to how NTP works. Actually it isn't. A bi-directional link is usually needed, but it seams the latest version also supports connecting to a multicast network for broadcasting the current time or for receiving it. In this case there is an unknown amount of network lag between the transmitter and receiver. For most computers this isn't a problem as it's unlikely the lag will be over 500 ms. Most computers only need 1 second accuracy if that even. -- | Bryan Andersen | [EMAIL PROTECTED] | http://www.nerdvest.com | | Buzzwords are like annoying little flies that deserve to be swatted. | | -Bryan Andersen|
Re: NTP security
See Ultra-Link, http://www.ulio.com/ for a low cost battery powerable atomic clock radio receiver. It has a 3V inverted TTL RS-232 link that runs at 2400 or 9600 baud. Power draw is +3.5V to 15V at 600uA. Thats pretty snazzy. Actually it isn't. A bi-directional link is usually needed, but it Ah I was making my observation based on that NTP seems to be designed around a connectionless protocol that structures itself in a tree-ish format, kinda like DNS, and that a connection based protocol would make the structure too unwieldy. Granted DNS does do some data transfer over TCP but its not generally needed during normal operation. At any rate, it couldn't be done without modifiing the code, and finding somebody else to peer with who also had a modified server. -- Jamie Heilman http://audible.transient.net/~jamie/ ...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity... -Rimmer
