Hi, Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183) ---Snip. Mar 8 17:40:16: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 1 packet .Mar 8 17:44:28: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 1 packet .Mar 8 17:45:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 3 packets .Mar 8 17:49:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 2 packets .Mar 9 07:39:04: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 1 packet .Mar 9 07:44:18: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 9 packets .Mar 9 09:53:46: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 1 packet .Mar 9 09:59:24: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 9 packets .Mar 9 12:11:55: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 1 packet .Mar 9 12:17:29: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 8 packets .Mar 9 12:22:30: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 4 packets ---snip Thanks
Vitts Networks (NETBLK-VITT-1BLK) 77 Sundial Ave Manchester, NH 03103 US Netname: VITT-1BLK Netblock: 216.64.0.0 - 216.64.127.255 Maintainer: VITT Coordinator: domreg (DOM68-ORG-ARIN) domreg@VITTS.COM 603-656-8000 Fax - 603-656-8100 Domain System inverse mapping provided by: NS1.VITTS.COM 216.64.31.76 NS2.VITTS.COM 216.64.117.21 ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE Rwhois reassignment information for this block is available at rwhois.vitts.net 4321 Record last updated on 30-Nov-1999. Database last updated on 9-Mar-2000 06:42:18 EDT. Scott McGrath wrote:
Hi,
Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183)
---Snip. Mar 8 17:40:16: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 1 packet .Mar 8 17:44:28: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 1 packet .Mar 8 17:45:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 3 packets .Mar 8 17:49:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 2 packets .Mar 9 07:39:04: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 1 packet .Mar 9 07:44:18: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 9 packets .Mar 9 09:53:46: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 1 packet .Mar 9 09:59:24: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 9 packets .Mar 9 12:11:55: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 1 packet .Mar 9 12:17:29: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 8 packets .Mar 9 12:22:30: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 4 packets ---snip
Thanks
-- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh
Hi,
Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183) Yes, all from Reserved(Private) IP's.. Over and over and over.. At two minute intervals.
Mar 9 11:48:52 xxxxxxxx ipmon[23116]: 11:48:52.169293 xl1 @0:4 b 10.2.8.31,80 -> xxx.xxx.xxx.xxx,51419 PR tcp len 20 40 -AF Mar 9 11:49:28 xxxxxxxx ipmon[23116]: 11:49:28.286393 xl1 @0:3 b 172.16.0.142,80 -> xxx.xxx.xxx.xxx,6736 PR tcp len 20 163 -AFP begins again... in 2 minutes.. same IP's, Flags and ports. M.
I cannot find anything in the literature about this attack method, As a WILD guess it is a mutation of one of the DDOS tools with new ports. but this underscores the importance of martian filters on border routers and also filtering outbounds so that spoofed addresses cannot leave your border routers. Cisco also has an obscure command to verify the path but it drops the router into process switch mode as I recall, If I am wrong please correct Scott "Matthew R. Potter" wrote:
Hi,
Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183) Yes, all from Reserved(Private) IP's.. Over and over and over.. At two minute intervals.
Mar 9 11:48:52 xxxxxxxx ipmon[23116]: 11:48:52.169293 xl1 @0:4 b 10.2.8.31,80 -> xxx.xxx.xxx.xxx,51419 PR tcp len 20 40 -AF Mar 9 11:49:28 xxxxxxxx ipmon[23116]: 11:49:28.286393 xl1 @0:3 b 172.16.0.142,80 -> xxx.xxx.xxx.xxx,6736 PR tcp len 20 163 -AFP
begins again... in 2 minutes.. same IP's, Flags and ports.
M.
At 05:53 PM 03/09/2000 -0500, Scott McGrath wrote:
I cannot find anything in the literature about this attack method, As a WILD guess it is a mutation of one of the DDOS tools with new ports. but this underscores the importance of martian filters on border routers and also filtering outbounds so that spoofed addresses cannot leave your border routers. Cisco also has an obscure command to verify the path but it drops the router into process switch mode as I recall, If I am wrong please correct
You're wrong. :-) I think you're talking about "ip verify unicast reverse-path", or what we also call Unicast RPF, which requires CEF switching (which is definately _not_ process level switching). - paul
Thank you sir may I have another.... :-) I had a vague recollection of that command from a 7000 session at Networkers but I was not really sure what was required as we have mostly 2/3/4XXX series routers around here with 7XXX and AGS+!!! (still going...) at the core Thanks - Scott Paul Ferguson wrote:
At 05:53 PM 03/09/2000 -0500, Scott McGrath wrote:
I cannot find anything in the literature about this attack method, As a WILD guess it is a mutation of one of the DDOS tools with new ports. but this underscores the importance of martian filters on border routers and also filtering outbounds so that spoofed addresses cannot leave your border routers. Cisco also has an obscure command to verify the path but it drops the router into process switch mode as I recall, If I am wrong please correct
You're wrong. :-)
I think you're talking about "ip verify unicast reverse-path", or what we also call Unicast RPF, which requires CEF switching (which is definately _not_ process level switching).
- paul
participants (4)
-
Henry R. Linneweh -
Matthew R. Potter -
Paul Ferguson -
Scott McGrath