RE: What about joe-jobs?
Speaking of joe-jobs, what's the "proper" proceedure for >dealing with such? The company I work for is currently >undergoing an admitedly minor joe-job. (about 300 or so >bounces that I've seen since mid > last week or so.)
Any suggestions for dealing with this?
What domains are you seeing the joe-jobs from? We > see alot of joe jobbing attacks from the large webmail providers eg. yahoo.com, hotmail.com, aol.com, netscape.net, etc. A promising response that we've been following is Sender Permitted From http://spf.pobox.com . It's basically a reverse RBL. The owner of a domain identifies ip's that are allowed to send mail for that domain in a TXT DNS record. The rest are tagged with a wildcard deny or probably softdeny initially. If yahoo.com, hotmail.com etc alone just added the DNS records, we'd all be able to identify joe-jobbers of these domains. It won't help their own spam situation but it'd help our massive attacks of spoofed email. Spammers seem to use these big providers since blocking all of hotmail.com or yahoo.com is tough for other providers.
I'm looking for a clueful person either inside of AOL's NetOps or someone else that can help us. Problem; Using AOL Dial-Up, through AOL Browser or MSIE users can connect to our web servers and our clients web servers via normal http with no problem. If they connect to a secure site (https://) they get 'page can not be displayed' and other errors. We have this issue with Linux/Apache as well as MSIE servers. Sniffing such connections, we get one of two scenerios: 1. A connection is opened from an AOL proxy server (172.151.135.3 for example) yet no data is transmitted. 2. A connection is opened from an AOL proxy server. what looks like a request is sent (580 bytes) and some response is sent back (5k bytes) Yet the clients browser never gets a website.. The webserver logs an 'error 408' from the request, Which is a request timeout. 2 test websites to try from AOL: https://www.krystal.net MS https://www.onrope1.com Linux/Apache Clue Bat's welcome. Thank You --Mike--
Last time I checked, SSL connections do not get proxied through the AOL caching servers. They go directly from the client. 172.151.135.3 is not an AOL proxy server, it is an end user IP address that a AOL user gets when they dial in. cache-rf03.proxy.aol.com is an AOL proxy. -------------------------- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511 ----- Original Message ----- From: "mike harrison" <meuon@highertech.net> To: <nanog@merit.edu> Cc: <rcurtis@krystal.com>; <gmilliard@krystal.com> Sent: Thursday, September 25, 2003 2:24 PM Subject: AOL Proxy Servers not connecting via https
I'm looking for a clueful person either inside of AOL's NetOps or someone else that can help us.
Problem;
Using AOL Dial-Up, through AOL Browser or MSIE users can connect to our web servers and our clients web servers via normal http with no problem.
If they connect to a secure site (https://) they get 'page can not be displayed' and other errors. We have this issue with Linux/Apache as well as MSIE servers.
Sniffing such connections, we get one of two scenerios:
1. A connection is opened from an AOL proxy server (172.151.135.3 for example) yet no data is transmitted.
2. A connection is opened from an AOL proxy server. what looks like a request is sent (580 bytes) and some response is sent back (5k bytes) Yet the clients browser never gets a website.. The webserver logs an 'error 408' from the request, Which is a request timeout.
2 test websites to try from AOL: https://www.krystal.net MS https://www.onrope1.com Linux/Apache
Clue Bat's welcome. Thank You --Mike--
On Thu, 25 Sep 2003, Brian Bruns wrote:
Last time I checked, SSL connections do not get proxied through the AOL caching servers. They go directly from the client. 172.151.135.3 is not an AOL proxy server, it is an end user IP address that a AOL user gets when they dial in. cache-rf03.proxy.aol.com is an AOL proxy.
Thanks, It seems when the connection swaps from a proxy/cache connection, that the AOL browser gets redirected to another AOL address first, and then goes out. There is a noticable delay (a second or two) from when the request gets sent, to when we see it on our network.. like an overloaded cache/proxy. Perhaps AOL is using some kind of "transparent" proxy.. or maybe it's the Dept of Homeland Security's mystery sniffer (just speculating in wild paranoid mode). Or maybe it's something on our network mangling packets.. But calls to AOL get me no-where..
participants (3)
-
Brian Bruns -
Darren Foo -
mike harrison