From chris at noncombatant.org Sat Aug 2 19:17:22 2008 From: chris at noncombatant.org (Chris Palmer) Date: Sat Aug 2 19:17:29 2008 Subject: A new kind of security needed In-Reply-To: References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Message-ID: <5D233428-9099-4924-B7F0-3017FD3C3E77@noncombatant.org> On Jul 28, 2008, at 12:28 PM, Matt Reimer wrote: > My idea was to basically have a secure file picker that grants the app > (e.g. Firefox) access to the file, in a way that would be transparent > to the user. For example, when Firefox wants to save a PDF it displays > the file picker as usual and the file is saved. Underneath what's > happening is that Firefox talks to the trusted system filepicker via a > socket, and depending on the user's input it grants access to the > file, whether temporarily or permanently. How can the trusted system filepicker know that it is receiving messages from the true Firefox filepicker, and in response to true user gestures? (Basically, it can't.) Microsoft had to deal with this problem; see e.g. http://en.wikipedia.org/wiki/User_Account_Control. From chris at noncombatant.org Sat Aug 2 19:21:08 2008 From: chris at noncombatant.org (Chris Palmer) Date: Sat Aug 2 19:21:14 2008 Subject: A new kind of security needed In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> Message-ID: On Jul 28, 2008, at 7:36 PM, Tim Clewlow wrote: > I'd like to offer a possible solution that I believe can be both > secure and usable. This will use the AID concept outlined above. What is an AID, and where does it come from? Is it a sequential uid_t assigned at install-time, is it the SHA-256 hash of the ELF file, or something else? What about programs that call dlopen(3) or which are controllable via RPC/LPC (Benjamin Lutz mentioned DCOP)? From bob at sinister.com Sat Aug 2 19:51:00 2008 From: bob at sinister.com (Bob Keyes) Date: Sat Aug 2 22:29:14 2008 Subject: The BIND scandal Message-ID: What's really sad is that bad attitudes from various OS security organizations, such as some people at FreeBSD, has made some people less willing to share vulnerabilities that they have discovered. I speak specifically from my experience in the year 2000, regarding the NAPTHA DoS. Mr. Robert Watson was quite uncivilized in his criticisms of me and the disclosure, even though it had been handled in the most reasonable way (through CERT). You may not believe it, but I've known about this BIND problem for some years, but kept it in my vest pocket. Why? Because I was tired of being made to suffer for doing what was right. I have an inkling about other problems which affect commonly used open-source software, but I see no reason to do a thorough investigation and disclose the results in a responsible way. Because of the bad attitudes of a number of people in the security community, I've been very quiet, not revealing any of my accidental discoveries nor pursuing fixes for the problems I see. Until reasonable and diplomatic people are installed as the security contacts for organizations such as FreeBSD, I will only make patches available to me and my close friends. Perhaps I am wrong, and that people who flamed me for my disclosure have grown up. I'd like to think so. -R. Keyes From phk at phk.freebsd.dk Sat Aug 2 23:03:28 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sat Aug 2 23:03:34 2008 Subject: The BIND scandal In-Reply-To: Your message of "Sat, 02 Aug 2008 15:09:37 -0400." Message-ID: <3228.1217718204@critter.freebsd.dk> In message , Bob Keyes writes: >Until reasonable and diplomatic people are installed as the security >contacts for organizations such as FreeBSD, I will only make patches >available to me and my close friends. I can warmly recommend you read the book "Blackmailing for dummies", as I can see that you make several classical beginner mistakes in this attempt. Better luck next time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From bob at sinister.com Sun Aug 3 02:19:06 2008 From: bob at sinister.com (Bob Keyes) Date: Sun Aug 3 02:24:12 2008 Subject: The BIND scandal In-Reply-To: <3228.1217718204@critter.freebsd.dk> References: <3228.1217718204@critter.freebsd.dk> Message-ID: On Sat, 2 Aug 2008, Poul-Henning Kamp wrote: > In message , Bob Keyes > writes: > >> Until reasonable and diplomatic people are installed as the security >> contacts for organizations such as FreeBSD, I will only make patches >> available to me and my close friends. > > I can warmly recommend you read the book "Blackmailing for dummies", > as I can see that you make several classical beginner mistakes in > this attempt. I really don't care to blackmail anyone. That's what's really great about the BSD license, I can keep my fixes to myself. Of course, what I am wondering right now is, why did I even bother telling you all this. But some of your are as well. Maybe there's some area for agreement. From phk at phk.freebsd.dk Sun Aug 3 07:05:31 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Sun Aug 3 07:05:39 2008 Subject: The BIND scandal In-Reply-To: Your message of "Sat, 02 Aug 2008 22:09:41 -0400." Message-ID: <4657.1217747125@critter.freebsd.dk> In message , Bob Keyes writes: >Of course, what I am wondering right now is, why did I even bother telling >you all this. But some of your are as well. No, I'm not wondering the least, it was pretty obvious that you behaved like a spurned primadonna type and now you were going to tell us how much we were missing out because we did not cater to your every whim and fancy. And since you had nothing concrete to bargain with, all you could do was say "Ha!, then you can't play with my dolls!" and go home with your nose in the sky, hoping that we would feel really miserable. Well, we don't. The FreeBSD project has been attempted blackmailed many times over the year, and it havn't worked yet, and it won't ever, if I can prevent it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From ady at freebsd.ady.ro Sun Aug 3 08:06:53 2008 From: ady at freebsd.ady.ro (Adrian Penisoara) Date: Sun Aug 3 08:07:00 2008 Subject: The BIND scandal In-Reply-To: <4657.1217747125@critter.freebsd.dk> References: <4657.1217747125@critter.freebsd.dk> Message-ID: <78cb3d3f0808030041w2e0627d4jacf5d0b4abaf0ce1@mail.gmail.com> Hi, On Sun, Aug 3, 2008 at 9:05 AM, Poul-Henning Kamp wrote: > > The FreeBSD project has been attempted blackmailed many times over > the year, and it havn't worked yet, and it won't ever, if I can > prevent it. > Sorry to suddenly stump into this, but can we get a bit more background on what is being referred to here and also the initial mail ? Just point me to relevant references if there are any, besides [1]. Mind me, but I think this may not be the most professional way to deal with such situations and I hate to see such (kiddish ?) arguments flow by on a FreeBSD/security list... [1] http://seclists.org/bugtraq/2000/Dec/0317.html Thank you, Adrian. From dougb at FreeBSD.org Sun Aug 3 17:21:35 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Aug 3 17:21:42 2008 Subject: The BIND scandal In-Reply-To: References: Message-ID: <4895E91B.3000002@FreeBSD.org> Bob is quite obviously trolling for a fight here, and I'm definitely not going to get sucked into that. I would like to point out however that the _DNS_ vulnerability that is currently in wide discussion is not in any way related to BIND, it's a fundamental flaw in the protocol related to response forgery. All major vendors of DNS systems and the IETF working groups on DNS are trying to find a permanent solution for this problem. As a stop-gap measure ISC has adopted the same solution for BIND that has proven effective for other vendors, randomizing the query source port. You can find more information about this issue here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience Hope this helps, Doug -- This .signature sanitized for your protection From matt at chronos.org.uk Sun Aug 3 18:23:38 2008 From: matt at chronos.org.uk (Matt Dawson) Date: Sun Aug 3 18:23:44 2008 Subject: The BIND scandal In-Reply-To: <4895E91B.3000002@FreeBSD.org> References: <4895E91B.3000002@FreeBSD.org> Message-ID: <200808031923.31775.matt@chronos.org.uk> On Sunday 03 Aug 2008, Doug Barton wrote: > Hope this helps, What actually did help was your most rapid update of the BIND ports to -p2 yesterday. You managed all of them three hours before I got the SANS handler's diary on the new releases from RSS! Just wanted to say thanks for that. Your work is appreciated. -- Matt Dawson. matt@chronos.org.uk MTD15-RIPE From dougb at FreeBSD.org Mon Aug 4 05:43:45 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Aug 4 05:43:52 2008 Subject: BIND -P2 update plans (Was: Re: The BIND scandal) In-Reply-To: <200808031923.31775.matt@chronos.org.uk> References: <4895E91B.3000002@FreeBSD.org> <200808031923.31775.matt@chronos.org.uk> Message-ID: <4896970E.1080205@FreeBSD.org> Matt Dawson wrote: > On Sunday 03 Aug 2008, Doug Barton wrote: >> Hope this helps, > > What actually did help was your most rapid update of the BIND ports to -p2 > yesterday. You managed all of them three hours before I got the SANS > handler's diary on the new releases from RSS! > > Just wanted to say thanks for that. Your work is appreciated. Thank you for the kind words. :) Since this update is performance related rather than directly security related I plan to give people a chance to update from ports and provide feedback before I update the base in HEAD and [67]-stable. So if you run a busy resolving name server, especially if you were having problems with -P1, then please let me know how -P2 works for you. Doug -- This .signature sanitized for your protection From LConrad at Go2France.com Mon Aug 4 06:25:20 2008 From: LConrad at Go2France.com (Len Conrad) Date: Mon Aug 4 06:25:27 2008 Subject: BIND -P2 update plans (Was: Re: The BIND scandal) In-Reply-To: <4896970E.1080205@FreeBSD.org> References: <4895E91B.3000002@FreeBSD.org> <200808031923.31775.matt@chronos.org.uk> <4896970E.1080205@FreeBSD.org> Message-ID: <20080804074531.SM01596@TX2.Go2France.com> http://www.freshports.org/search.php?query=bind9&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive ... shows 9.5.0.2 but the PortsMon page shows Latest as 9.5.0.1 Len From thomas at gibfest.dk Mon Aug 4 16:38:19 2008 From: thomas at gibfest.dk (Thomas Rasmussen) Date: Mon Aug 4 16:38:27 2008 Subject: BIND -P2 update plans (Was: Re: The BIND scandal) In-Reply-To: <4896970E.1080205@FreeBSD.org> References: <4895E91B.3000002@FreeBSD.org> <200808031923.31775.matt@chronos.org.uk> <4896970E.1080205@FreeBSD.org> Message-ID: <48972C4E.6010706@gibfest.dk> > Thank you for the kind words. :) > > Since this update is performance related rather than directly security > related I plan to give people a chance to update from ports and > provide feedback before I update the base in HEAD and [67]-stable. So > if you run a busy resolving name server, especially if you were having > problems with -P1, then please let me know how -P2 works for you. > > > Doug > Hello, I'd also like to thank you for updating the port so fast, I was hoping for sometime during the weekend, and was pleasantly surprised to see it available so fast. I've posted to the bind-users list to say this, but to confirm here: On 7-STABLE from a few weeks ago on a couple of busy recursive servers, this patch made an extreme positive difference. I was having problems with constant timeouts, very slow recursive lookups when they did work, and frequent errors about too many open files or somesuch in messages (regardless of kern.maxfiles and FD_SETSIZE settings), all of this disappeared when I applied P2. Number of successful queries almost doubled the minute I restarted with the -P2 patch applied, no more slowness or timeouts. This is the bind9.4 port by the way, 9.5 had even more weird errors and behaviour. I've since seen various sources claiming that 9.5 isn't ready for primetime on busy resolvers, so I'll wait for a while before moving on to 9.5. For the record, I have compiled dns/bind94 with make CFLAGS="-DFD_SETSIZE=65000" install clean to avoid "too many open file descriptors" errors, but with this setting (and increasing kern.maxfiles with sysctl) everything seems to be running nicely. -P2 might have removed the need for increasing FD_SETSIZE but this works, and for now I'll leave it at that. These servers have peak loads at around 1000 queries per second. They are both quad core 2-3ghz boxes with a couple of gigs of ram, and the cpu is around 50% utilized when the servers are busy. If you need more information please let me know. Best regards and thank you for all your work. Thomas Rasmussen From dougb at FreeBSD.org Tue Aug 5 05:06:41 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Tue Aug 5 05:06:48 2008 Subject: BIND -P2 update plans (Was: Re: The BIND scandal) In-Reply-To: <48972C4E.6010706@gibfest.dk> References: <4895E91B.3000002@FreeBSD.org> <200808031923.31775.matt@chronos.org.uk> <4896970E.1080205@FreeBSD.org> <48972C4E.6010706@gibfest.dk> Message-ID: <4897DFDE.5030406@FreeBSD.org> Thomas Rasmussen wrote: > I've posted to the bind-users list to say this, but to confirm here: On > 7-STABLE from a few weeks ago on a couple of busy recursive servers, > this patch made an extreme positive difference. I was having problems > with constant timeouts, very slow recursive lookups when they did work, > and frequent errors about too many open files or somesuch in messages > (regardless of kern.maxfiles and FD_SETSIZE settings), all of this > disappeared when I applied P2. Number of successful queries almost > doubled the minute I restarted with the -P2 patch applied, no more > slowness or timeouts. That's good news even taking your change to fd_setsize into account. > This is the bind9.4 port by the way, 9.5 had even more weird errors and > behaviour. I've since seen various sources claiming that 9.5 isn't ready > for primetime on busy resolvers, so I'll wait for a while before moving > on to 9.5. Yeah, if you don't have time to help debug the problems then sticking with 9.4 is a good decision. OTOH they can use all the help they can get. :) > For the record, I have compiled dns/bind94 with > > make CFLAGS="-DFD_SETSIZE=65000" install clean > > to avoid "too many open file descriptors" errors, but with this setting > (and increasing kern.maxfiles with sysctl) everything seems to be > running nicely. -P2 might have removed the need for increasing > FD_SETSIZE but this works, and for now I'll leave it at that. I can certainly understand not wanting to change something that's working, but I would like to get at least a couple of users to confirm that -P2 works out of the box before I import them. I don't mind adding a "big fd_setsize" knob to the ports and the base, but I want to be sure it's needed first. Doug -- This .signature sanitized for your protection From olli at lurza.secnetix.de Fri Aug 8 13:45:21 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Aug 8 13:45:28 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <20080807173525.GB37969@citylink.fud.org.nz> Message-ID: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Andrew Thompson wrote: > Pete French wrote: > > > The bce driver is not properly generating link state events. > > > > OK, that explains why it doesnt failover - but why does looking at it > > with ifconfig make a difference ? surely that should be 'read only ? > > ifconfig will cause the media status to be read from the hardware at > which time the link change is generated as it is different to the stored > value. Shouldn't that be considered a security flaw? After all, you can perform "ifconfig $IF" inside a jail to list the interface configuration, but you're not allowed to make any changes. Given your description above, it means that it is possible to modify the interface configuration (cause a failover) from within a jail. That's not good. I think that needs to be fixed, or at the very least it needs to be properly documented. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From mh at kernel32.de Fri Aug 8 14:00:58 2008 From: mh at kernel32.de (Marian Hettwer) Date: Fri Aug 8 14:01:05 2008 Subject: should looking at an interface with 'ifconfig' trigger a?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: <293d3dc9ebaee1119424aa58532d3c5d@localhost> Hi Oliver, On Fri, 8 Aug 2008 15:18:36 +0200 (CEST), Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at > > which time the link change is generated as it is different to the > stored > > value. > > Shouldn't that be considered a security flaw? After all, > you can perform "ifconfig $IF" inside a jail to list the > interface configuration, but you're not allowed to make > any changes. > > Given your description above, it means that it is possible > to modify the interface configuration (cause a failover) > from within a jail. That's not good. I think that needs > to be fixed, or at the very least it needs to be properly > documented. > And regarding documentation. It should be documented, that lagg(4) won't work very well with bce(4). If it's nowhere documented that bce and failover with lagg doesn't work, some people might be screwed... Just my 0,02 cents ./Marian From rwatson at FreeBSD.org Sat Aug 9 11:05:59 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 9 11:06:12 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: On Fri, 8 Aug 2008, Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at which > > time the link change is generated as it is different to the stored value. > > Shouldn't that be considered a security flaw? After all, you can perform > "ifconfig $IF" inside a jail to list the interface configuration, but you're > not allowed to make any changes. > > Given your description above, it means that it is possible to modify the > interface configuration (cause a failover) from within a jail. That's not > good. I think that needs to be fixed, or at the very least it needs to be > properly documented. While obviously a serious bug (link state notifications are required so that, for example, aggregates can take interfaces going down, or up, into account), I don't see this as a security flaw. The administrator intends for the higher abstraction state transition to be triggered by the lower one, but the problem is that the time it takes for that notification to take place is effectively non-deterministic. If they didn't want the higher level transition to take place, then they shouldn't have configured it that way. On the whole, we make no attempt to limit covert channels from jails to the host system, and there are potentially lots of interactions between them, so its not a violation of the security policy for jails. That said, this definitely needs to be fixed, as things like fail-over and routing updates happen pretty poorly otherwise. The epistemology of security flaws is complicated, needless to say... Robert N M Watson Computer Laboratory University of Cambridge From thompsa at FreeBSD.org Sat Aug 9 06:20:55 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Aug 9 13:30:39 2008 Subject: should looking at an interface with 'ifconfig' trigger a?change ? In-Reply-To: <293d3dc9ebaee1119424aa58532d3c5d@localhost> References: <200808081318.m78DIaXJ017555@lurza.secnetix.de> <293d3dc9ebaee1119424aa58532d3c5d@localhost> Message-ID: <20080809062049.GC95107@citylink.fud.org.nz> On Fri, Aug 08, 2008 at 04:00:56PM +0200, Marian Hettwer wrote: > Hi Oliver, > > On Fri, 8 Aug 2008 15:18:36 +0200 (CEST), Oliver Fromme > > > > Shouldn't that be considered a security flaw? After all, > > you can perform "ifconfig $IF" inside a jail to list the > > interface configuration, but you're not allowed to make > > any changes. > > > > Given your description above, it means that it is possible > > to modify the interface configuration (cause a failover) > > from within a jail. That's not good. I think that needs > > to be fixed, or at the very least it needs to be properly > > documented. > > > And regarding documentation. It should be documented, that lagg(4) won't > work very well with bce(4). If it's nowhere documented that bce and > failover with lagg doesn't work, some people might be screwed... I guess so although bce will not be the only one. Also spanning tree, carp and dhclient use link state events too, possibly others. Andrew From thompsa at FreeBSD.org Sat Aug 9 06:23:46 2008 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Sat Aug 9 13:34:06 2008 Subject: should looking at an interface with 'ifconfig' trigger a ?change ? In-Reply-To: <200808081318.m78DIaXJ017555@lurza.secnetix.de> References: <20080807173525.GB37969@citylink.fud.org.nz> <200808081318.m78DIaXJ017555@lurza.secnetix.de> Message-ID: <20080809060126.GB95107@citylink.fud.org.nz> On Fri, Aug 08, 2008 at 03:18:36PM +0200, Oliver Fromme wrote: > Andrew Thompson wrote: > > Pete French wrote: > > > > The bce driver is not properly generating link state events. > > > > > > OK, that explains why it doesnt failover - but why does looking at it > > > with ifconfig make a difference ? surely that should be 'read only ? > > > > ifconfig will cause the media status to be read from the hardware at > > which time the link change is generated as it is different to the stored > > value. > > Shouldn't that be considered a security flaw? After all, > you can perform "ifconfig $IF" inside a jail to list the > interface configuration, but you're not allowed to make > any changes. > > Given your description above, it means that it is possible > to modify the interface configuration (cause a failover) > from within a jail. That's not good. I think that needs > to be fixed, or at the very least it needs to be properly > documented. I dont think its a security flaw, this is meant to happen automatically after all. You cant make ifconfig change the link status within a jail, just catch up on reality. Andrew From ivoras at freebsd.org Thu Aug 14 02:49:00 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Aug 14 02:50:08 2008 Subject: MD5 man page Message-ID: <9bbcef730808131923o1ce56bc7i32b52ca884a54c@mail.gmail.com> Hi, In MD5Init(3) there's a paragraph that says: """MD5 has not yet (1999-02-11) been broken, but sufficient attacks have been made that its security is in some doubt. The attacks on both MD4 and MD5 are both in the nature of finding ``collisions'' - that is, multiple inputs which hash to the same value; it is still unlikely for an attacker to be able to determine the exact original input given a hash value. """ Shouldn't it be updated or at least the date of the statement moved to somewhere in this century? From des at des.no Fri Aug 15 10:02:21 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Aug 15 10:02:28 2008 Subject: MD5 man page In-Reply-To: <9bbcef730808131923o1ce56bc7i32b52ca884a54c@mail.gmail.com> (Ivan Voras's message of "Thu, 14 Aug 2008 04:23:40 +0200") References: <9bbcef730808131923o1ce56bc7i32b52ca884a54c@mail.gmail.com> Message-ID: <86k5eiwr22.fsf@ds4.des.no> "Ivan Voras" writes: > "MD5 has not yet (1999-02-11) been broken [...]" > Shouldn't it be updated or at least the date of the statement moved to > somewhere in this century? It should be updated, MD5 has been further weakened since then. This is why the ports tree now uses SHA256 checksums in addition to MD5. See http://en.wikipedia.org/wiki/MD5 for additional details. DES -- Dag-Erling Sm?rgrav - des@des.no From mi+mill at aldan.algebra.com Thu Aug 21 18:05:27 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Thu Aug 21 18:17:10 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts Message-ID: <48ADA81E.7090106@aldan.algebra.com> Hello! A machine I manage remotely for a friend comes under a distributed ssh break-in attack every once in a while. Annoyed (and alarmed) by the messages like: Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 I wrote an awk-script, which adds a block of the attacking IP-address to the ipfw-rules after three such "invalid user" attempts with: ipfw add 550 deny ip from ip The script is fed by syslogd directly -- through a syslog.conf rule ("|/opt/sbin/auth-log-watch"). Once in a while I manually flush these rules... I this a good (safe) reaction? I'm asking, because the machine (currently running 7.0 as of July 7) hangs solid once every few weeks... My only guess is that a spike in attacks causes "too many" ipfw-entries created, which paralyzes the kernel due to some bug -- the machine is running natd and is the gateway for the rest of the network... The hangs could, of course, be caused by something else entirely, but my self-defense mechanism is my first suspect... Any comments? Thanks! -mi From david at catwhisker.org Thu Aug 21 18:47:24 2008 From: david at catwhisker.org (David Wolfskill) Date: Thu Aug 21 18:47:34 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <20080821183130.GQ801@bunrab.catwhisker.org> On Thu, Aug 21, 2008 at 01:38:38PM -0400, Mikhail Teterin wrote: > ... > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > ... At a previous employer, we were building mail relay boxen (FreeBSD 6.0 - 6.2 timeframe); at one point, It Was Decided that rather than having /var/log/maillog written directly by syslogd(8), syslogd(8) would feed a Perl script that would do some "Database Things" and then get around to appending to /var/log/maillog itself. While the amount of work involved was assuredly greater in that case than in yours, those of us who were actually building and running the relays in question were very unsurprised when Postfix performance improved significantly following a redesign of the application, so that /var/log/maillog was written by syslogd(8) and the Perl script was effectively fed via "tail -F". > Once in a while I manually flush these rules... I this a good (safe) > reaction? I also see such things (on my home "firewall" machine); my approach is quite a bit different. If folks are interested, I could probably discuss it a bit, but I believe that would be, at best, tangential to your note, and thus ought not be crafted as if it were part of the thread -- and definitely does not warrant the cross-post. > ... Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080821/180a843a/attachment.pgp From oberman at es.net Thu Aug 21 19:00:34 2008 From: oberman at es.net (Kevin Oberman) Date: Thu Aug 21 19:25:32 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: Your message of "Thu, 21 Aug 2008 13:38:38 EDT." <48ADA81E.7090106@aldan.algebra.com> Message-ID: <20080821184947.BDAE94500F@ptavv.es.net> > Date: Thu, 21 Aug 2008 13:38:38 -0400 > From: Mikhail Teterin > Sender: owner-freebsd-stable@freebsd.org > > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the gateway > for the rest of the network... > The hangs could, of course, be caused by something else entirely, but my > self-defense mechanism is my first suspect... > > Any comments? Thanks! Looks remarkably like sshguard (ports/security/sshguard-*). It does almost exactly what you are doing but is written in C and has command-line switches to set how long a system is blocked, how many attempts constitute an attack and how long it should remember failed attempts. It also allows the use of back-end scripts if you want it to do something else such as generate reports (beyond an entry in /var/log/messages). As far as the hangs, I don't believe it is from the large nu,ber of brute force attempts as they will stop for a given host as soon as the firewall is updated. I seldom see more than a handful of attack sources over any short period. Should you want to continue with your own tool, at least for IPv4, consider using tables rather than a raft of rules. With tables, you need only a single rule and it is there at boot time. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080821/3ab8723f/attachment.pgp From hans at stare.cz Thu Aug 21 19:49:02 2008 From: hans at stare.cz (Jan Stary) Date: Thu Aug 21 19:49:14 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821184947.BDAE94500F@ptavv.es.net> References: <48ADA81E.7090106@aldan.algebra.com> <20080821184947.BDAE94500F@ptavv.es.net> Message-ID: <20080821193609.GA17896@www.stare.cz> > Should you want to continue with your own tool, at least for IPv4, > consider using tables rather than a raft of rules. With tables, you need > only a single rule and it is there at boot time. Also, you might want to consider switching to pf which this functionality built-in. Jan From neil at neely.cx Thu Aug 21 19:51:46 2008 From: neil at neely.cx (Neil Neely) Date: Thu Aug 21 19:51:53 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: I haven't explored this issue enough to speak with any authority - but once upon a time I had an app doing tons of ipfw rule add/removes all the time and we had no end of performance and stability problems on that box (this would have been in 4.x or so timeline I expect). As that approach wasn't really critical we abandoned it without really digging into the details. Years later a need for lots of rapid firewall changes came up again and I drilled into it and found the use of tables was excellent for doing this and it does the job very well. This is approach is on a FreeBSD 6.3 box. ipfw add 00550 deny ip from 'table(1)' to any Then just add remove entries to table 1 via: ipfw table 1 add 10.1.1.22/32 ipfw table 1 delete 10.1.1.22/32 show all entries in table 1 with: ipfw table 1 list Clear out the whole of table 1 ipfw table 1 flush I can't be sure if this relates to your particular issue, but I would recommend trying it out. Neil Neely http://neil-neely.blogspot.com On Aug 21, 2008, at 11:38 AM, Mikhail Teterin wrote: > Hello! > > A machine I manage remotely for a friend comes under a distributed > ssh break-in attack every once in a while. Annoyed (and alarmed) by > the messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from > 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from > 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP- > address to the ipfw-rules after three such "invalid user" attempts > with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the > gateway for the rest of the network... > The hangs could, of course, be caused by something else entirely, > but my self-defense mechanism is my first suspect... > > Any comments? Thanks! > > -mi > > _______________________________________________ > 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 mi+mill at aldan.algebra.com Thu Aug 21 19:54:18 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Thu Aug 21 19:59:24 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <48ADC7E7.9030907@aldan.algebra.com> Neil Neely ???????(??): > I haven't explored this issue enough to speak with any authority - but > once upon a time I had an app doing tons of ipfw rule add/removes all > the time and we had no end of performance and stability problems on > that box (this would have been in 4.x or so timeline I expect). As > that approach wasn't really critical we abandoned it without really > digging into the details. > > Years later a need for lots of rapid firewall changes came up again > and I drilled into it and found the use of tables was excellent for > doing this and it does the job very well. This is approach is on a > FreeBSD 6.3 box. > > ipfw add 00550 deny ip from 'table(1)' to any > > Then just add remove entries to table 1 via: > ipfw table 1 add 10.1.1.22/32 > ipfw table 1 delete 10.1.1.22/32 > > show all entries in table 1 with: > ipfw table 1 list > > Clear out the whole of table 1 > ipfw table 1 flush > > I can't be sure if this relates to your particular issue, but I would > recommend trying it out. Thanks! I was not even aware of this functionality... Yes, I'll try that -- maybe, a bug in ipfw only hits once per 1000 invocations :-) -mi From xi at borderworlds.dk Thu Aug 21 20:15:18 2008 From: xi at borderworlds.dk (Christian Laursen) Date: Thu Aug 21 20:15:24 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> (Mikhail Teterin's message of "Thu\, 21 Aug 2008 13\:38\:38 -0400") References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: Mikhail Teterin writes: > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address > to the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip I don't know if it will make your problem go away, but using ipfw tables for this seems to be a better idea than creating a new rule for every IP address. So you just need one rule: ipfw add 550 deny ip from table(1) And then when you want to add an IP address to the table: ipfw table 1 add You can add ranges too using the CIDR notation. -- Christian Laursen From koitsu at FreeBSD.org Thu Aug 21 20:21:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 21 20:21:29 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <20080821200309.GA19634@eos.sc1.parodius.com> On Thu, Aug 21, 2008 at 01:38:38PM -0400, Mikhail Teterin wrote: > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). > > Once in a while I manually flush these rules... I this a good (safe) > reaction? > I'm asking, because the machine (currently running 7.0 as of July 7) > hangs solid once every few weeks... My only guess is that a spike in > attacks causes "too many" ipfw-entries created, which paralyzes the > kernel due to some bug -- the machine is running natd and is the gateway > for the rest of the network... > The hangs could, of course, be caused by something else entirely, but my > self-defense mechanism is my first suspect... > > Any comments? Thanks! Yes, I have quite a few comments on this matter: The above looks like sshguard. I've personally never trusted something that *automatically* adjusts firewall rules based on data read from text logs or packets coming in off the Internet. The risks involved are insanely high. Stop for a moment and think what would happen to your box if a distributed brute-force attack (e.g. 300,000 different IPs) was launched against it; someone executing 20-30 SSH login attempts per IP. I'm willing to bet adding 300,000 individual ipfw entries would cause some serious havok on your machine (speculative: exhausted kernel memory, or at a bare minimum, exhaust the number of remaining ipfw rule entries) And yes, the liklihood of someone doing this is quite high. Try re-thinking your firewall logic. Instead of "allow any, deny specific IPs dynamically", how about "allow specific IPs, deny all others"? Surely you don't have that many users who SSH into the NAT router from random public IPs all over the world, rather than via the LAN? Surely if you yourself often SSH into your NAT router from a Blackberry device, that you wouldn't have much of a problem adding a /19 to the allow list. That's a hell of a lot better than allowing 0/0 and denying individual /32s. A different approach: consider putting sshd on a different port, rather than the default of 22. A lot of people I know do this, solely to decrease the number of brute-force attempts you see above; I've never seen any of those brute-force attacking programs portscan, then attack against a port which returns a OpenSSH string. Finally, consider moving to pf instead, if you really feel ipfw is what's causing your machine to crash. You might be pleasantly surprised by the syntax, and overall administrative usability (it is significantly superior to ipfw, IMHO). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From rink at FreeBSD.org Thu Aug 21 20:25:01 2008 From: rink at FreeBSD.org (Rink Springer) Date: Thu Aug 21 21:13:26 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> Message-ID: <20080821201042.GA56182@rink.nu> On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). In fact, pf can already do this out-of-the-box, by doing something like: table persist pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep state \ (max-src-conn 15, max-src-conn-rate 5/3, overload flush global) If that is not an option, I have found that security/denyhosts works pretty well too (it just adds IP's to /etc/hosts.deniedssh, and host_access(5) denies them based on this) Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From mi+mill at aldan.algebra.com Thu Aug 21 20:28:07 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Thu Aug 21 21:14:25 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821200309.GA19634@eos.sc1.parodius.com> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> Message-ID: <48ADCFD5.8020902@aldan.algebra.com> Jeremy Chadwick ???????(??): > The above looks like sshguard. Yes, several people have pointed this out. Thanks! > I've personally never trusted something that *automatically* adjusts firewall rules based on data read from text > logs or packets coming in off the Internet. The risks involved are insanely high. > An IP participating in a detected attack like this one, may also be the source of another problem, which may not be detected... I can't afford to monitor this system at all times, hence the reliance on automatic defenses -- better to crash/reboot than be taken over... > Stop for a moment and think what would happen to your box if a > distributed brute-force attack (e.g. 300,000 different IPs) was launched > against it; someone executing 20-30 SSH login attempts per IP. I'm > willing to bet adding 300,000 individual ipfw entries would cause some > serious havok on your machine (speculative: exhausted kernel memory, or > at a bare minimum, exhaust the number of remaining ipfw rule entries) > Yes, this is something I'm suspecting happening. But should not there be some frantic messages, when the system is getting closer to this point? There is nothing in the logs... > Surely you don't have that many users who SSH into the NAT router from > random public IPs all over the world, rather than via the LAN? Surely > if you yourself often SSH into your NAT router from a Blackberry device, > that you wouldn't have much of a problem adding a /19 to the allow list. > That's a hell of a lot better than allowing 0/0 and denying individual > /32s. > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" from anywhere in the world. Although we could, I suppose, find out the destination-country's IP-allocation and add it before leaving, that would be quite tedious to manage... > A different approach: consider putting sshd on a different port, rather > than the default of 22. A lot of people I know do this, solely to > decrease the number of brute-force attempts you see above; I've never > seen any of those brute-force attacking programs portscan, then attack > against a port which returns a OpenSSH string. > That's sounds kinda lame -- and temporary... Like buying an SUV to be higher (and heavier) than other cars, this only works, until everyone has an SUV :-) Once enough people move their sshd to different ports, the next release of the ssh-attack will be doing the portscanning, no doubt... Essential liberty vs. temporary security and all that :) > Finally, consider moving to pf instead, if you really feel ipfw is > what's causing your machine to crash. You might be pleasantly surprised > by the syntax, and overall administrative usability (it is significantly > superior to ipfw, IMHO). > Thanks for the suggestion... But would this solve the suspected problems with kernel memory exhaustion, etc.? Whatever the firewall method, it still needs to keep the rules memorized somewhere... Yours, -mi From julian at elischer.org Thu Aug 21 20:31:02 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 21 21:14:48 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821184947.BDAE94500F@ptavv.es.net> References: <20080821184947.BDAE94500F@ptavv.es.net> Message-ID: <48ADD084.9070707@elischer.org> Kevin Oberman wrote: >> Date: Thu, 21 Aug 2008 13:38:38 -0400 >> From: Mikhail Teterin >> Sender: owner-freebsd-stable@freebsd.org >> >> Hello! >> >> A machine I manage remotely for a friend comes under a distributed ssh >> break-in attack every once in a while. Annoyed (and alarmed) by the >> messages like: >> >> Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 >> Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 >> >> I wrote an awk-script, which adds a block of the attacking IP-address to >> the ipfw-rules after three such "invalid user" attempts with: >> >> ipfw add 550 deny ip from ip >> >> The script is fed by syslogd directly -- through a syslog.conf rule >> ("|/opt/sbin/auth-log-watch"). >> >> Once in a while I manually flush these rules... I this a good (safe) >> reaction? >> I'm asking, because the machine (currently running 7.0 as of July 7) >> hangs solid once every few weeks... My only guess is that a spike in >> attacks causes "too many" ipfw-entries created, which paralyzes the >> kernel due to some bug -- the machine is running natd and is the gateway >> for the rest of the network... >> The hangs could, of course, be caused by something else entirely, but my >> self-defense mechanism is my first suspect... >> >> Any comments? Thanks! also, if you do this, have a single rule that uses a table and add the addresses to the table. > > Looks remarkably like sshguard (ports/security/sshguard-*). It does almost > exactly what you are doing but is written in C and has command-line > switches to set how long a system is blocked, how many attempts > constitute an attack and how long it should remember failed attempts. It > also allows the use of back-end scripts if you want it to do something > else such as generate reports (beyond an entry in /var/log/messages). > > As far as the hangs, I don't believe it is from the large nu,ber of > brute force attempts as they will stop for a given host as soon as the > firewall is updated. I seldom see more than a handful of attack sources > over any short period. > > Should you want to continue with your own tool, at least for IPv4, > consider using tables rather than a raft of rules. With tables, you need > only a single rule and it is there at boot time. From brooks at freebsd.org Thu Aug 21 20:36:31 2008 From: brooks at freebsd.org (Brooks Davis) Date: Thu Aug 21 21:14:55 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821201042.GA56182@rink.nu> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <20080821201042.GA56182@rink.nu> Message-ID: <20080821203703.GA47728@lor.one-eyed-alien.net> On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote: > On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > > Finally, consider moving to pf instead, if you really feel ipfw is > > what's causing your machine to crash. You might be pleasantly surprised > > by the syntax, and overall administrative usability (it is significantly > > superior to ipfw, IMHO). > > In fact, pf can already do this out-of-the-box, by doing something like: > > table persist > pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep > state \ > (max-src-conn 15, max-src-conn-rate 5/3, overload flush > global) > > If that is not an option, I have found that security/denyhosts works > pretty well too (it just adds IP's to /etc/hosts.deniedssh, and > host_access(5) denies them based on this) You almost certainly don't want to rate limit ssh connections, only failed ones. If you rate limit connections and use svn, you're likely to lock your self out. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080821/1bd60406/attachment.pgp From imb at protected-networks.net Thu Aug 21 20:42:54 2008 From: imb at protected-networks.net (Michael Butler) Date: Thu Aug 21 21:15:05 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADCDAD.80507@gmail.com> References: <48ADA81E.7090106@aldan.algebra.com> <48ADCDAD.80507@gmail.com> Message-ID: <48ADD33A.9030907@protected-networks.net> I do something related to this with fwlogwatch although it can probably be adapted to any similar tool; when I hit the 'block' threshold, I execute something like: #!/bin/sh HR=`date "+%-k"` /sbin/ipfw table 0 add $3 ${HR} .. so each entry has a tag indicating the hour at which the block was initiated. At 5 to the hour, I run a simple cron job which does this to clean out everything older than 24 hours .. #!/bin/sh HR=`date -v+1H "+%-k"` /sbin/ipfw table 0 list >/tmp/xx.$$ cat /tmp/xx.$$ | while read LINE do set $LINE case "$2" in ${HR}) /sbin/ipfw table 0 delete $1 echo -n `date +"%H:%M:%S"` >>/var/log/fwlw_clean_log echo " fwlw_clean: removed $1 from table 0" >>/var/log/fwlw_clean_log esac done rm /tmp/xx.$$ I also have a script in /usr/local/etc/rc.d which saves the current state in the event of an orderly shutdown and restores it on boot: #!/bin/sh case "$1" in start) cat /var/db/ipfw/cache0 | while read LINE do set $LINE /sbin/ipfw table 0 add $1 $2 done ;; stop) /sbin/ipfw table 0 list >/var/db/ipfw/cache0 ;; restart) $0 $DEBUG stop $0 $DEBUG start exit $? ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac exit 0 Of course, this only works for ipv4 because of the restriction on the ipfw table data but it's just an example, Michael From ebutusov at gmail.com Thu Aug 21 20:52:14 2008 From: ebutusov at gmail.com (Eugene Butusov) Date: Thu Aug 21 21:15:18 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <48ADCDAD.80507@gmail.com> Mikhail Teterin pisze: > Hello! > > A machine I manage remotely for a friend comes under a distributed ssh > break-in attack every once in a while. Annoyed (and alarmed) by the > messages like: > > Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 > Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > > I wrote an awk-script, which adds a block of the attacking IP-address to > the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > > The script is fed by syslogd directly -- through a syslog.conf rule > ("|/opt/sbin/auth-log-watch"). Hi, You should look at 'bruteblock' (ports/security), it has similar fuctionality. It also provides daemon process, bruteblockd, which is responsible for removing entries from ipfw table. Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ .... ebutusov(at)gmail(dot)com From security at jim-liesl.org Thu Aug 21 21:37:34 2008 From: security at jim-liesl.org (security) Date: Thu Aug 21 22:01:09 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADC7E7.9030907@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> <48ADC7E7.9030907@aldan.algebra.com> Message-ID: <48ADD9DB.8060805@jim-liesl.org> Mikhail Teterin wrote: > Neil Neely ???????(??): >> I haven't explored this issue enough to speak with any authority - >> but once upon a time I had an app doing tons of ipfw rule add/removes >> all the time and we had no end of performance and stability problems >> on that box (this would have been in 4.x or so timeline I expect). >> As that approach wasn't really critical we abandoned it without >> really digging into the details. >> >> Years later a need for lots of rapid firewall changes came up again >> and I drilled into it and found the use of tables was excellent for >> doing this and it does the job very well. This is approach is on a >> FreeBSD 6.3 box. >> >> ipfw add 00550 deny ip from 'table(1)' to any >> >> Then just add remove entries to table 1 via: >> ipfw table 1 add 10.1.1.22/32 >> ipfw table 1 delete 10.1.1.22/32 >> >> show all entries in table 1 with: >> ipfw table 1 list >> >> Clear out the whole of table 1 >> ipfw table 1 flush >> >> I can't be sure if this relates to your particular issue, but I would >> recommend trying it out. > Thanks! I was not even aware of this functionality... Yes, I'll try > that -- maybe, a bug in ipfw only hits once per 1000 invocations :-) > > -mi blocksshd uses pf and a table to contain the addresses. you might want to check it out From mi+mill at aldan.algebra.com Thu Aug 21 22:22:21 2008 From: mi+mill at aldan.algebra.com (Mikhail Teterin) Date: Thu Aug 21 22:58:33 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080822074020.G32956@ali-syd-1.albury.net.au> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> <20080822074020.G32956@ali-syd-1.albury.net.au> Message-ID: <48ADEA96.70203@aldan.algebra.com> Ross Wheeler ???????(??): > I overcame these conflicting requirements with a 2-step process. They > "authorised" user first browsed to a website which asked their > username and password. When entered correctly, it opened a hole in the > firewall to allow that IP to their network. A timer ran every 15 > minutes to close the hole (but was over-ridden by the web page which > kept refreshing every 10 mins). The last part may not be necessary for > you, but this may be a possible workaround for your traveling access. > Leave a default of deny any except from trusted, fixed hosts, and add > transient access as required. This approach (or port-knocking of some sort) is good, but I'm not that worried about the sshd itself -- and the /detected/ attacks against it. It is the /undetected/ attacks against other services (such as apache), that worry me, and locking-out a rogue IP-address /completely/ is what I'd like to do. So your method would not work for me -- reaching the web-page (to allow myself a way back in) will be just as impossible as reaching the ssh-port... Thanks. Yours, -mi From rossw at albury.net.au Thu Aug 21 22:25:32 2008 From: rossw at albury.net.au (Ross Wheeler) Date: Thu Aug 21 22:58:41 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADCFD5.8020902@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> Message-ID: <20080822074020.G32956@ali-syd-1.albury.net.au> On Thu, 21 Aug 2008, Mikhail Teterin wrote: >> Surely you don't have that many users who SSH into the NAT router from >> random public IPs all over the world, rather than via the LAN? Surely >> if you yourself often SSH into your NAT router from a Blackberry device, >> that you wouldn't have much of a problem adding a /19 to the allow list. >> That's a hell of a lot better than allowing 0/0 and denying individual >> /32s. >> > Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" from > anywhere in the world. Although we could, I suppose, find out the > destination-country's IP-allocation and add it before leaving, that would be > quite tedious to manage... One of my clients used to have a microwave link from my network to their office - and they were totally paranoid about remote access yet needed live IPs fr other reasons. They too needed frequent remote access from arbitary addresses. I overcame these conflicting requirements with a 2-step process. They "authorised" user first browsed to a website which asked their username and password. When entered correctly, it opened a hole in the firewall to allow that IP to their network. A timer ran every 15 minutes to close the hole (but was over-ridden by the web page which kept refreshing every 10 mins). The last part may not be necessary for you, but this may be a possible workaround for your traveling access. Leave a default of deny any except from trusted, fixed hosts, and add transient access as required. (The system did fail where your browser was proxied, but I catered for that for the "network guys" by lettig them enter an IP address to open along with their user/pass - it just defaulted to the requesting host to make it easy) YMMV. RossW From dan at dracosplace.com Thu Aug 21 23:45:04 2008 From: dan at dracosplace.com (Dan Rowe) Date: Thu Aug 21 23:45:11 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <1078856133-1219360561-cardhu_decombobulator_blackberry.rim.net-634451014-@bxe020.bisx.prod.on.blackberry> May or may not be an option, but changing the default port that ssh runs on worked well enough for our needs. --It greatly reduced the number of automated attacks against the servers. It might work well enough to allow your DIY script to keep up without problems. -dan -----Original Message----- From: Mikhail Teterin Date: Thu, 21 Aug 2008 13:38:38 To: ; Subject: machine hangs on occasion - correlated with ssh break-in attempts Hello! A machine I manage remotely for a friend comes under a distributed ssh break-in attack every once in a while. Annoyed (and alarmed) by the messages like: Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 I wrote an awk-script, which adds a block of the attacking IP-address to the ipfw-rules after three such "invalid user" attempts with: ipfw add 550 deny ip from ip The script is fed by syslogd directly -- through a syslog.conf rule ("|/opt/sbin/auth-log-watch"). Once in a while I manually flush these rules... I this a good (safe) reaction? I'm asking, because the machine (currently running 7.0 as of July 7) hangs solid once every few weeks... My only guess is that a spike in attacks causes "too many" ipfw-entries created, which paralyzes the kernel due to some bug -- the machine is running natd and is the gateway for the rest of the network... The hangs could, of course, be caused by something else entirely, but my self-defense mechanism is my first suspect... Any comments? Thanks! -mi _______________________________________________ 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 dewayne_freebsd at yahoo.com Thu Aug 21 23:52:40 2008 From: dewayne_freebsd at yahoo.com (Dewayne Geraghty) Date: Thu Aug 21 23:58:33 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821203703.GA47728@lor.one-eyed-alien.net> Message-ID: <446595.9807.qm@web46413.mail.sp1.yahoo.com> There are many excellent suggestions on how to deal with invalid/unauthorised access attempts via ssh.? I'd used sshguard for around 8 months but recently changed to bruteblock, both are in the ports/security.? sshguard was very easy to configure, via rc.conf arguments. ?? Bruteblock handled the same problem more elegantly: uses two processes one for monitoring audit.log, via a pipe and one for maintaining the ipfw table entries, it uses the ipfw table value with the date/time entered, and the C code is cleaner (some optimisations are possible but this is V0.5).? If you'd like to try it here are the steps I used to get it going: Install package Configure /usr/local/etc/bruteblock-ssh.conf (Using regexp from sample, but modify parameters to suite your environment.) regexp????? = sshd.*Illegal user \S+ from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) regexp1???? = sshd.*Failed password for (?:illegal user )?\S+ from (\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} # three failures in 3 minutes is blocked for a day, using ipfw2 table 10max_count?? = 3 within_time = 180 reset_ip??? = 86400 ipfw2_table_no = 10 ? Insert into "/etc/syslog.conf" auth.info;authpriv.info |exec /usr/local/sbin/bruteblock ?f /usr/local/etc/bruteblock-ssh.conf Add to firewall rules (and /etc/rc.firewall)ipfw add 4 deny ip from table\(10\) to any ipfw add 4 deny ip from any to table\(10\)?Add into /etc/rc.confbruteblockd_enable="YES" bruteblockd_table="10" bruteblockd_flags="-s 7200"? # How frequently to review the ipfw table for entry removal?Now restart syslog, and start bruteblockd/etc/rc.d/syslogd restart /usr/local/etc/rc.d/bruteblockd.sh start Win a MacBook Air or iPod touch with Yahoo!7. http://au.docs..yahoo.com/homepageset From hans at stare.cz Fri Aug 22 06:59:09 2008 From: hans at stare.cz (Jan Stary) Date: Fri Aug 22 06:59:16 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080822074020.G32956@ali-syd-1.albury.net.au> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <48ADCFD5.8020902@aldan.algebra.com> <20080822074020.G32956@ali-syd-1.albury.net.au> Message-ID: <20080822065828.GA28155@www.stare.cz> On Aug 22 07:48:13, Ross Wheeler wrote: > On Thu, 21 Aug 2008, Mikhail Teterin wrote: > >>Surely you don't have that many users who SSH into the NAT router from > >>random public IPs all over the world, rather than via the LAN? Surely > >>if you yourself often SSH into your NAT router from a Blackberry device, > >>that you wouldn't have much of a problem adding a /19 to the allow list. > >>That's a hell of a lot better than allowing 0/0 and denying individual > >>/32s. > >> > >Myself -- and the owner of the box -- travel quite a bit, ssh-ing "home" > >from anywhere in the world. Although we could, I suppose, find out the > >destination-country's IP-allocation and add it before leaving, that would > >be quite tedious to manage... > > One of my clients used to have a microwave link from my network to their > office - and they were totally paranoid about remote access yet needed > live IPs fr other reasons. > > They too needed frequent remote access from arbitary addresses. > > I overcame these conflicting requirements with a 2-step process. They > "authorised" user first browsed to a website which asked their username > and password. When entered correctly, it opened a hole in the firewall to > allow that IP to their network. A timer ran every 15 minutes to close the > hole (but was over-ridden by the web page which kept refreshing every 10 > mins). The last part may not be necessary for you, but this may be a > possible workaround for your traveling access. Leave a default of deny any > except from trusted, fixed hosts, and add transient access as required. Eh? Sounds like a web-based reimplementation of authpf. Jan From derek at computinginnovations.com Fri Aug 22 08:04:17 2008 From: derek at computinginnovations.com (Derek Ragona) Date: Fri Aug 22 08:04:30 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <48ADA81E.7090106@aldan.algebra.com> References: <48ADA81E.7090106@aldan.algebra.com> Message-ID: <6.0.0.22.2.20080821132630.026c6a48@mail.computinginnovations.com> At 12:38 PM 8/21/2008, Mikhail Teterin wrote: >Hello! > >A machine I manage remotely for a friend comes under a distributed ssh >break-in attack every once in a while. Annoyed (and alarmed) by the >messages like: > >Aug 12 10:21:17 symbion sshd[4333]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:18 symbion sshd[4335]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:20 symbion sshd[4337]: Invalid user mythtv from 85.234.158.180 >Aug 12 10:21:21 symbion sshd[4339]: Invalid user mythtv from 85.234.158.180 > >I wrote an awk-script, which adds a block of the attacking IP-address to >the ipfw-rules after three such "invalid user" attempts with: > > ipfw add 550 deny ip from ip > >The script is fed by syslogd directly -- through a syslog.conf rule >("|/opt/sbin/auth-log-watch"). > >Once in a while I manually flush these rules... I this a good (safe) reaction? >I'm asking, because the machine (currently running 7.0 as of July 7) hangs >solid once every few weeks... My only guess is that a spike in attacks >causes "too many" ipfw-entries created, which paralyzes the kernel due to >some bug -- the machine is running natd and is the gateway for the rest of >the network... >The hangs could, of course, be caused by something else entirely, but my >self-defense mechanism is my first suspect... > >Any comments? Thanks! > > -mi I doubt it is your script, or syslog causing the crash. It is likely a hardware problem of some type if you have this server completely patched and up-to-date for security patches. I would look at the memory, ethernet, hard disk, or power supply as the most likely candidates. -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vadim_nuclight at mail.ru Fri Aug 22 10:20:56 2008 From: vadim_nuclight at mail.ru (Vadim Goncharov) Date: Fri Aug 22 11:22:29 2008 Subject: ipfw "bug" - recv any = not recv any References: <488F2B57.7000706@wagsky.com> Message-ID: Hi Jeff Kletsky! On Tue, 29 Jul 2008 07:38:15 -0700; Jeff Kletsky wrote about 'Re: ipfw "bug" - recv any = not recv any': >> In practice, both "recv any" and "not recv any" appear to be "no-op" >> phrases. >> > [...] >> In my opinion, the following would be "ideal" >> >> 1) "recv any" -- matches packets that have been received by the host >> through one of its interfaces >> 2) "not recv any" -- does not match packets that have been received by >> the host through one of its interfaces >> >> Unfortunately, implementing (1) would likely break a lot of people's >> rule sets >> >> (2), however, I can't immediately see being used without expecting that >> it would fail to match packets that were received by the current host, >> so its implementation would be a bit "safer" for the community >> > Julian Elishcher suggested: >> how does "not recv *" (appropriatly escaped for your shell) do? > This does appear to "work as desired" -- suggesting documentation > clarification rather than functionality change The trouble is that 'recv any' considered useless (yes, on the input it will always match, so why spend time for additional check) and optimised by parser, effectively cut out - kernel doesn't know anything about "any". I don't know why this keyword still exist at all. BTW, if you need to check for packets originating from local host, why don't you use "from me" as most intuitive approach? > My apologies for not posting to the ipfw list. Yes, that would be better... -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight] From mike at sentex.net Fri Aug 22 14:11:38 2008 From: mike at sentex.net (Mike Tancsa) Date: Fri Aug 22 14:11:45 2008 Subject: machine hangs on occasion - correlated with ssh break-in attempts In-Reply-To: <20080821203703.GA47728@lor.one-eyed-alien.net> References: <48ADA81E.7090106@aldan.algebra.com> <20080821200309.GA19634@eos.sc1.parodius.com> <20080821201042.GA56182@rink.nu> <20080821203703.GA47728@lor.one-eyed-alien.net> Message-ID: <200808221347.m7MDlwaN089762@lava.sentex.ca> At 04:37 PM 8/21/2008, Brooks Davis wrote: >On Thu, Aug 21, 2008 at 10:10:42PM +0200, Rink Springer wrote: > > On Thu, Aug 21, 2008 at 01:03:09PM -0700, Jeremy Chadwick wrote: > > > Finally, consider moving to pf instead, if you really feel ipfw is > > > what's causing your machine to crash. You might be pleasantly surprised > > > by the syntax, and overall administrative usability (it is significantly > > > superior to ipfw, IMHO). > > > > In fact, pf can already do this out-of-the-box, by doing something like: > > > > table persist > > pass quick on $wan_if proto tcp from any to any port ssh flags S/SA keep > > state \ > > (max-src-conn 15, max-src-conn-rate 5/3, overload flush > > global) > > > > If that is not an option, I have found that security/denyhosts works > > pretty well too (it just adds IP's to /etc/hosts.deniedssh, and > > host_access(5) denies them based on this) > >You almost certainly don't want to rate limit ssh connections, only failed >ones. If you rate limit connections and use svn, you're likely to lock your >self out. I find a happy balance is to exclude trusted CIDR blocks from the rate limiting and let everything else be limited. e.g. table persist table {192.168.0.0/16,1.0.0.0/24} block log quick proto tcp from to any port 22 block in log on $ext_if all pass log quick proto { tcp } from {!} to $myaddress port ssh \ flags S/SA keep state \ (max-src-conn 6, max-src-conn-rate 3/30, \ overload flush global) pass in on $ext_if inet proto tcp from to $ext_if port ssh keep state and then a crontab entry */5 * * * * /usr/local/sbin/expiretable -v -t 5m bruteforce ---Mike From spawk at acm.poly.edu Thu Aug 28 18:24:20 2008 From: spawk at acm.poly.edu (Boris Kochergin) Date: Thu Aug 28 18:24:27 2008 Subject: ACLs overriding umasks? Message-ID: <48B6E6EB.1030305@acm.poly.edu> Hi, list. A few years ago, there were plans to add an option to the filesystem ACL implementation that would allow ACLs to override umasks when creating files. I haven't been able to find anything else conclusive on the matter and was wondering if it was ever implemented. Thanks. -Boris From rwatson at FreeBSD.org Fri Aug 29 09:00:41 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Aug 29 09:00:49 2008 Subject: ACLs overriding umasks? In-Reply-To: <48B6E6EB.1030305@acm.poly.edu> References: <48B6E6EB.1030305@acm.poly.edu> Message-ID: On Thu, 28 Aug 2008, Boris Kochergin wrote: > Hi, list. A few years ago, there were plans to add an option to the > filesystem ACL implementation that would allow ACLs to override umasks when > creating files. I haven't been able to find anything else conclusive on the > matter and was wondering if it was ever implemented. Thanks. Hi Boris: The quick answer is: no, that hasn't happened yet, but it would be nice to do it for 8.0. There's a large in-progress project as part of Google Summer of Code to implement NFSv4 ACLs as well, which we should hear more on soon now that the summer is wrapping up. Robert N M Watson Computer Laboratory University of Cambridge From tethys.ocean at gmail.com Sat Aug 30 21:37:03 2008 From: tethys.ocean at gmail.com (tethys ocean) Date: Sat Aug 30 21:37:09 2008 Subject: jail stop extracting iso file Message-ID: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> Hi all In server jail and squid is running on it as lots of another packet. i want to extract iso image in this server. But i havent do it. #mdconfig -a -t vnode -f big_bcbcv.iso #mdconfig: open(/dev/mdctl): No such file or directory #ls -l /dev/md* #ls -ls /dev/mdctl ls: /dev/mdctl: No such file or directory i am not familiar with jail. only i can extract my iso file. ? suppose that jail stop me, jail blocking me for access some source is it true? 1-how can extract this iso file 2-is jail stop me? or any other trouble about my mdctl? regard -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From rwatson at FreeBSD.org Sat Aug 30 23:32:56 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Aug 30 23:33:02 2008 Subject: jail stop extracting iso file In-Reply-To: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> References: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> Message-ID: On Sun, 31 Aug 2008, tethys ocean wrote: > In server jail and squid is running on it as lots of another packet. i want > to extract iso image in this server. But i havent do it. You are correct that direct manipulation of md(4) devices is not allowed in jail. However, you may be running on a version FreeBSD in which tar(1) can be used to extract iso files, which is quite a bit more convenient for many uses. Robert N M Watson Computer Laboratory University of Cambridge > > #mdconfig -a -t vnode -f big_bcbcv.iso > #mdconfig: open(/dev/mdctl): No such file or directory > > #ls -l /dev/md* > #ls -ls /dev/mdctl > ls: /dev/mdctl: No such file or directory > > > i am not familiar with jail. only i can extract my iso file. ? suppose that > jail stop me, jail blocking me for access some source > > > is it true? > > 1-how can extract this iso file > 2-is jail stop me? or any other trouble about my mdctl? > > regard > -- > Share now a pigeon's flight > Bluebound along the ancient skies, > Its women forever hair and mammal, > A Mediterranean town may arise > If you rip apart a pigeon's heart. From trasz at FreeBSD.org Fri Aug 29 14:10:00 2008 From: trasz at FreeBSD.org (Edward Tomasz Napierala) Date: Sun Aug 31 13:33:15 2008 Subject: NFSv4 ACLs. Message-ID: <20080829135905.GA25236@pin.if.uz.zgora.pl> Right now, FreeBSD supports one type of ACLs - so called POSIX.1e ACLs. They are natural extension of the traditional Unix permissions, and for a long time were the only nonproprietary ACL type in Unix systems. Times change, and now there are several problems with them: they never actually become standard (the draft they are based on was withdrawn); this results in minor incompatibilities related to e.g. umask handling; they don't fit into Windows or NFSv4 security model, which makes interoperability between these systems harder; finally, they don't work with ZFS. The aim of my GSoC project was to implement NFSv4 ACLs in a similar way POSIX.1e ACLs are supported. That was done by extending user utilities (setfacl(1)/getfacl(1)), libc API and adding neccessary kernel stuff. Semantics is supposed to be identical to the one in SunOS. There is also a wrapper (distributed separately) that implements SunOS-compatible acl(2)/facl(2) API, to make porting applications like Samba easier. Userland tools - setfacl(1) and getfacl(1) were modified to work with new ACLs. The former was slightly restructured to make it more readable. Most of the setfacl(1) options work the same way with NFS4 ACLs as they do with POSIX.1e ACLs. However, things like "-m" or "-x" don't always fit in a model where ordering of entries matters and there may be more than one identical entry. Thus, two more options were added - "-a", that adds ACL entry at the specified position, and '-x number', which removes ACL entry at a specified position. Manual pages were updated as appropriate. ACL format is the same as SunOS "positional", aka "compact", format. For example: [trasz@traszkan:~]$ getfacl / # file: / # owner: root # group: wheel owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow There is also a "verbose" format, similar - but not identical - to the SunOS counterpart: [trasz@traszkan:~]$ getfacl -v / # file: / # owner: root # group: wheel owner@:::deny owner@:read_data/write_data/execute/append_data/write_attributes/write_xattr/write_acl/write_owner::allow group@:write_data/append_data::deny group@:read_data/execute::allow everyone@:write_data/append_data/write_attributes/write_xattr/write_acl/write_owner::deny everyone@:read_data/execute/read_attributes/read_xattr/read_acl/synchronize::allow The ls(1) and chmod(1) utilities were modified to remove POSIX.1e-specific assumptions. The following functions were added to the acl(3) API: acl_add_flag_np, acl_clear_flags_np, acl_create_entry_np, acl_delete_entry_np, acl_delete_flag_np, acl_get_extended_np, acl_get_flag_np, acl_get_flagset_np, acl_set_extended_np, acl_set_flagset_np, acl_to_text_np, acl_is_trivial_np, acl_strip_np, acl_get_brand_np. The flags part is source compatible with Darwin, other functions don't have their counterparts there. Manual pages were added or modified as neccessary. There should be no backward incompatible changes. As for the libc internals - "struct acl" et al were extended to make room for additional entries required by NFS4. Mechanism called "branding" was introduced to prevent API users from mixing POSIX and NFS4 specific stuff in a single ACL. One thing that still needs to be done is to add a few binary compatibility wrappers; these places are marked with 'XXX' in the code. ACL_MAX_ENTRIES was increased from 32 to 204. Syscall interface remains the same, except for a changed "type" constants, in order to preserve backwards compatibility with older libc. VOP_SETACL, VOP_GETACL and VOP_ACLCHECK interface remains the same, except for modified "struct acl". VOP_ACCESS changed a little - second argument was changed from "int" to "vaccess_t"; there should be no functional changes related to that. There are differences related to permissions granularity; as long as VOP_ACCESS implementation simply passes the "a_mode" parameter to the proper vaccess(9) routine, there should be no difference in behaviour. Adding granularity required adding some VWHATEVER defines to sys/vnode.h, adding several VOP_ACCESS checks in the syscall layer, replacing VADMIN with more specific permission in UFS and adding a unixify_vaccess() routine that "strips the granularity" from the mode. This routine is used in vaccess(9) and vaccess_acl_posix1e(9). Filesystem-independent functionality was implemented in kern/subr_acl_nfs4.c. This includes vaccess_acl_nfs4, routines to recompute ACL after the mode change, recompute the mode after ACL change, compute inherited ACL, and check the ACL for correctness. Implementation is based on draft-ietf-nfsv4-minorversion1-03, with small tweaks to make it behave exactly as ZFS does. Later drafts are unfortunately less specific, probably to make it possible to actually pass the voting. Note that these routines are used only by UFS; ZFS has its own implementation. Support for NFS4 ACL storage and retrieval was added to ufs/ufs/ufs_acl.c. Stored ACLs are variable in size, to reduce disk space used. Other parts of UFS (ufs_vnops.c and ufs_lookup.c) were modified to implement granularity. Support for NFS4 ACL storage and retrival was added to ZFS. It interfaces with ZFS own ACL mechanisms through wrappers. Two sets of unit tests were implemented. First, to test permission checks, was implemented as a part of fstest, tools/regression/fstest/tests/granular. Second, an "utility-level" test, is in tools/regression/acltools. It checks behaviour from the command-line point of view. It verifies the correct behaviour of getfacl(1), setfacl(1), cp(1) and mv(1) utilities (which obviously requires correct operation of the libc part), as well as recomputing ACLs on mode change, recomputing mode on ACL change, and ACL inheritance, which are performed by the kernel. These tests were used to make sure UFS behaves exactly the same way ZFS does. There is also a basic test for POSIX.1e ACLs as well, to make sure that part of functionality wasn't broken. The code is in working state. It can be found in Perforce: //depot/projects/soc2008/trasz_nfs4acl/... Patch against yesterdays -CURRENT is at: http://people.freebsd.org/~trasz/20080827-nfs4acls.diff I'd like to ask you for review, comments and suggestions. And testing, of course - this is just a prototype, but a working one. This work was done as a Google Summer of Code project. Thanks, Google :-) From carpetsmoker at rwxrwxrwx.net Sat Aug 30 22:03:55 2008 From: carpetsmoker at rwxrwxrwx.net (Martin Tournoij) Date: Sun Aug 31 13:33:46 2008 Subject: jail stop extracting iso file In-Reply-To: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> References: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> Message-ID: <20080830214746.GA7279@rwxrwxrwx.net> On Sun, Aug 31, 2008 at 12:08:31AM +0300, tethys ocean wrote: > Hi all > > In server jail and squid is running on it as lots of another packet. i want > to extract iso image in this server. But i havent do it. > > #mdconfig -a -t vnode -f big_bcbcv.iso > #mdconfig: open(/dev/mdctl): No such file or directory > > #ls -l /dev/md* > #ls -ls /dev/mdctl > ls: /dev/mdctl: No such file or directory > > > i am not familiar with jail. only i can extract my iso file. ? suppose that > jail stop me, jail blocking me for access some source > > > is it true? > > 1-how can extract this iso file > 2-is jail stop me? or any other trouble about my mdctl? You can use tar to extract iso images, i.e.: # tar xvf image.iso You can also use mdconfig, but you must add a devfs rule to add md devices, i.e.: add path 'md*' mode 0660 See devfs(8) and devfs.rules(5) -- Martin Tournoij carpetsmoker@rwxrwxrwx.net http://www.daemonforums.org QOTD: Beware of a tall blond man with one black shoe. From wojtek at wojtek.tensor.gdynia.pl Sun Aug 31 09:12:52 2008 From: wojtek at wojtek.tensor.gdynia.pl (Wojciech Puchar) Date: Sun Aug 31 13:33:59 2008 Subject: jail stop extracting iso file In-Reply-To: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> References: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> Message-ID: <20080831111208.P17652@wojtek.tensor.gdynia.pl> In server jail and squid is running on it as lots of another packet. i want to extract iso image in this server. But i havent do it. #mdconfig -a -t vnode -f big_bcbcv.iso #mdconfig: open(/dev/mdctl): No such file or directory you can't jail doesn't allow it. From tethys.ocean at gmail.com Sun Aug 31 19:01:10 2008 From: tethys.ocean at gmail.com (tethys ocean) Date: Sun Aug 31 19:01:18 2008 Subject: jail stop extracting iso file In-Reply-To: References: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> Message-ID: <235b80000808311201x1afc099t3b0af9615369fcd3@mail.gmail.com> ? see, i should extract this iso image (not using tar) may i close this jail? and can i restart correctly? i am hesitate since squid in running on jail? process is like [root@finn /etc]# ps ax -o pid,jid,args PID JID COMMAND 8415 0 /usr/local/sbin/httpd -k start 10414 0 sshd: mary [priv] (sshd) 10417 0 sshd: mary@ttyp3 (sshd) 17168 0 /usr/local/sbin/squid -D 17170 0 (squid) -D (squid) 17171 0 (unlinkd) (unlinkd) 20754 0 /usr/sbin/syslogd -ss 20871 0 /usr/sbin/sshd 35688 0 sshd: andy [priv] (sshd) 35691 0 sshd: andy@ttypb (sshd) 42074 0 /usr/local/sbin/munin-node (perl) 48630 0 /usr/local/sbin/httpd -k start 64266 0 screen 67740 0 /usr/local/sbin/httpd -k start 71171 0 /usr/local/sbin/httpd -k start 76426 0 /usr/local/sbin/httpd -k start 92862 0 /usr/local/sbin/httpd -k start 93912 0 sshd: alex [priv] (sshd) 93929 0 sshd: alex@ttypq (sshd) 93955 0 screen 10418 0 -bash (bash) 35692 0 -bash (bash) 35693 0 su - 35694 0 -su (csh) 64268 0 /usr/local/bin/bash 93930 0 -bash (bash) 93932 0 su - 93933 0 -su (bash) 93954 0 screen 93956 0 /usr/local/bin/bash 94654 0 ps ax -o pid,jid,args [root@finn /etc]# i think so i can stop jail by this command? (but it run) /etc/rc.d/jail start /etc/rc.d/jail stop OR i can kill jail process and than /etc/rc.d/jail stop and i can disable in sysctl jail line #security.jail.set_hostname_allowed=1 #security.jail.socket_unixiproute_only=1 #security.jail.sysvipc_allowed=0 #security.jail.enforce_statfs=2 #security.jail.allow_raw_sockets=0 #security.jail.chflags_allowed=0 #security.jail.jailed=0 than extract iso file and restart jail? possible? and it contains any risk? since squid is so so important since i ve read this paper http://www.freebsd.org/doc/en/books/handbook/jails-application.html but i wasn't able to find some jail details/setting in this server but neverthless jail is running regards 2008/8/31 Robert Watson > > On Sun, 31 Aug 2008, tethys ocean wrote: > > In server jail and squid is running on it as lots of another packet. i >> want to extract iso image in this server. But i havent do it. >> > > You are correct that direct manipulation of md(4) devices is not allowed in > jail. However, you may be running on a version FreeBSD in which tar(1) can > be used to extract iso files, which is quite a bit more convenient for many > uses. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > >> #mdconfig -a -t vnode -f big_bcbcv.iso >> #mdconfig: open(/dev/mdctl): No such file or directory >> >> #ls -l /dev/md* >> #ls -ls /dev/mdctl >> ls: /dev/mdctl: No such file or directory >> >> >> i am not familiar with jail. only i can extract my iso file. ? suppose >> that >> jail stop me, jail blocking me for access some source >> >> >> is it true? >> >> 1-how can extract this iso file >> 2-is jail stop me? or any other trouble about my mdctl? >> >> regard >> >> -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From ohauer at gmx.de Sun Aug 31 20:46:32 2008 From: ohauer at gmx.de (Olli Hauer) Date: Sun Aug 31 20:46:45 2008 Subject: jail stop extracting iso file In-Reply-To: <20080831111208.P17652@wojtek.tensor.gdynia.pl> References: <235b80000808301408v49e91675se91a257e257537fc@mail.gmail.com> <20080831111208.P17652@wojtek.tensor.gdynia.pl> Message-ID: <20080831201949.96800@gmx.net> > In server jail and squid is running on it as lots of another packet. i > want > to extract iso image in this server. But i havent do it. > > #mdconfig -a -t vnode -f big_bcbcv.iso > #mdconfig: open(/dev/mdctl): No such file or directory > > you can't > > jail doesn't allow it. Yes, but why don't mount the ISO at the host system and do a nullfs mount into the jail? at the host system (not in the jail) # mdconfig -a -t vnode -u 10 -f ${path_to_iso_image} # mount_cd9660 -o ro /dev/md10 /mnt/ # mount_nullfs /mnt ${path_to_jail}/mnt ssh into the jail # pkg_add /mnt/filename -- GMX Kostenlose Spiele: Einfach online spielen und Spa? haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196