From owner-freebsd-questions@FreeBSD.ORG Wed Feb 19 03:09:54 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDD301D1 for ; Wed, 19 Feb 2014 03:09:54 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id B558E1E06 for ; Wed, 19 Feb 2014 03:09:54 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 2546B3AD93 for ; Tue, 18 Feb 2014 19:09:51 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-questions@freebsd.org Subject: [SOLVED] Re: Semi-urgent: Disable NTP replies? Date: Tue, 18 Feb 2014 19:09:51 -0800 Message-ID: <3975.1392779391@server1.tristatelogic.com> X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 03:09:54 -0000 Thanks much to everybody who responded. All of the responses were enlightening and much appreciated. Obviously, yes, I screwed up big time when I constructed my firewall rules, and I was inadvertantly and unintentionally allowing stuff to come in from the outside on udp/123. That is no longer the case. I now have a rule in place to block it all... and I'm not likely to make THAT mistake again! (Live and learn.) And, ah, yes, Warren, thank you. I shall be joining the security mailing list forthwith. I had been reading recently about the recent dramatic uptick in offensive use of NTP, so I _was_ aware of the problem. I just had no idea, until today, that I was myself part of the problem. I ernestly believed that my existing firewall rules would have blocked me from being an unwitting participant in this kind of nonsense, but whereas I have always striven to be a good neighbor... e.g. making sure that I wasn't running an open mail relay or even an open recursive DNS resolver... I confess that I messed up when it came to properly securing this NTP stuff. But at least it is blocked off now, and shall not be abused by the Evil Ones any more. Meanwhile, in other news... Now that I've been given an excuse to go and look again at all my firewall rules, I've also just been skimming over some things that were logged (by my rules) as being a bit suspicious. I'd like to solicit the assembled intelligencia here for relevant comments on some of this stuff, in particular... 1) I've been told in the past that packet fragmentation is almost always a sign of some sort of nefarious skullduggery, so my FW rules block inbound fragments. But I noticed these log records from just a bit earlier today: Feb 18 18:16:26 segfault kernel: ipfw: 3700 Deny UDP 68.87.68.244 69.62.255.118 in via rl0 (frag 44517:774@1480) Feb 18 18:16:26 segfault kernel: ipfw: 3700 Deny UDP 68.87.68.244 69.62.255.118 in via rl0 (frag 44518:774@1480) Feb 18 18:16:26 segfault kernel: ipfw: 3700 Deny UDP 68.87.68.244 69.62.255.118 in via rl0 (frag 44519:774@1480) Feb 18 18:16:26 segfault kernel: ipfw: 3700 Deny UDP 68.87.68.244 69.62.255.118 in via rl0 (frag 28685:774@1480) Feb 18 18:16:26 segfault kernel: ipfw: 3700 Deny UDP 68.87.68.244 69.62.255.118 in via rl0 (frag 44520:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 69.252.250.103 69.62.255.118 in via rl0 (frag 41031:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 69.252.250.103 69.62.255.118 in via rl0 (frag 39119:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 69.252.250.103 69.62.255.118 in via rl0 (frag 41032:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 69.252.250.103 69.62.255.118 in via rl0 (frag 39120:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 69.252.250.103 69.62.255.118 in via rl0 (frag 39121:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 68.87.85.132 69.62.255.118 in via rl0 (frag 26282:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 68.87.85.132 69.62.255.118 in via rl0 (frag 44323:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 68.87.85.132 69.62.255.118 in via rl0 (frag 44324:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 68.87.85.132 69.62.255.118 in via rl0 (frag 44325:774@1480) Feb 18 18:16:27 segfault kernel: ipfw: 3700 Deny UDP 68.87.85.132 69.62.255.118 in via rl0 (frag 26283:774@1480) Can anybody give me a clue as to why the new Evil Empire (Comcast) might be sending me a short fast burst of fragmented packets from their various DNS servers? If I assume that these aren't actually evil, then I'm inclined to wonder if it would be wise for me now to _unblock_ fragmented packets in my FW rules. (To the best of my knowledge, I was _not_ sending any queries of any kind to Comcast at the time the above occured. Of course it is at least arguably possible that _something_ on my system was doing so on its own...) =-=-=-=-=-=- 2) Who the bleep is this guy, and who told him that he should be trying to poke around people's SNMP ports?? That seems downright abusive and intrusive to me!! Feb 18 18:26:28 segfault kernel: ipfw: 3700 Deny UDP 209.126.230.71:43150 69.62.255.118:161 in via rl0 Hey! I know how to do lookups. So this is "internetsurvey-2.erratasec.com". OK, fine. But I've never heard of these goofballs before, and their home page (http://www.erratasec.com/) does not exactly fill me with a sense of trust and kinship. Far from it! So really, who the hell are these jerks? And why hasn't anybody castrated them yet for going around, willy nilly, poking into people's SNMP ports for info that is surely none of their damn business? Ummm... I guess they have been doing this sort of thing for awhile now... http://www.tenable.com/blog/detecting-errata-securitys-port-22-internet-wide-scan Back in the day, this sort of mass random uninvited poking was grounds for instant termination (either of one's connection or one's self) in a lot of places, but I guess the times they are a changin'. Humph. Welcome to the pucked up future, where packet probes are as thick as the smog over Bejing. Regards, rfg