E.B. Dreger wrote:
>
> Okay. It's on by default on your system; not in the kernel
> (IIRC), but on your system.
>
Some where yes. When I have compiled some other kernels recently, there
is a question asking whether or not to turn it on by default.
At the moment the XTR is running the kernel that it came with.
> Cisco routers have something called TCP intercept that was
> introduced in IOS <I forget the version>. When you receive an
> incoming SYN, the router pretends to be the protected host, and
> replies with a SYN+ACK. If the connection is successfully built,
> the router then passes on a proxied connection to the system in
> your network.
>
> If you run your own border router, you can do this. If you're
> colo'ed, hopefully your provider will understand and help. If
> neither, then it's back to the drawing board.
>
We used to be colo'ed, but now we have a couple SDSL lines and a pair of
Netopia routers. I have been considering getting a Cisco PIX or
something to inspect packets and etc. that could most likely assist in
this situation. I will have to look into that. At the moment due to the
limited space on the Netopia routers I am blocking them out from the XTR
using ipchains on the XTR.
I have not had a problem on any other machines, but this XTR is the only
one that runs a web server publicly.
>
>>What concerns me most is the logs. I would assume it would not be
>>logging what it is without receiving some sort of impact. Hard to tell
>>if it has effected any services. Hasn't seemed to but I am hoping to
>>address it before it becomes a problem.
>>
>
> Agreed. And, after seeing your other post, you certainly are
> receiving many SYN requests.
>
> I noticed that the IPs on your machine were private. Are you
> running NAT? If not, the attacking machine has to be pretty
> close by, else it wouldn't get routed.
No I am running NAT or PAT to be specific. So they are not local
machines, definitely remote.
> If you are running a firewall, I almost have to wonder... might
> there be a problem with something such as ECN blocking legitimate
> requests? Might the heavy hitters be proxy caches?
I do not think so, but I may have to look into that.
> Somebody certainly is interested in HTTP/80 on your machine,
> though. Most port scans don't look like that. One interesting
> tidbit was the attempt that came from port 854 on the original
> machine: On *ix boxen, one must have root to use low port
> numbers.
Yes, and it is not normal web traffic because my apache logs do not show
the IP's. If someone is using port 854 on the other end, then maybe they
have root access, and know what they are doing?
>
>
> Hmmmm. If no response, it is quite possible. Did you get a RST
> back? Nothing at all? Did any ICMP queries respond?
>
Scratch that, after rescanning, all responded and I have records of the scans.
Each is not your average user. Each has some sort of firewall.
>
>>I have seen allot more SYN_RECV sockets than the six I have blocked. But
>>each of the six that I blocked had many simultaneous sockets active that
>>did not seem to time-out in a reasonable time.
>>
>
> The timeout is controlled on your end. If there are that many
> sockets open, it sounds like <whoever> is being rather
> persistent.
>
It sure seems like it. From a variety of IP's so I am not to sure if
it's one person using one of his platoons one me.
>
>
> You might try using "whois.geektools.com" to run queries. You
> can always find the origin ASN using a public route server, and
> contact its POC... although IP space should be registered.
>
Some of the more recent ones have had DNS records. One was
cruel.and.passively.rotted.org 65.116.181.236
>
>>Still my biggest concern is the logs, since I would assume it would only
>>log a valid SYN attack?
>>
>
> I presume. I'd need to go back and review the specifics of the
> Linux kernel version in question. (Somebody help me out,
> here...)
>
>
>
>>Although I may be a little trigger happy. I do not think so though, I
>>tried to take my time and be as thorough as possible.
>>
>
> Yes, you did more than I ass-umed from your first post. Knowing
> what I know now, I'd not say that you were trigger-happy...
> blocking first and figuring out later sounds prudent.
>
I am still a little skeptical, but at least I know I am not blocking out
the average surfer with broadband and a mouse. :)
> Eddy
>
> Brotsman & Dreger, Inc. - EverQuick Internet Division
> Phone: +1 (316) 794-8922 Wichita/(Inter)national
> Phone: +1 (785) 865-5885 Lawrence
> --
>
> Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
> From: A Trap <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Please ignore this portion of my mail signature.
>
> These last few lines are a trap for address-harvesting spambots. Do NOT
> send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
>
> _______________________________________________
> cobalt-developers mailing list
> [EMAIL PROTECTED]
> http://list.cobalt.com/mailman/listinfo/cobalt-developers
>
>
>
--
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax
707.766.8989
http://www.obsidian-studios.com
_______________________________________________
cobalt-developers mailing list
[EMAIL PROTECTED]
http://list.cobalt.com/mailman/listinfo/cobalt-developers
