Re: Mitigating HTTP DDoS attacks?
On Mon, Mar 24, 2008 at 11:34:58PM +, Paul Vixie wrote: > > i only use or recommend operating systems that have their own host based > firewalls. soon that will mean pf (from openbsd but available on freebsd) > but right now that means ipfw. ipfw has a "table" construct which uses a > data structure similar to the kernel's routing table. with a little bit > of tuning, and using X86_64 to get more kernel memory map space than I386, > i've listed every member of 60K-node botnets in a table whose only use is > "if a SYN comes from here, silently drop it with no ICMP response". with > more tuning work, a 200K-node botnet would pose no problem. we populate > these tables with a perl script that watches the apache server's logfiles. Even on an untuned fbsd i386, I had success with an ipfw table with well over 1e6 entries. What finally broke was doing a table list, possibly because the command prints in sorted order. No performance problems were observed at my limited volume of perhaps 3 hits per day. -- Barney Wolff I never met a computer I didn't like.
Re: Acceptable DSL Speeds (ms based)
On Thu, May 05, 2005 at 10:59:04AM +0800, Ong Beng Hui wrote: > > >When I switched from 1600/384 to 3000/768 dsl, download speed went up to > >very nearly the promised 3Mbps, but latency to the first hop went from > >14 ms to 26 ms. > > Is there a reason for that ? that, latency goes up when bandwidth goes up > for your case ? I assume it had to do with different settings for interleaving on the DSLAM, as some prior poster mentioned. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like.
Re: Acceptable DSL Speeds (ms based)
On Wed, May 04, 2005 at 09:34:35AM -0700, Bruce Pinsky wrote: > > Those times seem high to me. I have a 1.5/768 ADSL circuit and I routinely > see 13-15ms to my 1st IP hop and 15-18 to the upstream handoff. I'm > 14.5Kft from my CO and my IP is backhauled to SFO from SJC. Here are a few > examples: When I switched from 1600/384 to 3000/768 dsl, download speed went up to very nearly the promised 3Mbps, but latency to the first hop went from 14 ms to 26 ms. Now I have FTTH, and first-hop latency is 3 ms (acedsl.com, Verizon reseller, good guys). -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like.
Re: New Computer? Six Steps to Safer Surfing
On Mon, Dec 20, 2004 at 12:26:31AM +0100, Florian Weimer wrote: > * Barney Wolff: > > > Perhaps, then, one should not be so quick to disparage software-based > > firewalls, resident on the computer itself. > > Yes, but it's only a real obstacle if the malware doesn't run with > SYSTEM privileges. If it's impossible for home users to work with > reduced privileges, a host-based filter is no good (unless it's a very > obscure brand which is not targeted by the malware 8-). In general, home firewalls are better at preventing infection than containing it. That's true no matter where the firewall resides. > By the way, do you know if these "hardware firewalls" have a > management interface on a factory-default IP address? 192.168.0.1 admin/admin is a good bet. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: New Computer? Six Steps to Safer Surfing
On Sun, Dec 19, 2004 at 05:47:28PM -0500, Sean Donelan wrote: > > What's more interesting is the highest infection rate of all is for homes > with laptop/mobile computers. Even when your home broadband modem/gateway > has a firewall, when you take your laptop out of the home you lose > what little protection you had. Then you bring the infection back inside > and infect all your other home computers behind the gateway/firewall. > The crunchy outside, soft-chewy inside rule applies to home computers too. Perhaps, then, one should not be so quick to disparage software-based firewalls, resident on the computer itself. After all, there is really no such thing as a "hardware-based" firewall. bugtraq has plenty of reports of software bugs in firewalls resident on dedicated hardware. "Defense in depth" would suggest using both. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Mon, Nov 29, 2004 at 06:02:48PM -0800, Owen DeLong wrote: > > > Please point me to where I can get a version of SSH that uses SCTP instead > of TCP and talks to the existing SSHD services using TCP with flow > survivability. If the TCP library changes underneath SSH and provides this > capability, it will get deployed. If we need to completely rewrite all the > applications to support TCP and SCTP in some sort of split-brained idea of > how the world should work, then, adoption is less likely. But old-style tcp apps don't work with ipv6 either. So if you're going to demand binary compatibility, all the mechanics need to get done below the app anyway. It would have been nice to make sctp be the standard stream protocol for ipv6. For most nanog customers, there's still time. Those places that have already seen significant ipv6 adoption may need to upgrade again. If we wait much longer, of course, the opportunity will be lost. To argue that it's already too late, when ipv6 is a small fraction of all traffic and an infinitesmal fraction of future traffic is, imho, foolish. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: who gets a /32 [Re: IPV6 renumbering painless?]
On Sat, Nov 20, 2004 at 08:45:34PM +, Paul Vixie wrote: > > the second. we'd have built a v6 bastion network and put our public > services there and done some kind of overlay thing. for things like my > desktop, we'd've stuck with ipv4, or we'd've pirated some "site local" ipv6 > space. there is no possibility that any enterprise where i am responsible > for planning or design will ever run PA addresses out to the desktop -- it > makes multihoming impossible, which would leave me at the mercy of a single > provider's uptime, and a single provider's pricing. no, no, no, and again > i say, "no, that will not be done on my watch." Perhaps it is time to replace TCP with SCTP, where multihoming is not incompatible with PA addressing. If done as a socket shim, so applications don't have to be aware of it unless they want to be, it would appear to solve all of these problems. How much would it add to the pain of the v4-v6 transition, to just bite the bullet and do tcp-sctp at the same time? I'd sure rather be a network troubleshooter going through that than living with NAT forever. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: Distributed Dictonary email slam
On Sun, Sep 05, 2004 at 03:39:50PM -0600, Matt Hess wrote: > > And of course a few suggestions to mitigate this would be appreciated.. > I currently employ multiple blacklists such as spamcop.net, abuseat.org, > spews level 1 and 2, and spamhaus, plus my own blocklists for china and > korea to check on incoming email source addresses. Happened to me a few times, which is funny for a 1-man company with very few legit user-ids - >100K requests per day for nonexistent users. I used ipfw to limit each sender to 1 simultaneous conns, turned on sendmail's delay on bad users after 1 and edited the sendmail source to wait 10 sec before responding rather than 1. That seems to have discouraged them some. As has been mentioned, the key is either not to have/be a secondary mx or to make it smart enough to know who's valid, to avoid DoSing the forged senders. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: New Solution: (was: Re: Counter DoS)
On Thu, Mar 11, 2004 at 05:17:35PM -0500, Deepak Jain wrote: > > Just like the blackhole community routes, certain /32's (only, nothing > shorter) can be exported from the customer to the backbone to be > blackholed at the edges. The twist, is that instead of limited the > customer announcement to the customer's IPs, you force only /32s to be > announced for the blackhole prefixes and limit the total number of > prefixes. Say 100 (or 10, or 1000 depends how much trust you have) > > So say, joe-customer has identified his top 50 DDOS sources, he > announces them to you, voila, DDOS gone. (even for spoofed traffic, > depending on how your filters are set up) Obviously these would be > no-export routes so no peer need be worried. 1. Why is BGP the right tool for this? 2. Is your idea to block only packets destined for the customer making the request, or to 0/0? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: MTU path discovery and IPSec
On Wed, Dec 10, 2003 at 03:43:59PM -0500, Joe Maimon wrote:
>
> Packets are fragmented into equally sized units to prevent further
> downstream fragmentation.
For amusement's sake, in response to a challenge from Crist Clark,
here's code to do it right. Pretty simple, although I have no idea
how to do it in an ASIC.
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
// Simulate a fragmentation algorithm
// frag Omtu [Ihdrsz]
// Barney Wolff<[EMAIL PROTECTED]> 12/4/03
// Copyright (c) Databus Inc. Free to use with attribution.
#include
#include
using namespace std;
int
main(int argc, char **argv) {
int Ihdrsz=20, Omtu, MinIpaysz, MaxIpaysz, Opaylst, Opaysz;
switch (argc) {
default:cerr << "Usage: frag-alg Omtu [Ihdrsz]\n"; exit(1);
case 3: Ihdrsz = atoi(argv[2]);
case 2: Omtu = atoi(argv[1]);
}
MinIpaysz = Omtu - 1 - Ihdrsz;
MaxIpaysz = 65535 - Ihdrsz;
Opaylst = Omtu - Ihdrsz;
Opaysz = Opaylst & 0xfff8;
cout << "Output MTU " << Omtu << " Input header size " << Ihdrsz << endl;
cout << "Max payload of last packet: "< Ipaysz) Opayn -= ((Maxin - Ipaysz) / Nfrag) & 0xfff8;
Lastsz = Ipaysz - (Nfrag-1) * Opayn;
Delta = Opayn - Lastsz;
if (Delta >= 8) {
int Nfrag2 = Delta / 8;
Nfrag -= Nfrag2;
Lastsz += 8 * Nfrag2;
cout << " " << Nfrag2 << " " << Opayn-8+Ihdrsz;
}
if (Nfrag > 1) cout << " " << Nfrag-1 << " " << Opayn+Ihdrsz;
cout << " " << Lastsz+Ihdrsz;
if (Lastsz-Opayn>8 || Opayn-Lastsz>8) cout << " *";
cout << endl;
}
exit(0);
}
Re: MTU path discovery and IPSec
On Thu, Dec 04, 2003 at 05:54:42PM -0500, [EMAIL PROTECTED] wrote: > On Thu, 04 Dec 2003 16:40:45 EST, Joe Maimon <[EMAIL PROTECTED]> said: > > I was wondering would it not be wiser for fraggers to frag in half > > instead of just the overflow? > > There's 2 cases here: > > 1) This is the final frag on the path - if PMTUD is in use, we want to frag > right at the overflow so the connection can use the max (so if we're fragging > from 1500 down to 1410, they end up with 1410 rather than 750). > > 2) There's an even more restrictive frag further downstream. We frag from 1500 > to 1460, and somebody else frags from 1460 down to 1410. If you frag at overflow, > you end up with a PMTU of 1410. If you fragged it in half, you avoid the second > frag but end up with a PMTU of 750. > > After several dozen packets, the difference between 750 and 1410 will start to become > noticable. That's not how PMTUD works. If DF is set, you discard the packet and report back with ICMP. If DF is not set, you frag the packet - but that's not PMTUD, because no report ever goes back to the sender. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: more on filtering
> > I don't know much, but I do know that legal agreements in the US are > > NOT transitive in this way, unless each agreement is included by > > reference in the other. > They aren't legally, but they are effectively. Ok, enough legal debate. Let me use a strictly US analogy: The death penalty for shooting a cop is a legal deterrent, but a wise cop still wears a bulletproof vest. Filter to protect your own network, and, when necessary and possible, your customers from each other and the Internet from your customers. Legalisms punish, after the fact. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: 'Net security gets root-level boost
On Tue, Oct 28, 2003 at 09:58:20AM +0200, Hank Nussbacher wrote: > > http://www.nwfusion.com/news/2003/1027ddos.html Love this quote from Verisign: "We tested Anycast for about a year...to monitor its behavior," Silva says. "These are important servers, and we didn't want to make any rash decisions about deploying it." -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: WANTED: ISPs with DDoS defense solutions
On Wed, Aug 06, 2003 at 12:58:19AM +, Paul Vixie wrote: > > could someone here who can write win32 apps, and someone else who can > write cocoa apps, please volunteer short executables that will try to > spoof a few packets through some well known server, and then report as > to whether the current computer/firewall/cablemodem/isp/core permitted > this or not? isc would be happy to host the server component of this, > as long as source code for the executables is available under a bsd > style copyright, and the executables are released without any fee. How would the spoofing program, or its user, be able to tell if it was successful? Unless I'm very confused, the definition of spoofing is that the return packets aren't going to come back to you. I can imagine a packet format where the real source address was in the data, but with no authentication this would itself be subject to abuse. You'd need a little protocol: VolunteerServer real-source-->server <--back to real source with ip to fake, cookie fake-source-->server with cookie <--back to real source with result as a courtesy Doing this from behind a NAT would be difficult. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: User negligence?
On Sun, Jul 27, 2003 at 12:37:54AM -0400, Sean Donelan wrote: > > Unfortunately there are a lot, and growing number, of self-infected PCs > on the net. As the banks point out, this is not a breach of the bank's > security. Nor is it a breach of the ISP's security. The user infects > his PC with a trojan and then the criminal uses the PC to transfer money > from the user's account, with the user's own password. The bank hands out ATM cards, but does not offer the customer the option of logging in with SafeWord or SecureId or any other OTP. Given how much the bank saves in labor, it could surely afford the card expense. But it's easy to see why they don't, since it's the customer, not the bank, that is taking the risk. A sufficiently fancy trojan would notice when the user logged into the bank using OTP and change the destination of a money transfer or add an invisible transaction, but that's certainly quite a lot harder than a simple keystroke logger. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: Backbone Infrastructure and Secrecy
On Wed, Jul 09, 2003 at 05:30:27PM +0100, Peter Galbavy wrote: > > I hate to be a doom sayer, but any chump with a couple of tools and > rudimentary knowledge can lift manholes, cut cables and jump to another > location in minutes. ... Perhaps it's time for IDS on manholes? But really, since the gas lines are down there too, is fiber the chief worry? -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
[barney@databus.com: NYTimes.com Article: Worm Hits Microsoft, Which Ignored Own Advice]
- Forwarded message from [EMAIL PROTECTED] - Date: Tue, 28 Jan 2003 00:43:09 -0500 (EST) Worm Hits Microsoft, Which Ignored Own Advice January 28, 2003 By JOHN SCHWARTZ ... A spokesman for Microsoft, Rick Miller, confirmed that a number of the company's machines had gone unpatched, and that Microsoft Network services, like many others on the Internet, experienced a significant slowdown. "We, like the rest of the industry, struggle to get 100 percent compliance with our patch management," he said. ... http://www.nytimes.com/2003/01/28/technology/28SOFT.html?ex=1044732589&ei=1&en=6b35cf2b8a77f62e Copyright 2002 The New York Times Company - End forwarded message -
Re: Level3 routing issues?
On Mon, Jan 27, 2003 at 08:10:15PM +, Simon Lockhart wrote: > > As I suspected, but I keep being told that these problems were in old style > VPN clients, and stuff is much better these days. I remain unconvinced. A good VPN client (I'm familiar with Nortel) will enforce no *simultaneous* access to or from on-VPN and off-VPN destinations. But I'm not aware of anything that will enforce that a home or portable machine has never been connected to anything but the corporate network. That would take TCPA or the equivalent, which would not bother me if it's on the company's machine and under control of the company - maybe the only scenario where TCPA/Palladium-ng would be acceptable. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: DC power versus AC power
On Sun, Dec 29, 2002 at 08:11:46PM -0500, David Lesher wrote: > > I'm surprised you're still around after a sub battery accident. > They're a grade up from most CO's in available current, I'd bet. I'd bet the other way. CO battery has to supply ring current, dial tone and voice current, not just run the switch itself, at least in the Copper Age. I don't think -48VDC is an electrocution risk unless you're sweaty, but a vaporized wrench sure can burn you, and I don't think GFIs existed for DC. Anyway, nukes don't need the battery capacity of the old diesels. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: Experts: Don't dismiss cyberattack warning
Most Muslims are not Arab, or living in caves. There are certainly millions of Muslim computer users, by now. In fact, I'd bet there are more than a million Muslim computer users in the US alone. Most Muslims, thank God, are not murderous fanatics or computer abusers. But it would be quite foolish to underestimate the capability of any large group, sufficiently motivated, to inflict massive damage. On Tue, Nov 19, 2002 at 07:40:14PM -0600, Stephen Sprunk wrote: > > I'm not skeptical that millions of starving Arabs living in caves or being > slaughtered by their dictators are going to find computers, connect to the > Net (outlawed by their leaders), and attack us. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: new bind vuln
This does beg the question (not that I hold *you* responsible!)
why the advisory had to come out before the patch. Does anyone
know whether the news had escaped to the blackhats? Otherwise
I cannot understand the rationale.
Barney
On Wed, Nov 13, 2002 at 12:06:04AM -0500, Steven M. Bellovin wrote:
>
> CERT said that the ISS advisory was to be released on 13 November, and
> that the patch would be available from ISC next week. There was no
> indication about when CERT itself was going to issue an advisory, but
> clearly someone said something a day earlier than had been expected.
>
> --Steve Bellovin, http://www.research.att.com/~smb (me)
> http://www.wilyhacker.com ("Firewalls" book)
--
Barney Wolff http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: no ip forged-source-address
On Wed, Oct 30, 2002 at 09:26:30PM +0200, Hank Nussbacher wrote: > > Traceback would get me instantly back to the offending subnet but then it > would take a bit of digging on the network admin to track me down and > applying RPF checking won't help. Sure. But do you really want to give up a 95% solution just because it doesn't get you the last inch? We have no solution that will do that. Being able instantly to identify the subnets from which DDoS traffic is coming would make shutting off those subnets during the attack possible*, and that in turn would motivate the subnet owners to clean up their hosts. * I suspect that an attack that actually comes from 1000 compromised hosts does not come from nearly that many subnets. Is there any data? As a historical note, I put SAA in the filters for the ATT Worldnet dialup network from its very start in 1995. Work by smb on the dangers of spoofed source addresses was already public then. It's long past time for the rest of the world to catch up. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
Re: How do you stop outgoing spam?
On Tue, Sep 17, 2002 at 08:29:39PM -0700, Dave Crocker wrote: > > 3. SMTPAUTH does not require an alternate port, yet it is sufficient for > ensuring accountability. Hence it is sufficient for dealing with the > reason that port 25 is blocked, without requiring that it be blocked. I don't understand this reasoning. The ISP's justification for blocking 25 except to its own servers is to avoid having its facilities used for abuse. How would the local ISP enforce use of SMTPAUTH to connect to some remote ISP? -- Barney Wolff I'm available by contract or FT: http://www.databus.com/bwresume.pdf
Re: Paying for delivery of packets (was about Sprint Peering, and Importance of Content)
On Thu, Jul 11, 2002 at 08:00:45PM -0700, JC Dill wrote: > > The problem with asymmetric pricing is that the cost of passing the packets > is equally born by both ends. Take 2 networks that peer, one with mostly > content, one with mostly eyeballs. The content providers pay a higher > price *per MB* for bandwidth to their provider than the end user does, but > both networks have equal costs in transiting the packets from the server to > the end user. This might be true per Mbps of capacity, but is simply not true per average user's MB/month. The typical cable/dsl subscriber still only uses about 5-10 Kbps, averaged over a month. If lots of people start watching video streams for much of the day, current cable/dsl rates will not survive. -- Barney Wolff I never met a computer I didn't like.
