Cisco says attacks are due to operational practices
In an InteractiveWeek article the head of Cisco's security products group says the attacks are an operational problem not a technical problem.
Routers from Cisco and other vendors have the ability to detect the signature patterns of a denial-of-service attack, and the routers can filter out that traffic, Farnsworth said.
"The router knows which sources are legitimate or not and drops on the floor anything suspicious," Farnsworth said. "Generally speaking, ingress filtering and committed rates are effective in terms of preventing [malicious] traffic from ever showing up, or filtering it to a reasonable rate."
At 02:29 PM 2/10/00 -0800, Sean Donelan wrote:
In an InteractiveWeek article the head of Cisco's security products group says the attacks are an operational problem not a technical problem.
Routers from Cisco and other vendors have the ability to detect the signature patterns of a denial-of-service attack, and the routers can filter out that traffic, Farnsworth said.
"The router knows which sources are legitimate or not and drops on the floor anything suspicious," Farnsworth said. "Generally speaking, ingress filtering and committed rates are effective in terms of preventing [malicious] traffic from ever showing up, or filtering it to a reasonable rate."
I would agree with Farnsworth. Cisco routers do have some of the richest filtering mechanisms available. Though the configuration is best done at the edge routers (not on any core backbone). Considering the huge number of end sites out there, this is labor intensive. If you were a medium or large ISP that had 250+ end sites behind you, then you would have to go out and reprogram over 250+ routers. Placing the same changes on the core routers is impractical since it would be very CPU and Memory intensive and just as big a pain to administer. We made a decision over a year ago to start making changes on as many of our customer end sites as possible. We wrote an in-house perl script to take a Cisco router configuration and build inbound and outbound filters. These filters are then applied to the serial interface that connects to our network and toward the Internet. The inbound filter prevents outsiders from spoofing a LAN IP address aimed at that specific site. The outbound filter prevents someone on the LAN from sending spoofed packets (bogus source IP addresses) from getting to the Internet. Our script also adds the "no IP directed-broadcast", "no service udp-small-servers", and "no service tcp-small-servers" commands. We also add restricted telnet access and other security related commands. The suggested modifications are written to a text file and can be further edited and TFTP'd to the router at the discretion of the engineer. We routinely manage a large majority our customer's routers. For our customers who manage their own routers, we urge them to add these filets and work to make them aware of any security changes they should make. Education of the customer becomes key to stopping spoofed packets from leaving your network. :-) We turned on logging on a few sites where we suspected some suspicious activity and actually logged a number of spoofed packets that were caught in the anti-spoofing filters. The bad news is that we have not caught the actual persons sending out the spoofed packets. We suspect that these guys may have moved on somewhere else. If you are willing to commit the resources and time setting anti-spoofing filters on all your end site routers, it is a very worthwhile thing. -- Tom Beeson My 2 cents worth. Views are my own and not necessarily that of the company for which I work. --**--**--**--**--**--**--**--**--**--**--**-- Tom Beeson Oso Grande Technologies Network Engineer A New Mexico Technet Co. (505) 345-1748 noc@nm.net --**--**--**--**--**--**--**--**--**--**--**--
We have always built martian filters on our edge routers. In addition we built specific filters for ports that are not used, or are bad on the net. No matter what the customers router is doing, ours will drop 1918 and other IP blocks, and ports. This can be automated and can be deployed over a reasonable period of time. Most MAJOR backbone providers do not do this, wish they would jmbrown On Thu, Feb 10, 2000 at 06:48:06PM -0700, Tom Beeson wrote:
At 02:29 PM 2/10/00 -0800, Sean Donelan wrote:
In an InteractiveWeek article the head of Cisco's security products group says the attacks are an operational problem not a technical problem.
Routers from Cisco and other vendors have the ability to detect the signature patterns of a denial-of-service attack, and the routers can filter out that traffic, Farnsworth said.
"The router knows which sources are legitimate or not and drops on the floor anything suspicious," Farnsworth said. "Generally speaking, ingress filtering and committed rates are effective in terms of preventing [malicious] traffic from ever showing up, or filtering it to a reasonable rate."
I would agree with Farnsworth. Cisco routers do have some of the richest filtering mechanisms available. Though the configuration is best done at the edge routers (not on any core backbone). Considering the huge number of end sites out there, this is labor intensive. If you were a medium or large ISP that had 250+ end sites behind you, then you would have to go out and reprogram over 250+ routers. Placing the same changes on the core routers is impractical since it would be very CPU and Memory intensive and just as big a pain to administer. We made a decision over a year ago to start making changes on as many of our customer end sites as possible.
We wrote an in-house perl script to take a Cisco router configuration and build inbound and outbound filters. These filters are then applied to the serial interface that connects to our network and toward the Internet. The inbound filter prevents outsiders from spoofing a LAN IP address aimed at that specific site. The outbound filter prevents someone on the LAN from sending spoofed packets (bogus source IP addresses) from getting to the Internet. Our script also adds the "no IP directed-broadcast", "no service udp-small-servers", and "no service tcp-small-servers" commands. We also add restricted telnet access and other security related commands. The suggested modifications are written to a text file and can be further edited and TFTP'd to the router at the discretion of the engineer.
We routinely manage a large majority our customer's routers. For our customers who manage their own routers, we urge them to add these filets and work to make them aware of any security changes they should make. Education of the customer becomes key to stopping spoofed packets from leaving your network. :-)
We turned on logging on a few sites where we suspected some suspicious activity and actually logged a number of spoofed packets that were caught in the anti-spoofing filters. The bad news is that we have not caught the actual persons sending out the spoofed packets. We suspect that these guys may have moved on somewhere else. If you are willing to commit the resources and time setting anti-spoofing filters on all your end site routers, it is a very worthwhile thing.
-- Tom Beeson
My 2 cents worth. Views are my own and not necessarily that of the company for which I work.
--**--**--**--**--**--**--**--**--**--**--**-- Tom Beeson Oso Grande Technologies Network Engineer A New Mexico Technet Co. (505) 345-1748 noc@nm.net --**--**--**--**--**--**--**--**--**--**--**--
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ? If the customer is aware this is happening or even requests this type of firewall service, that's great. But to filter ports on backbone routers is stupid. On Thu, 10 Feb 2000, John M. Brown wrote: | | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net. | | No matter what the customers router is doing, ours will drop 1918 and other | IP blocks, and ports. | | This can be automated and can be deployed over a reasonable period of time. | Most MAJOR backbone providers do not do this, wish they would | | jmbrown | | | On Thu, Feb 10, 2000 at 06:48:06PM -0700, Tom Beeson wrote: | > | > At 02:29 PM 2/10/00 -0800, Sean Donelan wrote: | > | > >In an InteractiveWeek article the head of Cisco's security products group | > >says the attacks are an operational problem not a technical problem. | > > | > > >Routers from Cisco and other vendors have the ability to detect the | > > signature | > > >patterns of a denial-of-service attack, and the routers can filter out that | > > >traffic, Farnsworth said. | > > > | > > >"The router knows which sources are legitimate or not and drops on the floor | > > >anything suspicious," Farnsworth said. "Generally speaking, ingress | > > filtering | > > >and committed rates are effective in terms of preventing [malicious] traffic | > > >from ever showing up, or filtering it to a reasonable rate." | > | > I would agree with Farnsworth. Cisco routers do have some of the richest | > filtering mechanisms available. Though the configuration is best done at | > the edge routers (not on any core backbone). Considering the huge number | > of end sites out there, this is labor intensive. If you were a medium or | > large ISP that had 250+ end sites behind you, then you would have to go out | > and reprogram over 250+ routers. Placing the same changes on the core | > routers is impractical since it would be very CPU and Memory intensive and | > just as big a pain to administer. We made a decision over a year ago to | > start making changes on as many of our customer end sites as possible. | > | > We wrote an in-house perl script to take a Cisco router configuration and | > build inbound and outbound filters. These filters are then applied to the | > serial interface that connects to our network and toward the Internet. The | > inbound filter prevents outsiders from spoofing a LAN IP address aimed at | > that specific site. The outbound filter prevents someone on the LAN from | > sending spoofed packets (bogus source IP addresses) from getting to the | > Internet. Our script also adds the "no IP directed-broadcast", "no service | > udp-small-servers", and "no service tcp-small-servers" commands. We also | > add restricted telnet access and other security related commands. The | > suggested modifications are written to a text file and can be further | > edited and TFTP'd to the router at the discretion of the engineer. | > | > We routinely manage a large majority our customer's routers. For our | > customers who manage their own routers, we urge them to add these filets | > and work to make them aware of any security changes they should | > make. Education of the customer becomes key to stopping spoofed packets | > from leaving your network. :-) | > | > We turned on logging on a few sites where we suspected some suspicious | > activity and actually logged a number of spoofed packets that were caught | > in the anti-spoofing filters. The bad news is that we have not caught the | > actual persons sending out the spoofed packets. We suspect that these guys | > may have moved on somewhere else. If you are willing to commit the | > resources and time setting anti-spoofing filters on all your end site | > routers, it is a very worthwhile thing. | > | > | > -- Tom Beeson | > | > My 2 cents worth. Views are my own and not necessarily that of the company | > for which I work. | > | > --**--**--**--**--**--**--**--**--**--**--**-- | > Tom Beeson Oso Grande Technologies | > Network Engineer A New Mexico Technet Co. | > (505) 345-1748 | > noc@nm.net | > --**--**--**--**--**--**--**--**--**--**--**-- | > | > | | --- Gates' Law: Every 18 months, the speed of software halves.
On Thu, Feb 10, 2000 at 06:13:56PM -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
Filtering my customers to prevent them from sending me packets with source ip addresses other than those they have told me about, or I have assigned to them is not wrong.
If the customer is aware this is happening or even requests this type of firewall service, that's great. But to filter ports on backbone routers is stupid.
Lets explain it this way: If I were operating a telephone network, I would only allow calls from numbers that I assigned, or my customers ask to be routed to them. Or even this: If I operate a cellular network, I can choose what the source number is on their telephone, and if I want to allow it. - Jared
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
If the customer is aware this is happening or even requests this type of firewall service, that's great. But to filter ports on backbone routers is stupid.
In the context of martian filtering, I'd assume he's referring to daytime/echo/chargen/etc. And filtering those is understandable. --msa
At 06:13 PM 02/10/2000 -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
Excuse me, but can you please tell me what "application" a downstream customer might be running which originates packets for traffic with source addresses which they are not advertising (or you are advertising for them)? - paul
I wasn't talking about filtering IPs, I'm talking about filtering by port. I have no problem with IP based filtering ;) On Thu, 10 Feb 2000, Paul Ferguson wrote: | At 06:13 PM 02/10/2000 -0800, Chris Cappuccio wrote: | | >Filtering incoming our outgoing ports for anybody's network but your own (not | >your customer's) is wrong. You know specifically what apps you are running. | >How can you know what your customer is running or what they want to do ? | | Excuse me, but can you please tell me what "application" a downstream | customer might be running which originates packets for traffic with | source addresses which they are not advertising (or you are advertising | for them)? | | - paul | | --- Gates' Law: Every 18 months, the speed of software halves.
At 06:24 PM 02/10/2000 -0800, Chris Cappuccio wrote:
I wasn't talking about filtering IPs, I'm talking about filtering by port. I have no problem with IP based filtering ;)
I did't see anyone talking about port-level filtering. What I did see, on the other hand, was someone talking about about filtering Martian network traffic -- stuff which should not be there in the first place. - paul
Did anyone even read the post I was responding to ??
On Thu, 10 Feb 2000, John M. Brown wrote: | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net.
"Ports that are not used" What about when the tcp stack on a particular machine dynamically allocates a particular port for some tcp connection and you are filtering that port ? etc.... On Thu, 10 Feb 2000, Paul Ferguson wrote: | I did't see anyone talking about port-level filtering. What | I did see, on the other hand, was someone talking about about | filtering Martian network traffic -- stuff which should not | be there in the first place. | | - paul | | | --- Gates' Law: Every 18 months, the speed of software halves.
Umm, lets see, hosts are supposed to assign ports for sessions above 1024. Ports below 1024 are "priv / root" ports and are assigned for specific services. We filter <1023 >1023 we don't care about so much, except for a couple of well known ones. On Thu, Feb 10, 2000 at 07:02:25PM -0800, Chris Cappuccio wrote:
Did anyone even read the post I was responding to ??
On Thu, 10 Feb 2000, John M. Brown wrote: | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net.
"Ports that are not used" What about when the tcp stack on a particular machine dynamically allocates a particular port for some tcp connection and you are filtering that port ? etc....
On Thu, 10 Feb 2000, Paul Ferguson wrote:
| I did't see anyone talking about port-level filtering. What | I did see, on the other hand, was someone talking about about | filtering Martian network traffic -- stuff which should not | be there in the first place. | | - paul | | |
--- Gates' Law: Every 18 months, the speed of software halves.
Unfortunately, ssh on linux regularly assigns ports when ssh'ing out from a box below 1024, I think this is a bug, but make writing firewall commands annoying. Bora "John M. Brown" wrote:
Umm, lets see, hosts are supposed to assign ports for sessions above 1024. Ports below 1024 are "priv / root" ports and are assigned for specific services.
We filter <1023 >1023 we don't care about so much, except for a couple of well known ones.
On Thu, Feb 10, 2000 at 07:02:25PM -0800, Chris Cappuccio wrote:
Did anyone even read the post I was responding to ??
On Thu, 10 Feb 2000, John M. Brown wrote: | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net.
"Ports that are not used" What about when the tcp stack on a particular machine dynamically allocates a particular port for some tcp connection and you are filtering that port ? etc....
On Thu, 10 Feb 2000, Paul Ferguson wrote:
| I did't see anyone talking about port-level filtering. What | I did see, on the other hand, was someone talking about about | filtering Martian network traffic -- stuff which should not | be there in the first place. | | - paul | | |
--- Gates' Law: Every 18 months, the speed of software halves.
On Fri, Feb 11, 2000, Bora Akyol wrote:
Unfortunately, ssh on linux regularly assigns ports when ssh'ing out from a box below 1024, I think this is a bug, but make writing firewall commands annoying.
Bora
Its not a bug, its a leftover from rsh days - if the connection originates from a port below 1024, you could assume *cough* that the credentials the connection supplies are authentic, since the process needs to be root to bind to ports < 1024. This isn't a "but thats flawed!" discussion seed, take that to bugtraq. There's a flag to ssh somewhere to stop it doing that. Yup, -P . Adrian
Also, I believe ssh won't do this if you remove the suid bit (which is probably a good idea anyway). --Adam On Sat, Feb 12, 2000 at 03:07:25AM +0800, adrian@creative.net.au wrote:
Its not a bug, its a leftover from rsh days - if the connection originates from a port below 1024, you could assume *cough* that the credentials the connection supplies are authentic, since the process needs to be root to bind to ports < 1024.
This isn't a "but thats flawed!" discussion seed, take that to bugtraq.
There's a flag to ssh somewhere to stop it doing that. Yup, -P .
Adrian
After a quick (<30 sec) trip to the man page, voila! To use non-privileged ports, add to /etc/config or ~/.ssh/config: Host * RhostsAuthentication no RhostsRSAAuthentication no UsePrivilegedPort no This disables attempting rhosts-style authentication, which any sane server should reject anyways. Why these are still enabled by default escapes me. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: NSA, Network Consulting Engineer :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Pager: 800-365-4578 / 800-901-6078 C I S C O S Y S T E M S Email: ssprunk@cisco.com ----- Original Message ----- From: adrian@creative.net.au To: nanog@merit.edu Sent: Friday, February 11, 2000 13:07 Subject: Re: Cisco says attacks are due to operational practices Its not a bug, its a leftover from rsh days - if the connection originates from a port below 1024, you could assume *cough* that the credentials the connection supplies are authentic, since the process needs to be root to bind to ports < 1024. This isn't a "but thats flawed!" discussion seed, take that to bugtraq. There's a flag to ssh somewhere to stop it doing that. Yup, -P . Adrian
At 07:02 PM 02/10/2000 -0800, Chris Cappuccio wrote:
"Ports that are not used" What about when the tcp stack on a particular machine dynamically allocates a particular port for some tcp connection and you are filtering that port ? etc....
Okay, whatever. I'm talking about _source_ addresses, not ports. - paul
On Thu, 10 Feb 2000, Paul Ferguson wrote:
At 06:13 PM 02/10/2000 -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
Excuse me, but can you please tell me what "application" a downstream customer might be running which originates packets for traffic with source addresses which they are not advertising (or you are advertising for them)?
Trivial. I've seen several companies with two or more upstreams that are statically routed by their upstreams with a their respective blocks but default out. One might argue this is bad, but engineering is all about compromises and the real world and this happens in the real world. A lot. /vijay
One would assume that those upstreams know about the various blocks. If one of our customers starts blowing packets towards us with SRC IP not being something we know about, we drop it. Period. If they tell us we add it to the ACL. On Thu, Feb 10, 2000 at 09:50:22PM -0500, Vijay Gill wrote:
On Thu, 10 Feb 2000, Paul Ferguson wrote:
At 06:13 PM 02/10/2000 -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
Excuse me, but can you please tell me what "application" a downstream customer might be running which originates packets for traffic with source addresses which they are not advertising (or you are advertising for them)?
Trivial. I've seen several companies with two or more upstreams that are statically routed by their upstreams with a their respective blocks but default out.
One might argue this is bad, but engineering is all about compromises and the real world and this happens in the real world. A lot.
/vijay
At 06:13 PM 02/10/2000 -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
Excuse me, but can you please tell me what "application" a downstream customer might be running which originates packets for traffic with source addresses which they are not advertising (or you are advertising for them)?
- paul
In earlier days, direct-pc used to do this... Don't know if they "fixed" it or not. ---------------------------------------------------------------------- Wayne Bouchard [Immagine Your ] web@typo.org [Company Name Here] Network Engineer ----------------------------------------------------------------------
On Thu, Feb 10, 2000 at 06:13:56PM -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
If the customer is aware this is happening or even requests this type of firewall service, that's great. But to filter ports on backbone routers is stupid.
On Thu, 10 Feb 2000, John M. Brown wrote:
| | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net. | | No matter what the customers router is doing, ours will drop 1918 and other | IP blocks, and ports. | | This can be automated and can be deployed over a reasonable period of time. | Most MAJOR backbone providers do not do this, wish they would
Filtering traffic sourced from 1918 space is also stupid. There is absolutily nothing wrong with this traffic. There is something wrong with knowing how to get to 1918 space that is not on your network or trying to tell someone else how to get to your 1918 space, but the traffic itself is totally legit, for example as a return in a traceroute from a hop that is numbered in 1918 space. I am continueingly amazed how many people say "well we filtered 1918 space that will reduce the size of the attack". RFC1918 space is 6% of the available IPv4 address space. Infact the only traffic that should NOT be on the internet is from the loopback class A 127.0.0.0/8, so if you want to filter something useful why don't you try access-list 1911 permit 64.0.0.0 0.255.255.255 access-list 1911 deny 64.0.0.0 63.255.255.255 access-list 1911 deny 224 0.0.0 31.255.255.255 access-list 1911 permit any Thats a 35.9% reduction in the random sourced attacks, and takes care of multicast space sourced packets which you should never see either. -- Richard A. Steenbergen <ras@above.net> http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) MFN / AboveNet Communications Inc - ISX Network Engineer, Vienna VA
On Thu, 10 Feb 2000, Richard Steenbergen wrote:
Filtering traffic sourced from 1918 space is also stupid. There is absolutily nothing wrong with this traffic. There is something wrong with
Nothing wrong with it? It is private address space. It should not be sent across the Internet. If you are sending traffic sourced from those IPs and expecting it to get through to arbitrary destinations, then that is your problem, not the problem of the person filtering it. Sure, if within a certain set of cooperating networks you wish to agree about certain policies for such traffic then that is fine; that isn't the public Internet. There are a huge number of legitimate reasons to filter traffic from 1918 space, such as using those addresses internally. That is why they are private addresses and why you must not expect anyone to pass traffic that you send from such addresses and why you shouldn't send such traffic. Anyone who uses 1918 space for router links where there is a drop in MTU that can result in an ICMP can't fragment being sent from a 1918 address over the Internet has a broken setup that will cause problems, even if you don't hear about them. Generating such packets in other things, such as traceroutes, is not great either but doesn't actually break things in the same way.
I am not doing this on backbone routers. I am doing this on edge routers. Outside world, nor our customers really need to goto say port 19 (chargen), or say 7 (echo) etc. And, yes there is disclosure to our customers on this. Again, we don't do this on our core, we do it on our EDGE, at no point did I say core. Filtering against spoofed IP is a good thing On Thu, Feb 10, 2000 at 06:13:56PM -0800, Chris Cappuccio wrote:
Filtering incoming our outgoing ports for anybody's network but your own (not your customer's) is wrong. You know specifically what apps you are running. How can you know what your customer is running or what they want to do ?
If the customer is aware this is happening or even requests this type of firewall service, that's great. But to filter ports on backbone routers is stupid.
On Thu, 10 Feb 2000, John M. Brown wrote:
| | We have always built martian filters on our edge routers. In addition we | built specific filters for ports that are not used, or are bad on the net. | | No matter what the customers router is doing, ours will drop 1918 and other | IP blocks, and ports. | | This can be automated and can be deployed over a reasonable period of time. | Most MAJOR backbone providers do not do this, wish they would | | jmbrown | | | On Thu, Feb 10, 2000 at 06:48:06PM -0700, Tom Beeson wrote: | > | > At 02:29 PM 2/10/00 -0800, Sean Donelan wrote: | > | > >In an InteractiveWeek article the head of Cisco's security products group | > >says the attacks are an operational problem not a technical problem. | > > | > > >Routers from Cisco and other vendors have the ability to detect the | > > signature | > > >patterns of a denial-of-service attack, and the routers can filter out that | > > >traffic, Farnsworth said. | > > > | > > >"The router knows which sources are legitimate or not and drops on the floor | > > >anything suspicious," Farnsworth said. "Generally speaking, ingress | > > filtering | > > >and committed rates are effective in terms of preventing [malicious] traffic | > > >from ever showing up, or filtering it to a reasonable rate." | > | > I would agree with Farnsworth. Cisco routers do have some of the richest | > filtering mechanisms available. Though the configuration is best done at | > the edge routers (not on any core backbone). Considering the huge number | > of end sites out there, this is labor intensive. If you were a medium or | > large ISP that had 250+ end sites behind you, then you would have to go out | > and reprogram over 250+ routers. Placing the same changes on the core | > routers is impractical since it would be very CPU and Memory intensive and | > just as big a pain to administer. We made a decision over a year ago to | > start making changes on as many of our customer end sites as possible. | > | > We wrote an in-house perl script to take a Cisco router configuration and | > build inbound and outbound filters. These filters are then applied to the | > serial interface that connects to our network and toward the Internet. The | > inbound filter prevents outsiders from spoofing a LAN IP address aimed at | > that specific site. The outbound filter prevents someone on the LAN from | > sending spoofed packets (bogus source IP addresses) from getting to the | > Internet. Our script also adds the "no IP directed-broadcast", "no service | > udp-small-servers", and "no service tcp-small-servers" commands. We also | > add restricted telnet access and other security related commands. The | > suggested modifications are written to a text file and can be further | > edited and TFTP'd to the router at the discretion of the engineer. | > | > We routinely manage a large majority our customer's routers. For our | > customers who manage their own routers, we urge them to add these filets | > and work to make them aware of any security changes they should | > make. Education of the customer becomes key to stopping spoofed packets | > from leaving your network. :-) | > | > We turned on logging on a few sites where we suspected some suspicious | > activity and actually logged a number of spoofed packets that were caught | > in the anti-spoofing filters. The bad news is that we have not caught the | > actual persons sending out the spoofed packets. We suspect that these guys | > may have moved on somewhere else. If you are willing to commit the | > resources and time setting anti-spoofing filters on all your end site | > routers, it is a very worthwhile thing. | > | > | > -- Tom Beeson | > | > My 2 cents worth. Views are my own and not necessarily that of the company | > for which I work. | > | > --**--**--**--**--**--**--**--**--**--**--**-- | > Tom Beeson Oso Grande Technologies | > Network Engineer A New Mexico Technet Co. | > (505) 345-1748 | > noc@nm.net | > --**--**--**--**--**--**--**--**--**--**--**-- | > | > | |
--- Gates' Law: Every 18 months, the speed of software halves.
[Who knew, when I began what started as private response, that I'd find a soapbox? This is not so much directed at Tom personally, but at the recurring attitude that he has, all unbeknownst to himself, reiterated just as I got my second wind.] Tom Beeson <beeson@nm.net> wrote:
We wrote an in-house perl script to take a Cisco router configuration and build inbound and outbound filters. These filters are then applied to the serial interface that connects to our network and toward the Internet.
You aren't performing the filtering Farnsworth was talking about, you are helping others to do it. You are "stopping spoofed packets from leaving THEIR networks," not your own. Hoping that the configurations you deliver remain in place so that you "are filtering." For those customers that you provide a managed solution, where they do not have access to the configuration, this might be an acceptable substitute. I don't think so, but its arguably closer since the router is, effectively, part of your network. If it weren't for the physical access at their end I'd call it square, right away. For those customers that manage their own its a different story. Your suggestions are likely to be followed, until the first network event after the rules are installed, at which point they will be removed as suspect, then never restored since no "difference" was seen, or (worse) their router "worked" better. Since *you* aren't filtering you find out about this either through routine checks (which is another can of worms) or *after* something nasty happens. Most likely it won't be Earth- shattering, but it will *happen* -- spilt milk. You need filters in your edges, even internal ones, because YOU might be cracked, or because your customers are and the oh-so-careful filters you constructed have been removed, or because some edge customer makes a mistake. They need filters in their edges, even their internal ones, because you might be cracked, or because they might be and your oh-so-careful filters have been removed, or because some NOC technician makes a mistake (or made one, a month or six ago). Mutual assurance is not a bad thing. Bite the bullet. Protect *your* edges *yourself*. This does raise the cost of providing service, since you'll have to buy more router than you *currently* expect for a given situation.
participants (16)
-
Adam McKenna -
adrian＠creative.net.au -
Bora Akyol -
Chris Cappuccio -
Jared Mauch -
John M. Brown -
Majdi S. Abbas -
Marc Slemko -
Mark Milhollan -
Paul Ferguson -
Richard Steenbergen -
Sean Donelan -
Stephen Sprunk -
Tom Beeson -
Vijay Gill -
Wayne Bouchard