Re: Automated Network Abuse Reporting
When we get something that looks automated, we send back a reply saying We received this, if you'd like us to take action, please have a human reply. I've been thinking of instead having them send us a cryptographic hash of their message, saying that we MUST have all such notifications validated. I'd give them the URL to some page that would provide the hash, of course. Doug On Mon, 29 Dec 2003, Joel Jaeggli wrote: if you automate abuse reporting you can basically assume that the reciver will automate abuse handling. since that has in fact happened as far as i can tell the probably of you automated asbuse replaies ever reaching a human who cares or can do something about it is effecetivly zero. joelja On Mon, 29 Dec 2003, Jason Lixfeld wrote: We're a small company but none the less are inundated with firewall logs reporting numerous attempts to find holes in our network; c'est la vie. Seeing as how we are small, we don't have the resources to go through and send emails off to the abuse departments of each network sourcing the probes. Question is: Has there been development of some sort of intelligent unix land app that can understand Cisco syslog output, find the abuse departments of the sourcing networks and send them off a nice little FYI? -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: MS's new antispam idea
More than likely, spammers will have their hijacking programs spread out the load so as to remain unnoticeable. I think that's important to maintain control over a large number of machines: the jig is up once a user notices far more lagtime than ever before. I also think that make your operating system more secure is a specious request. To reduce spam, something as simple as highlighting email from addresses that you've written before, or that belong to a web-of-trust involving chains of such authorship, or many other fairly simple schemes wuld assist to minimize spam. And is something only Microsoft is in a good position to wield upon us. Doug On Fri, 26 Dec 2003, Owen DeLong wrote: It's an interesting concept... Now spammers will use a noticeable portion of the CPU on the boxes they've hijacked, instead of the currently virtually unnoticable portion of the resources, so, in that sense, it might help identify the owned boxes to their true owners. However, I think Micr0$0ft could do much more to reduce SPAM if they simply made their OS less 0wn-able. Owen --On Friday, December 26, 2003 2:23 PM + Stephen J. Wilcox [EMAIL PROTECTED] wrote: http://news.bbc.co.uk/1/hi/technology/3324883.stm Ok so in summary you have to use a bit of CPU to solve a puzzle before it lets you send email. So either this doesn't work because spammers dont actually use their own PCs to send email or we are talking about a whole new mail protocol, either way I'm thinking this isnt going to work and its yet another publicity stunt. Steve -- If it wasn't crypto-signed, it probably didn't come from me.
Re: a note to those who would automate their rejection notices
This reminds me: I'm scared to death of false positives. So much so that every email that triggers a positive from Spamassassin (i.e. several thousand spams a day) gets a response. It tries to be as polite as possible, both by being good-natured in tone and by both a Precedence: bulk header and an application-specific X-header to break loops. It's worked well enough for me to plan an implementation for an email system I run (servicing about 70k users). There are no real anti-DDOS provisions in it that would prevent someone from sending several million messages with a forged SMTP envelope to flood someone's mailbox quasi-anonymously. I haven't ever heard of this sort of system being used. Other than the obvious problems (like above, and the fact that it generates a LOT of mail that's going nowhere). Does anyone know of a precedent? Or wants to pick apart the idea in terms of community effect? Thanks, Doug
Re: MS's new antispam idea
It's too easy to introduce a worm that gives a spammer access to many teraflops of unwittingly collaborative computing resources. I can't imagine a compute-intensive puzzle scheme is going to do much more than the average iteration of a rule-based anti-spam filter. They'll just provide a temporary dent in the total spam flow. A reliance on new puzzles to provide obstacles to such spammers will end up being very close to homomorphic to rule-based filter iterations. Perhaps even a little less useful, as the spammers will not need to analyze and change each individual bit of spam, but merely need to reload the distributed sending cluster with the new solvers. Microsoft could indeed wipe out spam, in the short and long run. And they can do so without schemes that are likely to end up building upon the substantial plaque that already clogs the arteries of the net. Doug On Fri, 26 Dec 2003, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Jeff Shultz writes: I'm sure I've heard this one before, so it's not even a new idea... hope whoever came up with it originally patented it. 8-) Then again, maybe it was MS that I heard about the first time, and the Beeb is simply late to the game here. Yes, puzzles have been suggested before as defenses against SYN floods and SSL DoS attacks, and many other things as well. Has anyone calculated the increased server load, the extra storage needed for the now lengthened outgoing mail queue, and the extra bandwidth required to handle all this extra back and forth puzzle thing? YahooGroups and the like would definitely be impacted. It would be interesting to see what protections will be built into the puzzle thing as well... I can see some joker setting up his server to require that the sending computer calculate PI to some ridiculous number of decimals... although that might make a good honeypot. Or, if the puzzle is open source (which would be a good thing), how soon before the spammers (or even legit MTA authors) hardcode the answers into the server software? I suppose there would have to be some random elements. The usual way this is done is to pick a puzzle that's hard to compute but easy to verify. For example, the server could pick a random number, take the top N bits, and challenge the client to find *any* number whose SHA1 hash has the same high-order N bits *and* includes some other random string as the high-order bits of the answer. There are no known short cuts; the only feasible strategy is to calculate lots of SHA1 hashes for different input values. (The server sends some other random number to avoid precomputation attacks.) Bandwidth is probably not an issue; it's one extra round trip, and it's not very much text. Mail sender queues are more of an issue, as is the load on the sender; if I were doing this, I'd make it adaptive, with a high cost being required for unknown senders, or those that have sent suspected spam. For example, start with a 12-bit puzzle, i.e., one of client difficulty 4096. For each piece of non-spam, subtract some small value from the difficulty. For each piece of spam, double the difficulty rating for that client. There are lots of ways to do things like this; it will take more than back-of-the-envelope calculcations to understand all the knobs, let alone what countermeasures the spammers will deploy. For an introduction to schemes like this, see Stubblefield, A.., and D. Dean, Using Client Puzzles to Protect TLS, Proceedings of the Tenth USENIX Security Symposium, Washington, DC, August 2001, available at http://www.csl.sri.com/users/ddean/papers/usenix01b.pdf . It is interesting as an extension it might be nice to be able to set up a whitelist of trusted servers that don't have to go through the computational gyrations to send you mail - that way it would, hopefully, eventually impact the spammers more than it would impact legitimate e-mail servers. According to the article, that is indeed part of the scheme. --Steve Bellovin, http://www.research.att.com/~smb
Root Authority
An interesting question I've dealt with a few times: From whom do the root nameservers derive their authority? Doug
NANOG spam survey
All, I'm in the process of morphing my company into generalized corporate email outsource agency. The sales pitch: the average (1000+ user) company is finding it difficult-to-impossible to run their own email server. Just do away with the problem, and give it to me. The last couple of months in particular have been total hell. Spam-producing worms have been enabling individual spammers to leverage 10,000 unwitting DSL/cable users to cream my servers. In coming up with the business plan, I'm betting on this being a universal problem. To that end, I'd like to hear about people's experiences. I'm particularly interested in a couple of results: 1) Is my experience common? That is, do others find it excruciatingly painful just to operate a simple corporate email server? 2) What's working for people who are trying to address spam (and other problems, like email-borne virii, SMTP exploit scans, etc)? As I develop the business, I'm going to have to come up with a way to solve this problem. I'm thinking that I'll have to sign one or more partner companies that specialize in spam protection. I'd love to find a company that was down-to-earth and honest. And, especially, a company that is not investor-driven. If anyone has recommendations, please let me know. I've been following the spam threads over the past couple of months, but I haven't been able to distill solid recommendations out of them. If I end up with private responses, I'll summarize back to the list. Thanks, Doug
Re: WLAN shielding
Unless you are looking to isolate a small box for such purposes as testing RF devices, I would not use a shielding technique to limit access to your wireless network. Containing 2.4GHz signals within a room of any reasonable size is extremely difficult. You would probably have to cover it with a double-walled, seamless sheet or fine grid of conductive material. Any holes, cracks, windows, or doors are likely to blow the whole deal. I'd recommend using both WEP and an encrypting VPN if you're worried about people getting on your network. Also make sure to turn off SSID broadcasts. Planning on limiting signal using a physical mechanism of some sort's just a little too scifi to be useful. Cheers, Doug On Wed, 26 Nov 2003, Andy Grosser wrote: Apologies in advance if this may not quite be the proper list for such a question... My company is investigating the use of wireless in a couple of our conference rooms. Aside from limiting the scope of reception with various directional antennae, does anyone have any suggestions or pointers for other ways to limit the propagation of signals (i.e. special shielding paint, panels or other wall coatings)? Feel free to reply off-list. Thanks! Andy --- Andy Grosser, CCNP andy at meniscus dot org ---
Telerama job posting SUMMARY
I've received 15 SSH keys since posting the link to the job on Nanog. We may be hiring in the near future, but there are no open positions currently. As to the rest of the inquiries, I humbly submit: The Telerama Hiring FAQ, v0.5: 1) Where did you get your tests? Our tests are designed in-house. They are tailored to our particular systems and problems. They consist of a number of tasks that emulate real-world situations. They get progressively more difficult, with the last stages nearly impossible to complete, even by the most highly gifted individual. The tests are designed not only to measure technical proficiency, but also to give them a feeling for the way we do things (i.e. our corporate culture). The intent is to foster self-selection, allowing people to bow out if they feel they aren't going to be a good fit. 2) Why are you asking candidates for their SSH key? In addition to the sentiment that resumes are wholly inadequate tools by which to perform preliminary evaluations of candidates, we have a couple of purposes for requesting an SSH key: A) It demonstrates that the applicant actually read the posting, and therefore might truly consider themselves a good match. Lots of people, especially on the large job sites, will send their resumes to hundreds of different companies with very little discrimination. B) It shows that the applicant either knew about the technology or had the wherewithal to learn quickly and effectively about the technology. 3) But I have an impressive resume, why don't you want it? If you are able to demonstrate, that you possess the basic attributes necessary to be successful at the job position, then we will probably be looking at your resume. We are not trying to do away with resumes. We do request them further along in the hiring process. 4) I'm not interested in the job, but I want to take the tests. The tests require human shepherding and a number of specially-configured boxes. None of these resources are currently allocated. If you are not serious about the job, you probably don't want to take them anyway: when the tests are being given, you are asked to adhere to a particular testing schedule, and your response time is included in the metric that determines whether to advance through the process. 5) Are you hiring? As of this writing, 11/14/2003, there are currently no open technical positions. Please check out our web site at http://www.telerama.com to see if there are active positions.
Re: This may be stupid but.
This person obviously didn't understand the security implications associated with handing out your public SSH key. Also, to those that have been asking: the semi-automated test environment was dismantled about the same time we filled the position, so we don't have it available to go through. Doug From: imp mis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Bcc: Subject: Unix/Internet Systems Administration Position so you want my public ssh key or you won't consider me for you're position?? FUCK YOU!!! how's that On Mon, 10 Nov 2003, neal rauhauser wrote: Doug, Don't tease - you absolutely owe us the full text of the response from the fellow who was upset about your asking for a public SSH key as part of the interview process. Neal Doug Luce wrote: I rely on recruiters to funnel applicants to the company. I also use Monster and jobs.perl.org to do the same. But I don't rely on them top do much weeding. These days, I used semi-automated remote testing to find the good guys. I put very little faith in resumes, and do not use them to evaluate candidates. This has worked out extremely well. I imagine that this process is not suitable for many positions, or for cultures that are different from Telerama's. Check out the job posting at https://doug.telerama.com/admin_job.txt In particular: DO NOT SEND YOUR RESUME at this point of the application process. If you do send your resume, we will assume you did not bother to carefully read this job posting, and we will not consider your application. To begin taking the tests, please send your public SSH key to [EMAIL PROTECTED] along with your email contact information. Sending your SSH key is the only way to signal your interest in this position. Please do not send a resume, cover letter, or other plea. The last time I posted this, I received 200 total replies. 151 contained resumes, 52 contained public SSH keys, 4 contained public PGP keys, and 1 contained a private SSH key. One further response expressed hostility toward the requirement of a candidate's public SSH key in order to be considered for a position. Doug -- mailto:[EMAIL PROTECTED] phone:402-301-9555 IM:Neal R Rauhauser After all that I've been through, you're the only one who matters, you never left me in the dark here on my own - Widespread Panic
Re: This may be stupid but..
I rely on recruiters to funnel applicants to the company. I also use Monster and jobs.perl.org to do the same. But I don't rely on them top do much weeding. These days, I used semi-automated remote testing to find the good guys. I put very little faith in resumes, and do not use them to evaluate candidates. This has worked out extremely well. I imagine that this process is not suitable for many positions, or for cultures that are different from Telerama's. Check out the job posting at https://doug.telerama.com/admin_job.txt In particular: DO NOT SEND YOUR RESUME at this point of the application process. If you do send your resume, we will assume you did not bother to carefully read this job posting, and we will not consider your application. To begin taking the tests, please send your public SSH key to [EMAIL PROTECTED] along with your email contact information. Sending your SSH key is the only way to signal your interest in this position. Please do not send a resume, cover letter, or other plea. The last time I posted this, I received 200 total replies. 151 contained resumes, 52 contained public SSH keys, 4 contained public PGP keys, and 1 contained a private SSH key. One further response expressed hostility toward the requirement of a candidate's public SSH key in order to be considered for a position. Doug
