From owner-freebsd-security Sun Jul 8 4:37:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from gyw.com (gyw.com [209.55.67.177]) by hub.freebsd.org (Postfix) with ESMTP id 50D2D37B405 for ; Sun, 8 Jul 2001 04:37:37 -0700 (PDT) (envelope-from tjk@tksoft.com) Received: from smtp3.tksoft.com (smtp3.tksoft.com [192.168.50.56] (may be forged)) by gyw.com (8.8.8/8.8.8) with ESMTP id DAA06374; Sun, 8 Jul 2001 03:47:34 -0700 Received: (from tjk@tksoft.com) by smtp3.tksoft.com (8.8.8/8.8.8) id DAA07513; Sun, 8 Jul 2001 03:01:54 -0700 From: "tjk@tksoft.com" Message-Id: <200107081001.DAA07513@smtp3.tksoft.com> Subject: Re: Firewall and ftp service To: ascheepe@surf.iae.nl (Axel Scheepers) Date: Sun, 8 Jul 2001 03:01:54 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <20010707153247.A78448@surf.iae.nl> from "Axel Scheepers" at Jul 07, 2001 03:32:47 PM X-Info: None MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I wanted to point out that port 20 is for ftp data and port 21 is for ftp commands. When an ftp connection is made, the client connects to the server at port 21. All communications occur on that channel. When the server needs to send data to the client, it opens a connection to port 20 on the client. When it makes the connection, it allocates a local port > 1024 for its local port. When a client requests passive ftp, the server opens a random port > 1024 for listening. The client then opens a connection to that port. With both passive and regular ftp data connections, the server has a local port > 1024 open. The distinction is that with passive ftp the server does a "listen()," opening a port for incoming connections. With regular ftp, the server does a "connect()" and the client must open port 20 with "listen()." I hope this clarifies what you should be looking at. Good luck, Troy > > Hi everybody, > I hope I'm not being really off topic with this one but > it's been troubling me for a while now. > I'm looking for a way to provide acces to an ftpserver, my current > network layout looks like this: > > Cable Modem ------> Gateway ---------> http/ftp server > | > | > +------------> private http/ftp/sql server > | > | > +------------> my workstation > > The gateway does natd and ipf since the other servers have private > adresses. The problem now is that whenever I connect to my > ftp servers from the outside, the server is unable to set up a > data connection, because it wants to connect on a port > 1024, which > is blocked by my firewall(and I want to leave it that way). > Natd does the following: > natd -redirect_port tcp 192.168.0.5:20 20 -redirect_port 192.168.0.5:21 21 > which redirects the traffic to my public ftp server. > > As I see it there can be 2 problems with this setup; > 1) The server wants to initiate the data connection at a port > 1024 and/or > 2) The server still somehow reports 192.168.0.5 as its address to the clients. > > I have tried to connect with the option passive is off, which I thought > should force the server to stay on port 21 for tha data connection, but > it didn't work. :( > Can/will somebody help on getting this done the proper way ? > I just want to use ipfilter, if possible, and I don't like to install > a ftp proxy for this. > > Greetings, > Axel Scheepers > > Unix System Administrator > VIA NET.WORKS Nederland > http://www.vianetworks.nl > ascheepers@vianetworks.nl > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 4:56:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from void.xpert.com (xpert.com [199.203.132.1]) by hub.freebsd.org (Postfix) with ESMTP id B2BA737B403 for ; Sun, 8 Jul 2001 04:55:40 -0700 (PDT) (envelope-from Yonatan@xpert.com) Received: from mailserv.xpert.com ([199.203.132.135]) by void.xpert.com with esmtp (Exim 3.20 #1) id 15JCBe-0002jI-00 for freebsd-security@freebsd.org; Sun, 08 Jul 2001 13:53:14 +0300 Received: by mailserv.xpert.com with Internet Mail Service (5.5.2650.21) id <3GHBYTHL>; Sun, 8 Jul 2001 14:55:03 +0300 Message-ID: From: Yonatan Bokovza To: "'freebsd-security@freebsd.org'" Subject: FW: Small TCP packets == very large overhead == DoS? Date: Sun, 8 Jul 2001 14:54:53 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, This was just on bugtraq. Is net.inet.tcp.min_mss the solution? -----Original Message----- From: Darren Reed [mailto:avalon@coombs.anu.edu.au] Sent: Saturday, July 07, 2001 18:47 To: bugtraq@securityfocus.com Subject: Small TCP packets == very large overhead == DoS? On a lan far far away, a rouge packet was heading towards a server, ready to start up a new storm ... [I was going to start this by saying "years ago" but well... that might be showing my age ;)] Anyway, down to business. If any of you have tested what happens to the ability of a box to perform well when it has a small MTU you will know that setting the MTY to (say) 56 on a diskless thing is a VERY VERY bad idea when NFS read/write packets are generally 8k in size. Do not try it on a NFS thing unless you plan to reboot it, ok ? Last time I did this was when I worked out you could fragment packets inside the TCP header and that lesson was enough for me ;_) Following on from this, it occurs to me that the problem with the above can possibly be reproduced with TCP. How ? That thing called "maximum segment size". The problem? Well, the first is that there does not appear to be a minimum. The second is that it is negoiated by the caller, not callee. Did I hear someone say "oh dear" ? What's this mean? Well, if I connect to www.microsoft.com and set my MSS to 143 (say), they need to send me 11 packets for every one they would normally send me (with an MSS of 1436). Total output for them is 1876 bytes - a 30% increase. However, that's not the real problem. My experience is that hosts, especially PC's, have a lot of trouble handling *LOTS* of interrupts. To send 2k out via the network, it's no longer 2 packets but 20+ - a significant increase in the workload. A quick table (based on 20byte IP & TCP header):: datalen mss packets total bytes bytes %increase 1436 1436 1 1476 0 1436 1024 2 1516 3% 1436 768 2 1516 3% 1436 512 3 1556 5% 1436 256 6 1676 13% 1436 128 12 1916 30% 1436 64 23 2356 69% 1436 32 45 3236 119% 1426 28 52 3516 238% (MTU = 68) 1436 16 90 5036 241% 1436 8 180 8636 485% 1436 1 1436 58876 3989% For Solaris, you can enforce a more sane minimum MSS than the install default (1) with ndd: ndd -set /dev/tcp tcp_mss_min 128 HP-UX 11.* is in the same basket as Solaris. *BSD have varying minimums well above 1 - NetBSD at 32, FreeBSD at 64. (OpenBSD's comment on this says 32 but the code says 64 - mmm, qwality!) Linux 2.4 is 88 I can't see anything in the registry or MSDN which says what it is for Windows. By experimentation, Win2000 appears to be 88, NT 4 appears to be 1 Do I need to mention any other OS ? :*) Nothing else besides Solaris seems to have anything close to a reasonable manner in which to tune the minimum value. What's most surprising is that there does not appear to be a documented minimum, just as there is no "minimum MTU" size for IP. If there is, please correct me. About the only bonus to this is that there does not appear to be an easy way to affect the MSS sent in the initial SYN packet. Oh, so how's this a potential denial of service attack? Generally, network efficiency comes through sending lots of large packets...but don't tell ATM folks that, of course :-) Does it work? *shrug* It is not easy to test...the only testing I could do (with NetBSD) was to use the TCP_MAXSEG setsockopt BUT this only affects the sending MSS (now what use is that ? :-), but in testing, changing it from the default 1460 to 1 caused number of packets to go from 9 to 2260 to write 1436 bytes of data to discard. To send 100 * 1436 from the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with an MSS of 1460. Of even more significance, one connection like this made almost no difference after the first run but running a second saw kernel CPU jump to 30% on an SS20/712 (I suspect there are some serious TCP tuning happening dynamically). The sending host was likewise afflicted with a signifcant CPU usage penalty if more than one was running. There were some very surprising things happening too - with just one session active, ~170-200pps were seen with netstat on Solaris, but with the second, it was between 1750 and 1850pps. Can you say "ACK storm" ? Oh, and for fun you can enable TCP timestamping just to make those headers bigger and run the system a bit harder whilst processing packets! Oh, I haven't investigated the impact of ICMP PMTU discovery, but from my reading of at least the BSD source code, the MTU for the route will be ignored if it is less than the default MSS when sending out the TCP SYN with the MSS option. That aside, it will still impact current connections and would appear to be a way to force the _current_ MSS below that set at connect time. On BSD, it will not accept PMTU updates if the MTU is less than 296, on Solaris8 and Linux 2.4 it just needs to be above 68 (hmmm, allows you to get an effective MSS of less than 88 :). mmm, source code. So, what are defences ? Quite clearly the host operating system needs to set a much more sane minimum MSS than 1. Given there is no minimum MTU for IP - well, maybe "68" - it's hard to derive what it should be. Anything below 40 should just be banned (that's the point at which you're transmitting 50% data, 50% headers). Most of the defaults, above, are chosen because it fits in well with their internal network buffering (some use a default MSS of 512 rather than 536 for similar reasons). But above that, what do you choose? 80 for a 25/75 or something higher still? Whatever the choice and however it is calculated, it is not enough to just enforce it when the MSS option is received. It also needs to be enforced when the MTU parameter is checked in ICMP "need frag" packets. Darren p.s. I guess if I was one of those corporate types who get paid to do security stuff I'd write this up as a white paper but like this is the 'net man! p.p.s. So far as I know, nobody has covered this topic, from this angle, before or if they have, I'm ultralame for not being out on a saturday night when I could have been. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 5:25:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from mohegan.mohawk.net (mohegan.mohawk.net [63.66.68.21]) by hub.freebsd.org (Postfix) with ESMTP id A7C3C37B408 for ; Sun, 8 Jul 2001 05:25:39 -0700 (PDT) (envelope-from rjh@mohawk.net) Received: from mohegan.mohawk.net (mohegan.mohawk.net [63.66.68.21]) by mohegan.mohawk.net (8.11.3/8.11.3) with ESMTP id f68CRXx28729; Sun, 8 Jul 2001 08:27:33 -0400 (EDT) Date: Sun, 8 Jul 2001 08:27:33 -0400 (EDT) From: Ralph Huntington To: steve Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPFilter/IPNat and rdr In-Reply-To: <3B47EC3A.2734754F@clublinux.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The way ipfilter processes rules, a rule takes effect only if it is not overridden by a subsequent rule, unless the 'quick' keyword is used. If the 'quick' keywork is used, then the rule takes effect immediately and no further rule processing occurs for that packet. So how about something like this: block in on ep0 from any to 192.168.0.0/16 pass in quick on ep0 proto tcp from any to 192.168.1.100/32 port = 80 ... The first rule blocks traffic to the 192.168 net coming in through your public interface, but the next rule overrides lets the packet in IF it is bound for port 80 at that partiucular address. You may or may not want the quick keyword in that second rule, depending on whether or not you wish to do any further filtering on those packets bound for your web server. Ralph > pass in quick on ep0 proto tcp from any to 192.168.1.100/32 port = 80 > flags S keep state keep frags > > However, because NAT occurs before the filtering, I can no longer have a > rule to prevent packets from the outside that contain a destination IP > on my internal network from passing through my firewall and entering my > internal network like this: > > block in quick on ep0 from any to 192.168.0.0/16 > > I realize that packets with a source or destination of 192.168.0.0/16 > should be dropped by routers on the internet, but I know this doesn't > always happen as our firewall at work has recorded such packets in the > past. > > Am I mis-understanding how IPFilter/IPNat work together correctly? If > so, is there a way around this problem? If not, would the following > provide the protection I'm looking for while still allowing people to > access my web server from the outside? > > pass in quick on ep0 proto tcp from any to 192.168.1.100/32 port = 80 > flags S keep state keep frags > block in quick on ep0 from any to 192.168.0.0/16 > > This would prevent any packet from the outside with a destination > address of my internal network from passing through the firewall unless > it was specifically going to port 80 on my web server right? > > Please CC me on any replies as I'm not currently subscribed to the list. > > Thanks in advance, > Steve > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 6:22:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from gyw.com (gyw.com [209.55.67.177]) by hub.freebsd.org (Postfix) with ESMTP id 0A31437B401 for ; Sun, 8 Jul 2001 06:22:18 -0700 (PDT) (envelope-from tjk@tksoft.com) Received: from smtp3.tksoft.com (smtp3.tksoft.com [192.168.50.56] (may be forged)) by gyw.com (8.8.8/8.8.8) with ESMTP id FAA11658; Sun, 8 Jul 2001 05:32:20 -0700 Received: (from tjk@tksoft.com) by smtp3.tksoft.com (8.8.8/8.8.8) id EAA15423; Sun, 8 Jul 2001 04:47:41 -0700 From: "tjk@tksoft.com" Message-Id: <200107081147.EAA15423@smtp3.tksoft.com> Subject: Re: apache security question To: default013subscriptions@hotmail.com Date: Sun, 8 Jul 2001 04:47:40 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "default013 - subscriptions" at Jun 14, 2001 08:08:36 AM X-Info: None MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Just got back from vacation and saw this. Lots of software use the HEAD method to find out if a page has been modified. If it has, then it downloads the page. The HEAD method is a part of the HTTP protocol, and a very useful part of it. It prints the header for the requested page, but not the page itself. A GET request prints the header and the page. By removing the HEAD capability, you achieve nothing, but you will create problems for yourself. Troy > > Hello, I've been advised that someone is attempting to break into my box, > and I know that this person is knowledgeable so I've been watching for > unusual activity... > > I noticed this entry in one of my apache logfiles yesterday, and was > wondering if anyone could explain to me what this is: > > mydomainname.com otherguyshostname.com - - [12/Jun/2001:18:21:35 -0500] > "HEAD / HTTP/1.0" 200 0 "-" > > It appears to me like they somehow executed the 'head' command... how would > one do this, and how could you stop it? > > Thanks, Jordan > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 8:15:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from radius.tagil.ru (mail.tagil.ru [195.151.0.199]) by hub.freebsd.org (Postfix) with ESMTP id E3CD837B401 for ; Sun, 8 Jul 2001 08:15:15 -0700 (PDT) (envelope-from MichaelNottebrock@gmx.net) Received: from COMP_4 (dial5.postnt.tagil.ru [195.151.2.38]) by radius.tagil.ru (8.9.3/8.9.3) with ESMTP id VAA09991; Sun, 8 Jul 2001 21:15:09 +0600 Date: Sun, 8 Jul 2001 21:17:33 +0600 From: Michael Nottebrock X-Mailer: The Bat! (v1.47 Halloween Edition) Personal X-Priority: 3 (Normal) Message-ID: <262555312.20010708211733@chat.ru> To: bobay@chat.ru Cc: security@freebsd.org Subject: Re: IPSEC & TCP sequence number generation Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------F412819C10E85F80" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org ------------F412819C10E85F80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oh dear. Never forget to turn verbosity on, like they always say. Obviously, nmap likes to use the _first_ open port to do the fingerprinting. In my case, that port is being redirected to a windows box. Closed the port, got my usual all 9's back. Maybe here's some other way to do a little statistics-forgery, northern_? ;) Sorry for that un', folks, and also sorry for that CRAP my free webmail provider I'm temporarily stuck with is going to append to this message. Greetings, Michael Nottebrock -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net GMX Tipp: Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1! http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a ------------F412819C10E85F80 Content-Type: application/octet-stream Content-Transfer-Encoding: base64 ------------F412819C10E85F80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 13: 6:55 2001 Delivered-To: freebsd-security@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 1748537B401 for ; Sun, 8 Jul 2001 13:06:51 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.245.133.115.Dial1.SanJose1.Level3.net [209.245.133.115]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA00386; Sun, 8 Jul 2001 13:06:44 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f68K6Zc00873; Sun, 8 Jul 2001 13:06:35 -0700 (PDT) (envelope-from cjc) Date: Sun, 8 Jul 2001 13:06:30 -0700 From: "Crist J. Clark" To: "tjk@tksoft.com" Cc: Axel Scheepers , freebsd-security@FreeBSD.ORG Subject: Re: Firewall and ftp service Message-ID: <20010708130630.A307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20010707153247.A78448@surf.iae.nl> <200107081001.DAA07513@smtp3.tksoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107081001.DAA07513@smtp3.tksoft.com>; from tjk@tksoft.com on Sun, Jul 08, 2001 at 03:01:54AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 08, 2001 at 03:01:54AM -0700, tjk@tksoft.com wrote: > > I wanted to point out that port 20 is for ftp data and port 21 is > for ftp commands. Yep. For PORT or "active" FTP. > When an ftp connection is made, the client connects to the server at > port 21. All communications occur on that channel. All command and control communications. > When the server needs to send data to the client, it opens a connection > to port 20 on the client. When it makes the connection, it allocates a > local port > 1024 for its local port. *sigh* NO. When the server needs to send data to the client, it opens a connection _from_ port 20 on the server to some ephemeral port, >1024, on the client. Think about it. On a UNIX system, is the client program running with root privs? How could it open port 20? > When a client requests passive ftp, the server opens a random port > > 1024 for listening. The client then opens a connection to that port. That's usually what happens in PASV. > With both passive and regular ftp data connections, the server has a > local port > 1024 open. The distinction is that with passive ftp the > server does a "listen()," opening a port for incoming connections. With > regular ftp, the server does a "connect()" and the client must open port > 20 with "listen()." Again, no. The server uses its port 20 for a PORT command. The client never uses port 20 in either mode. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 13:26:41 2001 Delivered-To: freebsd-security@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 3184337B401 for ; Sun, 8 Jul 2001 13:26:36 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.245.133.115.Dial1.SanJose1.Level3.net [209.245.133.115]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA09479; Sun, 8 Jul 2001 13:26:33 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f68KQTM00917; Sun, 8 Jul 2001 13:26:29 -0700 (PDT) (envelope-from cjc) Date: Sun, 8 Jul 2001 13:26:29 -0700 From: "Crist J. Clark" To: Yonatan Bokovza Cc: "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010708132629.B307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yonatan@xpert.com on Sun, Jul 08, 2001 at 02:54:53PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 08, 2001 at 02:54:53PM +0300, Yonatan Bokovza wrote: > Hi, > This was just on bugtraq. > Is net.inet.tcp.min_mss the solution? To what problem? As I get to below, it is a symetrical DoS attack. As a general class, these are not a big threat. Darren... you came up with this? > -----Original Message----- > From: Darren Reed [mailto:avalon@coombs.anu.edu.au] > Sent: Saturday, July 07, 2001 18:47 > To: bugtraq@securityfocus.com > Subject: Small TCP packets == very large overhead == DoS? [snip] > What's this mean? Well, if I connect to www.microsoft.com and set > my MSS to 143 (say), they need to send me 11 packets for every one > they would normally send me (with an MSS of 1436). Total output > for them is 1876 bytes - a 30% increase. However, that's not the > real problem. My experience is that hosts, especially PC's, have > a lot of trouble handling *LOTS* of interrupts. To send 2k out > via the network, it's no longer 2 packets but 20+ - a significant > increase in the workload. The problem for the attacker is that he needs to be ACKing all of these segments. It may take more packets to move 2kB, but the packets are not going out any more rapidly than they would if we just asked for 50kB file (which also requires 20+ more packets without the change in MSS). > What's most surprising is that there does not appear to be a documented > minimum, just as there is no "minimum MTU" size for IP. If there is, > please correct me. The absolute minimum MTU for IP is 68 (RFC791). > Oh, so how's this a potential denial of service attack? Generally, > network efficiency comes through sending lots of large packets...but > don't tell ATM folks that, of course :-) Does it work? *shrug* It > is not easy to test...the only testing I could do (with NetBSD) was > to use the TCP_MAXSEG setsockopt BUT this only affects the sending > MSS (now what use is that ? :-), but in testing, changing it from > the default 1460 to 1 caused number of packets to go from 9 to 2260 > to write 1436 bytes of data to discard. To send 100 * 1436 from > the NetBSD box to Solaris8 took 60 seconds (MSS of 1) vs ~1 with > an MSS of 1460. Of even more significance, one connection like > this made almost no difference after the first run but running a > second saw kernel CPU jump to 30% on an SS20/712 (I suspect there > are some serious TCP tuning happening dynamically). The sending > host was likewise afflicted with a signifcant CPU usage penalty if > more than one was running. There were some very surprising things > happening too - with just one session active, ~170-200pps were > seen with netstat on Solaris, but with the second, it was between > 1750 and 1850pps. Can you say "ACK storm" ? Oh, and for fun you > can enable TCP timestamping just to make those headers bigger and > run the system a bit harder whilst processing packets! Was this done on a LAN. Anyone can DoS themselves locally by generating enough noise. This is a Denial/Degredation of Service attack. I do not believe it constitutes a major threat. Like so many such hypothetical DoS attacks, it is symetrical. That is, it causes just as much hardship for the attacker as the attackee. Yes, the machine being attacked needs to send out more packets, but the attacker needs to be responding with just as many ACKs[0]. If the attacker wants to generate lots of packets from the system being attacked, why not make just multple connections or try to do big downloads? What does this attack do that more straight forward attempts to consume the attacked machine's resources don't? [0] There actually are ways to make ACKing asymetrical, but that opens up a whole range of attacks of which this one is no more interesting or effective than the rest. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 14: 3:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.siol.net (odin.siol.net [193.189.160.10]) by hub.freebsd.org (Postfix) with ESMTP id DC94637B408 for ; Sun, 8 Jul 2001 14:03:08 -0700 (PDT) (envelope-from solwar@email.si) Received: from AS-101-90.dial-up.siol.net ([193.189.182.90]) by mail.siol.net (InterMail vK.4.02.00.10 201-232-116-110 license 3b7ff800a4377eede9efc7be81e8a7c4) with ESMTP id <20010708210306.NGXN27327.mail@AS-101-90.dial-up.siol.net> for ; Sun, 8 Jul 2001 23:03:06 +0200 Date: Sun, 8 Jul 2001 23:03:38 +0200 (CEST) From: solwar X-X-Sender: To: Subject: non-exec stack Message-ID: <20010708230147.C2090-100000@SOLos.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hello, Is there is any non-exec stack kernel patch available for FreeBSD? (like linux's openwall patch from solar designer, www.openwall.com) tnx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 15:41:47 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.quidel.com (webmail.quidel.com [63.125.144.4]) by hub.freebsd.org (Postfix) with ESMTP id E789C37B401 for ; Sun, 8 Jul 2001 15:41:45 -0700 (PDT) (envelope-from et@quidel.com) Received: by mail.quidel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 8 Jul 2001 15:48:38 -0700 Message-ID: <9D4A4E19244ED4119BE90050DAD5DD47BC5511@mail.quidel.com> From: Etienne de Bruin To: "'security@freebsd.org'" Subject: Checkpoint VPN + FreeBSD IPSEC Client? Date: Sun, 8 Jul 2001 15:48:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I was wondering if anyone has managed to configure a FreeBSD client to connect to a network secured by Checkpoint's VPN-1 using IPSEC? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 15:44: 1 2001 Delivered-To: freebsd-security@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id B7B2C37B401 for ; Sun, 8 Jul 2001 15:43:57 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id IAA08926; Mon, 9 Jul 2001 08:24:28 +1000 (EST) From: Darren Reed Message-Id: <200107082224.IAA08926@caligula.anu.edu.au> Subject: Re: FW: Small TCP packets == very large overhead == DoS? To: cjclark@alum.mit.edu Date: Mon, 9 Jul 2001 08:24:28 +1000 (Australia/ACT) Cc: Yonatan@xpert.com (Yonatan Bokovza), freebsd-security@FreeBSD.ORG ('freebsd-security@freebsd.org') In-Reply-To: <20010708132629.B307@blossom.cjclark.org> from "Crist J. Clark" at Jul 08, 2001 01:26:29 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In some mail from Crist J. Clark, sie said: > > On Sun, Jul 08, 2001 at 02:54:53PM +0300, Yonatan Bokovza wrote: > > Hi, > > This was just on bugtraq. > > Is net.inet.tcp.min_mss the solution? > > To what problem? As I get to below, it is a symetrical DoS attack. As > a general class, these are not a big threat. > > Darren... you came up with this? So are most DoS attacks which have anything to do with sending large numbers of packets. This is somewhat similar to ICMP smurf attacks that are directed at broadcast addresses. [...] > The problem for the attacker is that he needs to be ACKing all of > these segments. It may take more packets to move 2kB, but the packets > are not going out any more rapidly than they would if we just asked > for 50kB file (which also requires 20+ more packets without the change > in MSS). Think TCP windows. > > What's most surprising is that there does not appear to be a documented > > minimum, just as there is no "minimum MTU" size for IP. If there is, > > please correct me. > > The absolute minimum MTU for IP is 68 (RFC791). Yeah, enough for 64bytes of header options and 8 bytes of fragmented data. Not what I'd call a "useful" minimum. [...] > This is a Denial/Degredation of Service attack. I do not believe it > constitutes a major threat. Like so many such hypothetical DoS > attacks, it is symetrical. That is, it causes just as much hardship > for the attacker as the attackee. Yes, the machine being attacked > needs to send out more packets, but the attacker needs to be > responding with just as many ACKs[0]. If the attacker wants to > generate lots of packets from the system being attacked, why not make > just multple connections or try to do big downloads? What does this > attack do that more straight forward attempts to consume the attacked > machine's resources don't? PC's can only handle a set number of interrupts per second. Serving an interrupt is fairly expensive. This attack decreases the efficiency of the host in servicing interrupts in a dramatic fashion. The smaller you can force the packets can be, the bigger the hit. In testing on my LAN, which is connected into a switch, the high packet rate did not bother the switch (as it ought not to have) but it did the boxes involved. It's not just about pumping more data through and saturating the network, it's about causing the server to do more work than it normally does in order to send the same amount of data. In this respect it's not primarily a network DoS attack, but a sytem resources (CPU/interrupt servicing) DoS attack also. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 16:28:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from ns1.austclear.com.au (ns1.austclear.com.au [192.43.185.68]) by hub.freebsd.org (Postfix) with ESMTP id 8196337B401 for ; Sun, 8 Jul 2001 16:28:30 -0700 (PDT) (envelope-from ahl@austclear.com.au) Received: from tungsten.austclear.com.au (tungsten.austclear.com.au [192.168.70.1]) by ns1.austclear.com.au (8.11.2/8.11.3) with ESMTP id f68NSTH04412; Mon, 9 Jul 2001 09:28:29 +1000 (EST) (envelope-from ahl@austclear.com.au) Received: from tungsten (tungsten [192.168.70.1]) by tungsten.austclear.com.au (8.9.3/8.9.3) with ESMTP id JAA27170; Mon, 9 Jul 2001 09:28:29 +1000 (EST) Message-Id: <200107082328.JAA27170@tungsten.austclear.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: "tjk@tksoft.com" Cc: ascheepe@surf.iae.nl (Axel Scheepers), freebsd-security@FreeBSD.ORG Subject: Re: Firewall and ftp service In-Reply-To: Message from "tjk@tksoft.com" of "Sun, 08 Jul 2001 03:01:54 MST." <200107081001.DAA07513@smtp3.tksoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Jul 2001 09:28:28 +1000 From: Tony Landells Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Troy, I'm sorry, but your description of normal (active) mode FTP is incorrect. tjk@tksoft.com said: > I wanted to point out that port 20 is for ftp data and port 21 is for > ftp commands. > When an ftp connection is made, the client connects to the server at > port 21. All communications occur on that channel. So far, so good. > When the server needs to send data to the client, it opens a > connection to port 20 on the client. When it makes the connection, it > allocates a local port > 1024 for its local port. No. When the client requests data from the server, the CLIENT allocates a random port number and tells the SERVER what it is, and then the SERVER opens a connection FROM port 20 to that random port on the client. > When a client requests passive ftp, the server opens a random port > > 1024 for listening. The client then opens a connection to that port. And then we're back on track again. > With both passive and regular ftp data connections, the server has a > local port > 1024 open. The distinction is that with passive ftp the > server does a "listen()," opening a port for incoming connections. > With regular ftp, the server does a "connect()" and the client must > open port 20 with "listen()." And obviously the summary is off-track because the information it's derived from is slightly wrong. Anyone doing this stuff would do well to look at the O'Reilly book "Building Internet Firewalls" by Chapman and Zwicky which describes the packet filtering characteristics of all the major protocols. As far as Axel's problem goes, I'm not sure what natd does with FTP connections (I usually give public servers a public address) but the server certainly passes its address back to the client for passive mode connections along with the port number the client needs to connect to (in normal or active mode the client sends its address and port number to the server). Some FTP clients will tell you what the ports are, which you can compare with logs on your firewall (assuming you're logging FTP connections). If the connection is actually timing out, you can also look at netstat on the various boxes to see what ports are being used. Otherwise, I'd suggest running natd in "verbose" mode to actually watch the translations--it may be altering some port numbers as well, which will throw things off. I hope there's some help in there somewhere... Tony -- Tony Landells Senior Network Engineer Ph: +61 3 9677 9319 Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 Level 4, Rialto North Tower 525 Collins Street Melbourne VIC 3000 Australia To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 17:39:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id AF49E37B403 for ; Sun, 8 Jul 2001 17:39:11 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.245.140.126.Dial1.SanJose1.Level3.net [209.245.140.126]) by swan.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA15317; Sun, 8 Jul 2001 17:39:06 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f690d4D01640; Sun, 8 Jul 2001 17:39:04 -0700 (PDT) (envelope-from cjc) Date: Sun, 8 Jul 2001 17:39:04 -0700 From: "Crist J. Clark" To: Darren Reed Cc: cjclark@alum.mit.edu, Yonatan Bokovza , "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010708173904.D307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20010708132629.B307@blossom.cjclark.org> <200107082224.IAA08926@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107082224.IAA08926@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Mon, Jul 09, 2001 at 08:24:28AM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 08:24:28AM +1000, Darren Reed wrote: > In some mail from Crist J. Clark, sie said: > > > > On Sun, Jul 08, 2001 at 02:54:53PM +0300, Yonatan Bokovza wrote: > > > Hi, > > > This was just on bugtraq. > > > Is net.inet.tcp.min_mss the solution? > > > > To what problem? As I get to below, it is a symetrical DoS attack. As > > a general class, these are not a big threat. > > > > Darren... you came up with this? > > So are most DoS attacks which have anything to do with sending large > numbers of packets. This is somewhat similar to ICMP smurf attacks > that are directed at broadcast addresses. A Smurf attack is asymetrical. The attacker sends out a very small number of packets and the amplifier network does the real work. So, attacker sends low volume of traffic, attackee gets drowned in a large volume, asymetric. Another thing I forgot to mention is that this is "unspoofable" in the sense that the TCP handshake needs to be completed for it to work. This also greatly reduces the risk. > [...] > > The problem for the attacker is that he needs to be ACKing all of > > these segments. It may take more packets to move 2kB, but the packets > > are not going out any more rapidly than they would if we just asked > > for 50kB file (which also requires 20+ more packets without the change > > in MSS). > > Think TCP windows. Do I have to? *think* *ouch* I still don't see anything here that you couldn't do with "Daytona" TCP attack. This might be a way to make them worse. > > > What's most surprising is that there does not appear to be a documented > > > minimum, just as there is no "minimum MTU" size for IP. If there is, > > > please correct me. > > > > The absolute minimum MTU for IP is 68 (RFC791). > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > data. Not what I'd call a "useful" minimum. How about the 576 byte (IIRC) value? It's not really a network MTU, but all host must be able to handle datagrams of that size. > [...] > > This is a Denial/Degredation of Service attack. I do not believe it > > constitutes a major threat. Like so many such hypothetical DoS > > attacks, it is symetrical. That is, it causes just as much hardship > > for the attacker as the attackee. Yes, the machine being attacked > > needs to send out more packets, but the attacker needs to be > > responding with just as many ACKs[0]. If the attacker wants to > > generate lots of packets from the system being attacked, why not make > > just multple connections or try to do big downloads? What does this > > attack do that more straight forward attempts to consume the attacked > > machine's resources don't? > > PC's can only handle a set number of interrupts per second. Serving an > interrupt is fairly expensive. This attack decreases the efficiency of > the host in servicing interrupts in a dramatic fashion. The smaller > you can force the packets can be, the bigger the hit. Yeah, I understand it boils down to a packets/time issue. I still don't see how a high packet rate can be sustained. > In testing on my LAN, which is connected into a switch, the high packet > rate did not bother the switch (as it ought not to have) but it did the > boxes involved. It's not just about pumping more data through and > saturating the network, it's about causing the server to do more work > than it normally does in order to send the same amount of data. > > In this respect it's not primarily a network DoS attack, but a sytem > resources (CPU/interrupt servicing) DoS attack also. But I'd still like to see it done over the Internet rather than a LAN before anyone gets too excited. Although it might be something fun to mess with people on the LAN at DEFCON this weekend. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 18: 5: 3 2001 Delivered-To: freebsd-security@freebsd.org Received: from front8.grolier.fr (front8.grolier.fr [194.158.96.58]) by hub.freebsd.org (Postfix) with ESMTP id 8128637B401 for ; Sun, 8 Jul 2001 18:05:00 -0700 (PDT) (envelope-from huvier@linux.esiea.fr) Received: from linux.esiea.fr (bas2-6.idf2-1.club-internet.fr [195.36.220.6]) by front8.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id DAA03906 for ; Mon, 9 Jul 2001 03:04:50 +0200 (MET DST) Message-ID: <3B49033B.D498C5E4@linux.esiea.fr> Date: Mon, 09 Jul 2001 03:04:59 +0200 From: Adrien Huvier Organization: ESIEA X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: wtmp corrupted - ? References: <200107072255.f67MteA15656@giganda.komkon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Igor Roshchin wrote: > Sorry, > I just discovered, that it happened due to the disk partition being > filled up at some point, and wtmp became corrupted. I have the same problem on a 4.2-RELEASE. The only sessions concerned with this problems are various ftp sessions (we use proftpd). However the only partition that ever filled up on this computer is /usr/home and the problem didn't even solve when some space was freed... Does anyone have a clue? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 18: 7: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.siol.net (odin.siol.net [193.189.160.10]) by hub.freebsd.org (Postfix) with ESMTP id 438E337B401 for ; Sun, 8 Jul 2001 18:07:01 -0700 (PDT) (envelope-from solwar@email.si) Received: from AS-101-90.dial-up.siol.net ([193.189.182.90]) by mail.siol.net (InterMail vK.4.02.00.10 201-232-116-110 license 3b7ff800a4377eede9efc7be81e8a7c4) with ESMTP id <20010709010659.QDAO27327.mail@AS-101-90.dial-up.siol.net>; Mon, 9 Jul 2001 03:06:59 +0200 Date: Mon, 9 Jul 2001 03:07:34 +0200 (CEST) From: solwar X-X-Sender: To: alexus Cc: Subject: Re: non-exec stack In-Reply-To: <001701c107f1$b3881fc0$97625c42@alexus> Message-ID: <20010709030412.I3212-100000@SOLos.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Most buffer overflow exploits are based on overwriting a function's return address on the stack to point to some arbitrary code, which is also put onto the stack. If the stack area is non-executable, buffer overflow vulnerabilities become harder to exploit. On Sun, 8 Jul 2001, alexus wrote: > what do you mean by non-exec? > > ----- Original Message ----- > From: "solwar" > To: > Sent: Sunday, July 08, 2001 5:03 PM > Subject: non-exec stack > > > > Hello, > > Is there is any non-exec stack kernel patch available for FreeBSD? > > (like linux's openwall patch from solar designer, www.openwall.com) > > tnx > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 18:13: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id BEF9D37B40B for ; Sun, 8 Jul 2001 18:13:03 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 26432 invoked by uid 1000); 9 Jul 2001 01:13:02 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2001 01:13:02 -0000 Date: Sun, 8 Jul 2001 20:13:02 -0500 (CDT) From: Mike Silbersack To: Cc: Darren Reed , Yonatan Bokovza , "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? In-Reply-To: <20010708173904.D307@blossom.cjclark.org> Message-ID: <20010708200041.A26132-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 8 Jul 2001, Crist J. Clark wrote: > On Mon, Jul 09, 2001 at 08:24:28AM +1000, Darren Reed wrote: > > In some mail from Crist J. Clark, sie said: > > > > What's most surprising is that there does not appear to be a documented > > > > minimum, just as there is no "minimum MTU" size for IP. If there is, > > > > please correct me. > > > > > > The absolute minimum MTU for IP is 68 (RFC791). > > > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > > data. Not what I'd call a "useful" minimum. > > How about the 576 byte (IIRC) value? It's not really a network MTU, > but all host must be able to handle datagrams of that size. Looking at Darren's table, it seems like we could split the difference between breaking things and allowing this to be abused. 256 sounds like a good number. Perhaps we should just make that the new minimum and not worry any further. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 19:25:11 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.kyx.net (s216-232-31-82.bc.hsia.telus.net [216.232.31.82]) by hub.freebsd.org (Postfix) with ESMTP id B028137B401 for ; Sun, 8 Jul 2001 19:25:07 -0700 (PDT) (envelope-from dr@kyx.net) Received: from smp.kyx.net (unknown [10.22.22.45]) by mail.kyx.net (Postfix) with SMTP id B73AD1DC03; Sun, 8 Jul 2001 19:31:55 -0700 (PDT) From: Dragos Ruiu Organization: kyx.net To: Mike Silbersack , Subject: Re: FW: Small TCP packets == very large overhead == DoS? Date: Sun, 8 Jul 2001 19:15:59 -0700 X-Mailer: KYX-CP/M [version core00-mail-92] Content-Type: text/plain Cc: Darren Reed , Yonatan Bokovza , "'freebsd-security@freebsd.org'" References: <20010708200041.A26132-100000@achilles.silby.com> In-Reply-To: <20010708200041.A26132-100000@achilles.silby.com> MIME-Version: 1.0 Message-Id: <0107081922111G.08020@smp.kyx.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Am I understanding this correctly? You intend to muck with the RFC value and create another variant in behaviour to tweak for and to worry about, to account for the possibility of clients that have lame packet overhead behaviour? just curious, --dr On Sun, 08 Jul 2001, Mike Silbersack wrote: > On Sun, 8 Jul 2001, Crist J. Clark wrote: > > > On Mon, Jul 09, 2001 at 08:24:28AM +1000, Darren Reed wrote: > > > In some mail from Crist J. Clark, sie said: > > > > > What's most surprising is that there does not appear to be a documented > > > > > minimum, just as there is no "minimum MTU" size for IP. If there is, > > > > > please correct me. > > > > > > > > The absolute minimum MTU for IP is 68 (RFC791). > > > > > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > > > data. Not what I'd call a "useful" minimum. > > > > How about the 576 byte (IIRC) value? It's not really a network MTU, > > but all host must be able to handle datagrams of that size. > > Looking at Darren's table, it seems like we could split the difference > between breaking things and allowing this to be abused. 256 sounds like a > good number. Perhaps we should just make that the new minimum and not > worry any further. > > Mike "Silby" Silbersack > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Dragos Ruiu dursec.com ltd. / kyx.net - we're from the future gpg/pgp key on file at wwwkeys.pgp.net or at http://dursec.com/drkey.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 19:32:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.kyx.net (s216-232-31-82.bc.hsia.telus.net [216.232.31.82]) by hub.freebsd.org (Postfix) with ESMTP id 7E3BE37B401 for ; Sun, 8 Jul 2001 19:32:42 -0700 (PDT) (envelope-from dr@kyx.net) Received: from smp.kyx.net (unknown [10.22.22.45]) by mail.kyx.net (Postfix) with SMTP id 692141DC03; Sun, 8 Jul 2001 19:39:40 -0700 (PDT) From: Dragos Ruiu Organization: kyx.net To: Mike Silbersack , Subject: Re: FW: Small TCP packets == very large overhead == DoS? Date: Sun, 8 Jul 2001 19:24:29 -0700 X-Mailer: KYX-CP/M [version core00-mail-92] Content-Type: text/plain Cc: Darren Reed , Yonatan Bokovza , "'freebsd-security@freebsd.org'" References: <20010708200041.A26132-100000@achilles.silby.com> <0107081922111G.08020@smp.kyx.net> In-Reply-To: <0107081922111G.08020@smp.kyx.net> MIME-Version: 1.0 Message-Id: <0107081929561H.08020@smp.kyx.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 08 Jul 2001, Dragos Ruiu wrote: > > > > > The absolute minimum MTU for IP is 68 (RFC791). > > > > > > > > Yeah, enough for 64bytes of header options and 8 bytes of fragmented > > > > data. Not what I'd call a "useful" minimum. In some applications like streaming, latency or retransmission efficiency is more important than data throughput efficiency. "Useful" differs in meaning depending on your application. --dr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 19:42:36 2001 Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 4E4A037B406 for ; Sun, 8 Jul 2001 19:42:33 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 26616 invoked by uid 1000); 9 Jul 2001 02:42:32 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Jul 2001 02:42:32 -0000 Date: Sun, 8 Jul 2001 21:42:32 -0500 (CDT) From: Mike Silbersack To: Dragos Ruiu Cc: , Darren Reed , Yonatan Bokovza , "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? In-Reply-To: <0107081922111G.08020@smp.kyx.net> Message-ID: <20010708213736.C26132-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 8 Jul 2001, Dragos Ruiu wrote: > > Am I understanding this correctly? You intend to muck with the > RFC value and create another variant in behaviour to tweak for > and to worry about, to account for the possibility of clients that > have lame packet overhead behaviour? > > just curious, > --dr There's nothing wrong with questioning the correctness of RFCs. They were, after all, written by ordinary mortals like everyone in this discussion. Maybe 256 is too high, perhaps 128 would be more reasonable. 64 seems way too small in any case. Your arguement about latency isn't relevant here. If you were writing a latency-sensitive app, you wouldn't be running tcp. Also, as I understand it, we're setting a minimum on the maximum, not a minimum on the minimum. Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 20:30:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from a.mx.clublinux.org (h216-170-019-162.adsl.navix.net [216.170.19.162]) by hub.freebsd.org (Postfix) with SMTP id 429B037B403 for ; Sun, 8 Jul 2001 20:30:11 -0700 (PDT) (envelope-from steve@clublinux.org) Received: (qmail 6844 invoked from network); 9 Jul 2001 02:28:44 -0000 Received: from unknown (HELO clublinux.org) (192.168.33.33) by mail.internal with SMTP; 9 Jul 2001 02:28:44 -0000 Message-ID: <3B492672.55E0ADC8@clublinux.org> Date: Sun, 08 Jul 2001 22:35:14 -0500 From: steve X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: cvsup and security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I've been installing a few ports (great tool btw), and I've noticed that typing 'make install' in an app directory will perform an md5 checksum to verify that the download is legit and not corrupt. Is there anything similar done when using cvsup? Is there anyway to verify that the ports collection update that I'm receiving through cvsup is legit and not "trojaned" or altered in some other way? Thanks in advance, Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 22:11:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from stuart.microshaft.org (ns1.microshaft.org [208.201.249.2]) by hub.freebsd.org (Postfix) with ESMTP id 4816937B401 for ; Sun, 8 Jul 2001 22:11:17 -0700 (PDT) (envelope-from jono@stuart.microshaft.org) Received: (from jono@localhost) by stuart.microshaft.org (8.9.3/8.9.3) id WAA00610; Sun, 8 Jul 2001 22:11:15 -0700 (PDT) (envelope-from jono) Date: Sun, 8 Jul 2001 22:11:15 -0700 From: "Jon O ." To: Etienne de Bruin Cc: "'security@freebsd.org'" Subject: Re: Checkpoint VPN + FreeBSD IPSEC Client? Message-ID: <20010708221115.A178@networkcommand.com> Reply-To: "jono@networkcommand.com" References: <9D4A4E19244ED4119BE90050DAD5DD47BC5511@mail.quidel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <9D4A4E19244ED4119BE90050DAD5DD47BC5511@mail.quidel.com>; from et@quidel.com on Sun, Jul 08, 2001 at 03:48:31PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This might work for you: Integration of Checkpoint VPN-1/FW-1 with FreeBSD's IPSEC: http://www.securityreports.com/article.pl?sid=01/05/11/1711225&mode=thread&threshold= or http://securityportal.com/articles/cpbsd20010525.html I'm assuming by client you mean racoon or something that exchanges keys for you. Let me know if you have any comments or suggestions on the paper or any problems pulling this off. Checkpoint didn't think it would work, but it does. Thanks, Jon On 08-Jul-2001, Etienne de Bruin wrote: > I was wondering if anyone has managed to configure a FreeBSD client to > connect to a network secured by Checkpoint's VPN-1 using IPSEC? > > Thanks > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 22:11:45 2001 Delivered-To: freebsd-security@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-132.dsl.lsan03.pacbell.net [63.207.60.132]) by hub.freebsd.org (Postfix) with ESMTP id 7679337B403 for ; Sun, 8 Jul 2001 22:11:42 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1772C66D72; Sun, 8 Jul 2001 22:11:41 -0700 (PDT) Date: Sun, 8 Jul 2001 22:11:40 -0700 From: Kris Kennaway To: steve Cc: freebsd-security@freebsd.org Subject: Re: cvsup and security Message-ID: <20010708221140.A35469@xor.obsecurity.org> References: <3B492672.55E0ADC8@clublinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B492672.55E0ADC8@clublinux.org>; from steve@clublinux.org on Sun, Jul 08, 2001 at 10:35:14PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Jul 08, 2001 at 10:35:14PM -0500, steve wrote: > Hi, > I've been installing a few ports (great tool btw), and I've noticed > that typing 'make install' in an app directory will perform an md5 > checksum to verify that the download is legit and not corrupt. Is there > anything similar done when using cvsup? Is there anyway to verify that > the ports collection update that I'm receiving through cvsup is legit > and not "trojaned" or altered in some other way? Not currently. Note to all on the list: please resist the temptation to offer suggestions for how cvsup could be improved to achieve this unless they're in the form of patches. We all know how to do it, but the code needs to be written. Kris --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7ST0LWry0BWjoQKURAvZhAJ9hSoqE/xfmUBF57YqGBtNt9Qa36QCg7QD2 7uvKpS00ci7Ie/FZqt6XToA= =5Bp3 -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 22:38:13 2001 Delivered-To: freebsd-security@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id AE21737B401 for ; Sun, 8 Jul 2001 22:38:09 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.247.137.230.Dial1.SanJose1.Level3.net [209.247.137.230]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id WAA10916; Sun, 8 Jul 2001 22:36:53 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f695Yp902334; Sun, 8 Jul 2001 22:34:51 -0700 (PDT) (envelope-from cjc) Date: Sun, 8 Jul 2001 22:34:47 -0700 From: "Crist J. Clark" To: Kris Kennaway Cc: steve , freebsd-security@FreeBSD.ORG Subject: Re: cvsup and security Message-ID: <20010708223447.F307@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <3B492672.55E0ADC8@clublinux.org> <20010708221140.A35469@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708221140.A35469@xor.obsecurity.org>; from kris@obsecurity.org on Sun, Jul 08, 2001 at 10:11:40PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 08, 2001 at 10:11:40PM -0700, Kris Kennaway wrote: > On Sun, Jul 08, 2001 at 10:35:14PM -0500, steve wrote: > > Hi, > > I've been installing a few ports (great tool btw), and I've noticed > > that typing 'make install' in an app directory will perform an md5 > > checksum to verify that the download is legit and not corrupt. Is there > > anything similar done when using cvsup? Is there anyway to verify that > > the ports collection update that I'm receiving through cvsup is legit > > and not "trojaned" or altered in some other way? > > Not currently. > > Note to all on the list: please resist the temptation to offer > suggestions for how cvsup could be improved to achieve this unless > they're in the form of patches. We all know how to do it, but the > code needs to be written. We do know how to do this? What trusted location would these MD5 checksums come from? If someone has slipped in malicious code on a cvsupd server, it is relatively easy to change the MD5 sums provided by that server to match. Or is the idea that you get files from a random mirror, but get MD5 checksums from a different location? I'd also like to point out that the ports are checking something different with the MD5 sum. Since you got the MD5 hashes for the ports from an cvsupd server, you already are trusting cvsup (unless you are using old ones from a CD). All the MD5 hashes on ports prove is that the tarball you download is the same one the maintainer downloaded when he built the port skeleton. That does NOT mean that the maintainer audited the code, checked the code, or did not insert malicious code himself. When an MD5 check fails, the most common reason is that a developer modified the code without changing the version number, not that code was tampered with. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 23:13:17 2001 Delivered-To: freebsd-security@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-132.dsl.lsan03.pacbell.net [63.207.60.132]) by hub.freebsd.org (Postfix) with ESMTP id 7531137B401 for ; Sun, 8 Jul 2001 23:13:13 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A2E7166D72; Sun, 8 Jul 2001 23:13:11 -0700 (PDT) Date: Sun, 8 Jul 2001 23:13:11 -0700 From: Kris Kennaway To: cjclark@alum.mit.edu Cc: Kris Kennaway , steve , freebsd-security@FreeBSD.ORG Subject: Re: cvsup and security Message-ID: <20010708231310.A36630@xor.obsecurity.org> References: <3B492672.55E0ADC8@clublinux.org> <20010708221140.A35469@xor.obsecurity.org> <20010708223447.F307@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010708223447.F307@blossom.cjclark.org>; from cristjc@earthlink.net on Sun, Jul 08, 2001 at 10:34:47PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 08, 2001 at 10:34:47PM -0700, Crist J. Clark wrote: > On Sun, Jul 08, 2001 at 10:11:40PM -0700, Kris Kennaway wrote: > > On Sun, Jul 08, 2001 at 10:35:14PM -0500, steve wrote: > > > Hi, > > > I've been installing a few ports (great tool btw), and I've noticed > > > that typing 'make install' in an app directory will perform an md5 > > > checksum to verify that the download is legit and not corrupt. Is th= ere > > > anything similar done when using cvsup? Is there anyway to verify th= at > > > the ports collection update that I'm receiving through cvsup is legit > > > and not "trojaned" or altered in some other way? > >=20 > > Not currently. > >=20 > > Note to all on the list: please resist the temptation to offer > > suggestions for how cvsup could be improved to achieve this unless > > they're in the form of patches. We all know how to do it, but the > > code needs to be written. >=20 > We do know how to do this? What trusted location would these MD5 > checksums come from? cvsup-master. It's a straightforward problem to solve, but like I said there's no point wasting time talking about it unless someone is prepared to write the Modula-3 code. Kris --k1lZvvs/B4yU6o8G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7SUt1Wry0BWjoQKURAtEZAJ9AAi8BSPZr9WH85iIciK0JTqulswCg/CpH 1ykfo9DrRBGb8FyGCSiRaz4= =Zdj+ -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jul 8 23:37:49 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.kyx.net (s216-232-31-82.bc.hsia.telus.net [216.232.31.82]) by hub.freebsd.org (Postfix) with ESMTP id 9432A37B405 for ; Sun, 8 Jul 2001 23:37:45 -0700 (PDT) (envelope-from dr@kyx.net) Received: from smp.kyx.net (unknown [10.22.22.45]) by mail.kyx.net (Postfix) with SMTP id D527E1DC03; Sun, 8 Jul 2001 23:44:42 -0700 (PDT) From: Dragos Ruiu Organization: kyx.net To: Mike Silbersack Subject: Re: FW: Small TCP packets == very large overhead == DoS? Date: Sun, 8 Jul 2001 22:50:14 -0700 X-Mailer: KYX-CP/M [version core00-mail-92] Content-Type: text/plain Cc: , Darren Reed , Yonatan Bokovza , "'freebsd-security@freebsd.org'" References: <20010708213736.C26132-100000@achilles.silby.com> In-Reply-To: <20010708213736.C26132-100000@achilles.silby.com> MIME-Version: 1.0 Message-Id: <0107082333531I.08020@smp.kyx.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 08 Jul 2001, Mike Silbersack wrote: > There's nothing wrong with questioning the correctness of RFCs. They > were, after all, written by ordinary mortals like everyone in this > discussion. Certainly agreed. But I think the right way to do this is via changing the RFC in the IETF so that all the implementations are consistent rather than building yet another non-standard implementation of the standard. (Insert Tannenbaum standards quote "Nice thing about standards, there are so many to choose from." :-) > Maybe 256 is too high, perhaps 128 would be more reasonable. 64 seems way > too small in any case. I'm of a differing opinion. Using standard 20 byte headers instead of the more fanciful maximal IP option headers this gives 44 bytes of payload. I recall one standards group that argued for months about packetsize issues where for some applications the representatives argued that 64 bytes was too large a packetsize (this particular debate was over 32 or 64 byte cells, and oddly enough they agreed on 48 for no particular reason other than to stop arguing :-). > Your arguement about latency isn't relevant here. If you were writing a > latency-sensitive app, you wouldn't be running tcp. Also, as I understand > it, we're setting a minimum on the maximum, not a minimum on the minimum. Why wouldn't I want to use an error corrected channel on a latency sensitive app? I have written an applicaiton that needs this. It is exactly "optimizations" like these that drive streaming implementers to need to reinvent the wheel and develop their own error correction protocols on top of UDP. IMHO It's actually a minimum... If I understand MSS application (which I feel I do) it's what the packet sizes the OS will fragment the data into to convey it efficiently across the channel, which works out into pretty much being the minimum packet size the OS will segment streams into. Please correct me if I have made an error, as I too am merely human. But that's just my two cents, you gentlemen are free to implement what you choose, and I'm free to move my encrypted streaming app to whatever OSes I choose or force my users to patch kernels to use it accordingly. It's just less messy for me if this isn't changed. It may in practice not even be a big deal, but again, I question the logic of changing the implementations to forestall a hypothetical attack of marginal effect on another OS. cheers, --dr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 0:26: 8 2001 Delivered-To: freebsd-security@freebsd.org Received: from mx1.thinksec.com (time.thinksec.com [193.212.248.2]) by hub.freebsd.org (Postfix) with ESMTP id 69BF637B405 for ; Mon, 9 Jul 2001 00:26:06 -0700 (PDT) (envelope-from eivind@enigma.thinksec.com) Received: from enigma.thinksec.com (lsl53.nsn.no [195.159.104.244]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "enigma.thinksec.com", Issuer CN "ThinkSec CA admin" (verified OK)) by mx1.thinksec.com (Postfix) with ESMTP id 594FE4816D; Mon, 9 Jul 2001 09:26:04 +0200 (CEST) Received: by enigma.thinksec.com (Postfix, from userid 1001) id 80D613EB27; Mon, 9 Jul 2001 00:24:09 +0200 (CEST) Date: Mon, 9 Jul 2001 00:24:09 +0200 From: Eivind Eklund To: Jason Burdick Cc: security@freebsd.org Subject: Re: Hiding Versions Message-ID: <20010709002409.B49349@thinksec.no> References: <200107061929.MAA30700@user7.hushmail.com> <003801c1065e$c4724480$0c8e1581@yclan.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003801c1065e$c4724480$0c8e1581@yclan.net> User-Agent: Mutt/1.3.19i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jul 06, 2001 at 05:01:03PM -0400, Jason Burdick wrote: > Hiding version strings is very pointless. The only use is to let admins be > a tad bit more lazy in patching so s'kiddies, who only look for version > strings for exploit purposes, will pass by the box. This doesn't stop > someone with a clue, so it's a waste of time. Patch the box correctly, and > you'll have less problems. I agree that you should patch the box correctly. I do not agree that hiding verison numbers is useless. When you hide your version number, you make it less likely that the exploit will work the first time - and if your service is set up so the first attempt is all the attackers get (e.g, BIND exploits) then hiding the version number increase real security. It also increase the likelihood of detection, as a wrong exploit is likely to be tried first, and thus log an error. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 0:30: 7 2001 Delivered-To: freebsd-security@freebsd.org Received: from surf.iae.nl (surf.iae.nl [212.61.20.2]) by hub.freebsd.org (Postfix) with ESMTP id 9B03D37B403 for ; Mon, 9 Jul 2001 00:29:54 -0700 (PDT) (envelope-from ascheepe@iae.nl) Received: by surf.iae.nl (Postfix, from userid 22499) id 805F4BFD1F; Mon, 9 Jul 2001 09:29:43 +0200 (CEST) Date: Mon, 9 Jul 2001 09:29:43 +0200 From: Axel Scheepers To: freebsd-security@FreeBSD.ORG Subject: Re: Firewall and ftp service Message-ID: <20010709092943.A2548@surf.iae.nl> References: <20010707153247.A78448@surf.iae.nl> <20010707113849.C408@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010707113849.C408@blossom.cjclark.org>; from cristjc@earthlink.net on Sat, Jul 07, 2001 at 11:38:49AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Thank you all for your help! ;-) I do use kind of a mix of ipf/ipfw/natd at the moment, but that was bacause I wanted it working as fast as possible (Just switched from modem to cable ;-) Now my first "Wow, I want to do ... and ... and .." feelings are over I want to figure out a nice clean way for doing it. So thank you all for your great responses, you've given me a lot of starting points (ipnat instead of natd) and help (ftp howto ;-) Thanks, Axel Scheepers On Sat, Jul 07, 2001 at 11:38:49AM -0700, Crist J. Clark wrote: > On Sat, Jul 07, 2001 at 03:32:47PM +0200, Axel Scheepers wrote: > > I'll say it again, FTP is eeeevul. > > > Hi everybody, > > I hope I'm not being really off topic with this one but > > it's been troubling me for a while now. > > I'm looking for a way to provide acces to an ftpserver, my current > > network layout looks like this: > > > > Cable Modem ------> Gateway ---------> http/ftp server > > | > > | > > +------------> private http/ftp/sql server > > | > > | > > +------------> my workstation > > > > The gateway does natd and ipf since the other servers have private > > adresses. > > natd(8) and ipf(8) or natd(8) and ipfw(8)? I'd recommend either using, > natd(8) and ipfw(8) or ipnat(8) and ipf(8), and not mixing and > matching. There are sometimes reasons to run ipf(8) and ipfw(8) at the > same time, but when you need to proxy FTP, there is too much room for > confusion and weird interactions. > > > The problem now is that whenever I connect to my > > ftp servers from the outside, the server is unable to set up a > > data connection, because it wants to connect on a port > 1024, which > > is blocked by my firewall(and I want to leave it that way). > > Natd does the following: > > natd -redirect_port tcp 192.168.0.5:20 20 -redirect_port 192.168.0.5:21 21 > > which redirects the traffic to my public ftp server. > > > > As I see it there can be 2 problems with this setup; > > 1) The server wants to initiate the data connection at a port > 1024 and/or > > 2) The server still somehow reports 192.168.0.5 as its address to the clients. > > > > I have tried to connect with the option passive is off, which I thought > > should force the server to stay on port 21 for tha data connection, but > > it didn't work. :( > > OK, one more time on how FTP generally works. Everyone knows the > client connects to the server on port 21. That's easy. Now as for the > data connection, there are two modes, PORT (active) and PASV > (passive). In PORT, the client tells the server what port it will be > listening on and the _server_ then (usually) connects to the _client_ > with a source port of 20 and the arbitrary high port ("ephermeral") > the client gave the server as the destination. In PASV, the server > tells the client what port it will be listening on, usually an > arbitrary high, ephermeral port, and the client then connects with a > ephemeral port source to the ephemeral destination. And we should > point out that in both modes the server and client are passing not > only the port number back and forth, but actually the IP address to > connect to as well. > > So, the moral of the story is that FTP is an absolute bitch to work > with if you have a firewall or NAT'ing gateway between the client and > server. You need an application layer proxy for the > connection. Redirection alone will not cut it. > > > Can/will somebody help on getting this done the proper way ? > > I just want to use ipfilter, if possible, and I don't like to install > > a ftp proxy for this. > > Oops. You are really using ipf(8). IPFilter has an FTP proxy > built-in. However, use ipnat(8) and not natd(8) with ipf(8). > -- > Crist J. Clark cjclark@alum.mit.edu -- Met vriendelijke groet, VIA NET.WORKS Nederland Axel Scheepers Operations phone +31 40 239 33 93 fax +31 40 239 33 11 e-mail eindhoven.beheer@vianetworks.nl http://www.vianetworks.nl/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 1: 9: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from gate.ldn.swissbank.com (gate.ldn.ubswarburg.com [193.82.179.18]) by hub.freebsd.org (Postfix) with ESMTP id F2E9437B40B for ; Mon, 9 Jul 2001 01:08:54 -0700 (PDT) (envelope-from Khalil.Haddad@ubs.com) Received: (from smap@localhost) by gate.ldn.swissbank.com (8.8.8/8.8.8) id JAA18584 for ; Mon, 9 Jul 2001 09:07:43 +0100 (BST) From: Khalil.Haddad@ubs.com Received: from (eight.ubswarburg.com [192.168.0.3]) by gate via smap (V2.0) id xma018540; Mon, 9 Jul 2001 09:07:31 +0100 Received: from ln4p1013pos.ldn.swissbank.com (virscan1 [192.168.0.3]) by virscan1.swissbank.com (8.8.8/8.8.8) with ESMTP id IAA24367 for ; Mon, 9 Jul 2001 08:05:11 GMT Received: from ln4p1528.ldn.swissbank.com (ln4p1528.ldn.swissbank.com [172.16.232.54]) by ln4p1013pos.ldn.swissbank.com (8.8.8/8.8.8) with ESMTP id JAA02793 for ; Mon, 9 Jul 2001 09:07:29 +0100 (BST) Received: from ps3p84.par.swissbank.com (ps3p84.par.swissbank.com [155.145.25.41]) by ln4p1528.ldn.swissbank.com (8.8.6 (PHNE_14041)/8.8.6/WDR gamma evision: 1.4 $) with ESMTP id JAA14929 for ; Mon, 9 Jul 2001 09:07:28 +0100 (BST) Received: from localhost (root@localhost) by ps3p84.par.swissbank.com (8.8.6 (PHNE_14041)/8.8.6/WDR gamma evision: 1.4 $) with ESMTP id KAA03578 for ; Mon, 9 Jul 2001 10:07:27 +0200 (METDST) X-OpenMail-Hops: 1 Date: Mon, 9 Jul 2001 10:07:26 +0200 Message-Id: Subject: RE: Re: Hiding Versions MIME-Version: 1.0 To: freebsd-security@FreeBSD.ORG Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Mon, 9 Jul 2001 10:07:26 +0200" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org thx all for your answers. I read in the apache docs that the ServerTokens could do the trick (hiding apache version) for example i often see : Apache v1.3.x the x hiding the version. Unfortunately, i could make this to work, it always outputs the same string. Anyone has a successful experience ? Thank you Khalil -----Original Message----- From: roam [mailto:roam@orbitel.bg] Sent: 06 July 2001 17:15 To: Haddad, Khalil Cc: roam; freebsd-security Subject: Re: Hiding Versions On Fri, Jul 06, 2001 at 05:02:17PM +0200, Khalil.Haddad@ubs.com wrote: > Hello all, > > After visiting this web site : www.netcraft.com, I discovered that it > is possible to trace version changes of OS, apache or php. > > Example : > FreeBSD Apache/1.3.9 (Unix) mod_perl/1.20 4-Dec-2000 195.92.95.5 > Netcraft > unknown Apache/1.3.9 (Unix) mod_perl/1.20 3-Dec-2000 195.92.95.5 > Netcraft > FreeBSD Apache/1.3.9 (Unix) mod_perl/1.20 19-Nov-2000 195.92.95.5 > Planet Online > unknown Apache/1.3.9 (Unix) mod_perl/1.20 18-Nov-2000 195.92.95.5 > Planet Online > FreeBSD Apache/1.3.9 (Unix) mod_perl/1.20 14-Nov-2000 195.92.95.5 > Planet Online > FreeBSD Apache/1.3.9 (Unix) mod_perl/1.20 15-Sep-1999 195.188.192.5 > Netcraft Ltd > FreeBSD Apache/1.3.6 (Unix) mod_perl/1.20 2-Jul-1999 195.188.192.5 > Netcraft Ltd > FreeBSD Apache/1.3.6 (Unix) mod_perl/1.18 9-Jun-1999 195.188.192.5 > Netcraft Ltd > FreeBSD Apache/1.3.4 (Unix) mod_perl/1.18 26-May-1999 195.188.192.5 > Netcraft Ltd > > I wanted to know how this was possible, if FreeBSD stores version > history somewhere. What should I do to secure this and how, because > knowing that anyone can get the history of version changes on your > system doesn't make you fell secure... They can only track history in the sense of storing information obtained by somebody performing a query on the given date. This list just means that somebody has done those queries on May 26, 1999, June 9, 1999 etc, and the Netcraft database has stored the results. If nobody has been interested in *your* server, Netcraft would not have any information stored about it. It is the Netcraft database, not your OS, that keeps history. > By the way, the output for my server gives me Apache/1.3.19 but i have > upgraded to 1.3.20 recently, why hasn't this been taken in > consideration? (i used ports to upgrade) Maybe no one has performed a Netcraft query for your server since you upgraded. G'luck, Peter -- I am the meaning of this sentence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 1:56:12 2001 Delivered-To: freebsd-security@freebsd.org Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by hub.freebsd.org (Postfix) with ESMTP id D110F37B403 for ; Mon, 9 Jul 2001 01:56:07 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: (from avalon@localhost) by caligula.anu.edu.au (8.9.3/8.9.3) id SAA12298; Mon, 9 Jul 2001 18:55:45 +1000 (EST) From: Darren Reed Message-Id: <200107090855.SAA12298@caligula.anu.edu.au> Subject: Re: FW: Small TCP packets == very large overhead == DoS? To: dr@kyx.net (Dragos Ruiu) Date: Mon, 9 Jul 2001 18:55:44 +1000 (Australia/ACT) Cc: silby@silby.com (Mike Silbersack), cjclark@alum.mit.edu, avalon@coombs.anu.edu.au (Darren Reed), Yonatan@xpert.com (Yonatan Bokovza), freebsd-security@FreeBSD.ORG ('freebsd-security@freebsd.org') In-Reply-To: <0107082333531I.08020@smp.kyx.net> from "Dragos Ruiu" at Jul 08, 2001 10:50:14 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In some mail from Dragos Ruiu, sie said: > > On Sun, 08 Jul 2001, Mike Silbersack wrote: > > There's nothing wrong with questioning the correctness of RFCs. They > > were, after all, written by ordinary mortals like everyone in this > > discussion. > > Certainly agreed. But I think the right way to do this is via changing > the RFC in the IETF so that all the implementations are consistent rather > than building yet another non-standard implementation of the standard. Absolutely this needs to happen. > > Maybe 256 is too high, perhaps 128 would be more reasonable. 64 seems way > > too small in any case. > [...] > where for some applications the representatives argued that 64 bytes was > too large a packetsize (this particular debate was over 32 or 64 byte cells, > and oddly enough they agreed on 48 for no particular reason other > than to stop arguing :-). Err, wasn't the result 53 ? > IMHO It's actually a minimum... If I understand MSS application (which I feel > I do) it's what the packet sizes the OS will fragment the data into to convey > it efficiently across the channel, which works out into pretty much being the > minimum packet size the OS will segment streams into. Please correct me if I > have made an error, as I too am merely human. MSS is the largest fragment the OS will send. It could send smaller ones than the MSS value but that'd be inefficient. Larger ones are not going to be well received, if at all. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 2:11: 0 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by hub.freebsd.org (Postfix) with ESMTP id 8E3A437B403 for ; Mon, 9 Jul 2001 02:10:54 -0700 (PDT) (envelope-from cperciva@sfu.ca) Received: from cr263028-a.sfu.ca ([24.113.38.176]) by mail.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010709091054.GGTG11518.mail.rdc2.bc.home.com@cr263028-a.sfu.ca>; Mon, 9 Jul 2001 02:10:54 -0700 Message-Id: <5.0.0.25.1.20010709020039.04304240@popserver.sfu.ca> X-Sender: cperciva@popserver.sfu.ca X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 09 Jul 2001 02:10:49 -0700 To: Darren Reed From: Colin Percival Subject: Re: FW: Small TCP packets == very large overhead == DoS? Cc: dr@kyx.net (Dragos Ruiu), silby@silby.com (Mike Silbersack), cjclark@alum.mit.edu, avalon@coombs.anu.edu.au (Darren Reed), Yonatan@xpert.com (Yonatan Bokovza), freebsd-security@FreeBSD.ORG ('freebsd-security@freebsd.org') In-Reply-To: <200107090855.SAA12298@caligula.anu.edu.au> References: <0107082333531I.08020@smp.kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 06:55 PM 7/9/2001 +1000, Darren Reed wrote: >In some mail from Dragos Ruiu, sie said: > > where for some applications the representatives argued that 64 bytes was > > too large a packetsize (this particular debate was over 32 or 64 byte > cells, > > and oddly enough they agreed on 48 for no particular reason other > > than to stop arguing :-). > >Err, wasn't the result 53 ? I believe the argument was over the amount of data per cell, not the total cell size; with 53 byte cells there are 5 bytes of header and 48 bytes of data. But in any case... shouldn't this be on -net? I think the question of security was put to rest several emails ago. Colin Percival To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 6:12: 6 2001 Delivered-To: freebsd-security@freebsd.org Received: from gyw.com (gyw.com [209.55.67.177]) by hub.freebsd.org (Postfix) with ESMTP id 1804837B401 for ; Mon, 9 Jul 2001 06:11:57 -0700 (PDT) (envelope-from tjk@tksoft.com) Received: from smtp3.tksoft.com (smtp3.tksoft.com [192.168.50.56] (may be forged)) by gyw.com (8.8.8/8.8.8) with ESMTP id FAA18824; Mon, 9 Jul 2001 05:21:48 -0700 Received: (from tjk@tksoft.com) by smtp3.tksoft.com (8.8.8/8.8.8) id EAA25037; Mon, 9 Jul 2001 04:36:48 -0700 From: "tjk@tksoft.com" Message-Id: <200107091136.EAA25037@smtp3.tksoft.com> Subject: Re: Firewall and ftp service To: ahl@austclear.com.au (Tony Landells) Date: Mon, 9 Jul 2001 04:36:46 -0700 (PDT) Cc: tjk@tksoft.com (tjk@tksoft.com), ascheepe@surf.iae.nl (Axel Scheepers), freebsd-security@FreeBSD.ORG In-Reply-To: from "Tony Landells" at Jul 09, 2001 09:28:28 AM X-Info: None MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Tony, You are right. The server connects to a port opened by the client, and uses port 20 for its local port. Can't believe I was confused like that. Goes to tell, I guess, how easy it is to screw up. Thanks for the correction. So, the firewall rule should allow any connection from port 20 on the external network, to any port > 1024 on any potential ftp client on the internal network. Troy > > Troy, > > I'm sorry, but your description of normal (active) mode FTP is incorrect. > tjk@tksoft.com said: > > I wanted to point out that port 20 is for ftp data and port 21 is for > > ftp commands. > > > When an ftp connection is made, the client connects to the server at > > port 21. All communications occur on that channel. > > So far, so good. > > > When the server needs to send data to the client, it opens a > > connection to port 20 on the client. When it makes the connection, it > > allocates a local port > 1024 for its local port. > > No. > > When the client requests data from the server, the CLIENT allocates > a random port number and tells the SERVER what it is, and then the > SERVER opens a connection FROM port 20 to that random port on the > client. > > > When a client requests passive ftp, the server opens a random port > > > 1024 for listening. The client then opens a connection to that port. > > And then we're back on track again. > > > With both passive and regular ftp data connections, the server has a > > local port > 1024 open. The distinction is that with passive ftp the > > server does a "listen()," opening a port for incoming connections. > > With regular ftp, the server does a "connect()" and the client must > > open port 20 with "listen()." > > And obviously the summary is off-track because the information it's > derived from is slightly wrong. > > Anyone doing this stuff would do well to look at the O'Reilly book > "Building Internet Firewalls" by Chapman and Zwicky which describes > the packet filtering characteristics of all the major protocols. > > As far as Axel's problem goes, I'm not sure what natd does with FTP > connections (I usually give public servers a public address) but > the server certainly passes its address back to the client for > passive mode connections along with the port number the client > needs to connect to (in normal or active mode the client sends its > address and port number to the server). > > Some FTP clients will tell you what the ports are, which you can compare > with logs on your firewall (assuming you're logging FTP connections). > If the connection is actually timing out, you can also look at netstat > on the various boxes to see what ports are being used. > > Otherwise, I'd suggest running natd in "verbose" mode to actually watch > the translations--it may be altering some port numbers as well, which will > throw things off. > > I hope there's some help in there somewhere... > > Tony > -- > Tony Landells > Senior Network Engineer Ph: +61 3 9677 9319 > Australian Clearing Services Pty Ltd Fax: +61 3 9677 9355 > Level 4, Rialto North Tower > 525 Collins Street > Melbourne VIC 3000 > Australia > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 8:14:26 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.sageian.com (ns.sage-consult.com [208.201.118.11]) by hub.freebsd.org (Postfix) with ESMTP id C524537B406 for ; Mon, 9 Jul 2001 08:14:19 -0700 (PDT) (envelope-from RRaykov@Sageian.com) Received: from sageian.com (proxy.sageian.com [208.201.118.126]) by mail.sageian.com (Postfix) with ESMTP id D8AC36A909; Mon, 9 Jul 2001 11:14:18 -0400 (EDT) Subject: RE: Re: Hiding Versions To: Khalil.Haddad@ubs.com User-Agent: IMHO/0.97.1 (Webmail for Roxen) Cc: freebsd-security@FreeBSD.org Content-Transfer-Encoding: 8bit Date: Mon, 09 Jul 2001 11:14:18 -500 From: Rossen Raykov Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 Message-Id: <20010709151418.D8AC36A909@mail.sageian.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, If you are using: ServerTokens Prod Then the response header will be: Server: Apache Regards, Rossen Raykov > thx all for your answers. > > I read in the apache docs that the ServerTokens could do the trick > (hiding apache version) for example i often see : Apache v1.3.x the x > hiding the version. > > Unfortunately, i could make this to work, it always outputs the same > string. > Anyone has a successful experience ? > > Thank you > > Khalil > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 9:30:15 2001 Delivered-To: freebsd-security@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B2BE637B409; Mon, 9 Jul 2001 09:30:00 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.3/8.11.3) id f69GU0o91452; Mon, 9 Jul 2001 09:30:00 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Mon, 9 Jul 2001 09:30:00 -0700 (PDT) Message-Id: <200107091630.f69GU0o91452@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Ports Security Advisory FreeBSD-SA-01:41.hanterm Reply-To: security-advisories@FreeBSD.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-01:41 Security Advisory FreeBSD, Inc. Topic: hanterm ports allow local root compromise Category: ports Module: ko-hanterm, ko-hanterm-xf Announced: 2001-07-09 Credits: ksecurity@iland.co.kr Affects: Ports collection prior to the correction date. Corrected: 2001-05-29 Vendor status: Contacted FreeBSD only: NO I. Background hanterm is a modified version of xterm which supports Korean language entry and display. It is included in the FreeBSD ports collection in two versions: ko-hanterm and ko-hanterm-xf. II. Problem Description The hanterm binary is installed with setuid root permissions, but contains insecure code which allows unprivileged local users to obtain root access on the local system. The hanterm ports are not installed by default, nor is it "part of FreeBSD" as such: it is part of the FreeBSD ports collection, which contains over 5400 third-party applications in a ready-to-install format. The ports collections shipped with FreeBSD 4.3 contain this problem since it was discovered after the release. FreeBSD makes no claim about the security of these third-party applications, although an effort is underway to provide a security audit of the most security-critical ports. III. Impact Unprivileged local users can obtain root access on the local system. If you have not chosen to install the ko-hanterm or ko-hanterm-xf ports/packages, then your system is not vulnerable to this problem. IV. Workaround 1) Deinstall the ko-hanterm and ko-hanterm-xf ports/packages, if you have installed them. 2) Remove the setuid root permission from the /usr/X11R6/bin/hanterm file. Execute the following command as root: # chmod u-s /usr/X11R6/bin/hanterm V. Solution One of the following: 1) Upgrade your entire ports collection and rebuild the ko-hanterm/ko-hanterm-xf ports. 2) Deinstall the old package and install a new package dated after the correction date, obtained from: [i386] ko-hanterm: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/korean/ko-hanterm-3.1.5_1.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/korean/ko-hanterm-3.1.5_1.tgz ko-hanterm-xf: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/korean/ko-hanterm-xf-19_1.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/korean/ko-hanterm-xf-19_1.tgz [alpha] Packages are not automatically generated for the alpha architecture at this time due to lack of build resources. 3) download a new port skeleton for the ko-hanterm/ko-hanterm-xf port from: http://www.freebsd.org/ports/ and use it to rebuild the port. 4) Use the portcheckout utility to automate option (3) above. The portcheckout port is available in /usr/ports/devel/portcheckout or the package can be obtained from: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/devel/portcheckout-2.0.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/devel/portcheckout-2.0.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-4-stable/devel/portcheckout-2.0.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/devel/portcheckout-2.0.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/alpha/packages-5-current/devel/portcheckout-2.0.tgz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBO0lzS1UuHi5z0oilAQGuXwP9EZWLrlaxYZYBBFLASErm2PjTSgazT/8c EyrxNw33Qal+xecxopeS3p/3Cf9x/Y0cH53ZMJoId6MaWJSwQOWlVqNC/ehjm2tx NPfLu3eR1JhguFoQ0YRHnMBvX1KBRfVQnfoa7HFd1vPeKEqsaXBvRz8HSurpgNml nUXVwvklmPc= =W5bd -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 14:44:16 2001 Delivered-To: freebsd-security@freebsd.org Received: from clavin.efn.org (clavin.efn.org [206.163.176.10]) by hub.freebsd.org (Postfix) with ESMTP id 63EB337B403 for ; Mon, 9 Jul 2001 14:44:12 -0700 (PDT) (envelope-from jay@efn.org) Received: from garcia.efn.org (jay@garcia.efn.org [206.163.176.5]) by clavin.efn.org (8.10.1/8.10.1) with ESMTP id f69LiBO18418; Mon, 9 Jul 2001 14:44:11 -0700 (PDT) Received: (from jay@localhost) by garcia.efn.org (8.10.1/8.10.1) id f69LiAk10414; Mon, 9 Jul 2001 14:44:10 -0700 (PDT) Date: Mon, 9 Jul 2001 14:44:08 -0700 From: Jay To: cjclark@alum.mit.edu Cc: freebsd-security@FreeBSD.ORG, Jay Subject: Re: firewall question Message-ID: <20010709144408.D8562@efn.org> Reply-To: Jay References: <20010702192720.P17514@speedy.gsinet> <20010704002534.D1476@blossom.cjclark.org> <20010704011623.G1476@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010704011623.G1476@blossom.cjclark.org> Organization: Eugene Free Community Network http://www.efn.org/ X-Pom: The Moon is Waning Gibbous (90.94% of Full) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20010704011623.G1476@blossom.cjclark.org>, "Crist J. Clark" writes: >Anyway, I just wanted to note that I committed a fix to CURRENT that >actually logs first fragments as fragments (PR 23446). It should make >logs of -1 rules a little more clear. I plan to MFC it in a few days. Speaking of logging enhancements, is there any chance that your IPFIREWALL_EXTRA_VERBOSE patches will be added any time soon? - Jay -- efn systems &c. T^\---+') email: jay@efn.org Perth-->* | L_______| To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 16:21:31 2001 Delivered-To: freebsd-security@freebsd.org Received: from a.mx.clublinux.org (h216-170-019-162.adsl.navix.net [216.170.19.162]) by hub.freebsd.org (Postfix) with SMTP id 4F13B37B401 for ; Mon, 9 Jul 2001 16:21:27 -0700 (PDT) (envelope-from steve@clublinux.org) Received: (qmail 7302 invoked from network); 9 Jul 2001 22:20:01 -0000 Received: from unknown (HELO clublinux.org) (192.168.33.33) by mail.internal with SMTP; 9 Jul 2001 22:20:01 -0000 Message-ID: <3B4A3DA8.B04EFC27@clublinux.org> Date: Mon, 09 Jul 2001 18:26:32 -0500 From: steve X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: cvsup and security References: <3B492672.55E0ADC8@clublinux.org> <20010708221140.A35469@xor.obsecurity.org> <20010708223447.F307@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, > > We do know how to do this? What trusted location would these MD5 > checksums come from? If someone has slipped in malicious code on a > cvsupd server, it is relatively easy to change the MD5 sums provided > by that server to match. Or is the idea that you get files from a > random mirror, but get MD5 checksums from a different location? For those that are paranoid about security (like me), perhaps the ports.tar.gz file could be signed so I can download the tar ball and verify it with a signature file (e.g. ports.tar.gz.sign). This still wouldn't allow you to verify when updating via CVSup, but at least I could verify that my ports directory skeleton is legit through alternative means. The same thing could be done with the system source code (src-all.tar.gz and src-all.tar.gz.sign). One of the FreeBSD people could be responsible for the private/public key and creating the signature files. > > I'd also like to point out that the ports are checking something > different with the MD5 sum. Since you got the MD5 hashes for the ports > from an cvsupd server, you already are trusting cvsup (unless you are > using old ones from a CD). Sorry, I should have been more clear about that. I'm am using the original /usr/ports and /usr/src skeletons from the CD and I want to update those skeletons in a secure manner so that I can safely install the latest and greatest (both ports and system software). > All the MD5 hashes on ports prove is that > the tarball you download is the same one the maintainer downloaded > when he built the port skeleton. That does NOT mean that the > maintainer audited the code, checked the code, or did not insert > malicious code himself. If there was a way to make the md5sums in the ports/src skeletons trustworthy, (e.g. signing files, or using the one from the CD) they could be used to verify the authenticity of a port/system program that is being installed. I would personally like a way to verify that the kernel source updates I've downloaded aren't trojaned in some way if I'm going to be updating my kernel with them. > When an MD5 check fails, the most common > reason is that a developer modified the code without changing the > version number, not that code was tampered with. This may be true, but I like to know for sure ;-) What do you think? Steve P.S. I apologize if I'm using FreeBSD terminology (e.g. ports/src skeleton) incorrectly as I'm new to FreeBSD. > -- > Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 9 17:14:32 2001 Delivered-To: freebsd-security@freebsd.org Received: from sec-tools.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id BC24737B401 for ; Mon, 9 Jul 2001 17:14:25 -0700 (PDT) (envelope-from cclark@globalstar.com) Received: (from cclark@localhost) by sec-tools.corp.globalstar.com (8.11.3/8.11.3) id f6A0CT687395; Mon, 9 Jul 2001 17:12:29 -0700 (PDT) (envelope-from cclark) Date: Mon, 9 Jul 2001 17:12:29 -0700 From: "Crist J. Clark" To: Darren Reed Cc: Dragos Ruiu , Mike Silbersack , cjclark@alum.mit.edu, Yonatan Bokovza , "'freebsd-security@freebsd.org'" Subject: Re: FW: Small TCP packets == very large overhead == DoS? Message-ID: <20010709171229.D87064@sec-tools.corp.globalstar.com> References: <0107082333531I.08020@smp.kyx.net> <200107090855.SAA12298@caligula.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200107090855.SAA12298@caligula.anu.edu.au>; from avalon@coombs.anu.edu.au on Mon, Jul 09, 2001 at 06:55:44PM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 09, 2001 at 06:55:44PM +1000, Darren Reed wrote: [snip] > MSS is the largest fragment the OS will send. It could send smaller ones > than the MSS value but that'd be inefficient. Larger ones are not going > to be well received, if at all. OK, it may just be that I have been looking at this too long but... Doesn't following seem wrong? 16:23:09.673022 172.18.113.26.4648 > AAA.BBB.CCC.106.80: S 3084535793:3084535793(0) win 16384 (DF) (ttl 64, id 63179) 16:23:09.673782 AAA.BBB.CCC.106.80 > 172.18.113.26.4648: S 1140257897:1140257897(0) ack 3084535794 win 8760 (DF) (ttl 254, id 42862) OK, both sides only want 1460 bytes as the maximum segment size, right? But then a few packets later in this connection, 16:23:09.679401 AAA.BBB.CCC.106.80 > 172.18.113.26.4648: . 584:2044(1460) ack 310 win 8760 (DF) (ttl 254, id 42866) 0x0000 4500 05dc a772 4000 fe06 48b9 AABB CC6a E....r@...H..X.j 0x0010 ac12 711a 0050 1228 43f6 f6b1 b7da 4927 ..q..P.(C.....I' 0x0020 5010 2238 3084 0000 0a3c 5343 5249 5054 P."80....