From owner-freebsd-questions@FreeBSD.ORG Fri Feb 13 06:35:20 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D193D16A4CF; Fri, 13 Feb 2004 06:35:20 -0800 (PST) Received: from smtp14.singnet.com.sg (smtp14.singnet.com.sg [165.21.6.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 433B943D1D; Fri, 13 Feb 2004 06:35:20 -0800 (PST) (envelope-from spades@galaxynet.org) Received: from bryanuptrvb0jc (bb-203-125-28-129.singnet.com.sg [203.125.28.129])i1DEZI2w009046; Fri, 13 Feb 2004 22:35:18 +0800 Message-ID: <022001c3f23e$9b4b3fc0$fa10fea9@bryanuptrvb0jc> From: "Spades" To: Date: Fri, 13 Feb 2004 22:35:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: freebsd-security@freebsd.org Subject: Re: SYN Attacks - how i cant stop it X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Spades List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2004 14:35:21 -0000 Hi, I got this error when i tried to type for some of those. "sysctl: unknown oid...." any idea.. my server seems to be very lagged, where else the network connection seems fine, i think BSD itself as my other redhat box is fine. What else can i do to get optimum protection. Thanks. ----- Original Message ----- From: "Per Engelbrecht" To: Cc: Sent: Saturday, February 07, 2004 5:58 PM Subject: Re: SYN Attacks - how i cant stop it > Hi, > > > > all nights. Check this. > > > > Feb 6 11:54:24 TCP: port scan detected [port 6667] from > > 212.165.80.117 [ports 63432,63453,63466,63499,63522,...] > > Feb 6 11:58:09 TCP: port scan mode expired for 212.165.80.117 - > > > > It's hard to get rid of shit-heads like this - I'm talking about the > person doing this attac, that is. > You send a looong output of a log, but no info on your system or any > adjustments you have made (or not made) on your system i.e. kernel > (options), sysctl (tweaks) and ipfw (rules). > If the problem is out-of-bandwith (and your system already has been > optimized) then the only real solution is more 'pipe' a.k.a the > Microsoft-solution. > So fare I've only been guessing, but here is what I normally do with my > setup. I'm not telling you that this is the solution! just adwises! > > Kernel; > options SC_DISABLE_REBOOT > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=100 > options IPDIVERT > options IPFILTER > options IPFILTER_LOG > options IPSTEALTH (don't touch the ttl/can't see the wall) > options TCP_DROP_SYNFIN (drop tcp packet with syn+fin/scanner) > options RANDOM_IP_ID (hard to do calculate ip frekv. number) > options DUMMYNET (e.g. 40% for web, 30% for mail and so on) > options DEVICE_POLLING (can't do this short and not with SMP) > options HZ=1000 (can't do this short and not with SMP) > > Sysctl; > kern.ipc.somaxconn=1024 #this is set high! > kern.ipc.nmbclusters=65536 #this is set high! > kern.polling.enable=1 #remember kernel options > kern.polling.user_frac=50>90 #remember kernel options > net.xorp.polling=1 > net.xorp.poll_burst=10 > net.xorp.poll_in_trap=3 > (if you use dynamic rules in ipfw [stateful] you can tweak this) > net.inet.ip.fw.dyn_ack_lifetime=200 #shorte timeout on connection > net.inet.ip.fw.dyn_syn_lifetime=20 > net.inet.ip.fw.dyn_fin_lifetime=20 > net.inet.ip.fw.dyn_rst_lifetime=5 > net.inet.ip.fw.dyn_short_lifetime=10 #longer timeout for e.g. icmp > net.inet.ip.fw.dyn_max=1500 #higher number of dynamic rules > net.inet.ip.fw.dyn_count: #count of number of dynamic rules > > ipfw; > There's a zillion ways to set it up. start with a few rules regarding > lo0 and icmp. Then use stateful inspection and dynamic rules for the > rest of the wall. > > ... and by the way, I could see that a few of the scan came from RIPE > ranges. Do some digging and report it! > Even if the boxes are use without the owners awareness, you can [we all > can] bring this part to an end. > > respectfully > /per > per@xterm.dk > > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"