Re: Problems sending mail to yahoo?
Joe Greco wrote: So it's a vast sea of security by obscurity and standards be damned. It's a real and serious failure of the IETF et al. ... Having nearly given up in disgust on trying to devise workable anti-spam solutions that would reliably deliver requested/desired mail to my own mailbox, I came to the realization that the real problem with the e-mail system is so fundamental that there's no trivial way to save it. Sounds like the party line inside Yahoo, but there are plenty of ISPs that do a really good job of combating spam. They do it with standard tools like RBLs, Spamassassin, OCR, ClamAV and without ineffective diversions like SPF or DKIM. Add a few local customizations (I know, this is the time consuming part), IP-layer IDS, stir carefully and voila, spam to real mail ratios well below 1 to 100. All without big junk folders, with very rare false positives, and little or no effort on the part of end-users. The problem is that it is an art, not well documented (without reading 5 or 6 sendmail/postfix and anti-spam mailing lists for a several years), is not taught in school (unlike systems and network administration), and rarely gets measured with decent metrics. Not that spam really has much to do with network operations, well, except perhaps for those pesky Netcool/Openview/Nagios alerts... Roger Marquis
Re: Mitigating HTTP DDoS attacks?
Mike Lyon wrote: So, i'm kind of new to this so please deal with my ignorance. But, what is common practice these days for HTTP DDoS mitigation during an attack? You can of course route every offending ip address to null0 at your border. But, if it's a botnet or trojan or something, It's coming from numerous different source IPs and Null0 routes can get very cumbersome. obviously. How do you folk usually deal with this? Depends a lot on the size of the network. If it's more than a few colos I highly recommend Arbor Peakflow (http://www.arbornetworks.com/). Not cheap but it works and scales well. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Security gain from NAT: Top 5
Mark Smith wrote: For all those people who think IPv4 NAT is quite fine, I challenge them to submit RFCs to the IETF that resolve, without creating worse or more even more complicated problems, the list of problems here. All the IPv6 RFCs do ... http://www.cs.utk.edu/~moore/what-nats-break.html These RFCs clearly have an agenda: selling IPv6. It is unfortunate they don't feel it necessary to make a balanced presentation of the pros and cons but instead appear to believe that spreading FUD about NAT is an effective method of promoting IPv6. Problem is that NAT will not go away or even become less common in IPv6 networks for a number of reasons. #1 NAT advantage: it protects consumers from vendor lock-in. Consider the advantage of globally unique public addressing to ISPs and telcos. Without NAT they have a very effective vendor lock-in. Want to change ISPs? It's only as easy as reconfiguring every device and/or DHCP server on your internal network. With NAT you only need to reconfigure a single device, sometimes not even that. #2 NAT advantage: it protects consumers from add-on fees for addresses space. Given the 100 to 10,000% mark-ups many telcos and ISPs already charge for more than a /29 it should come as no surprise they would be opposed to NAT. #3 NAT advantage: it prevents upstreams from limiting consumers' internal address space. Even after full implementation of IPv6 the trend of technology will continue to require more address space. Businesses will continue to grow and households will continue to acquire new IP-enabled devices. Without NAT consumers will be forced to request new netblocks from their upstream, often resulting in non-contiguous networks. Not surprisingly, often incurring additional fees as well. Follow the money and you'll end up with these three reasons why the technical arguments being made against NAT in opinion pieces like Keith Moore's (URL above) are so one sided and overtly biased. But there are still more reasons NAT will continue to increase in popularity regardless of IPv6. #4 NAT advantage: it requires new protocols to adhere to the ISO seven layer model. H.323, SIP and other badly designed protocols imbed the local address in the data portion of IP packets. This trend is somewhat discouraged by the layer-isolation requirements of NAT. #5 NAT advantage: it does not require replacement security measures to protect against netscans, portscans, broadcasts (particularly microsoft's netbios), and other malicious inbound traffic. The vendors of non-NAT devices would love to have you believe that their stateful inspection and filtering is a good substitute for the inspection and filtering required by NAT devices. Problem is the non-NAT devices all cost more, many are less secure in their default configurations, and the larger rulesets they are almost always configured with are less security than the equivalent NAT device. These are just some of the reasons why NAT is, and will continue to be, an increasingly popular technology for much more than address conservation. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Security gain from NAT
Donald Stahl wrote: Ever try to set up a VPN between two offices using the same address space? Sure, very easily, by using NAT between the subnets. NAT is still evil though, the problems it causes operationally are just plain not worth it. Can you clarify this claim? What about managing NAT is allegedly difficult. Are you unable to easily map public addresses with private addresses on your own networks? Stateful inspection provides security benefits. Neither SI nor NAT provides any security. It is the rules commonly implemented on top of them that can provide security. Please be consistent in the use of these terms to avoid confusing the issue. Jeff McAdams wrote: But it is correct. Just mangling the addresses in the headers doesn't actually stop anything from getting through, it just means it gets through mangled. The security comes from SI and dropping packets that don't have an active session established from inside, or related. Crux of the thread for sure. In an academic context NAT only swaps header addresses, however, in the world of network operators and end-users all NAT devices do SI and filtering. It is the filtering, blocking connections initiated from public addresses, that provides NAT security. That is still NAT security if only because it is characteristic of virtually all NAT devices, and not the default or even a common configuration of non-NAT network devices and applications. Perhaps it is difficult to understand this vernacular NAT after studying Comer, Stevens et al, but when you've run the equivalent of 'sh conn' regularly for several years the narrow, some would say ivory tower, definition of NAT tends to morph into one based on actual implementations. Since this mailing list is by and for network operators as opposed to academics perhaps we could ask the later (NANAGs?) to use footnotes(1) to clarify their meaning? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Security gain from NAT
Sure, very easily, by using NAT between the subnets. Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in a dns entry pointing to 172.29.10.10 End-users prefer hostnames to IPs. DNS hostnames are valid on both sides due to either local zone files or a DNS protocol-NAT. It's a no-brainer to implement and a lot easier than using public address space given the relatively complex firewalling and filtering that requires. NAT'ing the address on your side to their side and from their side back to your side, and adding the rules. That's definitely simpler than allow a - b for service c. Not simpler than running something like fixup protocol dns on a VPN termination. I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it. Most of the rest of us will continue to listen to both sides and continue to prefer NAT, in no small part because of the absurd examples and inconsistent terminology NATophobes seem to feel is necessary to make their case. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Security gain from NAT
So now the cruft extends and embraces, and you have to play DNS view games based on whether it's on company A's legacy net, company B's legacy net, or the DMZ in between them, and start poking around in the middle of DNS packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC). Are you proposing that every company use publicly routable address space? How about the ones that don't qualify for a /19 and so are dependent on addresses owned by their upstream? To change ISPs for example, would it be simpler to change the IP address of every node in the company or to run NAT on the gateways? How about multi-homing? Can you even do it without NAT on a network too small assign an AS? In the mid-90s I was CSO at a company whose internal networks were publicly routable thanks to a /16 they owned (though they really only needed a few /24s). In my experience, for every example of how complex NAT is there are at least 10 counter-examples of how an equivalent non-NATed network is more complex, less flexible, less reliable, and less secure. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Security gain from NAT
Matthew Palmer wrote: While protection from mistakes is a valid reason, it's a pretty weak one. It is indeed a weak reason but, evidently, much stronger as a straw man argument. NAT is A security tool, not THE security tool. I would say that those who rely on NAT for security are the ones with the narrow world-view. Depends wholly on the security requirements of the client. Then again, I can't say I've ever seen a site that relies on NAT exclusively. This is another straw man argument. A core but often neglected factor in IT security is KIS. NAT, particularly in the form of PAT, is an order of magnitude simpler to administer than a stateful firewall with one-to-one address mappings. Given the degree to which complexity negatively correlates with security, for non-server addresses at least, NAT has far and away the better ROI. Any security auditor will tell you that, in the real world, stateful one-to-one firewalls are rarely as secure as NAT gateways for the simple reason that the non-NAT firewalls have more rules. This debate mirrors one that took place in a large university where I worked several years ago. The network admins made passionate arguments against NAT but did little to firewall vulnerable departments. The risk was obvious but so was the underlying motivation. They were simply protecting their turf. In this case multiple class-B allocations, awarded decades ago, before NAT and PAT became affordable technologies. Perhaps they also did a lot of peer-to-peer filesharing behind those non-NATed subnets. I don't know all of the reasons but, having managed thousands of clients behind NAT and unNATted gateways I'll take NAT any day. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
On Thu, 24 May 2007, Chris L. Morrow wrote: which brings us back to my original comment: we need a policy most likely from ICANN that requires some action based on proper documentation and evidence or wrong-doing/malfeasance. Agreed, and I'd love to help define the draft rfc/policy, but is there a contact at ICANN for this type of thing? We used to be able to email Carl Auerbach but that was a while back. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
Why are people trying to solve these problems in the core? Because that's the only place it can be done. These issues need to and must be solved at the edge. Been there, done that, with smtp/spam, netbios, and any number of other protocols that would also be ideally addressed at the source or edge but, in reality, cannot. These issues should not be solved by the registry operators or root server operators, that's very dangerous. Do you know that it is dangerous to fix problems at the core or are you speculating? If you can cite specific examples please do. Simply saying it is dangerous is indistinguishable from any other verisign astroturfing. People are suggesting it become the rule because nobody is trying anything else. Can you say what that 'anything else' might consist of? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
On Mon, 21 May 2007, Chris L. Morrow wrote: ok, so 'today' you can't think of a reason (nor can I really easily) but it's not clear that this may remain the case tomorrow. Not a good justification for doing nothing while this sort of trojan propagates. As analogy, it is also true we cannot see how email-based trojans may be desirable tomorrow, but that doesn't stop us from protecting ourselves against their detrimental effects today. It's possible that as a way to 'better loadshare' traffic akamai (just to make an example) could start doing this as well. Actually not. There is no legitimate purpose for this dns hack. So, I think that what we (security folks) want is probably not to auto-squish domains in the TLD because of NS's moving about at some rate other than 'normal' Except that there's a lot more to this pattern than simply changing NS at a rate other than normal, enough that it can be easily identified for what it is. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
On Mon, 21 May 2007, Jason Frisvold wrote: They're likely not name servers, or at least not all name servers.. I'd venture a guess as to these being part of a Snowshoe spammer network... I've been getting hit by similar domains for a few weeks now.. Blocking seems to be the best way to handle them.. Fastflux does seem to be a tool in some spammer's kits but these particular domains are probably not being used for that, at least not effectively, since they have no MX records. Are there sites that accept mail from domains without a valid MX/A record? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
On Mon, 21 May 2007, Stephane Bortzmeyer wrote: I cannot believe that people in NANOG may confuse the .com name servers with the root name servers. Not to confuse the issue but among some managerial circles the root nameservers comprise both root and tld. Point taken though, root and tld should not be confounded in a forum like nanog. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Interesting new dns failures
An odd pattern of DNS failures began appearing in the logs yesterday: May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns5.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns4.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns3.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns2.uzmores.com) May 20 15:05:19 PDT named[345]: wrong ans. name (uzmores.com != ns13.uzmores.com) ... May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns8.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns7.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns6.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns4.loptran.com) May 20 11:10:00 PDT named[345]: wrong ans. name (loptran.com != ns2.loptran.com) ... May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns7.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns5.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns9.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns12.dsinlet.com) May 20 10:12:25 PDT named[345]: wrong ans. name (dsinlet.com != ns3.dsinlet.com) ... (All multiplied by a factor of 10) Very odd to see a dozen nameservers for several new and obscure domains. Does this look like a rat? The apparently misconfigured domains are served by a single registrar, estdomains.com. (whois -h whois.estdomains.com ..., Registration Service Provided By: N/A, Contact: +876.78484). Certainly smells like a rat. Most of the individual nameservers do not answer queries, the ones that do are open to recursion, and all are hosted in cable/dsl/dial-up address space with correspondingly rfc-illegal reverse zones. Running 'host -at ns' a few times shows the list of nameservers is rotated every few seconds, and occasionally returns server localhost. Obviously a rat, but the pattern brings up a number of questions. Are these spoofed queries and replies? If not, have any root nameservers been hacked? Do the queries exploit known named vulnerabilities? What ICANN policy might address this? Finally, what, if anything, are DNS admins doing about it? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
If not, have any root nameservers been hacked? To partly answer my own question, no. The data returned by root (gtld) nameservers is not changing rapidly. Thanks for the pointers to fast flux too. Wasn't familiar with this attack or terminology. All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Interesting new dns failures
All the same, it would seem to be an easy and cheap abuse to address, at the gtlds. Why are these obvious trojans are being propagated by the root servers anyhow? the root servers are responsible how exactly for the fast-flux issues? Also, there might be some legittimate business that uses something like the FF techniques... but, uhm... how are the root servers involved again? Nobody's saying that the root servers are responsible, only that they are the point at which these domains would have to be squelched. In theory registrars could do this, but some would have a financial incentive not to. Also I don't believe registrars can update the roots quickly enough to be effective (correct me if I'm wrong). Given the obvious differences between legitimate fast flux and the pattern/domains in question it would seem to be a no-brainer, technically at least. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Network graphics tools
John Kinsella wrote: Not sure how preferring things like rectangles stops you from using Visio, but *shrug* Probably has more to do with the other features of Visio. Hidden metadata, slow VBS, fragile registry dependencies, ... all of which engineers tend to discover before an important deadline. Not trying to start a Visio religious war, just saying there's a reason enterprises use it. Like most things enterprises use it because that's what they know. Managers also believe they can't get fired for buying IBM. They will likely continue believing this until another manager comes along who knows open-source and how to use it for a better ROI. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: zotob - blocking tcp/445
Andy Johnson wrote: I think the point of many on this list is, they are a transit provider, not a security provider. They should not need to filter your traffic, that should be up to the end user/edge network to decide for themselves. How is this different from a transit provider allowing their network to be used for spam? Seems the same hands-off argument was made wrt spam a decade ago but has since proved unsustainable. Our particular problem is with an ISP in Wisconsin, NETNET-WAN. We get tens of thousands of scans to netbios ports every day from their /19. This is several orders of magnitude more netbios than we see from the rest of the net combined. It's eating nontrivial bandwidth and cpu that we pay real money for. They've had our logs for months but seem incapable of doing anything about their infected customers. The suits recommend documenting time and bandwidth costs and sending a bill with a cease and desist request. My question is not what can we do about bots, we already filter these worst case networks, but what can we do to make it worthwhile for bot-providers like NETNET to police their own networks without involving lawyers? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Underscores in host names
Laurent Frigault wrote: gethostbyaddr (and may be other functions) will return NULL under at least FreeBSD/NetBSD for ANY PTR having the _ character. As it should. I wish it would also return a null for hostnames containing sequential non-alphanumerics (--, ---, __, ___, ...). -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Underscores in host names
On Thu, 19 May 2005 [EMAIL PROTECTED] wrote:
On Thu, 19 May 2005 08:04:31 PDT, Roger Marquis said:
Laurent Frigault wrote:
gethostbyaddr (and may be other functions) will return NULL under at
least FreeBSD/NetBSD for ANY PTR having the _ character.
As it should. I wish it would also return a null for hostnames
containing sequential non-alphanumerics (--, ---, __, ___, ...).
Don't like RFC3490 and its xn-- hostnames? ;)
Most definitely not, and if this were 1985 I'd be {rf}commenting on
the inadvisability of such hostnames, and those beginning or ending
with -, TLD names shorter than 2 or longer than 4 characters,
spaces in hostnames, [^a-z0-9\\-\\.], and other such marginally
useful but infinitely problematic features.
There is real value in KIS, and not just from the perspective of a
security-minded coder...
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Re: djbdns: An alternative to BIND
David Conrad wrote: - Amount of code Again, what should be counted? Should you include rsync? Should you include utility programs like check-namedconf, axfr-get, rbldns, walldns, walldns-conf, etc.? You need only count the lines of code needed by the daemon/s servicing requests. That is, IMO, bind's only major failing. Too much code, too many little used features (nobody I know needs or wants rndc), and no way to compile without them. If you read Bruce Schneier, as every developer should, you know how important that Amount of code is. All I really want is to configure --minimal make make install and not have to fix ISC's ill thought-out defaults (like /usr/local/etc on Solaris...). Using bind 8 and 9 but still looking for something better, -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: books every network operator should read?
Janet Sullivan wrote: I'd like to make a list for the BGP4.net wiki of books that are thought highly of by the network community. What books stand out for you as being excellent? If you could only own 5 network related books, what would they be? One of my favorites from years back though not BGP-related, probably out of date and out of print, a very good read none the less: A Guide to Fractional T1 James E. Trulove, 1992 Artech House, ISBN 0-89006-524-1 -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: in case nobody else noticed it, there was a mail worm released today
Scott Francis [EMAIL PROTECTED] wrote: I've been wondering lately, after about 10 years of email worms spreading in exactly the same manner with every incarnation ... why do you think people haven't learned not to open unexpected attachments yet? Blaming it on end users is one way to look at the problem, but not a way that will result in a solution. You should be wondering, after 10+ years of virus laden MS operating systems, why they haven't fixed this stuff. Similar vulnerabilities in Unix, Mac, and other OS were fixed long ago. They're not patched in Windows because MS doesn't have to. MS doesn't write secure code because they are a monopoly and maintain that status by introducing subtle OS bugs that plague competitive third party applications. They don't publish an API for many of their system calls so nobody can write secure code other than MS themselves. They also run as much of their own software as possible in priviliged mode for performance (to avoid context switching). You'll never seen any real security from this type of business model. (Note: I really do not want this to degenerate into another rant against vendor M; Sorry for not sharing your disinterest in the actual reasons we continue to see these viruses and trojans infecting MS and, for all intents and purposes, only MS operating systems. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
RE: in case nobody else noticed it, there was a mail worm released today
On Wed, 28 Jan 2004, Vivien M. wrote: And, care to tell me why, as someone else pointed out, if I were to switch to Evolution on your random GNU/Linux distribution, someone couldn't write a similar worm. Rhetorical questions illustrate a lack of technical rational, thanks. But do re-read the message you're referring to, specifically, the section regarding unpublished APIs and context switching. If you need more in-depth reasons see any of the URLs listed at http://www.msfree.com/. The reason they don't do it is because there isn't a critical mass of Evolution/GNU/Linux/glibcX.Y to make a big stink... And there is such a critical mass for MS. No, sorry, false analogy though it does account for some portion of MS' mess. The larger reason is that viruses are substantially easier to write for Outlook, Exchange, et al. For another example look at Unix Apache's market share (75%) and it's vulnerability share (1%). As Java applications make clear, it doesn't matter what your market share is if the software is secure in the first place. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: example.com/net/org DNS records
On Mon, 5 Jan 2004, Doug Barton wrote:
Does anyone know why IANA has assigned NS and A records to the
example.{com,org,net,...} domains? They even put up a website
at the IP explaining RFC 2606.
There's already been a lot of discussion about why this is a good thing,
so I won't reiterate it all.
Thanks Doug. Are those discussions available on the net? If so
could you post the URL?
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
example.com/net/org DNS records
Does anyone know why IANA has assigned NS and A records to the
example.{com,org,net,...} domains? They even put up a website
at the IP explaining RFC 2606.
* Why did they assign NSs and a valid IP to these invalid domains?
* Are they breaking the RFC by doing this?
* Are they breaking anti-UCE filters by doing this? (yes)
* Are they harvesting URLs and referrers?
* Will they next advertise routes for RFC 1918 addresses?
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Re: example.com/net/org DNS records
* Are they breaking anti-UCE filters by doing this? (yes) How? They own example.com. A) They don't own example.com and, B) this is the crux of the issue. IANA was not granted special privileges by RFC2606 nor do they have any more claim to these domains than Verisign does to unregistered domains or expired domains. Example.dom was placed in the pubic domain by a public and open RFC process. It seems that IANA has violated this process and in so doing exceeded the authority vested in them by their contract with DARPA (and the DOC?). If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter? Yes. Roble manages several email gateways for companies other than ourselves and we've found that rejecting invalid domains and senders is an indispensable component of spam filtering. Not only is it effective it is also 100% false-positive proof (so far). -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: example.com/net/org DNS records
On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote: * Why did they assign NSs and a valid IP to these invalid domains? So they can put up an explanatory website that says Don't do that, you idiot. This is the best explanation I've read so far. Problem is, it's not a compelling rational. Is this really the only reason for assigning NS and A records, violating the RFC, and breaking thousands of spam filters in the process? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: example.com/net/org DNS records
On Mon, 5 Jan 2004, Suresh Ramasubramanian wrote: What spam did you see that forged example.* in the sender envelope / rDNS? reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 [EMAIL PROTECTED]: Recipient address rejected: Relay access denied; from= to=[EMAIL PROTECTED] reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 [EMAIL PROTECTED]: Recipient address rejected: Relay access denied; from= to=[EMAIL PROTECTED] reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 [EMAIL PROTECTED]: Recipient address rejected: Relay access denied; from= to=[EMAIL PROTECTED] reject: RCPT from unknown[195.219.161.18]: 504 sss: Helo command rejected: need fully-qualified hostname; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 [EMAIL PROTECTED]: Recipient address rejected: Relay access denied; from= to=[EMAIL PROTECTED] reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 [EMAIL PROTECTED]: Recipient address rejected: Relay access denied; from= to=[EMAIL PROTECTED] reject: RCPT from adsl-65-66-178-75.dsl.snantx.swbell.net[65.66.178.75]: 554 [EMAIL PROTECTED]: Recipient address rejected; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=compuserve.com warning: 213.230.38.5: hostname reserved-multicast-range-NOT-delegated.example.com verification failed: Host not found reject: RCPT from cmailg1.svr.pol.co.uk[195.92.195.171]: 554 cmailg1.svr.pol.co.uk[195.92.195.171]: Client host rejected: Access denied; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] reject: RCPT from lsanca2-ar24-4-62-187-078.lsanca2.dsl-verizon.net[4.62.187.78]: 554 Service unavailable; Client host [4.62.187.78] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?4.62.187.78; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=compuserve.com reject: RCPT from 12-252-121-69.client.attbi.com[12.252.121.69]: 554 Service unavailable; Client host [12.252.121.69] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?12.252.121.69; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=aol.com reject: RCPT from unknown[219.234.9.254]: 554 Service unavailable; Client host [219.234.9.254] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?219.234.9.254; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=rambler.ru reject: RCPT from unknown[166.104.200.92]: 554; Client host [166.104.200.92] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?166.104.200.92; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=microsoft.com reject: RCPT from host202-60.pool21759.interbusiness.it[217.59.60.202]: 554 Service unavailable; Client host [host202-60.pool21759.interbusiness.it] blocked; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=mailserv reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=c-66-229-245-245.we.client2.attbi.com reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=c-66-229-245-245.we.client2.attbi.com reject: RCPT from flandre-1-81-57-169-89.fbx.proxad.net[81.57.169.89]: 554; Client host [81.57.169.89] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?81.57.169.89; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=flandre-1-81-57-169-89.fbx.proxad.net reject: RCPT from unknown[61.105.251.12]: 554 Service unavailable; Client host [61.105.251.12] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?61.105.251.12; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=microsoft.com reject: RCPT from ool-182f3f56.dyn.optonline.net[24.47.63.86]: 554 Service unavailable; Client host [24.47.63.86] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?24.47.63.86; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=compuserve.com reject: RCPT from mrdn-01-25.dialup.netins.net[207.177.98.90]: 504 sss: Helo command rejected: need fully-qualified hostname; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] reject: RCPT from 13-156.ae.cgocable.ca[24.122.13.156]: 554; Client host [24.122.13.156] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=24.122.13.156; from=[EMAIL PROTECTED] to=[EMAIL PROTECTED] proto=SMTP helo=13-156.ae.cgocable.ca ...
donotcall.gov - special interests vs the public interest
Tried the website again this morning (7/4) and got: We're sorry. The site is unavailable at the moment. Please try again later. Which is not surprising given the underlying technology: # HEAD www.donotcall.gov Server: Microsoft-IIS/5.0 X-Powered-By: ASP.NET Another busy government site using the least secure web server software. You can imagine the backend. Their javascript is also broken. It could be worse I suppose, if managed by the USPS... The site and exceptions list are great examples of the level of special interest influence in DC. Unfortunately, their influence is also a roadblock to national security: Bruce Schneier http://www.counterpane.com/crypto-gram-0210.html#1 Marcus Ranum http://www.tisc2002.com/newsletters/414.html Anyone here familiar with the subcontractor list for DNC's Internet servers? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: anti-spam vs network abuse
Richard Irving wrote Jack Bates wrote:(SNIPO) Should we outlaw a potentially beneficial practice due to its abuse by criminals? Okay. What happens if you make a mistake and overload one of my devices costing my company money. That is usually a civil issue, not criminal. Legal considerations aside it is not good practice to scan a subnet/server hosting dozens of websites. Typical symptoms are slow connections to all the sites, increased memory utilization, and error logs like the following: [Wed Feb 26 02:14:57 2003] [info] server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers), spawning 26 children, there are 60 idle, and 88 total children As a result the ISP must either A) purchase more RAM, faster CPUs, and additional servers, or B) run the risk of complaints and lost customer goodwill. All of this costs time and money. The best mitigation is to set a _slow_ scan rate but even that can still get you blacklisted by a well designed NIDS. Given the potential cost to third parties it's difficult to see any case for netscanning, regardless of the scanner's rational. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: Banc of America Article
[EMAIL PROTECTED] wrote: It could be that BoA's network wasn't flooded / servers infected, but that the ATM's do not dial BoA directly, and dial somewhere else (ie, maybe some kind of ATM Dial Provider, nationwide wholesale, etc), and then tunnel back to BoA to get the data. Could be that the upstream of either the dial provider, or BoA was just flooded... Again, that design makes nearly no sense. The vast majority of the ATMs that banks own and operate directly are located in the LATAs with bank branches. Those branches do have good connectivity to the bank processing centers be that via dedicated links, VPN or carrier pigeons. While the exact mechanism of BofA's exposure is important it is nowhere near as important as the fact that they were, and presumably are still, exposed. My money's on Frame Relay congestion. Some department at BofA, short on engineers and long on budget-oriented management, likely made a decision that saving a lot of money was worth a bit of exposure. I know that decision has been made at other banks. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Tracking a DDOS
One of our clients sustained a severe SMTP DDOS attack on New Years' Day. The DDOS was caused by a bulk mailing which had forged their domain name in the return address. The attack was staged over several days from dial-up lines at fast.net (Bethlehem, PA). We contacted fast.net shortly after the massmail began but it continued unabated for two additional days. Some of the source IPs were eventually listed by MAPS and Wirehub and they're still listed to this date. 5 minutes after our call to fast.net's support desk we tracked a portscan from one of their netblocks (206.245.164.0-206.245.164.255, Internet Unlimited, at nearly the same address in Bethlehem, PA). A quick check of the reverse DNS revealed nearly exclusive use by porn, throw-away, and otherwise spam domains. Though we're still tabulating damages and collecting evidence it appears the DDOS was hosted by and allowed to continue unabated by fast.net (aka iuinc.com) after they had knowledge of the problem, knowledge of its source, and knowledge of its effects. Since fast.net/iuinc.com has not replied to our email or phone calls we're looking for anyone with information on this company, its owners or operators, and any history of network or SMTP abuse. All help will be appreciated and kept confidential. Thanks in advance, -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Anyone home at AOL?
Not the first time one of our clients has been impacted by AOL, nor the first time AOL has failed respond to requests/complaints. Though this isn't a DDOS like previous AOL-based network abuse, and probably isn't a dictionary attack, it is placing considerable strain on a couple of leased lines and mailexchangers. Any idea how a small network admin can get someone at AOL to deal with a problem like this? TIA, -- Roger Marquis Roble Systems Consulting http://www.roble.com/ PS. these logs illustrate only a small fraction of the SMTP activity from AOL's servers. Oct 9 10:57:06 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:02:51 PDT reject: RCPT from omr-r01.mx.aol.com[152.163.225.129]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:03:19 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:04:00 PDT reject: RCPT from omr-r04.mx.aol.com[152.163.225.132]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:07:24 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:08:07 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:08:23 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:11:35 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:11:54 PDT reject: RCPT from omr-r02.mx.aol.com[152.163.225.130]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:16:22 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:24:39 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:27:31 PDT reject: RCPT from omr-d07.mx.aol.com[205.188.159.13]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:29:59 PDT reject: RCPT from omr-d04.mx.aol.com[205.188.159.7]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:33:29 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:35:59 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:38:27 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:42:03 PDT reject: RCPT from omr-r02.mx.aol.com[152.163.225.130]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:43:30 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:48:58 PDT reject: RCPT from omr-d04.mx.aol.com[205.188.159.7]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:49:49 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:50:44 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:51:59 PDT reject: RCPT from omr-d10.mx.aol.com[205.188.156.78]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:54:40 PDT reject: RCPT from omr-m01.mx.aol.com[64.12.138.1]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:56:51 PDT reject: RCPT from omr-d09.mx.aol.com[205.188.156.77]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:56:57 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 11:57:50 PDT reject: RCPT from omr-r03.mx.aol.com[152.163.225.131]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:06:01 PDT reject: RCPT from omr-d08.mx.aol.com[205.188.156.76]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:06:52 PDT reject: RCPT from omr-r08.mx.aol.com[152.163.225.153]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:11:59 PDT reject: RCPT from omr-r04.mx.aol.com[152.163.225.132]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:14:38 PDT reject: RCPT from omr-d06.mx.aol.com[205.188.156.71]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:14:51 PDT reject: RCPT from omr-r07.mx.aol.com[152.163.225.147]: 550 [EMAIL PROTECTED]: User unknown; from= to=[EMAIL PROTECTED] Oct 9 12:15:47 PDT reject: RCPT from omr-d05.mx.aol.com[205.188.156.66]: 550 [EMAIL PROTECTED]: User unknown; from
Re: BGP and aggregation
Scott Granados wrote: We set ospf internally, set up bgp for the announcements at each site and used the no-export tag for the more specifics. Then gre tunnels:) for the internal. It worked and I pushed probably 45 to 50mb over the internal loops or gre tunnels. Not ideal but it worked. Last time I tried this (IOS11.X to IOS11.X GRE) it was unreliable due to MTU limits. Certain websites (mainly financial) send large packets and set DF. This probably works around some security issue but the result was that these SSL servers couldn't reach clients over the GRE. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Re: How to get better security people
E.B. Dreger [EMAIL PROTECTED] wrote: Service patches were never applied. When some suspicious happenings left said server inoperable, they just installed Win2000 and went on, not caring what had happened or why. No, I was not the employee. A friend of mine worked there before getting fed up and quitting. We see this a lot too. It is, IMHO, why good security people who are not in finance, defense or other security-conscious sectors tend to be consultants. Consultant or not IS security gurus are no different than other in-demand technical specialists. You have to 1) pay them appropriately, 2) have a decent working environment (no windowless cubicles, junk food cafeterias, inflexible hours, unskilled management, etc), and 3) provide constant training opportunities (conferences, classes, good assignments). Don't expect them to have programming degrees or be interested in coding. Those would be security developers as opposed to security analysts. Finally, NEVER ask a Unix literate engineer to use an MS Windows PC... -- Roger Marquis Roble Systems Consulting http://www.roble.com/
