Has anyone seen an increase of broadcast pings, where the source route appears to be from a nameserver? We took a look through our access-list logs, and it seems all of the attempted attacks during the last few days have had an IP-source of a nameserver. Just thought it was curious. Best regards, Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie@fast.net (610)954-5200 http://www.fast.net/ FASTNET - Business and Personal Internet Solutions
Yes we see a lot of broadcast pings, one network after the next in sequential order through CIDR blocks. Fun. Probably 5-10 attacks/day. On Mon, 22 Dec 1997, Jamie Scheinblum wrote:
Has anyone seen an increase of broadcast pings, where the source route appears to be from a nameserver?
We took a look through our access-list logs, and it seems all of the attempted attacks during the last few days have had an IP-source of a nameserver.
Just thought it was curious.
Best regards,
Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie@fast.net (610)954-5200 http://www.fast.net/ FASTNET - Business and Personal Internet Solutions
I had a customers link go down because they were the target of a smurf attack a few weeks ago, and when I was sniffing the link to find out what was going on, I found tons of packets coming from root nameservers, .gov sites, and other places. If I hadn't been at a terminal, I'd have done a better job of logging them when it happened. As it stands, I just turned off ICMP into my routers for a few hours and all was well. What I would have given to have had a dedicated sniffer so I could have done a better job of logging. Regards, Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Fortune for the day: "Speak softly and carry a +6 two-handed sword." On Mon, 22 Dec 1997, Jamie Scheinblum wrote:
Has anyone seen an increase of broadcast pings, where the source route appears to be from a nameserver?
We took a look through our access-list logs, and it seems all of the attempted attacks during the last few days have had an IP-source of a nameserver.
Just thought it was curious.
Best regards,
Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie@fast.net (610)954-5200 http://www.fast.net/ FASTNET - Business and Personal Internet Solutions
block/log broadcast pings: ------------- access-list 198 deny icmp any 0.0.0.255 255.255.255.0 log route-map ICMP-DENY permit 10 match ip address 198 interface ATM3/0 ip policy route-map ICMP-DENY ------------- Here's someone working thier way through a CIDR block(source address removed to protect the inocent): Dec 13 15:32:01 e1-1.baltimore.mae-east.clark.net 169458: .Dec 13 20:32:00.878: %SEC-6-IPACCESSLOGDP: list 198 denied icmp x.x.x.x -> 207.196.61.255 (8/0), 1 packet Dec 13 15:32:11 e1-1.baltimore.mae-east.clark.net 169459: .Dec 13 20:32:10.410: %SEC-6-IPACCESSLOGDP: list 198 denied icmp x.x.x.x -> 207.196.63.255 (8/0), 1 packet Dec 13 15:32:17 e1-1.baltimore.mae-east.clark.net 169460: .Dec 13 20:32:16.406: %SEC-6-IPACCESSLOGDP: list 198 denied icmp x.x.x.x -> 207.196.98.255 (8/0), 1 packet On Mon, 22 Dec 1997, Joe Shaw wrote:
I had a customers link go down because they were the target of a smurf attack a few weeks ago, and when I was sniffing the link to find out what was going on, I found tons of packets coming from root nameservers, .gov sites, and other places. If I hadn't been at a terminal, I'd have done a better job of logging them when it happened. As it stands, I just turned off ICMP into my routers for a few hours and all was well. What I would have given to have had a dedicated sniffer so I could have done a better job of logging.
Regards, Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Fortune for the day: "Speak softly and carry a +6 two-handed sword."
On Mon, 22 Dec 1997, Jamie Scheinblum wrote:
Has anyone seen an increase of broadcast pings, where the source route appears to be from a nameserver?
We took a look through our access-list logs, and it seems all of the attempted attacks during the last few days have had an IP-source of a nameserver.
Just thought it was curious.
Best regards,
Jamie Scheinblum - FASTNET(tm) / You Tools Corporation jamie@fast.net (610)954-5200 http://www.fast.net/ FASTNET - Business and Personal Internet Solutions
Joe Shaw wrote:
I had a customers link go down because they were the target of a smurf attack a few weeks ago, and when I was sniffing the link to find out what was going on, I found tons of packets coming from root nameservers, .gov sites, and other places. If I hadn't been at a terminal, I'd have done a better job of logging them when it happened. As it stands, I just turned off ICMP into my routers for a few hours and all was well. What I would have given to have had a dedicated sniffer so I could have done a better job of logging.
Although this could double the load on routers, I think this could still be a valuable feature on the Internet, if all routers had it. There do remain some technical problems with it that need to be worked out, but I hope you can see what I am getting at, and maybe with that idea in mind a way can be found to make this work. When a packet arrives, take note of the interface and gateway it came from. Check the route tables for where a reply to this packet could be delivered. Don't choose only the best route, but compare where the packet came from with all valid reply routes (except broad defaults larger than a certain size that can be configured). If the packet came from where it is valid to reply, then allow the packet to proceed. If not, then discard it (an ICMP probably won't make it back to the right place anyway). Those who are faking source addresses will have a tougher time when such a feature in place throughout the net. At some point their packets are being injected invalidly, and if the router there is doing this, it can discard the attempt. One problem could be in layer 3 switches which might have only the best route. It would then not handle an asymmetric situation. Switch logic would have to be extended to handle more than one return route if the switch is to perform this chore. Any other ideas on eliminating smurfing and spoofing and such? -- Phil Howard | no22ads0@nowhere6.com w1x6y2z3@anyplace.net end5ads7@dumb9ads.net phil | stop6it0@s5p7a4m3.org stop2104@no9where.edu no6spam3@nowhere0.edu at | no3spam4@anywhere.org stop5it6@spam9mer.com no7spam4@no2place.com milepost | ads1suck@no1where.edu no9way41@nowhere8.net a1b1c5d2@noplace2.org dot | blow6me1@spammer2.edu eat0this@noplace8.net ads8suck@s2p2a0m9.com com | end4ads1@spammer0.com suck5it1@lame8ads.org stop1ads@no28ads4.org
At 05:32 PM 12/23/97 -0600, Phil Howard wrote:
When a packet arrives, take note of the interface and gateway it came from. Check the route tables for where a reply to this packet could be delivered. Don't choose only the best route, but compare where the packet came from with all valid reply routes (except broad defaults larger than a certain size that can be configured). If the packet came from where it is valid to reply, then allow the packet to proceed. If not, then discard it (an ICMP probably won't make it back to the right place anyway).
Yes. Some of us call this 'unicast RPF'. Your point is well taken. ;-) - paul
On Tue, Dec 23, 1997 at 05:32:15PM -0600, Phil Howard wrote:
When a packet arrives, take note of the interface and gateway it came from. Check the route tables for where a reply to this packet could be delivered. Don't choose only the best route, but compare where the packet came from with all valid reply routes (except broad defaults larger than a certain size that can be configured). If the packet came from where it is valid to reply, then allow the packet to proceed. If not, then discard it (an ICMP probably won't make it back to the right place anyway).
Oh ghod... weren't you around, Phil, when _I_ got roundly trounced and reviled as a clueless newbie about 3 months ago for alomst exactly the same solution? The outcome as I recall, was that the only practical thing to do was ingress filtering at boundary routers, if they would. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592
At 6:32 PM -0500 12/23/97, Phil Howard wrote:
When a packet arrives, take note of the interface and gateway it came from. Check the route tables for where a reply to this packet could be delivered. Don't choose only the best route, but compare where the packet came from with all valid reply routes (except broad defaults larger than a certain size that can be configured). If the packet came from where it is valid to reply, then allow the packet to proceed. If not, then discard it (an ICMP probably won't make it back to the right place anyway).
Actually, you want to check that it is reasonable for a packet with a particular source address to arrive on a particular interface. Packets from customers should only come from customer source addresses. (input filter on the customer link) Packets from you should only come from your IP space, or that which you transit for others. (transmit filter at your borders) All bad packets come from somewhere. All you can do is make sure they can't come from your customers. You can also try not to send them on to others. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
participants (7)
-
Dean Anderson -
Jamie Scheinblum -
Jay R. Ashworth -
Joe Shaw -
Paul Ferguson -
Phil Howard -
Stephen Balbach