Re: Nachi/Welchia Aftermath
> > > lesson learned: > > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > > L3 core more generally... "if you want routing, buy a router." i have a hybrid switer that i'm very happy with. at my house, that is. (the idea of using one in commerce or production gives me cold shivers.) -- Paul Vixie
Re: Nachi/Welchia Aftermath
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote: > Not all L3-switches are flow-based; prefix-based ones should do just fine. > Can people add/correct this initial list ? > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > Sup2(A), Sup3(A/BXL) The 2948G-L3 and the 4908G-L3 I believe are Prefix/ASIC based. I believe the 3550-EMI is as well, but I'm not familiar with that equipment.
Re: Nachi/Welchia Aftermath
On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote: > > Not all L3-switches are flow-based; prefix-based ones should do just fine. > Can people add/correct this initial list ? > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > Sup2(A), Sup3(A/BXL) Don't confuse "flow based" with "slow-path initial lookup", they aren't the same. -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: Nachi/Welchia Aftermath
On Tue, 20 Jan 2004, Rubens Kuhl Jr. wrote: > > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with > Sup1(A) > > > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 > with > > > Sup2(A), Sup3(A/BXL) > > Where do the Extreme and Juniper fit into this? > > Private and public answers to my question indicate that both Summit 48i and > Black Diamond from Extreme are flow-based; Juniper doesn't make layer 3 > switches, but their routers also do prefix-based forwarding; Cisco routers > also do prefix-based forwarding at usual configurations. > > Also of notice, flow-based forwarding is not the only thing that makes a L3 > device suffer at worm attacks. If a directly connected interface is an > Ethernet (or any other medium that is not point to point), ARPing for a lot > of new addresses per second can also do harm. Nearly. Any frames needing to go to the CPU will harm your box.. this tends to be L2 occurances (arp storms is one ) which therefore means connected ethernets. DoSing (L3 IP eg smurf) a router will usually hurt and if you can manage it higher level applications (announce/withdraw 1000s routes in BGP, fill up NAT tables). Of course your architectures differ so ymmv. Steve > > > Rubens > > > > > > > > > > - Original Message - > > > From: <[EMAIL PROTECTED]> > > > To: "Brent Van Dussen" <[EMAIL PROTECTED]> > > > Cc: "NANOG" <[EMAIL PROTECTED]> > > > Sent: Tuesday, January 20, 2004 9:46 PM > > > Subject: Re: Nachi/Welchia Aftermath > > > > > > > lesson learned: > > > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > > > L3 core > >
Re: sniffer/promisc detector
In message <[EMAIL PROTECTED]>, "Alexei Roudnev" writes: > > >> >> Uhm, that would be wrong. This is simply "security through obscurity". >Yes, it is wrong for the _smart books_. But it works in real life. Of >course, it should not be the last line of defense; but it works as a first >line very effectively. > Precisely. Don't count on security through obscurity -- there are targeted attacks, if nothing else -- but *after* you've taken all due precautions against a knowledgeable adversary, throwing in some obscurity can help, too. (Want a worked example? Ask the NSA to publish the algorithm for one of their top secret encryption algorithms...) But there's another major caveat: this sort of obscurity doesn't scale very well. It's fine to put ssh on another port if you have a relatively small community of reasonably sophisticated users who can cope, or if you can hand out canned configurations to less sophisticated users. But you couldn't easily put SMTP elsewhere, or no one could find you. You'd also have support problems with your user base if you tried doing that as an anti-relay technique. Obscurity works in small, closed communities. Beyond that, operational considerations can kill you. --Steve Bellovin, http://www.research.att.com/~smb
Re: Nachi/Welchia Aftermath
> > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > > Sup2(A), Sup3(A/BXL) > Where do the Extreme and Juniper fit into this? Private and public answers to my question indicate that both Summit 48i and Black Diamond from Extreme are flow-based; Juniper doesn't make layer 3 switches, but their routers also do prefix-based forwarding; Cisco routers also do prefix-based forwarding at usual configurations. Also of notice, flow-based forwarding is not the only thing that makes a L3 device suffer at worm attacks. If a directly connected interface is an Ethernet (or any other medium that is not point to point), ARPing for a lot of new addresses per second can also do harm. Rubens > > > > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: "Brent Van Dussen" <[EMAIL PROTECTED]> > > Cc: "NANOG" <[EMAIL PROTECTED]> > > Sent: Tuesday, January 20, 2004 9:46 PM > > Subject: Re: Nachi/Welchia Aftermath > > > > > lesson learned: > > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > > L3 core
Re: Nachi/Welchia Aftermath
On Tuesday 20 January 2004 04:16 pm, Rubens Kuhl Jr. wrote: > Not all L3-switches are flow-based; prefix-based ones should do just fine. > Can people add/correct this initial list ? > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > Sup2(A), Sup3(A/BXL) > > > Rubens > Where do the Extreme and Juniper fit into this? > > - Original Message - > From: <[EMAIL PROTECTED]> > To: "Brent Van Dussen" <[EMAIL PROTECTED]> > Cc: "NANOG" <[EMAIL PROTECTED]> > Sent: Tuesday, January 20, 2004 9:46 PM > Subject: Re: Nachi/Welchia Aftermath > > > lesson learned: > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > L3 core > > > > -J > > > > On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: > > > Well folks, since the middle of August I've been tracking the spread > > > and subsequent efforts by our community to stop the nachia/welchia > > > infection that took down so many networks. > > > > > > Sadly, by my estimations, only about 20-30% of infected hosts were > > > cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) > > of > > > > remaining infected hosts were rebooted and the worm removed > > > itself. Network traffic has finally returned to normal. > > > > > > What kind of effects did everyone see from this devastating worm and > > what > > > > lessons did we learn for preventing network downtime in the future? > > > > -- > > James Jun (formerly Haesu) > > TowardEX Technologies, Inc. > > 1740 Massachusetts Ave. > > Boxborough, MA 01719 > > Consulting, IPv4 & IPv6 colocation, web hosting, network design & > > implementation > > > http://www.towardex.com | [EMAIL PROTECTED] > > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > > Fax: (978)263-0033 | AIM: GigabitEthernet0 > > NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE -- Donovan Hill Electronics Engineering Technologist, CCNA www.lazyeyez.net, www.gwsn.com
Re: Nachi/Welchia Aftermath
yes in concur.. prefix based ones (like FIB) are fine. unfortunately some models from some vendors (tisk tisk) who use slow process path to reprogram the CAM per flow can be quite painful during situations like random dest. dos attacks and worms.. add the E vendor to your list too.. we had summit48i that loved the worm traffic -J On Tue, Jan 20, 2004 at 10:16:03PM -0200, Rubens Kuhl Jr. wrote: > > > Not all L3-switches are flow-based; prefix-based ones should do just fine. > Can people add/correct this initial list ? > > Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) > Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with > Sup2(A), Sup3(A/BXL) > > > Rubens > > > - Original Message - > From: <[EMAIL PROTECTED]> > To: "Brent Van Dussen" <[EMAIL PROTECTED]> > Cc: "NANOG" <[EMAIL PROTECTED]> > Sent: Tuesday, January 20, 2004 9:46 PM > Subject: Re: Nachi/Welchia Aftermath > > > > > > lesson learned: > > stop using /makeshift/ layer3 switches (without naming vendor) to run > > L3 core > > > > -J > > > > On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: > > > > > > Well folks, since the middle of August I've been tracking the spread and > > > subsequent efforts by our community to stop the nachia/welchia infection > > > that took down so many networks. > > > > > > Sadly, by my estimations, only about 20-30% of infected hosts were > > > cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) > of > > > remaining infected hosts were rebooted and the worm removed > > > itself. Network traffic has finally returned to normal. > > > > > > What kind of effects did everyone see from this devastating worm and > what > > > lessons did we learn for preventing network downtime in the future? > > > > -- > > James Jun (formerly Haesu) > > TowardEX Technologies, Inc. > > 1740 Massachusetts Ave. > > Boxborough, MA 01719 > > Consulting, IPv4 & IPv6 colocation, web hosting, network design & > implementation > > http://www.towardex.com | [EMAIL PROTECTED] > > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > > Fax: (978)263-0033 | AIM: GigabitEthernet0 > > NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE > > -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
Not all L3-switches are flow-based; prefix-based ones should do just fine. Can people add/correct this initial list ? Flow-based: Foundry with IronCore modules, Cisco Catalyst 6500 with Sup1(A) Prefix-based: Foundry with JetCore modules, Cisco Catalyst 6500/7600 with Sup2(A), Sup3(A/BXL) Rubens - Original Message - From: <[EMAIL PROTECTED]> To: "Brent Van Dussen" <[EMAIL PROTECTED]> Cc: "NANOG" <[EMAIL PROTECTED]> Sent: Tuesday, January 20, 2004 9:46 PM Subject: Re: Nachi/Welchia Aftermath > > lesson learned: > stop using /makeshift/ layer3 switches (without naming vendor) to run > L3 core > > -J > > On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: > > > > Well folks, since the middle of August I've been tracking the spread and > > subsequent efforts by our community to stop the nachia/welchia infection > > that took down so many networks. > > > > Sadly, by my estimations, only about 20-30% of infected hosts were > > cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of > > remaining infected hosts were rebooted and the worm removed > > itself. Network traffic has finally returned to normal. > > > > What kind of effects did everyone see from this devastating worm and what > > lessons did we learn for preventing network downtime in the future? > > -- > James Jun (formerly Haesu) > TowardEX Technologies, Inc. > 1740 Massachusetts Ave. > Boxborough, MA 01719 > Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation > http://www.towardex.com | [EMAIL PROTECTED] > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > Fax: (978)263-0033 | AIM: GigabitEthernet0 > NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE >
Re: sniffer/promisc detector
* [EMAIL PROTECTED] (Dave Israel) [Tue 20 Jan 2004, 18:48 CET]: > On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said: [..] >> - unpatched sshd on port 30013 - safety is 7 (higher) because no one >> automated script can find it, and no one manual scan find it in reality > Actually, an automated script or manual scan can find it trivially. > All you have to do is a quick port scan, looking for this: [..] Indeed. And Alexei's point is that noone is looking for that. > one across the enterprise, so it is only really obscure once. Moving > port numbers only protects you against idle vandalism; it is useless > against people who truly wish you harm. Alexei's point also was that you need additional measures against those people. > You really need a firewall, particularly one that can detect a port > scan and shut off the scanner, for changing ports to have any real > security. It is kind of like a 4-digit PIN being useless for a bank > card without the 3-try limit. Unless you like really, really sore fingers, and don't think a long line of people waiting behind you at the ATM will attract any attention from the bank employees. -- Niels.
Re: Nachi/Welchia Aftermath
lesson learned: stop using /makeshift/ layer3 switches (without naming vendor) to run L3 core -J On Tue, Jan 20, 2004 at 02:22:52PM -0800, Brent Van Dussen wrote: > > Well folks, since the middle of August I've been tracking the spread and > subsequent efforts by our community to stop the nachia/welchia infection > that took down so many networks. > > Sadly, by my estimations, only about 20-30% of infected hosts were > cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of > remaining infected hosts were rebooted and the worm removed > itself. Network traffic has finally returned to normal. > > What kind of effects did everyone see from this devastating worm and what > lessons did we learn for preventing network downtime in the future? -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
Re: Nachi/Welchia Aftermath
: : What kind of effects did everyone see from this devastating worm and what : : lessons did we learn for preventing network downtime in the future? : : : Proper network design is a good thing... ;-) Before I get flamed, I should say that is for end-user networks, not the normal BANs (Big A$$ Networks) that're the norm on this list. I'm a .edu-eyeball network now-a-days and I don't have to get everything to the end-user nor do I have to send out everything from the end-user, so I can block whatever I need, so long as my customers are happy. 99.9% of the time, they don't know I'm blocking anything... scott
Re: Nachi/Welchia Aftermath
: What kind of effects did everyone see from this devastating worm and what : lessons did we learn for preventing network downtime in the future? Proper network design is a good thing... ;-) scott
Re: Nachi/Welchia Aftermath
Flow based "attacks" can kill flow based routers. James Edwards Routing and Security Administrator [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Nachi/Welchia Aftermath
Well folks, since the middle of August I've been tracking the spread and subsequent efforts by our community to stop the nachia/welchia infection that took down so many networks. Sadly, by my estimations, only about 20-30% of infected hosts were cleaned. After Jan 1, 2004 it appears that the thousands, (millions?) of remaining infected hosts were rebooted and the worm removed itself. Network traffic has finally returned to normal. What kind of effects did everyone see from this devastating worm and what lessons did we learn for preventing network downtime in the future?
Re: What's the best way to wiretap a network?
In message <[EMAIL PROTECTED]>, William Allen Simpson writes: > >Eriks Rugelis wrote: >> >> On the other hand, if your environment consists of a large number (100's) of >> potential tapping points, then you will quickly determine that in-line taps >> have very poor scaling properties. >> a) They are not rack-dense >> b) They require external power warts >> c) They are not cheap (in the range of US$500 each) >> d) Often when you have that many potential tapping points, you are >> likely to be processing a larger number of warrants in a year. An in-line >> tap arrangement will require a body to physically install the recording >> equipment and cables to the trace-ports on the tap. You may also need to >> make room for more than one set of recording gear at each site. >> >This is a feature, not a bug. Law enforcement is required to pay -- >up front -- all costs of tapping. No pay, no play. Right, at least in the U.S. See section 4(e) of http://www4.law.cornell.edu/uscode/18/2518.html --Steve Bellovin, http://www.research.att.com/~smb
Re: What's the best way to wiretap a network?
Eriks Rugelis wrote: > > On the other hand, if your environment consists of a large number (100's) of > potential tapping points, then you will quickly determine that in-line taps > have very poor scaling properties. > a) They are not rack-dense > b) They require external power warts > c) They are not cheap (in the range of US$500 each) > d) Often when you have that many potential tapping points, you are > likely to be processing a larger number of warrants in a year. An in-line > tap arrangement will require a body to physically install the recording > equipment and cables to the trace-ports on the tap. You may also need to > make room for more than one set of recording gear at each site. > This is a feature, not a bug. Law enforcement is required to pay -- up front -- all costs of tapping. No pay, no play. > Large-scale providers will probably want to examine solutions based on > support built directly into their traffic-carrying infrastructure (switches, > routers.) > > You should be watchful for law enforcement types trying dictate a 'solution' > which is not a good fit to your own business environment. There are usually > several ways of getting them the data which they require to do their jobs. > Whatever they are willing to pay for -- a good fit for the business environment is the largest effort and highest cost, as the overhead and administrative charges should enough to be profitable. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Re: sniffer/promisc detector
> PS. Sniffer... there are not any way to detect sniffer in the non-switched > network, and there is not much use for sniffer in switched network, if this > network is configured properly and is watched for the unusial events. depends on brand and model of switch $ portinstall dsniff $ man macof -J (and yes, the thread topic is about ways for _watching_ "the unusual events" aka sniffing) > > > > > > The real smart ones - professionals - won't attack unless there's a > chance > > > of a serious payback. This excludes most businesses, and makes anything > > > but a well-known script-based attack a very remote possibility. > > > > that's just not so. ask me about it in person and i might tell you > stories. > > > > > For most other people a trivial packet-filtering firewall, lack of > > > Windoze, and a switch instead of a hub will do just fine. > > > > this part, i agree with. > > -- > > Paul Vixie -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
RE: sniffer/promisc detector
Remote power on :P -HenryMichel Py <[EMAIL PROTECTED]> wrote: > Alexei Roudnev wrote:> - turn off power - safety is 10. Secure> system, is a dark system.I have to disagree on this one; there is WOL (Wake-up On Lan), thesystem can be lit remotely.- turn off power - safety is 9- Unplug all cords - safety is 10Michel.
Re: sniffer/promisc detector
On 1/20/2004 at 09:18:07 -0800, Alexei Roudnev said: > > > > > > Uhm, that would be wrong. This is simply "security through obscurity". > Yes, it is wrong for the _smart books_. But it works in real life. Of > course, it should not be the last line of defense; but it works as a first > line very effectively. > > If I rate safety as a number (10 is the best, 0 is the worst): > - unpatched sshd on port 22 - safety is zero (will be hacked by automated > script in a few weeks) > - patched sshd on port 22 - safety is 5 (even patched sshd have a bugs, and > I do not know, what happen first - I patch next bug or hacker's script find > this sshd and hack it) > - unpatched sshd on port 30013 - safety is 7 (higher) because no one > automated script can find it, and no one manual scan find it in reality > - patched sshd on port 30013 - safety is 9 > - turn off power - safety is 10. Secure system, is a dark system. > > (I did not rated firewalls etc). Actually, an automated script or manual scan can find it trivially. All you have to do is a quick port scan, looking for this: 12:31 biohazard~>telnet [somewhere] [port] Trying [ip_address]... Connected to localhost. Escape character is '^]'. SSH-1.99-OpenSSH_3.4p1c Plus, if you put it on a non-standard port, you tend to use the same one across the enterprise, so it is only really obscure once. Moving port numbers only protects you against idle vandalism; it is useless against people who truly wish you harm. You really need a firewall, particularly one that can detect a port scan and shut off the scanner, for changing ports to have any real security. It is kind of like a 4-digit PIN being useless for a bank card without the 3-try limit. -Dave
RE: sniffer/promisc detector
> Alexei Roudnev wrote: > - turn off power - safety is 10. Secure > system, is a dark system. I have to disagree on this one; there is WOL (Wake-up On Lan), the system can be lit remotely. - turn off power - safety is 9 - Unplug all cords - safety is 10 Michel.
Re: Diversity as defense
Correct. Microsoft's problem is not security alone, but monoculture. If we have all systems around Windows2003, we are exposed to risk of devastating virus attack. No matter, how secure this Windows2003 is. - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, January 20, 2004 7:18 AM Subject: Re: Diversity as defense > Agreed, vendor lock in is a very big problem, what the economists would call increasing returns. Interestingly most of the research on the subjest finds that a vendor achieves "lock in" and a dominant market position not by being the most competitive product. Random historical accident, policies, market fluctuations, etc. - i.e. beta vs. vhs or CP/M vs. DOS vs. Apple. Probably getting far off topic here, but if you decreased the ability of vendors to lock in customers (increase competition) could you increase diversity and security at the macro scale. > > On Mon, 19 Jan 2004 15:35:22 EST, [EMAIL PROTECTED] said: > > The diversity, monoculture and agricutlure analogy makes nice press, but how > > realistic is diversity as a defense. > > Well.. if diversity were to actually exist, it would be quite helpful. Right now, > if you have a Windows exploit, you might as well point and pull the trigger because > you have an 86% chance of nailing the target. Add in a Linux exploit and you're well > over 90%. That's Russian Roulette with a 10-shooter and one bullet. > > On the other hand, let's think about if there were 10 products that each have 10% > market share, and even a minimal attempt at deterring fingerprinting of the target, > you're looking at a 90% chance that the exploit you launch will fail and leave a > nasty mark on an IDS. Suddenly, it's 9 bullets and one blank. And even worse odds > if you haven't been picking up all the exploits in the series - or not all the products > are vulnerable. > > Unfortunately, it's not a realistic scenario, because... > > > Is cost the biggest hurdle or limited > > avaiability of competitive products, or simply no bang for the buck by > > diversifying. > > I can sum up *every* problem I've had in getting people to migrate in just > 3 words: "vendor lock in". Enough said on that topic. >
Re: sniffer/promisc detector
> > Uhm, that would be wrong. This is simply "security through obscurity". Yes, it is wrong for the _smart books_. But it works in real life. Of course, it should not be the last line of defense; but it works as a first line very effectively. If I rate safety as a number (10 is the best, 0 is the worst): - unpatched sshd on port 22 - safety is zero (will be hacked by automated script in a few weeks) - patched sshd on port 22 - safety is 5 (even patched sshd have a bugs, and I do not know, what happen first - I patch next bug or hacker's script find this sshd and hack it) - unpatched sshd on port 30013 - safety is 7 (higher) because no one automated script can find it, and no one manual scan find it in reality - patched sshd on port 30013 - safety is 9 - turn off power - safety is 10. Secure system, is a dark system. (I did not rated firewalls etc). > > Go grab nessus (www.nessus.org), modify the code a bit, and I guarantee you Yes, correct. Do it. Measure scan time, and you will be surprised. Open old logs, and you will found, that such things are not used, they are absolutely not effective for any wide scanning. And they are very easy to detect by IDS systems (it is useless to detect port 22 scan - every hacker is doing it). Scan 65000 ports by T1 link, using 'nessus', and see the time and traffic. It can be used by insider on 100,000 Mbit network only, and (just again) such scan will be 100% catched by any IDS. > that your ssh daemon running on a non-standard port can still be found, > identified, and exploited. Trivial. Can != WILL. It WILL NOT. And it is FIRST line of defense. But this line decreases attacks level at 10,000 times, And it costs 0 (zero). Do not read _smart books_ without some thinking. (There are many cases, where it is impossible. But if it is possible, use it). Second line of defense is patched system, host IDS etc etc - standard security. It shuld not be the first line. And it should not be the last line. Last line of defense is HoneyPot. PS. I worked as a RU-CERT expert, make a traps, found and told with hackers, investigated many cases, so I have some background. And, of course, I know _smart books theory_. > > -b >
Re: What's the best way to wiretap a network?
Scott C. McGrath On Tue, 20 Jan 2004, Eriks Rugelis wrote: > > Sean Donelan wrote: > > Assuming lawful purposes, what is the best way to tap a network > > undetectable to the surveillance subject, not missing any > > relevant data, and not exposing the installer to undue risk? > > 'Best' rarely has a straight-forward answer. ;-) > > Lawful access is subject to many of the same scaling issues which we > confront in building up our networks. Solutions which can work well for > 'small' access or hosting providers may not be sensible for larger scale > environment. > > If you have only a low rate of warrants to process per year, >and if your facilities are few in number and/or geographically close > together, >and if your 'optimum' point of tap insertion happens to be a link which > can be reasonably traced without very expensive ASIC-based gear >and if your operation can tolerate breaking open the link to insert the > tap, >and if the law enforcement types agree that the surveillance target is > unlikely to notice the link going down to insert the tap... > >then in-line taps such as Finisar or NetOptics can be quite sensible. > > If your operation can tolerate the continuing presence of the in-line tap > and you only ever need a small number of them then leaving the taps > permanently installed may be entirely reasonable. > > On the other hand, if your environment consists of a large number (100's) of > potential tapping points, then you will quickly determine that in-line taps > have very poor scaling properties. > a) They are not rack-dense > b) They require external power warts > c) They are not cheap (in the range of US$500 each) > d) Often when you have that many potential tapping points, you are > likely to be processing a larger number of warrants in a year. An in-line > tap arrangement will require a body to physically install the recording > equipment and cables to the trace-ports on the tap. You may also need to > make room for more than one set of recording gear at each site. > > Large-scale providers will probably want to examine solutions based on > support built directly into their traffic-carrying infrastructure (switches, > routers.) Using cisco's feature set on a uBR it would be cable intercept interface x/y as an example of lawful access on infrastructure equipment > > You should be watchful for law enforcement types trying dictate a 'solution' > which is not a good fit to your own business environment. There are usually > several ways of getting them the data which they require to do their jobs. > > Eriks > --- > Eriks Rugelis -- Senior Consultant > Netidea Inc. Voice: +1 416 876 0740 > 63 Charlton Boulevard,FAX:+1 416 250 5532 > North York, Ontario, E-mail: [EMAIL PROTECTED] > Canada > M2M 1C1 > > PGP public key is here: > http://members.rogers.com/eriks.rugelis/certs/pgp.htm > > >
Re: What's the best way to wiretap a network?
Sean Donelan wrote: > Assuming lawful purposes, what is the best way to tap a network > undetectable to the surveillance subject, not missing any > relevant data, and not exposing the installer to undue risk? 'Best' rarely has a straight-forward answer. ;-) Lawful access is subject to many of the same scaling issues which we confront in building up our networks. Solutions which can work well for 'small' access or hosting providers may not be sensible for larger scale environment. If you have only a low rate of warrants to process per year, and if your facilities are few in number and/or geographically close together, and if your 'optimum' point of tap insertion happens to be a link which can be reasonably traced without very expensive ASIC-based gear and if your operation can tolerate breaking open the link to insert the tap, and if the law enforcement types agree that the surveillance target is unlikely to notice the link going down to insert the tap... then in-line taps such as Finisar or NetOptics can be quite sensible. If your operation can tolerate the continuing presence of the in-line tap and you only ever need a small number of them then leaving the taps permanently installed may be entirely reasonable. On the other hand, if your environment consists of a large number (100's) of potential tapping points, then you will quickly determine that in-line taps have very poor scaling properties. a) They are not rack-dense b) They require external power warts c) They are not cheap (in the range of US$500 each) d) Often when you have that many potential tapping points, you are likely to be processing a larger number of warrants in a year. An in-line tap arrangement will require a body to physically install the recording equipment and cables to the trace-ports on the tap. You may also need to make room for more than one set of recording gear at each site. Large-scale providers will probably want to examine solutions based on support built directly into their traffic-carrying infrastructure (switches, routers.) You should be watchful for law enforcement types trying dictate a 'solution' which is not a good fit to your own business environment. There are usually several ways of getting them the data which they require to do their jobs. Eriks --- Eriks Rugelis -- Senior Consultant Netidea Inc. Voice: +1 416 876 0740 63 Charlton Boulevard,FAX:+1 416 250 5532 North York, Ontario, E-mail: [EMAIL PROTECTED] Canada M2M 1C1 PGP public key is here: http://members.rogers.com/eriks.rugelis/certs/pgp.htm
Re: Diversity as defense
Agreed, vendor lock in is a very big problem, what the economists would call increasing returns. Interestingly most of the research on the subjest finds that a vendor achieves "lock in" and a dominant market position not by being the most competitive product. Random historical accident, policies, market fluctuations, etc. - i.e. beta vs. vhs or CP/M vs. DOS vs. Apple. Probably getting far off topic here, but if you decreased the ability of vendors to lock in customers (increase competition) could you increase diversity and security at the macro scale. On Mon, 19 Jan 2004 15:35:22 EST, [EMAIL PROTECTED] said: > The diversity, monoculture and agricutlure analogy makes nice press, but how > realistic is diversity as a defense. Well.. if diversity were to actually exist, it would be quite helpful. Right now, if you have a Windows exploit, you might as well point and pull the trigger because you have an 86% chance of nailing the target. Add in a Linux exploit and you're well over 90%. That's Russian Roulette with a 10-shooter and one bullet. On the other hand, let's think about if there were 10 products that each have 10% market share, and even a minimal attempt at deterring fingerprinting of the target, you're looking at a 90% chance that the exploit you launch will fail and leave a nasty mark on an IDS. Suddenly, it's 9 bullets and one blank. And even worse odds if you haven't been picking up all the exploits in the series - or not all the products are vulnerable. Unfortunately, it's not a realistic scenario, because... > Is cost the biggest hurdle or limited > avaiability of competitive products, or simply no bang for the buck by > diversifying. I can sum up *every* problem I've had in getting people to migrate in just 3 words: "vendor lock in". Enough said on that topic.
