One piece of the puzzle that might make all the others
fit here:
The home.com domain came just a hair away from being
blacklisted by uunet because of the amount of spam
originating from that domain.
@home replied that the problem was that a lot of their
customers had mis-configured proxies that were being
used by spammers outside of @home to relay spam,
and promised to initiate a program of scanning their
customers' machines for proxy services that were open
to the external network.
GNAT Box tells me that @home has, in fact, been
scanning my system on port 119 (nntp) fairly regularly
(...and it looks like they also took the opportunity to
start scanning port 80 also. The @home service
agreement forbids running any type of server, but until
now it's been pretty loosely enforced if the traffic
volumes were low).
-----Original Message-----
From: owner-gb-users_at_gta_dot_com [mailto:owner-gb-users_at_gta_dot_com]On Behalf Of
Griffiths, Jeff
Sent: Thursday, March 09, 2000 8:46 AM
To: 'Joe Biniskiewicz'; GB Users
Subject: RE: Remote access filter blocks
All of the IP addresses in your logs are owned by @home.
Reverse DNS shows 24.0.0.205 to .207 is a mailer group on the west coast.
(mx1-w.mail.home.com, mx2..., mx3...)
Reverse DNS is not available for 24.0.95.51 to .56 although they are all up
(I was able to PING them)
Reverse DNS shows 24.2.2.197 to .199 us a mailer group on the east coast.
(mx2-e.mail.home.com, mx3..., mx4...)
The interesting thing is the FLAG on all your packets in your log = 0x10.
0x10 = ACK.
Based on this info, I would tend to think that these are mailers trying to
reconnect to you because of timeouts (although that does not explain the
ACK) or you are being port scanned (which also doesn't explain the ACK very
well since most scans are based on SYN).
I'm not sure if it is possible to do a port scan based on ACK with any known
"security" tools, but NMAP (and other freely available "hack" tools) can set
its source port to anything you want and also send from multiple decoy IP
addresses. You can also adjust the speed of the packet sends anywhere from
milliseconds to hours (to interdict detection by intrusion alert devices).
Hackers like to use ports 25, 53 & 80 as source ports because most FW
filters would let that info pass if they were not stateful or simply were
misconfigured. I'm not saying that this IS the situation in your case, just
that it is something you can consider.
Regards,
Jeff
-----------------------------------------------------------------
Jeffery Griffiths <jgriffiths_at_swfllp_dot_com>
Network Engineer
Schreeder Wheeler & Flint, LLP
Atlanta, GA USA
-----------------------------------------------------------------
-----Original Message-----
From: Joe Biniskiewicz [mailto:joeb_at_joeb_dot_com]
Sent: Wednesday, March 08, 2000 5:49 PM
To: GB Users
Subject: Re: Remote access filter blocks
Send postings to: gb-users_at_gta_dot_com Access the list archives at:
http://www.gnatbox.com/gb-users/ ---------------------------------- My
apologies if I'm missing your points, but I believe that you've all missed
my point. Allow me to elaborate and maybe we can start over again:
I do have a local mail server behind the GB, and it is properly configured
and operational, using the SMTP Relay feature of GB 3.0.2 as well as three
RBL's. I check the logs every morning to determine which hosts were denied
from sending mail to me. I use VisualRoute to trace to their SMTP server
and do a quick lookup on their domain and host names. I monitor this
closely to be sure that no "good" mail was rejected via MAPS, and if it was,
I stop using that RBL. After all, it is better to let ten guilty men go
free rather than to convict one wrongly. Once I have performed that morning
ritual, I put down my cup of coffee and get to work.
I am the only user behind my GB, though I am a power user ;-) My point is
that nobody is checking their mail from my PRO network, and even if they
were, their traffic would be "replies" (ACK vs SYN packets), so that would
not be a problem. Even if it were the case, the Destination port on the
remote mail server for POP3 is port 110, not 25.
We are talking about a SOURCE PORT of 25, not a DESTINATION PORT of 25. I
have several OBJECTS established which are used in filters that deny all
traffic from entire ISP's in third world countries from which I will have no
meaningful dialogue. I can readily see the difference in my logs between
traffic that was denied access to DESTINATION PORT 25. In fact, please
consider that I have a fairly good understanding of services, subnets and
filters.
If you take a moment to look at the logs, you will quickly see a pattern.
The pattern is that when traffic was unsuccessful from a given host, the
originator attempted communication from a different IP address later. I've
pasted the log to the end of this message for easy reference. Perhaps that
is a bank of mail servers, but again, why a source port of 25 with a random
destination port. How could they possibly hope to connect?
At 05:39 AM 3/8/2000 -0800, Joe Biniskiewicz wrote:
Can anyone give me an explanation why every day I see entries in my logs for
hosts that try to connect with my GB using a "source" port of 25 and a
random destination port? I fully expect GB to block these packets, as it
does, but why are they trying on a source port of 25? What is their intent?
-joeb
Mar 7 09:34:16 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.0.205/25]->[209.239.242.112/13883] l=0 f=0x10.
At 09:38 AM 3/8/2000 -0500, Michael W. Burden wrote:
Chances are that someone at your office is retrieving their personal
email (Does anyone at your office have a cable modem? home.com is
the domain used by @Home which provides cable modem services to
cable companies such as AT&T and Roadrunner).
At 10:59 AM 3/8/2000 -0600, Suresh Ganu wrote:
Systems coming in on port 25 are SMTP mailers.
This is a well known port and can potentially be used by Spammers to relay
junk e-mail from your Servers.
As someone suggested, it is also being used by 'smart' users to receive
personal e-mail like hotmail.
At 12:27 PM 3/8/2000 -0500, Michael W. Burden wrote:
One thing to note is that this will only work if you don't
host your own primary email server (the one indicated by
the MX record for your domain.)
If you host your own primary email server, then your SMTP
server needs to be accessible from anywhere on the Internet
in order for you to receive email.
Mar 7 09:34:16 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.0.205/25]->[209.239.242.112/13883] l=0 f=0x10.
Mar 7 23:24:12 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.0.207/25]->[209.239.242.112/14710] l=0 f=0x10.
Mar 7 07:10:56 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.0.208/25]->[209.239.242.112/13850] l=0 f=0x10.
Mar 8 00:14:02 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.0.208/25]->[209.239.242.112/14761] l=0 f=0x10.
Mar 7 07:40:38 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.95.51/25]->[209.239.242.112/13858] l=0 f=0x10.
Mar 7 15:36:04 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.95.51/25]->[209.239.242.112/13987] l=0 f=0x10.
Mar 7 21:45:37 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.95.52/25]->[209.239.242.112/14628] l=0 f=0x10.
Mar 8 02:01:49 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.95.53/25]->[209.239.242.112/14820] l=0 f=0x10.
Mar 7 08:12:23 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.0.95.56/25]->[209.239.242.112/13862] l=0 f=0x10.
Mar 7 17:24:55 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.2.2.197/25]->[209.239.242.112/14006] l=0 f=0x10.
Mar 7 20:03:23 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.2.2.198/25]->[209.239.242.112/14292] l=0 f=0x10.
Mar 7 22:40:00 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.2.2.198/25]->[209.239.242.112/14648] l=0 f=0x10.
Mar 7 20:50:39 192.168.2.254 FILTER: Remote access filter blocks: TCP ed0
[24.2.2.199/25]->[209.239.242.112/14513] l=0
f=0x10. ---------------------------------------------- To Unsubscribe: send
mail to majordomo_at_gta_dot_com with "unsubscribe gb-users your_email_address in
the body of the message
|