From thomas at gibfest.dk Thu Oct 1 00:59:50 2009 From: thomas at gibfest.dk (Thomas Rasmussen) Date: Thu Oct 1 00:59:58 2009 Subject: Update on protection against slowloris In-Reply-To: <4AC37D6B.3060409@optiksecurite.com> References: <4AC37D6B.3060409@optiksecurite.com> Message-ID: <4AC3FA90.1000405@gibfest.dk> Martin Turgeon wrote: > Hi list! > > We tested mod_antiloris 0.4 and found it quite efficient, but before > putting it in production, we would like to hear some feedback from > freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is > anyone using it? Do you have any other way to patch against Slowloris > other than putting a proxy in front or using the HTTP accept filter? > > Thanks for your feedback, > > Martin > _______________________________________________ > 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" Hello, I am using it succesfully although not under any serious load, same Apache and FreeBSD versions. I found it easy (compared to the alternatives) and efficient, and no I don't know of any other ways of blocking the attack, short of using Varnish or similar. However, accf_http doesn't help at all, since HTTP POST requests bypass the filter. HTTP POST can be enabled by passing the -httpready switch to Slowloris. Please report back with your findings, I've been wondering how it would perform under load. Best of luck with it, Thomas Rasmussen From tevans.uk at googlemail.com Thu Oct 1 09:29:28 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Thu Oct 1 09:29:36 2009 Subject: Update on protection against slowloris In-Reply-To: <4AC3FA90.1000405@gibfest.dk> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> Message-ID: <1254387556.39148.10.camel@strangepork.london.mintel.ad> On Thu, 2009-10-01 at 02:40 +0200, Thomas Rasmussen wrote: > Martin Turgeon wrote: > > Hi list! > > > > We tested mod_antiloris 0.4 and found it quite efficient, but before > > putting it in production, we would like to hear some feedback from > > freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is > > anyone using it? Do you have any other way to patch against Slowloris > > other than putting a proxy in front or using the HTTP accept filter? > > > > Thanks for your feedback, > > > > Martin > > _______________________________________________ > > 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" > Hello, > > I am using it succesfully although not under any serious load, same > Apache and FreeBSD versions. I found it easy (compared to the > alternatives) and efficient, and no I don't know of any other ways of > blocking the attack, short of using Varnish or similar. However, > accf_http doesn't help at all, since HTTP POST requests bypass the > filter. HTTP POST can be enabled by passing the -httpready switch to > Slowloris. > > Please report back with your findings, I've been wondering how it > would perform under load. > > Best of luck with it, > > Thomas Rasmussen We use Apache 2.2 with the event MPM. This configuration is immune to slowloris, as it was designed (several years before 'slowloris' came along) to solve that exact problem. Cheers Tom From ltning at anduin.net Thu Oct 1 18:20:11 2009 From: ltning at anduin.net (=?iso-8859-1?Q?Eirik_=D8verby?=) Date: Thu Oct 1 18:20:19 2009 Subject: Update on protection against slowloris In-Reply-To: <1254387556.39148.10.camel@strangepork.london.mintel.ad> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <1254387556.39148.10.camel@strangepork.london.mintel.ad> Message-ID: <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> On 1. okt. 2009, at 10.59, Tom Evans wrote: > On Thu, 2009-10-01 at 02:40 +0200, Thomas Rasmussen wrote: >> Martin Turgeon wrote: >>> Hi list! >>> >>> We tested mod_antiloris 0.4 and found it quite efficient, but before >>> putting it in production, we would like to hear some feedback from >>> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is >>> anyone using it? Do you have any other way to patch against >>> Slowloris >>> other than putting a proxy in front or using the HTTP accept filter? >>> >>> Thanks for your feedback, >>> >>> Martin >>> _______________________________________________ >>> 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" >> Hello, >> >> I am using it succesfully although not under any serious load, same >> Apache and FreeBSD versions. I found it easy (compared to the >> alternatives) and efficient, and no I don't know of any other ways of >> blocking the attack, short of using Varnish or similar. However, >> accf_http doesn't help at all, since HTTP POST requests bypass the >> filter. HTTP POST can be enabled by passing the -httpready switch to >> Slowloris. >> >> Please report back with your findings, I've been wondering how it >> would perform under load. >> >> Best of luck with it, >> >> Thomas Rasmussen > > We use Apache 2.2 with the event MPM. This configuration is immune to > slowloris, as it was designed (several years before 'slowloris' came > along) to solve that exact problem. Without SSL, I presume? /Eirik From leccine at gmail.com Thu Oct 1 18:46:04 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Thu Oct 1 18:46:11 2009 Subject: Update on protection against slowloris In-Reply-To: <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <1254387556.39148.10.camel@strangepork.london.mintel.ad> <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> Message-ID: "The bad news is that it can indeed take a badly-configured apache server down, and the worse news is that that includes a low-traffic out-of-the box configuration. Even with the Event MPM, slowloris can tie up one worker thread per connection." for sure 2009/10/1 Eirik ?verby > > On 1. okt. 2009, at 10.59, Tom Evans wrote: > > On Thu, 2009-10-01 at 02:40 +0200, Thomas Rasmussen wrote: >> >>> Martin Turgeon wrote: >>> >>>> Hi list! >>>> >>>> We tested mod_antiloris 0.4 and found it quite efficient, but before >>>> putting it in production, we would like to hear some feedback from >>>> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is >>>> anyone using it? Do you have any other way to patch against Slowloris >>>> other than putting a proxy in front or using the HTTP accept filter? >>>> >>>> Thanks for your feedback, >>>> >>>> Martin >>>> _______________________________________________ >>>> 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" >>>> >>> Hello, >>> >>> I am using it succesfully although not under any serious load, same >>> Apache and FreeBSD versions. I found it easy (compared to the >>> alternatives) and efficient, and no I don't know of any other ways of >>> blocking the attack, short of using Varnish or similar. However, >>> accf_http doesn't help at all, since HTTP POST requests bypass the >>> filter. HTTP POST can be enabled by passing the -httpready switch to >>> Slowloris. >>> >>> Please report back with your findings, I've been wondering how it >>> would perform under load. >>> >>> Best of luck with it, >>> >>> Thomas Rasmussen >>> >> >> We use Apache 2.2 with the event MPM. This configuration is immune to >> slowloris, as it was designed (several years before 'slowloris' came >> along) to solve that exact problem. >> > > Without SSL, I presume? > > /Eirik > > _______________________________________________ > 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 > " > -- the sun shines for all From me at johnea.net Fri Oct 2 00:30:15 2009 From: me at johnea.net (johnea) Date: Fri Oct 2 00:30:23 2009 Subject: openssh concerns Message-ID: <4AC545C3.9020608@johnea.net> Hello, Sorry if this is dumb as ditch water but I just felt like I should ask. I'm been running an independent host here for the last 5 years with the usual toaster services: http, smtp, and imap all using ssl and ssh for remote login. I installed sshgaurd after dealing with the incessant brute force crack attempts. Lately I've been under ssh attack by a botnet with hundreds of IPs. The thing that concerned me is an entry I saw in netstat showing my system connecting back to a machine that was attempting to log in to ssh. This is where I may be a braindead noob, but is that normal? Does the ssh server establish a socket to a client attempting login? The details from netstat are below along with a bunch of other info that seemed relevant. Thank you so much for considering my question and for your work on the FreeBSD project. johnea ~~~~~~~~~~~~~~~~~~~~~~ issue information ~~~~~~~~~~~~~~~~~~~~~~ atom# openssl version OpenSSL 0.9.8e 23 Feb 2007 atom# uname -a FreeBSD atom.johnea.net 7.1-RELEASE-p6 FreeBSD 7.1-RELEASE-p6 #0: Tue Jun 9 16:26:47 UTC 2009 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 from netstat: tcp4 0 0 atom.60448 host154.advance.com.ar.auth TIME_WAIT tcp4 0 0 atom.ssh host154.advance.com.ar.37833 TIME_WAIT from auth.log: The same IP as above: Oct 1 15:51:56 atom sshd[84887]: warning: /etc/hosts.allow, line 37: can't verify hostname: getaddrinfo(host154.advance.com.ar, AF_INET) failed Other example entries from auth.log: Oct 1 13:45:55 atom sshd[82209]: error: PAM: authentication error for root from 222.211.93.81 Oct 1 13:47:14 atom sshd[82252]: error: PAM: authentication error for root from 217.77.72.115 Oct 1 13:47:29 atom sshd[82266]: error: PAM: authentication error for root from 60.170.80.198 Oct 1 13:48:23 atom sshd[82271]: error: PAM: authentication error for root from 201.26.169.150 Oct 1 13:49:11 atom sshd[82279]: error: PAM: authentication error for root from 200.36.249.22 Oct 1 13:50:11 atom sshd[82291]: error: PAM: authentication error for root from 80.152.227.160 Oct 1 13:50:47 atom sshd[82300]: error: PAM: authentication error for root from 80.108.8.74 Oct 1 13:51:38 atom sshd[82311]: error: PAM: authentication error for root from 58.60.106.119 Oct 1 13:52:27 atom sshd[82371]: error: PAM: authentication error for root from 200.36.249.22 Oct 1 13:53:21 atom sshd[82378]: error: PAM: authentication error for root from 74.218.172.158 Oct 1 13:54:05 atom sshd[82384]: error: PAM: authentication error for root from 220.248.9.163 Oct 1 13:54:55 atom sshd[82394]: error: PAM: authentication error for root from 58.60.106.199 Oct 1 13:56:31 atom sshd[82419]: error: PAM: authentication error for root from 222.128.48.222 Oct 1 13:57:22 atom sshd[82472]: error: PAM: authentication error for root from 83.65.166.74 Oct 1 13:58:20 atom sshd[82482]: error: PAM: authentication error for root from 81.244.253.110 Oct 1 13:59:02 atom sshd[82492]: error: PAM: authentication error for root from 76.12.185.151 Oct 1 13:59:49 atom sshd[82505]: error: PAM: authentication error for root from 200.41.97.213 Oct 1 14:00:00 atom newsyslog[82517]: logfile turned over due to size>100K Oct 1 15:50:58 atom sshd[84875]: error: PAM: authentication error for root from 74.56.151.159 Oct 1 15:51:56 atom sshd[84887]: warning: /etc/hosts.allow, line 37: can't verify hostname: getaddrinfo(host154.advance.com.ar, AF_INET) failed Oct 1 15:51:58 atom sshd[84887]: refused connect from 200.51.40.154 (200.51.40.154) Oct 1 15:52:49 atom sshd[84943]: warning: /etc/hosts.allow, line 37: can't verify hostname: getaddrinfo(static.khi77.pie.net.pk, AF_INET) failed Oct 1 15:52:49 atom sshd[84943]: refused connect from 221.120.201.71 (221.120.201.71) Oct 1 15:53:43 atom sshd[84955]: error: PAM: authentication error for root from 196.211.146.154 Oct 1 15:54:30 atom sshd[84964]: error: PAM: authentication error for root from 74.239.115.130 Oct 1 15:55:18 atom sshd[84990]: warning: /etc/hosts.allow, line 37: can't verify hostname: getaddrinfo(mail.iesmos.ru, AF_INET) failed Oct 1 15:55:19 atom sshd[84990]: refused connect from 217.147.21.166 (217.147.21.166) Oct 1 15:55:53 atom sshd[84994]: error: PAM: authentication error for root from 80.152.227.160 Oct 1 15:57:39 atom sshd[85042]: error: PAM: authentication error for root from 124.232.131.156 Oct 1 15:58:32 atom sshd[85048]: error: PAM: authentication error for root from 83.65.166.74 Oct 1 15:59:12 atom sshd[85062]: error: PAM: authentication error for root from 218.204.223.214 Oct 1 16:00:01 atom sshguard[83827]: Got exit signal, flushing blocked addresses and exiting... Oct 1 16:00:01 atom sshguard[85089]: Started successfully [(a,p,s)=(4, 420, 1200)], now ready to scan. Oct 1 16:00:03 atom sshd[85092]: warning: /etc/hosts.allow, line 37: can't verify hostname: getaddrinfo(adsl3-pool From stef-list at memberwebs.com Fri Oct 2 00:55:32 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Fri Oct 2 02:59:57 2009 Subject: openssh concerns In-Reply-To: <4AC545C3.9020608@johnea.net> References: <4AC545C3.9020608@johnea.net> Message-ID: <4AC54B58.9030900@memberwebs.com> johnea wrote: > tcp4 0 0 atom.60448 host154.advance.com.ar.auth > TIME_WAIT > tcp4 0 0 atom.ssh host154.advance.com.ar.37833 > TIME_WAIT Your machine is, for some reason, connecting to the ident service on the remote machine. This isn't done by default by openssh, as far as I know. Cheers, Stef From wollman at bimajority.org Fri Oct 2 01:16:30 2009 From: wollman at bimajority.org (Garrett Wollman) Date: Fri Oct 2 03:00:11 2009 Subject: openssh concerns In-Reply-To: <4AC545C3.9020608@johnea.net> References: <4AC545C3.9020608@johnea.net> Message-ID: <19141.20047.694147.865710@hergotha.csail.mit.edu> < said: > The thing that concerned me is an entry I saw in netstat showing > my system connecting back to a machine that was attempting to log > in to ssh. > Does the ssh server establish a socket to a client attempting login? The SSH protocol does not, but you appear to be using "TCP wrappers" (/etc/hosts.allow) configured in such a way that it make an IDENT protocol request back to the originating server. This is rarely likely to do anything useful and should probably be disabled. > tcp4 0 0 atom.60448 host154.advance.com.ar.auth TIME_WAIT "auth" is the port number used by the IDENT protocol. -GAWollman From jmarneweck at gmail.com Fri Oct 2 05:28:58 2009 From: jmarneweck at gmail.com (Jacques Marneweck) Date: Fri Oct 2 05:37:10 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <20090928192256.GC2111@arthur.nitro.dk> References: <4AAF45B4.60307@isafeelin.org> <4AAF5999.7020501@delphij.net> <200909251248.n8PCmJPY011925@lava.sentex.ca> <20090928192256.GC2111@arthur.nitro.dk> Message-ID: <4802d0520910012200p271a2d5awc5e69b9ab1235851@mail.gmail.com> Hi Simon, Is there any further feedback regarding this bug? Has anyone tested to see if this also affects FreeBSD 5.x? Regards --jm On Mon, Sep 28, 2009 at 9:22 PM, Simon L. Nielsen wrote: > On 2009.09.25 08:52:25 -0400, Mike Tancsa wrote: >> At 05:08 AM 9/15/2009, Xin LI wrote: >> >Frederique Rijsdijk wrote: >> > > Hi, >> > > >> > > Any info on this subject on >> > > >> > > http://www.theregister.co.uk/2009/09/14/freebsd_security_bug/ >> > >> >Currently we (secteam@) are testing the correction patch and do >> >peer-review on the security advisory draft, the bug was found and fixed >> >on -HEAD and 7-STABLE before 7.1-RELEASE during some stress test but was >> >not recognized as a security vulnerability at that time. ?The exploit >> >code has to be executed locally, i.e. either by an untrusted local user, >> >or be exploited in conjunction with some remote vulnerability on >> >applications that allow the attacker to inject their own code. >> > >> >We can not release further details about the problem at this time, >> >though, but I think we will likely to publish the advisory and >> >correction patch this patch Wednesday. >> >> ? ? ? ? ?Just wondering if there is any update on this issue ? > > It turned out more difficult to fix than expected and we (secteam) > didn't handle that as well as we should have, but I think we are > almost there so the advisory should be out soon - sometime this week > at the latest. > > Sorry about the delay - this should have been fixed by now. > > -- > Simon L. Nielsen > FreeBSD Deputy Security Officer -- Jacques Marneweck http://www.powertrip.co.za/ http://www.powertrip.co.za/blog/ http://www.ataris.co.za/ #include From bzeeb-lists at lists.zabbadoz.net Fri Oct 2 06:57:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri Oct 2 06:57:15 2009 Subject: FreeBSD bug grants local root access (FreeBSD 6.x) In-Reply-To: <4802d0520910012200p271a2d5awc5e69b9ab1235851@mail.gmail.com> References: <4AAF45B4.60307@isafeelin.org> <4AAF5999.7020501@delphij.net> <200909251248.n8PCmJPY011925@lava.sentex.ca> <20090928192256.GC2111@arthur.nitro.dk> <4802d0520910012200p271a2d5awc5e69b9ab1235851@mail.gmail.com> Message-ID: <20091002063444.L26486@maildrop.int.zabbadoz.net> On Fri, 2 Oct 2009, Jacques Marneweck wrote: Hi, > Is there any further feedback regarding this bug? There is progress. > Has anyone tested > to see if this also affects FreeBSD 5.x? FreeBSD 5.x is not a supported branch anymore, so it's unlikely that anyone will check it. See http://security.freebsd.org/#sup for a list of branches SO/secteam care about. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From tevans.uk at googlemail.com Fri Oct 2 08:15:59 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Oct 2 08:16:06 2009 Subject: Update on protection against slowloris In-Reply-To: <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <1254387556.39148.10.camel@strangepork.london.mintel.ad> <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> Message-ID: <1254471354.54871.7.camel@strangepork.london.mintel.ad> On Thu, 2009-10-01 at 19:48 +0200, Eirik ?verby wrote: > On 1. okt. 2009, at 10.59, Tom Evans wrote: > > > On Thu, 2009-10-01 at 02:40 +0200, Thomas Rasmussen wrote: > >> Martin Turgeon wrote: > >>> Hi list! > >>> > >>> We tested mod_antiloris 0.4 and found it quite efficient, but before > >>> putting it in production, we would like to hear some feedback from > >>> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is > >>> anyone using it? Do you have any other way to patch against > >>> Slowloris > >>> other than putting a proxy in front or using the HTTP accept filter? > >>> > >>> Thanks for your feedback, > >>> > >>> Martin > >>> _______________________________________________ > >>> 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" > >> Hello, > >> > >> I am using it succesfully although not under any serious load, same > >> Apache and FreeBSD versions. I found it easy (compared to the > >> alternatives) and efficient, and no I don't know of any other ways of > >> blocking the attack, short of using Varnish or similar. However, > >> accf_http doesn't help at all, since HTTP POST requests bypass the > >> filter. HTTP POST can be enabled by passing the -httpready switch to > >> Slowloris. > >> > >> Please report back with your findings, I've been wondering how it > >> would perform under load. > >> > >> Best of luck with it, > >> > >> Thomas Rasmussen > > > > We use Apache 2.2 with the event MPM. This configuration is immune to > > slowloris, as it was designed (several years before 'slowloris' came > > along) to solve that exact problem. > > Without SSL, I presume? > > /Eirik > Yes, we run a prefork MPM apache as a reverse proxy in front of that, serving just SSL and proxying to the other. We're eagerly awaiting the release of httpd 2.4, which promotes event MPM to non experimental (as they've solved the problem with SSL). Cheers Tom From tevans.uk at googlemail.com Fri Oct 2 08:18:53 2009 From: tevans.uk at googlemail.com (Tom Evans) Date: Fri Oct 2 08:19:00 2009 Subject: Update on protection against slowloris In-Reply-To: References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <1254387556.39148.10.camel@strangepork.london.mintel.ad> <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> Message-ID: <1254471526.54871.10.camel@strangepork.london.mintel.ad> On Thu, 2009-10-01 at 19:46 +0100, Istv?n wrote: > "The bad news is that it can indeed take a badly-configured apache > server down, and the worse news is that that includes a low-traffic > out-of-the box configuration. Even with the Event MPM, slowloris can > tie up one worker thread per connection." > > > > > for sure > It doesn't tie up one thread, one thread is partially occupied by waiting for the slowloris connection to finish sending the request. That thread can still handle other connections that are sending requests. In our tests, running a couple of slowloris instances against event MPM had virtually no effect. Cheers Tom From leccine at gmail.com Fri Oct 2 08:49:03 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Fri Oct 2 08:49:11 2009 Subject: Update on protection against slowloris In-Reply-To: <1254471526.54871.10.camel@strangepork.london.mintel.ad> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <1254387556.39148.10.camel@strangepork.london.mintel.ad> <4E7E6B51-2B63-459C-A6FE-F327E899DCF6@anduin.net> <1254471526.54871.10.camel@strangepork.london.mintel.ad> Message-ID: hmm, i am curious as well, lets wait to 2.4 On Fri, Oct 2, 2009 at 9:18 AM, Tom Evans wrote: > On Thu, 2009-10-01 at 19:46 +0100, Istv?n wrote: > > "The bad news is that it can indeed take a badly-configured apache > > server down, and the worse news is that that includes a low-traffic > > out-of-the box configuration. Even with the Event MPM, slowloris can > > tie up one worker thread per connection." > > > > > > > > > > for sure > > > > It doesn't tie up one thread, one thread is partially occupied by > waiting for the slowloris connection to finish sending the request. That > thread can still handle other connections that are sending requests. In > our tests, running a couple of slowloris instances against event MPM had > virtually no effect. > > Cheers > > Tom > > -- the sun shines for all From me at johnea.net Fri Oct 2 15:28:00 2009 From: me at johnea.net (johnea) Date: Fri Oct 2 15:28:07 2009 Subject: openssh concerns In-Reply-To: <19141.20047.694147.865710@hergotha.csail.mit.edu> References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> Message-ID: <4AC61C0B.3050704@johnea.net> Garrett Wollman wrote: > < said: > >> The thing that concerned me is an entry I saw in netstat showing >> my system connecting back to a machine that was attempting to log >> in to ssh. > >> Does the ssh server establish a socket to a client attempting login? > > The SSH protocol does not, but you appear to be using "TCP wrappers" > (/etc/hosts.allow) configured in such a way that it make an IDENT > protocol request back to the originating server. This is rarely > likely to do anything useful and should probably be disabled. > >> tcp4 0 0 atom.60448 host154.advance.com.ar.auth TIME_WAIT > > "auth" is the port number used by the IDENT protocol. > > -GAWollman Thank You to everyone who responded! In fact I did discover these lines in hosts.allow: 31-# Protect against simple DNS spoofing attacks by checking that the 32-# forward and reverse records for the remote host match. If a mismatch 33-# occurs, access is denied, and any positive ident response within 34-# 20 seconds is logged. No protection is afforded against DNS poisoning, 35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS 36-# pass this rule. 37:ALL : PARANOID : RFC931 20 : deny This is what was generating the auth protocol socket. I've disabled it to prevent the establishment of the auth socket to hosts who are attempting to breakin. Per another suggestion I also intend to change the port for ssh to a non-standard number (after synchronizing with the users of course 8-) Maybe I'm a little paranoid, but after watching the level of spam ever increasing over the last 5 years, and more and more people moving to big (monopolistic?) service providers like google and hotmail. I've wondered if these big corporate service providers don't tolerate the spam level in order to prevent anyone who doesn't have a building full of IT staff from running their own mail servers. Perhaps with the help of people like those on this list, the internet won't have to be abandoned by independents? Thanks again to everyone! johnea From leccine at gmail.com Fri Oct 2 15:32:27 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Fri Oct 2 15:32:34 2009 Subject: openssh concerns In-Reply-To: <4AC61C0B.3050704@johnea.net> References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> <4AC61C0B.3050704@johnea.net> Message-ID: Protect against simple DNS spoofing attacks by checking that the... So if the ssh bruteforce is coming from a properly setup DNS host it is ok :)))) On Fri, Oct 2, 2009 at 4:28 PM, johnea wrote: > Garrett Wollman wrote: > >> < said: >> >> The thing that concerned me is an entry I saw in netstat showing >>> my system connecting back to a machine that was attempting to log >>> in to ssh. >>> >> >> Does the ssh server establish a socket to a client attempting login? >>> >> >> The SSH protocol does not, but you appear to be using "TCP wrappers" >> (/etc/hosts.allow) configured in such a way that it make an IDENT >> protocol request back to the originating server. This is rarely >> likely to do anything useful and should probably be disabled. >> >> tcp4 0 0 atom.60448 host154.advance.com.ar.auth >>> TIME_WAIT >>> >> >> "auth" is the port number used by the IDENT protocol. >> >> -GAWollman >> > > Thank You to everyone who responded! > > In fact I did discover these lines in hosts.allow: > > 31-# Protect against simple DNS spoofing attacks by checking that the > 32-# forward and reverse records for the remote host match. If a mismatch > 33-# occurs, access is denied, and any positive ident response within > 34-# 20 seconds is logged. No protection is afforded against DNS poisoning, > 35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS > 36-# pass this rule. > 37:ALL : PARANOID : RFC931 20 : deny > > This is what was generating the auth protocol socket. > > I've disabled it to prevent the establishment of the auth socket to hosts > who are attempting to breakin. > > Per another suggestion I also intend to change the port for ssh to a > non-standard number (after synchronizing with the users of course 8-) > > Maybe I'm a little paranoid, but after watching the level of spam ever > increasing over the last 5 years, and more and more people moving to > big (monopolistic?) service providers like google and hotmail. I've > wondered if these big corporate service providers don't tolerate the > spam level in order to prevent anyone who doesn't have a building full > of IT staff from running their own mail servers. > > Perhaps with the help of people like those on this list, the internet > won't have to be abandoned by independents? > > Thanks again to everyone! > > johnea > _______________________________________________ > 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 > " > -- the sun shines for all From devin at spamcop.net Fri Oct 2 16:09:57 2009 From: devin at spamcop.net (Tod McQuillin) Date: Fri Oct 2 16:10:05 2009 Subject: openssh concerns In-Reply-To: <4AC61C0B.3050704@johnea.net> References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> <4AC61C0B.3050704@johnea.net> Message-ID: <20091003003817.C1868@plexi.pun-pun.prv> On Fri, 2 Oct 2009, johnea wrote: > Maybe I'm a little paranoid, but after watching the level of spam ever > increasing over the last 5 years, and more and more people moving to > big (monopolistic?) service providers like google and hotmail. I've > wondered if these big corporate service providers don't tolerate the > spam level in order to prevent anyone who doesn't have a building full > of IT staff from running their own mail servers. As recently as last month I was thinking along the same lines, but now that I have installed a greylisting spam filter (mail/spamd from ports) spam is down to extremely manageable levels on my home mail server. With a little time spent configuring your world, there is still room for do-it-yourself admins with small networks. -- Tod From smithi at nimnet.asn.au Fri Oct 2 19:09:25 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Oct 2 19:09:33 2009 Subject: openssh concerns In-Reply-To: <4AC61C0B.3050704@johnea.net> References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> <4AC61C0B.3050704@johnea.net> Message-ID: <20091003042802.O10039@sola.nimnet.asn.au> On Fri, 2 Oct 2009, johnea wrote: > Garrett Wollman wrote: [..] > > > tcp4 0 0 atom.60448 host154.advance.com.ar.auth > > > TIME_WAIT > > > > "auth" is the port number used by the IDENT protocol. > > > > -GAWollman > > Thank You to everyone who responded! > > In fact I did discover these lines in hosts.allow: > > 31-# Protect against simple DNS spoofing attacks by checking that the > 32-# forward and reverse records for the remote host match. If a mismatch > 33-# occurs, access is denied, and any positive ident response within > 34-# 20 seconds is logged. No protection is afforded against DNS poisoning, > 35-# IP spoofing or more complicated attacks. Hosts with no reverse DNS > 36-# pass this rule. > 37:ALL : PARANOID : RFC931 20 : deny > > This is what was generating the auth protocol socket. > > I've disabled it to prevent the establishment of the auth socket to hosts > who are attempting to breakin. > > Per another suggestion I also intend to change the port for ssh to a > non-standard number (after synchronizing with the users of course 8-) This will provide the greatest relief against drive-by ssh probes, which are pretty much background radiation these days. Some may decry it as 'security by obscurity', but who cares when it works so effectively :) http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers provides a reasonably useful list of ports NOT to choose for an obscure ssh port. cheers, Ian From patpro at patpro.net Fri Oct 2 19:57:24 2009 From: patpro at patpro.net (Patrick Proniewski) Date: Fri Oct 2 19:57:31 2009 Subject: openssh concerns In-Reply-To: <20091003042802.O10039@sola.nimnet.asn.au> References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> <4AC61C0B.3050704@johnea.net> <20091003042802.O10039@sola.nimnet.asn.au> Message-ID: > This will provide the greatest relief against drive-by ssh probes, > which > are pretty much background radiation these days. Some may decry it as > 'security by obscurity', but who cares when it works so effectively :) against script kiddies and bots, obscurity is good. > http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers > provides a > reasonably useful list of ports NOT to choose for an obscure ssh port. /etc/services is a good start too :) patpro From security-advisories at freebsd.org Fri Oct 2 20:11:57 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Fri Oct 2 20:12:09 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe Message-ID: <200910022011.n92KBukq003891@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:13.pipe Security Advisory The FreeBSD Project Topic: kqueue pipe race conditions Category: core Module: kern Announced: 2009-10-02 Credits: Przemyslaw Frasunek Affects: FreeBSD 6.x Corrected: 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background Pipes are a form of inter-process communication (IPC) provided by the FreeBSD kernel. kqueue is an event management API that applications can use to monitor pipes and other kernel services. II. Problem Description A race condition exists in the pipe close() code relating to kqueues, causing use-after-free for kernel memory, which may lead to an exploitable NULL pointer vulnerability in the kernel, kernel memory corruption, and other unpredictable results. III. Impact Successful exploitation of the race condition can lead to local kernel privilege escalation, kernel data corruption and/or crash. To exploit this vulnerability, an attacker must be able to run code on the target system. IV. Workaround An errata notice, FreeBSD-EN-09:05.null has been released simultaneously to this advisory, and contains a kernel patch implementing a workaround for a more broad class of vulnerabilities. However, prior to those changes, no workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or to the RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3 and 6.4. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_6 src/sys/kern/kern_event.c 1.93.2.7 src/sys/kern/kern_fork.c 1.252.2.8 src/sys/kern/sys_pipe.c 1.184.2.6 src/sys/sys/event.h 1.32.2.1 src/sys/sys/pipe.h 1.29.2.1 RELENG_6_4 src/UPDATING 1.416.2.40.2.11 src/sys/conf/newvers.sh 1.69.2.18.2.13 src/sys/kern/kern_event.c 1.93.2.6.6.2 src/sys/kern/kern_fork.c 1.252.2.7.4.2 src/sys/kern/sys_pipe.c 1.184.2.4.2.3 src/sys/sys/event.h 1.32.12.2 src/sys/sys/pipe.h 1.29.16.2 RELENG_6_3 src/UPDATING 1.416.2.37.2.18 src/sys/conf/newvers.sh 1.69.2.15.2.17 src/sys/kern/kern_event.c 1.93.2.6.4.1 src/sys/kern/kern_fork.c 1.252.2.7.2.1 src/sys/kern/sys_pipe.c 1.184.2.2.6.3 src/sys/sys/event.h 1.32.10.1 src/sys/sys/pipe.h 1.29.12.1 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r197715 releng/6.4/ r197715 releng/6.3/ r197715 - ------------------------------------------------------------------------- VII. References http://svn.freebsd.org/viewvc/base?view=revision&revision=179243 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:13.pipe.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFKxlthFdaIBMps37IRAlk2AJ9mUrNPd1RMztbzO4w7g+AxosqJzgCgmr5l FKxrbF0G4v9P6SyyfAdVOFY= =TWhC -----END PGP SIGNATURE----- From security-advisories at freebsd.org Fri Oct 2 20:12:05 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Fri Oct 2 20:12:28 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:14.devfs Message-ID: <200910022012.n92KC4Tb003955@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:14.devfs Security Advisory The FreeBSD Project Topic: Devfs / VFS NULL pointer race condition Category: core Module: kern Announced: 2009-10-02 Credits: Przemyslaw Frasunek Affects: FreeBSD 6.x and 7.x Corrected: 2009-05-18 10:41:59 UTC (RELENG_7, 7.2-STABLE) 2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4) 2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8) 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The device file system (devfs) provides access to system devices, such as storage devices and serial ports, via the file system namespace. VFS is the Virtual File System, which abstracts file system operations in the kernel from the actual underlying file system. II. Problem Description Due to the interaction between devfs and VFS, a race condition exists where the kernel might dereference a NULL pointer. III. Impact Successful exploitation of the race condition can lead to local kernel privilege escalation, kernel data corruption and/or crash. To exploit this vulnerability, an attacker must be able to run code with user privileges on the target system. IV. Workaround An errata note, FreeBSD-EN-09:05.null has been released simultaneously to this advisory, and contains a kernel patch implementing a workaround for a more broad class of vulnerabilities. However, prior to those changes, no workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.1, and 7.2 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 6.x] # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs6.patch # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs6.patch.asc [FreeBSD 7.x] # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs7.patch # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs7.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_6 src/sys/fs/devfs/devfs_vnops.c 1.114.2.17 RELENG_6_4 src/UPDATING 1.416.2.40.2.11 src/sys/conf/newvers.sh 1.69.2.18.2.13 src/sys/fs/devfs/devfs_vnops.c 1.114.2.16.2.2 RELENG_6_3 src/UPDATING 1.416.2.37.2.18 src/sys/conf/newvers.sh 1.69.2.15.2.17 src/sys/fs/devfs/devfs_vnops.c 1.114.2.15.2.1 RELENG_7 src/sys/fs/devfs/devfs_vnops.c 1.149.2.9 RELENG_7_2 src/UPDATING 1.507.2.23.2.7 src/sys/conf/newvers.sh 1.72.2.11.2.8 src/sys/fs/devfs/devfs_vnops.c 1.149.2.8.2.2 RELENG_7_1 src/UPDATING 1.507.2.13.2.11 src/sys/conf/newvers.sh 1.72.2.9.2.12 src/sys/fs/devfs/devfs_vnops.c 1.149.2.4.2.2 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- stable/6/ r197715 releng/6.4/ r197715 releng/6.3/ r197715 stable/7/ r192301 releng/7.2/ r197715 releng/7.1/ r197715 - ------------------------------------------------------------------------- VII. References The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:14.devfs.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iD8DBQFKxltlFdaIBMps37IRAp4zAJwJEwIySGqxH4EXwc0wjkDXlcTb1wCfTltO Syds53GSM0YbsMNUVMGsLaU= =exPZ -----END PGP SIGNATURE----- From jon at passki.us Fri Oct 2 21:04:12 2009 From: jon at passki.us (Jon Passki) Date: Fri Oct 2 21:04:19 2009 Subject: Fwd: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe Message-ID: <1B399692-1D5A-49C3-BDE7-7FAAA9C63910@passki.us> Has the FreeBSD Secteam tested setting VM_MIN_ADDRESS to some high number such as 65536? This does not fix the vulnerability per se, but one would hope it stops a user mapping code to 0x0. Also, were these the issues Przemyslaw Frasunek discovered? If so, I did not see an attribution to him in the advisory. (I could have missed it.) Any reason why not? Cheers, Jon Begin forwarded message: > From: FreeBSD Security Advisories > Date: October 2, 2009 20:11:56 CDT > To: FreeBSD Security Advisories > Subject: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe > Reply-To: freebsd-security@freebsd.org > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > === > === > === > ==================================================================== > FreeBSD-SA-09:13.pipe Security > Advisory > The FreeBSD > Project > > Topic: kqueue pipe race conditions > Category: core > Module: kern > Announced: 2009-10-02 > Credits: Przemyslaw Frasunek > Affects: FreeBSD 6.x > Corrected: 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) > 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) > 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. Background > > Pipes are a form of inter-process communication (IPC) provided by the > FreeBSD kernel. kqueue is an event management API that applications > can > use to monitor pipes and other kernel services. > > II. Problem Description > > A race condition exists in the pipe close() code relating to kqueues, > causing use-after-free for kernel memory, which may lead to an > exploitable NULL pointer vulnerability in the kernel, kernel memory > corruption, and other unpredictable results. > > III. Impact > > Successful exploitation of the race condition can lead to local kernel > privilege escalation, kernel data corruption and/or crash. > > To exploit this vulnerability, an attacker must be able to run code on > the target system. > > IV. Workaround > > An errata notice, FreeBSD-EN-09:05.null has been released > simultaneously to > this advisory, and contains a kernel patch implementing a workaround > for a > more broad class of vulnerabilities. However, prior to those > changes, no > workaround is available. > > V. Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to 6-STABLE, or to the RELENG_6_4, > or > RELENG_6_3 security branch dated after the correction date. > > 2) To patch your present system: > > The following patches have been verified to apply to FreeBSD 6.3 and > 6.4. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch > # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch.asc > > b) Apply the patch. > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile your kernel as described in > and reboot the > system. > > VI. Correction details > > The following list contains the revision numbers of each file that was > corrected in FreeBSD. > > CVS: > > Branch > Revision > Path > - > --- > ---------------------------------------------------------------------- > RELENG_6 > src/sys/kern/kern_event.c > 1.93.2.7 > src/sys/kern/kern_fork.c > 1.252.2.8 > src/sys/kern/sys_pipe.c > 1.184.2.6 > src/sys/sys/event.h > 1.32.2.1 > src/sys/sys/pipe.h > 1.29.2.1 > RELENG_6_4 > src/UPDATING 1.416.2.40.2.11 > src/sys/conf/newvers.sh 1.69.2.18.2.13 > src/sys/kern/kern_event.c 1.93.2.6.6.2 > src/sys/kern/kern_fork.c 1.252.2.7.4.2 > src/sys/kern/sys_pipe.c 1.184.2.4.2.3 > src/sys/sys/event.h > 1.32.12.2 > src/sys/sys/pipe.h > 1.29.16.2 > RELENG_6_3 > src/UPDATING 1.416.2.37.2.18 > src/sys/conf/newvers.sh 1.69.2.15.2.17 > src/sys/kern/kern_event.c 1.93.2.6.4.1 > src/sys/kern/kern_fork.c 1.252.2.7.2.1 > src/sys/kern/sys_pipe.c 1.184.2.2.6.3 > src/sys/sys/event.h > 1.32.10.1 > src/sys/sys/pipe.h > 1.29.12.1 > - > --- > ---------------------------------------------------------------------- > > Subversion: > > Branch/path > Revision > - > --- > ---------------------------------------------------------------------- > stable/6/ > r197715 > releng/6.4/ > r197715 > releng/6.3/ > r197715 > - > --- > ---------------------------------------------------------------------- > > VII. References > > http://svn.freebsd.org/viewvc/base?view=revision&revision=179243 > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-09:13.pipe.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (FreeBSD) > > iD8DBQFKxlthFdaIBMps37IRAlk2AJ9mUrNPd1RMztbzO4w7g+AxosqJzgCgmr5l > FKxrbF0G4v9P6SyyfAdVOFY= > =TWhC > -----END PGP SIGNATURE----- > _______________________________________________ > 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 > " From pieter at thedarkside.nl Fri Oct 2 21:11:23 2009 From: pieter at thedarkside.nl (Pieter de Boer) Date: Fri Oct 2 21:11:30 2009 Subject: Fwd: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe In-Reply-To: <1B399692-1D5A-49C3-BDE7-7FAAA9C63910@passki.us> References: <1B399692-1D5A-49C3-BDE7-7FAAA9C63910@passki.us> Message-ID: <4AC66C5A.3020301@thedarkside.nl> Jon Passki wrote: > Has the FreeBSD Secteam tested setting VM_MIN_ADDRESS to some high > number such as 65536? This does not fix the vulnerability per se, but > one would hope it stops a user mapping code to 0x0. > See the FreeBSD-EN-09:05.null erratum that contains a patch that allows you to do this with a sysctl :) -- Pieter From jon at passki.us Fri Oct 2 21:27:56 2009 From: jon at passki.us (Jon Passki) Date: Fri Oct 2 21:28:04 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe In-Reply-To: <1B399692-1D5A-49C3-BDE7-7FAAA9C63910@passki.us> References: <1B399692-1D5A-49C3-BDE7-7FAAA9C63910@passki.us> Message-ID: I'm an idiot re: credits. Sorry. Jon On Oct 2, 2009, at 16:03, Jon Passki wrote: > Has the FreeBSD Secteam tested setting VM_MIN_ADDRESS to some high > number such as 65536? This does not fix the vulnerability per se, > but one would hope it stops a user mapping code to 0x0. > > Also, were these the issues Przemyslaw Frasunek discovered? If so, I > did not see an attribution to him in the advisory. (I could have > missed it.) Any reason why not? > > Cheers, > > Jon > > Begin forwarded message: > >> From: FreeBSD Security Advisories >> Date: October 2, 2009 20:11:56 CDT >> To: FreeBSD Security Advisories >> Subject: FreeBSD Security Advisory FreeBSD-SA-09:13.pipe >> Reply-To: freebsd-security@freebsd.org >> > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> === >> === >> === >> ==================================================================== >> FreeBSD-SA-09:13.pipe >> Security Advisory >> The >> FreeBSD Project >> >> Topic: kqueue pipe race conditions >> Category: core >> Module: kern >> Announced: 2009-10-02 >> Credits: Przemyslaw Frasunek >> Affects: FreeBSD 6.x >> Corrected: 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) >> 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) >> 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) >> >> For general information regarding FreeBSD Security Advisories, >> including descriptions of the fields above, security branches, and >> the >> following sections, please visit . >> >> I. Background >> >> Pipes are a form of inter-process communication (IPC) provided by the >> FreeBSD kernel. kqueue is an event management API that >> applications can >> use to monitor pipes and other kernel services. >> >> II. Problem Description >> >> A race condition exists in the pipe close() code relating to kqueues, >> causing use-after-free for kernel memory, which may lead to an >> exploitable NULL pointer vulnerability in the kernel, kernel memory >> corruption, and other unpredictable results. >> >> III. Impact >> >> Successful exploitation of the race condition can lead to local >> kernel >> privilege escalation, kernel data corruption and/or crash. >> >> To exploit this vulnerability, an attacker must be able to run code >> on >> the target system. >> >> IV. Workaround >> >> An errata notice, FreeBSD-EN-09:05.null has been released >> simultaneously to >> this advisory, and contains a kernel patch implementing a >> workaround for a >> more broad class of vulnerabilities. However, prior to those >> changes, no >> workaround is available. >> >> V. Solution >> >> Perform one of the following: >> >> 1) Upgrade your vulnerable system to 6-STABLE, or to the >> RELENG_6_4, or >> RELENG_6_3 security branch dated after the correction date. >> >> 2) To patch your present system: >> >> The following patches have been verified to apply to FreeBSD 6.3 >> and 6.4. >> >> a) Download the relevant patch from the location below, and verify >> the >> detached PGP signature using your PGP utility. >> >> # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch >> # fetch http://security.FreeBSD.org/patches/SA-09:13/pipe.patch.asc >> >> b) Apply the patch. >> >> # cd /usr/src >> # patch < /path/to/patch >> >> c) Recompile your kernel as described in >> and reboot >> the >> system. >> >> VI. Correction details >> >> The following list contains the revision numbers of each file that >> was >> corrected in FreeBSD. >> >> CVS: >> >> Branch >> Revision >> Path >> - >> --- >> --- >> ------------------------------------------------------------------- >> RELENG_6 >> src/sys/kern/kern_event.c >> 1.93.2.7 >> src/sys/kern/kern_fork.c >> 1.252.2.8 >> src/sys/kern/sys_pipe.c >> 1.184.2.6 >> src/sys/sys/event.h >> 1.32.2.1 >> src/sys/sys/pipe.h >> 1.29.2.1 >> RELENG_6_4 >> src/UPDATING 1.416.2.40.2.11 >> src/sys/conf/newvers.sh 1.69.2.18.2.13 >> src/sys/kern/kern_event.c 1.93.2.6.6.2 >> src/sys/kern/kern_fork.c 1.252.2.7.4.2 >> src/sys/kern/sys_pipe.c 1.184.2.4.2.3 >> src/sys/sys/event.h >> 1.32.12.2 >> src/sys/sys/pipe.h >> 1.29.16.2 >> RELENG_6_3 >> src/UPDATING 1.416.2.37.2.18 >> src/sys/conf/newvers.sh 1.69.2.15.2.17 >> src/sys/kern/kern_event.c 1.93.2.6.4.1 >> src/sys/kern/kern_fork.c 1.252.2.7.2.1 >> src/sys/kern/sys_pipe.c 1.184.2.2.6.3 >> src/sys/sys/event.h >> 1.32.10.1 >> src/sys/sys/pipe.h >> 1.29.12.1 >> - >> --- >> --- >> ------------------------------------------------------------------- >> >> Subversion: >> >> Branch/path >> Revision >> - >> --- >> --- >> ------------------------------------------------------------------- >> stable/6/ >> r197715 >> releng/6.4/ >> r197715 >> releng/6.3/ >> r197715 >> - >> --- >> --- >> ------------------------------------------------------------------- >> >> VII. References >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=179243 >> >> The latest revision of this advisory is available at >> http://security.FreeBSD.org/advisories/FreeBSD-SA-09:13.pipe.asc >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (FreeBSD) >> >> iD8DBQFKxlthFdaIBMps37IRAlk2AJ9mUrNPd1RMztbzO4w7g+AxosqJzgCgmr5l >> FKxrbF0G4v9P6SyyfAdVOFY= >> =TWhC >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 >> " > From stef-list at memberwebs.com Sat Oct 3 03:01:56 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Sat Oct 3 03:17:41 2009 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-09:05.null In-Reply-To: <200910022012.n92KCtLI004038@freefall.freebsd.org> References: <200910022012.n92KCtLI004038@freefall.freebsd.org> Message-ID: <4AC6BE97.1030406@memberwebs.com> FreeBSD Errata Notices wrote: > To actually enable the feature in FreeBSD 6.x and 7.x, add the > following to either /boot/loader.conf or /etc/sysctl.conf: > > security.bsd.map_at_zero="0" The sysctl.conf setting must not have quotes. Or you get this: sysctl: invalid integer '"0"' Instead one should use: security.bsd.map_at_zero=0 Cheers, Stef From des at des.no Sat Oct 3 11:26:03 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat Oct 3 11:26:10 2009 Subject: openssh concerns In-Reply-To: <20091003042802.O10039@sola.nimnet.asn.au> (Ian Smith's message of "Sat, 3 Oct 2009 04:43:08 +1000 (EST)") References: <4AC545C3.9020608@johnea.net> <19141.20047.694147.865710@hergotha.csail.mit.edu> <4AC61C0B.3050704@johnea.net> <20091003042802.O10039@sola.nimnet.asn.au> Message-ID: <86hbugyb06.fsf@ds4.des.no> Ian Smith writes: > http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers provides a > reasonably useful list of ports NOT to choose for an obscure ssh port. In practice, you have no choice but to use someting like 443 or 8080, because corporate firewalls often block everything but a small number of ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and 8080 go through a transparent proxy) DES -- Dag-Erling Sm?rgrav - des@des.no From ohauer at gmx.de Sat Oct 3 12:18:40 2009 From: ohauer at gmx.de (olli hauer) Date: Sat Oct 3 12:20:08 2009 Subject: openssh concerns Message-ID: <20091003121830.GA15170@sorry.mine.nu> >> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers >> provides a >> reasonably useful list of ports NOT to choose for an obscure ssh >> port. > > In practice, you have no choice but to use someting like 443 or 8080, > because corporate firewalls often block everything but a small number > of > ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and > 8080 > go through a transparent proxy) This may work if the firewall does only port and no additional protocol filtering. For many products used in corporate envirion it is even possible to filter ssh v1, skype, stunnel, openvpn with a verry high success rate within the first packet's on the wire. In case for the ssh server take a look into this parameters - LoginGraceTime - MaxAuthTries - MaxSessions - MaxStartups -- olli From purpleshadow100 at gmail.com Sat Oct 3 21:50:11 2009 From: purpleshadow100 at gmail.com (Eric Williams) Date: Sat Oct 3 21:50:18 2009 Subject: openssh concerns In-Reply-To: <20091003121830.GA15170@sorry.mine.nu> References: <20091003121830.GA15170@sorry.mine.nu> Message-ID: <4AC7B690.1060607@gmail.com> On 10/3/2009 7:18 AM, olli hauer wrote: >>> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers >>> provides a >>> reasonably useful list of ports NOT to choose for an obscure ssh >>> port. >> >> In practice, you have no choice but to use someting like 443 or 8080, >> because corporate firewalls often block everything but a small number >> of >> ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and >> 8080 >> go through a transparent proxy) > > This may work if the firewall does only port and no additional protocol > filtering. For many products used in corporate envirion it is even > possible to filter ssh v1, skype, stunnel, openvpn with a verry high > success rate within the first packet's on the wire. > > In case for the ssh server take a look into this parameters > - LoginGraceTime > - MaxAuthTries > - MaxSessions > - MaxStartups The absolute best way to filter out the attacks is to disable authentication methods other than public keys. Obviously this isn't possible in all situations, but it's very effective. Most attack bots will just disconnect when they attempt login, and it's almost impossible to crack a key and gain access. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20091003/cfcb2488/signature.pgp From db at danielbond.org Mon Oct 5 09:57:36 2009 From: db at danielbond.org (Daniel Bond) Date: Mon Oct 5 09:57:46 2009 Subject: openssh concerns In-Reply-To: <4AC7B690.1060607@gmail.com> References: <20091003121830.GA15170@sorry.mine.nu> <4AC7B690.1060607@gmail.com> Message-ID: Hi, as long as one uses good passwords, or disable authentication with passwords and only authorize using SSH-keys, you should be fine, if you can survive a little spam in your system logs. Personally I tend to either firewall the OpenSSH daemon, or leave it wide open. I don't really see the point in changing ports, as long as they are still publicly available. However, I'm concerned about the suggestion of using an unprivileged port (I see port 8080 suggested in earlier mails). If you really do need to use a unprivileged port, one solution could be rewrite the port-number with a NAT redirect, so NAT forwards to a privileged port. The reason for this, is that any local user is capable of binding to unprivileged ports. If for some reason, a local user/attacker is able to crash the OpenSSH daemon process, or bind to the socket before the sshd(8) does, the attacker can install an "evil sshd", to capture information about keys and passwords. Not all users care about host-key warnings. One workaround may be to create a special rule for sshd, with mac_portacl(4), so only sshd can bind to port 8080, or whatever. ( http://www.freebsd.org/doc/en/books/handbook/mac-portacl.html ). Best regards, Daniel Bond. On Oct 3, 2009, at 10:39 PM, Eric Williams wrote: > On 10/3/2009 7:18 AM, olli hauer wrote: >>>> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers >>>> provides a >>>> reasonably useful list of ports NOT to choose for an obscure ssh >>>> port. >>> >>> In practice, you have no choice but to use someting like 443 or >>> 8080, >>> because corporate firewalls often block everything but a small >>> number >>> of >>> ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and >>> 8080 >>> go through a transparent proxy) >> >> This may work if the firewall does only port and no additional >> protocol >> filtering. For many products used in corporate envirion it is even >> possible to filter ssh v1, skype, stunnel, openvpn with a verry high >> success rate within the first packet's on the wire. >> >> In case for the ssh server take a look into this parameters >> - LoginGraceTime >> - MaxAuthTries >> - MaxSessions >> - MaxStartups > > The absolute best way to filter out the attacks is to disable > authentication methods other than public keys. Obviously this isn't > possible in all situations, but it's very effective. Most attack bots > will just disconnect when they attempt login, and it's almost > impossible > to crack a key and gain access. > -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20091005/0da33ae1/PGP.pgp From budiyt at gmail.com Mon Oct 5 11:48:14 2009 From: budiyt at gmail.com (budsz) Date: Mon Oct 5 11:48:21 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:14.devfs In-Reply-To: <200910022012.n92KC4Tb003955@freefall.freebsd.org> References: <200910022012.n92KC4Tb003955@freefall.freebsd.org> Message-ID: <4d4dc3640910050423i24d9ee19q967152458b449df6@mail.gmail.com> On Sat, Oct 3, 2009 at 3:12 AM, FreeBSD Security Advisories wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ============================================================================= > FreeBSD-SA-09:14.devfs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Security Advisory > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?The FreeBSD Project > > Topic: ? ? ? ? ?Devfs / VFS NULL pointer race condition > > Category: ? ? ? core > Module: ? ? ? ? kern > Announced: ? ? ?2009-10-02 > Credits: ? ? ? ?Przemyslaw Frasunek > Affects: ? ? ? ?FreeBSD 6.x and 7.x > Corrected: ? ? ?2009-05-18 10:41:59 UTC (RELENG_7, 7.2-STABLE) > ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4) > ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8) > ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) > ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) > ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) > > For general information regarding FreeBSD Security Advisories, > including descriptions of the fields above, security branches, and the > following sections, please visit . > > I. ? Background > > The device file system (devfs) provides access to system devices, such as > storage devices and serial ports, via the file system namespace. > > VFS is the Virtual File System, which abstracts file system operations in > the kernel from the actual underlying file system. > > II. ?Problem Description > > Due to the interaction between devfs and VFS, a race condition exists > where the kernel might dereference a NULL pointer. > > III. Impact > > Successful exploitation of the race condition can lead to local kernel > privilege escalation, kernel data corruption and/or crash. > > To exploit this vulnerability, an attacker must be able to run code with user > privileges on the target system. > > IV. ?Workaround > > An errata note, FreeBSD-EN-09:05.null has been released simultaneously to > this advisory, and contains a kernel patch implementing a workaround for a > more broad class of vulnerabilities. ?However, prior to those changes, no > workaround is available. > > V. ? Solution > > Perform one of the following: > > 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the > RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch > dated after the correction date. > > 2) To patch your present system: > > The following patches have been verified to apply to FreeBSD 6.3, 6.4, > 7.1, and 7.2 systems. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 6.x] > # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs6.patch > # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs6.patch.asc > > [FreeBSD 7.x] > # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs7.patch > # fetch http://security.FreeBSD.org/patches/SA-09:14/devfs7.patch.asc > > b) Apply the patch. > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile your kernel as described in > and reboot the > system. > > VI. ?Correction details > > The following list contains the revision numbers of each file that was > corrected in FreeBSD. > > CVS: > > Branch ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Revision > ?Path > - ------------------------------------------------------------------------- > RELENG_6 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.114.2.17 > RELENG_6_4 > ?src/UPDATING ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.416.2.40.2.11 > ?src/sys/conf/newvers.sh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.69.2.18.2.13 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? 1.114.2.16.2.2 > RELENG_6_3 > ?src/UPDATING ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.416.2.37.2.18 > ?src/sys/conf/newvers.sh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.69.2.15.2.17 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? 1.114.2.15.2.1 > RELENG_7 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.149.2.9 > RELENG_7_2 > ?src/UPDATING ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.507.2.23.2.7 > ?src/sys/conf/newvers.sh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.72.2.11.2.8 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.149.2.8.2.2 > RELENG_7_1 > ?src/UPDATING ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.507.2.13.2.11 > ?src/sys/conf/newvers.sh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.72.2.9.2.12 > ?src/sys/fs/devfs/devfs_vnops.c ? ? ? ? ? ? ? ? ? ? ? ? ? ?1.149.2.4.2.2 > - ------------------------------------------------------------------------- > > Subversion: > > Branch/path ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Revision > - ------------------------------------------------------------------------- > stable/6/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r197715 > releng/6.4/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r197715 > releng/6.3/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r197715 > stable/7/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r192301 > releng/7.2/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r197715 > releng/7.1/ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? r197715 > - ------------------------------------------------------------------------- > > VII. References > > The latest revision of this advisory is available at > http://security.FreeBSD.org/advisories/FreeBSD-SA-09:14.devfs.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (FreeBSD) > > iD8DBQFKxltlFdaIBMps37IRAp4zAJwJEwIySGqxH4EXwc0wjkDXlcTb1wCfTltO > Syds53GSM0YbsMNUVMGsLaU= > =exPZ > -----END PGP SIGNATURE----- > _______________________________________________ > 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" > Hi folks, I just got some problem when compling my kerne. Here we go: rm -f hack.c MAKE=make sh /usr/src/sys/conf/newvers.sh WILLSZPROXY cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror vers.c linking kernel.debug kern_fork.o(.text+0x1d18): In function `fork1': /usr/src/sys/kern/kern_fork.c:737: undefined reference to `knote_fork' *** Error code 1 Stop in /usr/obj/usr/src/sys/WILLSZPROXY. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. My box running FreeBSD 7.2-STABLE. Thanks in advance. -- budsz From bzeeb-lists at lists.zabbadoz.net Mon Oct 5 12:35:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 5 12:35:19 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:14.devfs In-Reply-To: <4d4dc3640910050423i24d9ee19q967152458b449df6@mail.gmail.com> References: <200910022012.n92KC4Tb003955@freefall.freebsd.org> <4d4dc3640910050423i24d9ee19q967152458b449df6@mail.gmail.com> Message-ID: <20091005123008.R26486@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, budsz wrote: > On Sat, Oct 3, 2009 at 3:12 AM, FreeBSD Security Advisories > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> ============================================================================= >> FreeBSD-SA-09:14.devfs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Security Advisory >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?The FreeBSD Project >> >> Topic: ? ? ? ? ?Devfs / VFS NULL pointer race condition >> >> Category: ? ? ? core >> Module: ? ? ? ? kern >> Announced: ? ? ?2009-10-02 >> Credits: ? ? ? ?Przemyslaw Frasunek >> Affects: ? ? ? ?FreeBSD 6.x and 7.x >> Corrected: ? ? ?2009-05-18 10:41:59 UTC (RELENG_7, 7.2-STABLE) >> ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4) >> ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8) >> ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) >> ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) >> ? ? ? ? ? ? ? ?2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) > Hi folks, > > I just got some problem when compling my kerne. Here we go: > > rm -f hack.c > MAKE=make sh /usr/src/sys/conf/newvers.sh WILLSZPROXY > cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc > -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -Werror vers.c > linking kernel.debug > kern_fork.o(.text+0x1d18): In function `fork1': > /usr/src/sys/kern/kern_fork.c:737: undefined reference to `knote_fork' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/WILLSZPROXY. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > My box running FreeBSD 7.2-STABLE. Thanks in advance. If you are on 7.2-STABLE only the EN patch would have been interesting for you. The FreeBSD-SA-09:14.devfs was not applicable to a 7.2-STABLE from 2009-05-18 and later. Can you please check that you didn't accidentally patch something that didn't need to be patched anymore? /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From MH at kernel32.de Mon Oct 5 14:08:06 2009 From: MH at kernel32.de (Marian Hettwer) Date: Mon Oct 5 14:08:13 2009 Subject: openssh concerns In-Reply-To: <20091003121830.GA15170@sorry.mine.nu> References: <20091003121830.GA15170@sorry.mine.nu> Message-ID: <4AC9F9C1.9030702@kernel32.de> Hej All, olli hauer schrieb: >>> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers >>> provides a >>> reasonably useful list of ports NOT to choose for an obscure ssh >>> port. >>> >> In practice, you have no choice but to use someting like 443 or 8080, >> because corporate firewalls often block everything but a small number >> of >> ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and >> 8080 >> go through a transparent proxy) >> > > This may work if the firewall does only port and no additional protocol > filtering. For many products used in corporate envirion it is even > possible to filter ssh v1, skype, stunnel, openvpn with a verry high > success rate within the first packet's on the wire. > > In case for the ssh server take a look into this parameters > - LoginGraceTime > - MaxAuthTries > - MaxSessions > - MaxStartups > > I think nobody mentioned the overload rules from pf(4). I keep away most of the tried attempts by using it. Setup is pretty easy: table persist pass quick log proto { tcp, udp } from any to any port ssh label "ssh-brute" \ flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 10/30, \ overload flush global) Obviously, read pf.conf(5) to check what you might want to configure WRT max-src-conn and max-src-conn-rate. These rules in combination with enforced key authentication should keep your logfiles clean and your host secured. No need to go to another tcp port. Cheers, Marian From lyndon at orthanc.ca Mon Oct 5 18:03:51 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg - VE6BBM/VE7TFX) Date: Mon Oct 5 18:03:58 2009 Subject: openssh concerns In-Reply-To: Message-ID: > Personally I tend to either firewall the OpenSSH daemon, or leave it > wide open. I don't really see the point in changing ports, as long as > they are still publicly available. The ssh bots only seem to probe port 22. In well over a year of running my ssh servers on a different (very low numbered) port I haven't logged a single probe (across about a dozen highly visible servers). --lyndon From booloo at ucsc.edu Mon Oct 5 18:30:22 2009 From: booloo at ucsc.edu (Mark Boolootian) Date: Mon Oct 5 18:30:28 2009 Subject: openssh concerns In-Reply-To: References: Message-ID: <20091005181634.GA37622@root.ucsc.edu> There's always fwknop: http://www.cipherdyne.org/fwknop/ From a.kuriger at liquidphlux.com Mon Oct 5 18:32:39 2009 From: a.kuriger at liquidphlux.com (Andrew Kuriger) Date: Mon Oct 5 18:32:48 2009 Subject: openssh concerns In-Reply-To: References: Message-ID: On Mon, 5 Oct 2009 12:03:44 -0600, Lyndon Nerenberg - VE6BBM/VE7TFX wrote: >> Personally I tend to either firewall the OpenSSH daemon, or leave it >> wide open. I don't really see the point in changing ports, as long as >> they are still publicly available. > > The ssh bots only seem to probe port 22. In well over a year of > running my ssh servers on a different (very low numbered) port I > haven't logged a single probe (across about a dozen highly visible > servers). > > --lyndon > I personally don't use it (although I'm considering it), but you could look into port knocking. Changing the port that SSHD binds to definitely falls under that obscurity line since if somebody is targeting you, they very well may run a SYN scan (Mmm namp) and read the banners to quickly find out what port you are running sshd on, then target bots accordingly. Granted, if somebody is not specifically targeting you and is just scanning ranges to find sshd on 22 they will pass you right up since that port will be closed. Andrew -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From lyndon at orthanc.ca Mon Oct 5 18:47:02 2009 From: lyndon at orthanc.ca (Lyndon Nerenberg - VE6BBM/VE7TFX) Date: Mon Oct 5 18:47:08 2009 Subject: openssh concerns In-Reply-To: Message-ID: <7f1779bf9fa52b6cbf7a8384883232a6@yyc.orthanc.ca> > Granted, if somebody is not specifically targeting you and is just scanning > ranges to find sshd on 22 they will pass you right up since that port will > be closed. The port change was intended only to avoid the port scanners. From m at micheas.net Mon Oct 5 20:26:42 2009 From: m at micheas.net (Micheas Herman) Date: Mon Oct 5 20:26:49 2009 Subject: openssh concerns In-Reply-To: <7f1779bf9fa52b6cbf7a8384883232a6@yyc.orthanc.ca> References: <7f1779bf9fa52b6cbf7a8384883232a6@yyc.orthanc.ca> Message-ID: <1254772966.30618.1405.camel@vcampaign> On Mon, 2009-10-05 at 12:46 -0600, Lyndon Nerenberg - VE6BBM/VE7TFX wrote: > > Granted, if somebody is not specifically targeting you and is just scanning > > ranges to find sshd on 22 they will pass you right up since that port will > > be closed. > > The port change was intended only to avoid the port scanners. And when you get notices in your logs, you can respond, as you know you are being targeted and can take appropriate responses. The biggest reason I can see for running ssh on an non-standard port is increasing the signal to noise ratio in the logs. If you can investigate every failed ssh login, you should be safer than if you ignore 40,000 failed logins a day. Just my experience, but of course being able to effortlessly investigate 40,000 failed logins would probably be a better situation. > > _______________________________________________ > 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" -- Things past redress and now with me past care. -- William Shakespeare, "Richard II" From a.kuriger at liquidphlux.com Mon Oct 5 20:56:28 2009 From: a.kuriger at liquidphlux.com (Andrew Kuriger) Date: Mon Oct 5 20:56:34 2009 Subject: openssh concerns In-Reply-To: <1254772966.30618.1405.camel@vcampaign> References: <7f1779bf9fa52b6cbf7a8384883232a6@yyc.orthanc.ca> <1254772966.30618.1405.camel@vcampaign> Message-ID: On Mon, 05 Oct 2009 13:02:46 -0700, Micheas Herman wrote: > On Mon, 2009-10-05 at 12:46 -0600, Lyndon Nerenberg - VE6BBM/VE7TFX > wrote: >> > Granted, if somebody is not specifically targeting you and is just >> > scanning >> > ranges to find sshd on 22 they will pass you right up since that port >> > will >> > be closed. >> >> The port change was intended only to avoid the port scanners. > > > And when you get notices in your logs, you can respond, as you > know you are being targeted and can take appropriate responses. > > The biggest reason I can see for running ssh on an non-standard > port is increasing the signal to noise ratio in the logs. > > If you can investigate every failed ssh login, you should be > safer than if you ignore 40,000 failed logins a day. > > Just my experience, but of course being able to effortlessly > investigate 40,000 failed logins would probably be a better > situation. > I agree its not a bad thing to have sshd running on a non-standard port, but just wait until the bot herder with 10,000 bots under his control finds out what port your running it under... If your receiving 40,000 false logins a day, your either targeted, or extremely popular and probably shouldn't be running sshd that is accessible via the internet anyways, aside from port knocking/VPN. I don't know about you, but when I have been attacked its not 100 connections from the same IP, its thousands randomly throughout the world. It does however eliminate the background script kiddie noise and sshd scanners, but once your found out/targeted its all in the air anyways. -Andrew -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From erik at cederstrand.dk Mon Oct 5 21:47:42 2009 From: erik at cederstrand.dk (Erik Cederstrand) Date: Mon Oct 5 21:47:48 2009 Subject: openssh concerns In-Reply-To: References: <7f1779bf9fa52b6cbf7a8384883232a6@yyc.orthanc.ca> <1254772966.30618.1405.camel@vcampaign> Message-ID: Den 05/10/2009 kl. 22.55 skrev Andrew Kuriger: > I agree its not a bad thing to have sshd running on a non-standard > port, > but just wait until the bot herder with 10,000 bots under his > control finds > out what port your running it under... It's like spam filtering: at the time this actually becomes a problem, we change tactics. It's not about finding the perfect solution, it's about having a manageable log. My log is being spammed, and changing the port solves that. "botnet-12-34-56-78.couldntcareless.mx tried to log into your nonexistent oracle account" is not a very interesting log message. Someone bruteforcing a valid non-trivial account name on a non-standard port is, even though they will never succeed. > If your receiving 40,000 false logins a day, your either targeted, or > extremely popular and probably shouldn't be running sshd that is > accessible > via the internet anyways, aside from port knocking/VPN. 6 normal, very boring colo-servers here. 40.000 login attempts a day per server on port 22 sounds about right - that's still almost nothing translated to bandwidth. I use only key-based auth and the bots were still trying, som I'm pretty sure it's just someone trying to bruteforce every IP under the sun looking for low-hanging fruit. I still need ssh access for normal admin work so disabling ssh is not an option. Erik From dougb at FreeBSD.org Mon Oct 5 22:24:43 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 5 22:24:51 2009 Subject: openssh concerns In-Reply-To: References: <20091003121830.GA15170@sorry.mine.nu> <4AC7B690.1060607@gmail.com> Message-ID: <4ACA6BE8.3000402@FreeBSD.org> Daniel Bond wrote: > However, I'm concerned about the suggestion of using an > unprivileged port Please explain your reasoning, and how it's relevant in a world where the vast majority of Internet users have complete administrative control over the systems they use. Doug -- This .signature sanitized for your protection From chris at noncombatant.org Mon Oct 5 22:57:43 2009 From: chris at noncombatant.org (Chris Palmer) Date: Mon Oct 5 22:57:50 2009 Subject: openssh concerns In-Reply-To: <4ACA6BE8.3000402@FreeBSD.org> References: <20091003121830.GA15170@sorry.mine.nu> <4AC7B690.1060607@gmail.com> <4ACA6BE8.3000402@FreeBSD.org> Message-ID: <20091005225736.GA28186@noncombatant.org> Doug Barton writes: > > However, I'm concerned about the suggestion of using an unprivileged > > port > > Please explain your reasoning, and how it's relevant in a world where the > vast majority of Internet users have complete administrative control over > the systems they use. Shared shell servers do still exist, and on such systems, it would be unwise to allow low-privilege users to be able to listen on what the other users think the "official" SSH port is. The port ACL idea, and the port != 22 && port < 1024 idea, therefore still make sense. Of course, can we really trust that local low-privilege users can't escalate to root? Sob. As for the log spam issue, the problem is more general than just SSH -- do you have your web server listen on port 81, too? ;) There's tons of spam in there, and there's tons of real stuff in there. Web apps are real apps... what are people doing with them? The general solution is something like Marcus Ranum's "artificial ignorance". Whether it is a cheap-ass Python script like mine or a real grown-up log management system like Splunk, you want something that lets you easily see the real stuff and ignore the spam for ALL your apps, not just SSH. It doesn't take much effort to generate the cheap-ass solution (ping me privately if you want my trivial code), but the pay-off is huge. Imagine relevant cron emails! The dream is alive... -- http://www.noncombatant.org/ http://hemiolesque.blogspot.com/ From fbsdq at peterk.org Tue Oct 6 05:31:33 2009 From: fbsdq at peterk.org (Peter) Date: Tue Oct 6 05:31:41 2009 Subject: openssh concerns In-Reply-To: <4AC9F9C1.9030702@kernel32.de> References: <20091003121830.GA15170@sorry.mine.nu> <4AC9F9C1.9030702@kernel32.de> Message-ID: > Hej All, > > olli hauer schrieb: >>>> http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers >>>> provides a >>>> reasonably useful list of ports NOT to choose for an obscure ssh >>>> port. >>>> >>> In practice, you have no choice but to use someting like 443 or 8080, >>> because corporate firewalls often block everything but a small number >>> of >>> ports (usually 20, 22, 80, 443, 8080, and odds are that 20, 80 and >>> 8080 >>> go through a transparent proxy) >>> >> >> This may work if the firewall does only port and no additional protocol >> filtering. For many products used in corporate envirion it is even >> possible to filter ssh v1, skype, stunnel, openvpn with a verry high >> success rate within the first packet's on the wire. >> >> In case for the ssh server take a look into this parameters >> - LoginGraceTime >> - MaxAuthTries >> - MaxSessions >> - MaxStartups >> >> > I think nobody mentioned the overload rules from pf(4). I keep away most > of the tried attempts by using it. > Setup is pretty easy: > table persist > pass quick log proto { tcp, udp } from any to any port ssh label > "ssh-brute" \ > flags S/SA keep state \ > (max-src-conn 15, max-src-conn-rate 10/30, \ > overload flush global) > > Obviously, read pf.conf(5) to check what you might want to configure WRT > max-src-conn and max-src-conn-rate. > > These rules in combination with enforced key authentication should keep > your logfiles clean and your host secured. > No need to go to another tcp port. > > Cheers, > Marian Or combine that with portknocking - Only open port 22 after X number of attempts to connect on port 1234: # Table for allowed IPs # [gets auto populated via portknocking] table persist . .. ... block #default block policy # Allow everyone to hit 'any' on port '1234' - pf proxies tcp connection # [if not using 'synproxy', the connection is never established to # 'overload' the rule] # 5 attempts in 15 seconds pass in log quick proto tcp from any to any port {1234} synproxy state \ (max-src-conn-rate 5/15, overload ) #Allow IPs that have been 'overload'ed into the portknock_ssh table pass in log quick proto tcp from {} to any port {ssh} . .. ... Then put a crontab on a per needed basis to expire all IPs in that table that have not been referenced in 60 seconds: * * * * * /sbin/pfctl -vt portknock_ssh -T expire 60 All established sessions will be kept alive, all new sessions will need to portknock after the IP is cleared from table ]Peter[ From des at des.no Tue Oct 6 09:06:35 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Oct 6 09:06:42 2009 Subject: openssh concerns In-Reply-To: (Peter's message of "Mon, 5 Oct 2009 23:04:48 -0600 (MDT)") References: <20091003121830.GA15170@sorry.mine.nu> <4AC9F9C1.9030702@kernel32.de> Message-ID: <86vdis99ie.fsf@ds4.des.no> "Peter" writes: > Or combine that with portknocking - Only open port 22 after X number of > attempts to connect on port 1234: As has already been explained, that's no good if you need to ssh in from behind a corporate firewall that blocks everything except 20, 22, 80 and 443. DES -- Dag-Erling Sm?rgrav - des@des.no From freebsd at optiksecurite.com Tue Oct 6 16:42:57 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Tue Oct 6 16:43:06 2009 Subject: Update on protection against slowloris In-Reply-To: <4AC3FA90.1000405@gibfest.dk> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> Message-ID: <4ACB7391.5040204@optiksecurite.com> Thomas Rasmussen a ?crit : > Martin Turgeon wrote: >> Hi list! >> >> We tested mod_antiloris 0.4 and found it quite efficient, but before >> putting it in production, we would like to hear some feedback from >> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is >> anyone using it? Do you have any other way to patch against Slowloris >> other than putting a proxy in front or using the HTTP accept filter? >> >> Thanks for your feedback, >> >> Martin >> _______________________________________________ >> 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" > Hello, > > I am using it succesfully although not under any serious load, same > Apache and FreeBSD versions. I found it easy (compared to the > alternatives) and efficient, and no I don't know of any other ways of > blocking the attack, short of using Varnish or similar. However, > accf_http doesn't help at all, since HTTP POST requests bypass the > filter. HTTP POST can be enabled by passing the -httpready switch to > Slowloris. > > Please report back with your findings, I've been wondering how it > would perform under load. > > Best of luck with it, > > Thomas Rasmussen > Hi everyone, We haven't put mod_antiloris in production yet, but I wrote this little shell script to protect us against distributed attack. It's running every minutes in crontab. It checks for any IP with more than 100 connections in FIN_WAIT_2 state and block those IP in PF. #!/bin/sh /usr/bin/netstat -nfinet | grep FIN_WAIT_2 > netstat.out /usr/local/sbin/expiretable -t 300 slowloris for ip in `awk '{print $5}' netstat.out | awk -F. '{print $1"."$2"."$3"."$4}' | sort | uniq` ; do if [ `grep -c $ip netstat.out` -gt 100 ] ; then pfctl -t slowloris -Ta $ip 2> /dev/null fi done Did anyone have any comments on the script itself or the method used to detect the attackers? Thanks for your input, Martin From mwoliver at gmail.com Tue Oct 6 18:41:18 2009 From: mwoliver at gmail.com (Mike Oliver) Date: Tue Oct 6 18:41:25 2009 Subject: openssh concerns In-Reply-To: <20091005181634.GA37622@root.ucsc.edu> References: <20091005181634.GA37622@root.ucsc.edu> Message-ID: <8c64b8d20910061119ya32f330s876809d96e33fb49@mail.gmail.com> On Mon, Oct 5, 2009 at 14:16, Mark Boolootian wrote: > > There's always fwknop: ?http://www.cipherdyne.org/fwknop/ Back when I ran ipfw I had a Bourne script that would change the outside port (translated to 22 on the inside by natd) to something between 10000 and 65500 every so often, maybe hourly. The script would rewrite the natd.conf, bounce natd, do some other stuff I can't remember, and finish by sending me the new outside port number via SMS. I did that for a few years and never had a single problem with it. That was a fun project. -- Mike Oliver, KT2T +1-863-738-2334 kt2t@arrl.net -or- mwoliver@gmail.com From jhell at DataIX.net Tue Oct 6 20:18:26 2009 From: jhell at DataIX.net (jhell) Date: Tue Oct 6 20:18:32 2009 Subject: openssh concerns In-Reply-To: <86vdis99ie.fsf@ds4.des.no> References: <20091003121830.GA15170@sorry.mine.nu> <4AC9F9C1.9030702@kernel32.de> <86vdis99ie.fsf@ds4.des.no> Message-ID: On Tue, 6 Oct 2009 11:06 +0200, des@ wrote: > "Peter" writes: >> Or combine that with portknocking - Only open port 22 after X number of >> attempts to connect on port 1234: > > As has already been explained, that's no good if you need to ssh in from > behind a corporate firewall that blocks everything except 20, 22, 80 and > 443. > > DES > Don't forget about making good use of the following configuration turntables. You can enforce a default policy of deny by just saying that a user must be in the group of AllowGroups. This does enforce a little bit more of a administrative overhead but that's for your staff and policy to decide. AllowGroups AllowUsers DenyGroups DenyUsers Collect tried user names and don't allow those to be added to your system as legitimate users is another approach. Configuring pw(8) and adduser(8) for this will be a good exercise. -- %{----------------------------------------------------+ | dataix.net!jhell 2048R/89D8547E 2009-09-30 | | BSD since FreeBSD 4.2 Linux since Slackware 2.1 | | 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E | +----------------------------------------------------%} From wollman at bimajority.org Tue Oct 6 21:09:20 2009 From: wollman at bimajority.org (Garrett Wollman) Date: Tue Oct 6 21:38:56 2009 Subject: openssh concerns In-Reply-To: References: <20091003121830.GA15170@sorry.mine.nu> <4AC9F9C1.9030702@kernel32.de> <86vdis99ie.fsf@ds4.des.no> Message-ID: <19147.45544.619211.308287@hergotha.csail.mit.edu> < said: > Don't forget about making good use of the following configuration > turntables. You can enforce a default policy of deny by just saying that a > user must be in the group of AllowGroups. This does enforce a little bit > more of a administrative overhead but that's for your staff and policy to > decide. Indeed, for a personal server that only I ever log in to, one of the first things that I do is add "AllowUsers wollman" to /usr/local/etc/ssh/sshd_config. That's just a belt-and-suspenders thing, though, to make sure that I don't fat-finger the password file or something. I generally ignore the ssh "invalid user" complaints -- I have a modified version of /etc/periodic/security/800.loginfail that filters them out -- because they're totally irrelevant and have no impact on security. That allows me to pay attention to the (very occasional) password failures on real user accounts. -GAWollman From freebsd at optiksecurite.com Thu Oct 8 16:19:21 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Thu Oct 8 16:19:29 2009 Subject: Update on protection against slowloris In-Reply-To: <4ACB7391.5040204@optiksecurite.com> References: <4AC37D6B.3060409@optiksecurite.com> <4AC3FA90.1000405@gibfest.dk> <4ACB7391.5040204@optiksecurite.com> Message-ID: <4ACE10F5.2000303@optiksecurite.com> Martin Turgeon a ?crit : > Thomas Rasmussen a ?crit : >> Martin Turgeon wrote: >>> Hi list! >>> >>> We tested mod_antiloris 0.4 and found it quite efficient, but before >>> putting it in production, we would like to hear some feedback from >>> freebsd users. We are using Apache 2.2.x on Freebsd 6.2 and 7.2. Is >>> anyone using it? Do you have any other way to patch against >>> Slowloris other than putting a proxy in front or using the HTTP >>> accept filter? >>> >>> Thanks for your feedback, >>> >>> Martin >>> _______________________________________________ >>> 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" >> Hello, >> >> I am using it succesfully although not under any serious load, same >> Apache and FreeBSD versions. I found it easy (compared to the >> alternatives) and efficient, and no I don't know of any other ways of >> blocking the attack, short of using Varnish or similar. However, >> accf_http doesn't help at all, since HTTP POST requests bypass the >> filter. HTTP POST can be enabled by passing the -httpready switch to >> Slowloris. >> >> Please report back with your findings, I've been wondering how it >> would perform under load. >> >> Best of luck with it, >> >> Thomas Rasmussen >> > Hi everyone, > > We haven't put mod_antiloris in production yet, but I wrote this > little shell script to protect us against distributed attack. It's > running every minutes in crontab. It checks for any IP with more than > 100 connections in FIN_WAIT_2 state and block those IP in PF. > > #!/bin/sh > > /usr/bin/netstat -nfinet | grep FIN_WAIT_2 > netstat.out > > /usr/local/sbin/expiretable -t 300 slowloris > > for ip in `awk '{print $5}' netstat.out | awk -F. '{print > $1"."$2"."$3"."$4}' | sort | uniq` ; do > if [ `grep -c $ip netstat.out` -gt 100 ] ; then > pfctl -t slowloris -Ta $ip 2> /dev/null > fi > done > > Did anyone have any comments on the script itself or the method used > to detect the attackers? > > Thanks for your input, > > Martin > Sorry for replying to my own post, but I have new informations to share. We putted in production mod_antiloris and my script yesterday night. No problem yet with the module but I got a few false positive with my script. It seems that there are a few IP that got more than 100 simultaneous connections in FIN_WAIT_2 state. We noticed that a lot of the FIN_WAIT_2 connections were related to a jail running Lighttpd (immune to slowloris, which IP is 127.0.0.25) so I modified the initial netstat so it looks like that: /usr/bin/netstat -nfinet | grep -v 127.0.0.25 | grep FIN_WAIT_2 > netstat.out We didn't get any false positive since then but I'm wondering how a client can have so many unclosed connections? To get in FIN_WAIT state, it's the server that closed the connections but the client never closed it's side of the connections. Does anyone have an idea how this can happen? Is this because of a bad browser, a bad OS/TCP stack or something else? Thanks for taking the time to shed some light on this, Martin From remodeler at alentogroup.org Sat Oct 10 04:14:39 2009 From: remodeler at alentogroup.org (remodeler) Date: Sat Oct 10 04:14:46 2009 Subject: GPU crypto acceleration? Message-ID: <20091010035529.M29871@alentogroup.org> I'm wondering if there's any core functionality or third-party utilities to off-load cryptographic processing to the GPU or audio chip, instead of using a hardware acceleration expansion card? This is on amd64 build. Thank you. From chris at noncombatant.org Sat Oct 10 06:36:42 2009 From: chris at noncombatant.org (Chris Palmer) Date: Sat Oct 10 06:36:49 2009 Subject: GPU crypto acceleration? In-Reply-To: <20091010035529.M29871@alentogroup.org> References: <20091010035529.M29871@alentogroup.org> Message-ID: <65088DA3-6AFD-4758-B2C3-A88F9B15AEA1@noncombatant.org> On Oct 9, 2009, at 8:57 PM, remodeler wrote: > I'm wondering if there's any core functionality or third-party > utilities to > off-load cryptographic processing to the GPU or audio chip, instead > of using a > hardware acceleration expansion card? This is on amd64 build. Check out the Nvidia Tesla, although it probably will only work on Windows and Linux. What is your application, though? -- http://www.noncombatant.org/ http://hemiolesque.blogspot.com/ From case at sdf.lonestar.org Wed Oct 14 18:15:03 2009 From: case at sdf.lonestar.org (John Case) Date: Wed Oct 14 18:24:44 2009 Subject: FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR) Message-ID: There are a number of hardware solutions for performing AES-CTR in hardware - for example the broadcom BCM5825, which is supported by the ubsec driver. The problem is that OpenSSL does not currently support hardware acceleration of AES-CTR. The solution on a Sun system is to use the Sun crypto framework APIs (PKCS#11) which does support AES-CTR in hardware. Is there an analagous API in FreeBSD that I could implement in my code so as to use the hardware AES-CTR of devices supported by ubsec ? Or do I need to directly manipulate ubsec with my actual application in order to do this ? From rwmaillists at googlemail.com Wed Oct 14 22:54:43 2009 From: rwmaillists at googlemail.com (RW) Date: Wed Oct 14 22:54:50 2009 Subject: FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR) In-Reply-To: References: Message-ID: <20091014232307.4f6d8479@gumby.homeunix.com> On Wed, 14 Oct 2009 18:02:36 +0000 (UTC) John Case wrote: > > There are a number of hardware solutions for performing AES-CTR in > hardware - for example the broadcom BCM5825, which is supported by > the ubsec driver. > > The problem is that OpenSSL does not currently support hardware > acceleration of AES-CTR. The solution on a Sun system is to use the > Sun crypto framework APIs (PKCS#11) which does support AES-CTR in > hardware. > > Is there an analagous API in FreeBSD that I could implement in my > code so as to use the hardware AES-CTR of devices supported by ubsec ? Aside from crypto(3) (OpenSSL), there's also crypto(9) (kernel) and crypto(4) (userland), but they don't appear to support CTR - just CBC. From case at sdf.lonestar.org Fri Oct 16 02:26:47 2009 From: case at sdf.lonestar.org (John Case) Date: Fri Oct 16 05:04:35 2009 Subject: FreeBSD equivalent to Sun crypto framework APIs (PKCS#11) (for hardware AES-CTR) Message-ID: > There are a number of hardware solutions for performing AES-CTR in > hardware - for example the broadcom BCM5825, which is supported by > the ubsec driver. > > The problem is that OpenSSL does not currently support hardware > acceleration of AES-CTR. The solution on a Sun system is to use the > Sun crypto framework APIs (PKCS#11) which does support AES-CTR in > hardware. > > Is there an analagous API in FreeBSD that I could implement in my > code so as to use the hardware AES-CTR of devices supported by ubsec ? > Aside from crypto(3) (OpenSSL), there's also crypto(9) (kernel) and > crypto(4) (userland), but they don't appear to support CTR - just CBC. Understood. How difficult or trivial would it be to add AES-CTR to either crypto(9) or crypto(4) ? Are those just derived from OpenSSL in some way anyway ? If not, who is responsible for this kind of work ? From avalon at coombs.anu.edu.au Sat Oct 17 22:56:24 2009 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Sun Oct 18 03:31:19 2009 Subject: openssh concerns In-Reply-To: <21075_1254443471_4AC549CE_21075_106_1_4AC545C3.9020608@johnea.net> References: <21075_1254443471_4AC549CE_21075_106_1_4AC545C3.9020608@johnea.net> Message-ID: <1255819013.8559.1340620221@webmail.messagingengine.com> If this hasn't been mentioned already, disable password logins in sshd_config and require RSA authentication only. I do this on all hosts I administer that are internet accessible and it allows me to confidently ignore all of the password guessing attacks, resulting in peace of mind. Darren RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no From cperciva at freebsd.org Sun Oct 18 12:36:27 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Sun Oct 18 12:36:35 2009 Subject: HEADS UP: FreeBSD 6.3 EoL coming soon Message-ID: <4ADB0BCA.8050904@freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, On January 31st, FreeBSD 6.3 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of this release are strongly encouraged to upgrade to a newer release before that date -- more conservative users will probably wish to upgrade to FreeBSD 6.4 or FreeBSD 7.1 (which are both extended-support branches), while others will probably wish to upgrade to FreeBSD 7.2 or the upcoming FreeBSD 8.0. The freebsd-update(8) utility can be used to upgrade i386 and amd64 systems from 6.3-RELEASE (or 6.3-RELEASE-pX for some X) to 6.4-RELEASE using binary updates (i.e., without compiling from source) as described in the 6.4-RELEASE announcement; given an adequate internet connection, this process usually takes 15 minutes or less. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_6_3 |6.3-RELEASE |Extended|January 18, 2008 |January 31, 2010 | |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |May 31, 2010 | +---------------------------------------------------------------------+ When FreeBSD 8.0-RELEASE is released, it will receive "Normal" support, i.e., it will be supported for at least 12 months. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrbC8oACgkQFdaIBMps37KQOQCgmnXQGtI/hKlFCT+dKAXzGX90 gi4An0uC5y3SLNtrTxOvYD6HqpnrR99k =fl+f -----END PGP SIGNATURE----- From rea-fbsd at codelabs.ru Sat Oct 24 18:28:49 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sat Oct 24 18:29:00 2009 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages In-Reply-To: References: <48DE5CC0.9000708@localhost.inse.ru> <48DF6735.4030906@quip.cz> <4bESZpNwE3z/DdlE2fwK/BXzQSo@2MQ0uKCiT7mdMUuLeUzs8Nv3ToQ> Message-ID: Fri, May 01, 2009 at 10:42:21PM +0400, Eygene Ryabinkin wrote: > Gentlemen, good day. > > Just a reminder about this PR -- it is already a bit old. But it is > still viable and kicking on many machines of mine. I am seeing speedups > from 10x to 26x comparing to the plain portaudit. Since VuXML database > will only grow, this will be good to consider these patches and (likely) > integrate them into main trees. > > Could someone, please, look at the patches? I had uploaded slightly > modified patches to the old locations. Most of changes were cosmetic: > whitespace and so on. No real code was changed. Hmm, I am going to be a bit nasty this time -- the PR lies for 1.5 years and no one really looked at it. Though, Simon and Martin promised to do so. If you really don't want this patch to go in -- just say, I'll try to rework it to suit the project's needs. But for me it is rediculous that no one is really interested in speeding up the stuff: number of installed ports and number of VuXML entries will only grow and the patch provides great opportunity to keep things very fast for the vast amount of time. Sorry for a slightly harsh tone, but I am really disappointed with the handling of this PR. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From naveen.bn at globaledgesoft.com Tue Oct 27 11:37:20 2009 From: naveen.bn at globaledgesoft.com (Naveen BN) Date: Tue Oct 27 11:37:26 2009 Subject: issue with outbound SA selection Message-ID: <4AE6D27A.8060700@globaledgesoft.com> Hi All, I have a problem using SA with selectors based on , and for outbound traffic. I have written two out bound SA's for the same destination IP with different destination port, but I am seeing wrong SA has been selected for outbound traffic. My concern is why the SA is not getting selected based on ports mentioned security policy. FYI.. content of file setkey.conf /************************* start setkey.conf ************************/ flush; spdflush; add 172.16.8.36 172.16.8.38[*800]* esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6; add 172.16.8.38[500] 172.16.8.36 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df -A hmac-md5 0x96358c90783bbfa3d7b196ceabe0536b; add 172.16.8.36 172.16.8.38[*500] *esp 0x208 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831 -A hmac-md5 0xc0291ff014dccdd03874d9e8e4cdf3e6; # Security policies spdadd 172.16.8.36 172.16.8.38[*800]* esp -P out ipsec esp/tunnel/172.16.8.36-172.16.8.38/require; spdadd 172.16.8.38[*800] *172.16.8.36 esp -P in ipsec esp/tunnel/172.16.8.38-172.16.8.36/require; /************************* end setkey.conf ************************/ *When a packet is sent to dest port 800 , SA which is getting selected is 0x208[spi] with dstport 500 instead of 0x201[spi] **with dstport 800 instead**.* Please provide the criteria for outboud SA selection, please guide me regarding this issue . My Linux kernel version is 2.6.23.1-42.fc8 Thanks and Regards Naveen From bzeeb-lists at lists.zabbadoz.net Tue Oct 27 13:35:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Tue Oct 27 13:35:35 2009 Subject: issue with outbound SA selection In-Reply-To: <4AE6D27A.8060700@globaledgesoft.com> References: <4AE6D27A.8060700@globaledgesoft.com> Message-ID: <20091027133313.W91695@maildrop.int.zabbadoz.net> On Tue, 27 Oct 2009, Naveen BN wrote: Hi, let me copy & paste what I rpelied on bugs@ already. > My Linux kernel version is 2.6.23.1-42.fc8 Unfortunately this is not a linux but a FreeBSD mailing list. If your issue is with a FreeBSD kernel we can certainly help, if you are running a linux kernel I'd try the linux-ipsec list, which no longer seems to exist? A good fallback might be linux-net or linux-netdev or a similar list. Good luck there. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing.