Re: DSL Network Design Question
Roy Badami [EMAIL PROTECTED] wrote: [...] Interesting, thanks. TBH, I really don't understand why Cisco have kept the classful support for this long... When a friend was doing a CCNA back in 2003-ish, Cisco were still teaching classful addressing. There was plenty of other misinformation there. Apparently my home network is impossible to build with such few IP addresses. (I use proxy ARP to avoid creating unnecessary subnets of the already too small block I have.) Meanwhile, RIPE's training sessions rap you on the knuckles for using terms like Class C even though in a world of broken stacks from Cisco and Microsoft, you pretty much need to know about it anyway. -- PGP key ID E85DC776 - finger [EMAIL PROTECTED] for full key /:.*posting.google.com.*/HX-Trace:+j
Re: DSL Network Design Question
On Mon, 15 Aug 2005 [EMAIL PROTECTED] wrote: Roy Badami [EMAIL PROTECTED] wrote: [...] Interesting, thanks. TBH, I really don't understand why Cisco have kept the classful support for this long... When a friend was doing a CCNA back in 2003-ish, Cisco were still teaching classful addressing. There was plenty of other misinformation there. Apparently my home network is impossible to build with such few IP addresses. (I use proxy ARP to avoid creating unnecessary subnets of the already too small block I have.) Meanwhile, RIPE's training sessions rap you on the knuckles for using terms like Class C even though in a world of broken stacks from Cisco and Microsoft, you pretty much need to know about it anyway. I recently did the CCNA training courses (Its now broken into two - INTRO-E (As the instructor put it.. Intro 'essentials' means fit a 4 day course into 3 days by stripping or abbreviating that which isn't quite as 'essential) and ICND) and IP Classes are still covered. It was basically a history lesson but it helps newcomers to understand the decision making process behind a lot of the historical network configs and legacy options within IOS. (And how you can theoretically set up an interface without a netmask). I dont see the harm in retaining the terms and the training for historical perspective. As long as its clearly explained. Most especially for those who dont understand that class c != /24 . Mark.
drone armies CC report - July/2005
Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish our regular reports, with some additional information. As of this month, any responsible party that wishes to receive information about botnet CC's in their net space can contact us and be added to our notification list. This month's survey is of 3629 unique domain with port or IP with port suspect CCs. This list is extracted from the BBL which currently has a historical base of 4464 reported CCs. Of the suspect CCs surveyed, 920 reported as Open, 3115 reported as closed and 393 issued resets to the survey instrument. Of the CCs listed by domain name, 2080 are mitigated via remapping. 276 ASNs report one or more open CCs. ASNs with 10 or more unresolved and open suspect CCs: ASNumber Responsible Party Count Open/Unresolved 21840 SAGONET-TPA - Sago Networks 53 34 30058 FDCSERVERS - FDCservers.net LL 65 32 30083 SERVER4YOU - Server4You Inc.41 28 12832 LYCOS-EUROPE Lycos Europe GmbH 31 27 23522 CIT-FOONET - CREATIVE INTERNET 25 23 174 COGENT Cogent/PSI 45 23 13680 AS13680 Hostway Corporation Ta 22 22 6461 MFNX MFN - Metromedia Fiber Ne 23 18 27595 ATRIVO-AS - Atrivo 27 16 15083 INFOLINK-MIA-US - Infolink Inf 19 15 4766 KIXS-AS-KR Korea Telecom41 15 8560 SCHLUND-AS Schlund + Partner A 28 14 27645 ASN-NA-MSG-01 - Managed Soluti 19 12 13237 LAMBDANET-AS European Backbone 15 12 1113 TUGNET Technische Universitaet 12 11 13301 UNITEDCOLO-AS Autonomous Syste 16 11 6939 HURRICANE - Hurricane Electric 12 10 16265 LEASEWEB LEASEWEB AS13 10 21698 NEBRIX-CA - Nebrix Communicati 25 10 Top 10 ASNs by total count: ASNumber Responsible Party Count Open/Unresolved 14742 INTERNAP-BLOCK-4 - Internap Ne118 1 14744 INTERNAP-BLOCK-4 - Internap Ne118 1 25761 STAMINUS-COMM - Staminus Commu69 25 10913 INTERNAP-BLK - Internap Networ67 1 30058 FDCSERVERS - FDCservers.net LL65 32 21840 SAGONET-TPA - Sago Networks 53 34 174 COGENT Cogent/PSI 45 23 4766 KIXS-AS-KR Korea Telecom 41 15 30083 SERVER4YOU - Server4You Inc. 41 28 3356 LEVEL3 Level 3 Communications 37 2 ASNs with 0ne or more open CCs: ASNumber Responsible Party 81CONCERT - MCNC Center of Commu 174 COGENT Cogent/PSI 237 MERIT-AS-14 - Merit Network In 701 ALTERNET-AS - UUNET Technologi 790 EUNETFI EUnet Finland 813 UUNET-AS1 - UUNET Technologies 1113 TUGNET Technische Universitaet 1221 ASN-TELSTRA Telstra Pty Ltd 1239 SPRINTLINK - Sprint 1267 ASN-INFOSTRADA Infostrada S.p. 1659 ERX-TANET-ASN1 Tiawan Academic 1668 AOL-ATDN - AOL Transit Data Ne 1784 GNAPS - Global NAPs Networks 1785 USLEC-ASN-1785 - USLEC Corp. 1955 HBONE-AS HUNGARNET 2042 ERX-JARING Malaysian institute 2108 CARNET-AS Croatian Academic an 2119 TELENOR-NEXTEL Telenor Interne 2501 JPNIC-ASBLOCK-AP JPNIC 2514 JPNIC-ASBLOCK-AP JPNIC 2527 JPNIC-ASBLOCK-AP JPNIC 2828 XO-AS15 - XO Communications 2856 BT-UK-AS BTnet UK Regional net 2907 ERX-SINET-AS National Center f 2914 VERIO - Verio Inc. 3064 AFFINITY-FTL - Affinity Intern 3215 AS3215 France Telecom Transpac 3246 TDCSONG TDC Song 3248 SIL-AT SILVER:SERVER GmbH 3265 XS4ALL-NL XS4ALL 3292 TDC TDC Data Networks 3301 TELIANET-SWEDEN TeliaNet Swede 3307 BANETELE-NORWAY BaneTele AS (f 3313 INET-AS I.NET S.p.A. 3344 KEWLIO-DOT-NET Kewlio.net Limi 3352 TELEFONICA-DATA-ESPANA Interne 3356 LEVEL3 Level 3 Communications 3462 HINET Data Communication Busin 3491 BTN-ASN - Beyond The Network A 3561 SAVVIS - Savvis 3701 NERONET - Oregon Joint Graduat 3758 ERX-SINGNET SingNet 3786 ERX-DACOMNET DACOM Corporation 3801 MISNET - Mikrotec Internet Ser 4134 CHINANET-BACKBONE No.31 Jin-ro 4230 Embratel 4436 AS-NLAYER - nLayer Communicati 4589 EASYNET Easynet Group Plc 4618 INET-TH-AS Internet Thailand C 4628 ASN-PACIFIC-INTERNET-IX Pacifi 4637 REACH Reach Network Border AS 4645 ASN-HKNET-AP HKNet Co. Ltd 4670 HYUNDAI-KR Shinbiro 4713 OCN NTT Communications Corpora 4732 DION KDDI CORPORATION 4766 KIXS-AS-KR Korea Telecom 4780 SEEDNET Digital United Inc. 4812 CHINANET-SH-AP China Telecom ( 4837 CHINA169-BACKBONE
zotob CC servers
Hi guys. Zotob, once infected, connects the machine to a botnet CC (command control) server. Due to the extremely rapid spread of these worms, here is the CC servers information that has been confirmed so far: 62.193.233.52:8080 84.244.7.62:8080 204.13.171.157:8080 62.193.233.4:8080 ASN | IP | Responsible Party --- 12832 | 84.244.7.62 | LYCOS-EUROPE Lycos Europe GmbH 19742 | 204.13.171.157 | MARLIN - Marlin eSourcing Solu 28677 | 62.193.233.52| AMEN AMEN Network 28677 | 62.193.233.4 | AMEN AMEN Network For your information and possible follow-up on your networks. This is spreading too quickly that wider activity is necessary. For comments back to the drone armies botnets research and mitigation mailing list, please go through our new PR team lead, Fergie (Paul Ferguson) [EMAIL PROTECTED]. Gadi.
RE: drone armies CC report - July/2005
[ SNIP ] Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have Serious question. Is this self promotion of IL CERT? -M
Re: zotob CC servers
We haven't seen it yet on our network, but I was hoping somebody might have a text dump or packet capture of the CC traffic that they would be willing to send me so I can tune our IDS to recognize it. I already have exploit rules loaded, just wanted to see if the CC traffic varied significantly from the (relatively) standard *bot variety. Thanks, Michael Grinnell Network Security Administrator The American University e-mail: [EMAIL PROTECTED] On Aug 15, 2005, at 3:13 PM, Gadi Evron wrote: Hi guys. Zotob, once infected, connects the machine to a botnet CC (command control) server. Due to the extremely rapid spread of these worms, here is the CC servers information that has been confirmed so far: 62.193.233.52:8080 84.244.7.62:8080 204.13.171.157:8080 62.193.233.4:8080 ASN | IP | Responsible Party --- 12832 | 84.244.7.62 | LYCOS-EUROPE Lycos Europe GmbH 19742 | 204.13.171.157 | MARLIN - Marlin eSourcing Solu 28677 | 62.193.233.52| AMEN AMEN Network 28677 | 62.193.233.4 | AMEN AMEN Network For your information and possible follow-up on your networks. This is spreading too quickly that wider activity is necessary. For comments back to the drone armies botnets research and mitigation mailing list, please go through our new PR team lead, Fergie (Paul Ferguson) [EMAIL PROTECTED]. Gadi.
zotob - blocking tcp/445
I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works. Gadi.
Re: botnet reporting by AS - what about you?
On Aug 13, 2005, at 12:03 AM, Fergie (Paul Ferguson) wrote: Good suggestions for Gadi. ,-) - ferg -- Christopher L. Morrow [EMAIL PROTECTED] wrote: cool, among the 800k+ complaints we see a month (yes, 800k) there are quite a few completely useless ones :( Anything sent in as a complaint has to have complete and useful information, else it's hard/impossible to action properly. It'd help if the format it was sent in was also machine parseable :) With 800k+ complaints/month I'm not sure people want to spend time figuring each one out, a script/machine should be doing as much as possible. As far as standard reporting goes, please be aware of the existence of the following: http://www.shaftek.org/publications/drafts/abuse-report/
Re: zotob CC servers
Michael Grinnell wrote: We haven't seen it yet on our network, but I was hoping somebody might have a text dump or packet capture of the CC traffic that they would be willing to send me so I can tune our IDS to recognize it.I already have exploit rules loaded, just wanted to see if the CC traffic varied significantly from the (relatively) standard *bot variety. Hi. Any IRC JOIN sig will do, channel is: #niggah Gadi.
Re: zotob - blocking tcp/445
NetBIOS was never meant to be a WAN protocol, so no problem in blocking it. For example: grc.com/su-techzone1.htm scott - Original Message Follows - From: Gadi Evron [EMAIL PROTECTED] To: nanog list nanog@merit.edu Subject: zotob - blocking tcp/445 Date: Mon, 15 Aug 2005 21:51:43 +0200 I heard from several different big ISP's that to stop the spread of the worm they now block tcp/445. I suppose it works. Gadi.
Re: zotob - blocking tcp/445
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem. for we who are under-clued, do you have a url for suggested tools and procedures? thanks! randy
Re: zotob - blocking tcp/445
On (2005-08-15 09:28 -1000), Randy Bush wrote: There are real solutions to the problem, which include monitoring the end-user traffic and do traffic steering for infected hosts to a web page thats helps solving their problem. for we who are under-clued, do you have a url for suggested tools and procedures? www.rommon.com, I'm confident there are others. And some people are using home-baked solutions. Probably plethora (and money) will be one of the bigger problems when deciding to implement this kind of solution. -- ++ytti
Re: zotob - blocking tcp/445
I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html as i just replied to a private message from an enterprise op, o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic o enterprise / site ops can set their users' security policies as that's part of their job and charter randy
RE: drone armies CC report - July/2005
The question of self promotion came back split down the middle. It was noted that IL CERT does a fantastic job seeing that there are no IL networks listed. Or none that are easily identifiable. YMMV. -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations Infrastructure [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gadi Evron Sent: Monday, August 15, 2005 8:22 AM To: nanog@merit.edu Subject: drone armies CC report - July/2005 Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish our regular reports, with some additional information. As of this month, any responsible party that wishes to receive information about botnet CC's in their net space can contact us and be added to our notification list. This month's survey is of 3629 unique domain with port or IP with port suspect CCs. This list is extracted from the BBL which currently has a historical base of 4464 reported CCs. Of the suspect CCs surveyed, 920 reported as Open, 3115 reported as closed and 393 issued resets to the survey instrument. Of the CCs listed by domain name, 2080 are mitigated via remapping. 276 ASNs report one or more open CCs. ASNs with 10 or more unresolved and open suspect CCs: ASNumber Responsible Party Count Open/Unresolved 21840 SAGONET-TPA - Sago Networks 53 34 30058 FDCSERVERS - FDCservers.net LL 65 32 30083 SERVER4YOU - Server4You Inc.41 28 12832 LYCOS-EUROPE Lycos Europe GmbH 31 27 23522 CIT-FOONET - CREATIVE INTERNET 25 23 174 COGENT Cogent/PSI 45 23 13680 AS13680 Hostway Corporation Ta 22 22 6461 MFNX MFN - Metromedia Fiber Ne 23 18 27595 ATRIVO-AS - Atrivo 27 16 15083 INFOLINK-MIA-US - Infolink Inf 19 15 4766 KIXS-AS-KR Korea Telecom41 15 8560 SCHLUND-AS Schlund + Partner A 28 14 27645 ASN-NA-MSG-01 - Managed Soluti 19 12 13237 LAMBDANET-AS European Backbone 15 12 1113 TUGNET Technische Universitaet 12 11 13301 UNITEDCOLO-AS Autonomous Syste 16 11 6939 HURRICANE - Hurricane Electric 12 10 16265 LEASEWEB LEASEWEB AS13 10 21698 NEBRIX-CA - Nebrix Communicati 25 10 Top 10 ASNs by total count: ASNumber Responsible Party Count Open/Unresolved 14742 INTERNAP-BLOCK-4 - Internap Ne118 1 14744 INTERNAP-BLOCK-4 - Internap Ne118 1 25761 STAMINUS-COMM - Staminus Commu69 25 10913 INTERNAP-BLK - Internap Networ67 1 30058 FDCSERVERS - FDCservers.net LL65 32 21840 SAGONET-TPA - Sago Networks 53 34 174 COGENT Cogent/PSI 45 23 4766 KIXS-AS-KR Korea Telecom 41 15 30083 SERVER4YOU - Server4You Inc. 41 28 3356 LEVEL3 Level 3 Communications 37 2 ASNs with 0ne or more open CCs: ASNumber Responsible Party 81CONCERT - MCNC Center of Commu 174 COGENT Cogent/PSI 237 MERIT-AS-14 - Merit Network In 701 ALTERNET-AS - UUNET Technologi 790 EUNETFI EUnet Finland 813 UUNET-AS1 - UUNET Technologies 1113 TUGNET Technische Universitaet 1221 ASN-TELSTRA Telstra Pty Ltd 1239 SPRINTLINK - Sprint 1267 ASN-INFOSTRADA Infostrada S.p. 1659 ERX-TANET-ASN1 Tiawan Academic 1668 AOL-ATDN - AOL Transit Data Ne 1784 GNAPS - Global NAPs Networks 1785 USLEC-ASN-1785 - USLEC Corp. 1955 HBONE-AS HUNGARNET 2042 ERX-JARING Malaysian institute 2108 CARNET-AS Croatian Academic an 2119 TELENOR-NEXTEL Telenor Interne 2501 JPNIC-ASBLOCK-AP JPNIC 2514 JPNIC-ASBLOCK-AP JPNIC 2527 JPNIC-ASBLOCK-AP JPNIC 2828 XO-AS15 - XO Communications 2856 BT-UK-AS BTnet UK Regional net 2907 ERX-SINET-AS National Center f 2914 VERIO - Verio Inc. 3064 AFFINITY-FTL - Affinity Intern 3215 AS3215 France Telecom Transpac 3246 TDCSONG TDC Song 3248 SIL-AT SILVER:SERVER GmbH 3265 XS4ALL-NL XS4ALL 3292 TDC TDC Data Networks 3301 TELIANET-SWEDEN TeliaNet Swede 3307 BANETELE-NORWAY BaneTele AS (f 3313 INET-AS I.NET S.p.A. 3344 KEWLIO-DOT-NET Kewlio.net Limi 3352 TELEFONICA-DATA-ESPANA Interne 3356 LEVEL3 Level 3 Communications 3462 HINET Data Communication Busin 3491 BTN-ASN -
RE: drone armies CC report - July/2005
Going further I think IL-CERT is doing a great service to the Internet community. Their alerts allow to responsible network admins to investigate and to preserve their networks clean of debris like spyware and trojans. Do what you want with your networks, but PLEASE keep the Internet clean. Abraços, Marlon Borba, CISSP. -- Nova campanha: Centro de Resposta a Incidentes de Segurança da Justiça Federal - Vamos criar! -- Hannigan, Martin [EMAIL PROTECTED] 08/15/05 6:05 PM The question of self promotion came back split down the middle. It was noted that IL CERT does a fantastic job seeing that there are no IL networks listed. Or none that are easily identifiable. [...]
RE: drone armies CC report - July/2005
Going further I think IL-CERT is doing a great service to the Internet community. Their alerts allow to responsible network admins to investigate and to preserve their networks clean of debris like spyware and trojans. The point is that aged data is an eternity when you're talking about botnets, worms, zombies, c/c's, etc which is what made me wonder why it was being posted in the first step. A month is a long time in botland. Yes, I'm all for clean networks. Yes, IL CERT does as good a job as any CERT, I'm sure. -M
Re: zotob - blocking tcp/445
Chris, This isn't directed at you, just adding my 2 cents to the thread ... On Aug 15, 2005, at 3:29 PM, Christopher L. Morrow wrote: On Mon, 15 Aug 2005, [EMAIL PROTECTED] wrote: NetBIOS was never meant to be a WAN protocol, so no problem in blocking it. rule #1: do not be the Internet's Firewall rule #2: see rule #1 That should definitely be on a T-shirt. :-) a leaf network can make any decisions they want on traffic filtering, large ISP's should probably not do this as there are invariably people out there that will want SNMP/ICMP/NetBIOS/SQL-NameService to work over their WAN link(S). I recall some 'fun' with this issue on: 1) slammer worm (ms has a developers thingy that REQUIRES 1434 to work over the internet) 2) welchia/nachi - how can I ping monitor my remote sites? ymmv. Leaf network filtering (or not) is largely solved. Keep in mind, some SP's sell Managed Security Services, which may be PE- or CE- based firewalls, but run by the SP on behalf of the customer. If the customer cares enough, then ask and/or pay the SP to block the traffic they don't want, only on their access circuit(s). Presumably, the SP will figure out a model for the service to both instantiate and maintain the filter(s) as well as recoup costs for backhauled bits that get dropped at, or near, the doorstep of the CE. (Note, the word model could mean an additional charge above beyond basic access or it may be included as part of basic access -- it all depends on how much work, sophistication in filtering, etc. occurs as well as what the market can bear). In this case, one size (a.k.a.: filtering) does not (easily) fit all ... -shane
Re: zotob - blocking tcp/445
On Mon, 15 Aug 2005, Daniel Golding wrote: On 8/15/05 4:46 PM, Randy Bush [EMAIL PROTECTED] wrote: I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html as i just replied to a private message from an enterprise op, o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic While its not uncommon to run SMB/Windows file system drive mounts across private WANs, doing so across the Internet, on a non-encrypted tunnel, is the equivalent of running with scissors. no one was arguing that... just like no one argues that riding a motorcycle sans-helmet is stupid (or playing hockey without a helmet) I am unaware of any enterprise security folks foolish enough to allow that. Of course, I may be sheltered. 'enterprise security folks' are probably not the issue... The fact remains that lots of folks DO do this :( There are quite a few folks between 'consumer' and 'enterprise' that do all manner of dumb things on the Internet (where 'dumb' is equivalent to running smb shares across the public network minus encryption/ipsec). It's their choice to do that, and their network providers are expected/demanded to pass those packets for them. -Chris
Re: zotob - blocking tcp/445
While its not uncommon to run SMB/Windows file system drive mounts across private WANs, doing so across the Internet, on a non-encrypted tunnel, is the equivalent of running with scissors. yep. agree. but, as it does not damage the track, and only opens the runner to harm, as the track maintainer, it's not mine to legislate against it. I am unaware of any enterprise security folks foolish enough to allow that. i suspect there are risk-takers and fools out there and we just happen not to know them. randy
Re: drone armies CC report - July/2005
Going further I think IL-CERT is doing a great service to the Internet community. Their alerts allow to responsible network admins to investigate and to preserve their networks clean of debris like spyware and trojans. The point is that aged data is an eternity when you're talking about botnets, worms, zombies, c/c's, etc which is what made me wonder why it was being posted in the first step. A month is a long time in botland. while i'm not the one posting it, i do see these summaries and i also see much of the raw data that's being summarized, in real time, as it's found and shared. AS owners/operators who want to get the data in real time have already been told to send [EMAIL PROTECTED] some e-mail asking for it. the summaries are primarily useful for CC's that are still alive a month later even though plenty of notices have been sent to the relevant NOC's. in other words it's sort of like defcon's wall of sheep. i like the approach. -- Paul Vixie
RE: zotob - blocking tcp/445
'enterprise security folks' are probably not the issue... The fact remains that lots of folks DO do this :( There are quite a few folks between 'consumer' and 'enterprise' that do all manner of dumb things on the Internet (where 'dumb' is equivalent to running smb shares across the public network minus encryption/ipsec). It's their choice to do that, and their network providers are expected/demanded to pass those packets for them. -Chris Surely the ratio of 'useful' traffic compared to 'junk' for a particular protocol must be considered. What percentage of netbios entering a service provider's edge is intentional? 1%? 0.1%? I'm guessing much less than that. If 5 or 6 nines worth of a particular protocol entering or leaving an ISP's network is unintentional, and highly susceptible to viral activity, isn't it in our best interest to block it? With proper notification to subscribers and instructions on setting up host-to-host PPTP/whatever, blocking netbios can solve a large bunch of issues Just my .02 though, Chuck
RE: zotob - blocking tcp/445
On Mon, 15 Aug 2005, Church, Chuck wrote: 'enterprise security folks' are probably not the issue... The fact remains that lots of folks DO do this :( There are quite a few folks between 'consumer' and 'enterprise' that do all manner of dumb things on the Internet (where 'dumb' is equivalent to running smb shares across the public network minus encryption/ipsec). It's their choice to do that, and their network providers are expected/demanded to pass those packets for them. -Chris Surely the ratio of 'useful' traffic compared to 'junk' for a particular protocol must be considered. What percentage of netbios entering a on your piece of the network you can consider the ratio of pigs to birds, or good to bad traffic or phases of the moon, it's your network do what you will. I can say that if you have a vocal enough customer the blocks won't last very long, or the customer will find another network to connect to... service provider's edge is intentional? 1%? 0.1%? I'm guessing much less than that. If 5 or 6 nines worth of a particular protocol entering or leaving an ISP's network is unintentional, and highly susceptible to viral activity, isn't it in our best interest to block it? With proper your best interest might be to do that sure... 'your network, your call'. notification to subscribers and instructions on setting up host-to-host PPTP/whatever, blocking netbios can solve a large bunch of issues please send my instructions for host-to-host pptp that my grandmother can follow without help of techsupport.
Re: drone armies CC report - July/2005
MARLON BORBA wrote: Going further I think IL-CERT is doing a great service to the Internet community. Their alerts allow to responsible network admins to investigate and to preserve their networks clean of debris like spyware and trojans. Do what you want with your networks, but PLEASE keep the Internet clean. Thanks for the compliments, Marlon, but this service is unrelated to the Israeli CERT, as stated. :) The people behind the drone armies list are net-ops guys who care, just like you. With AV-ers, researchers, and other vetted individuals. Gadi.
RE: drone armies CC report - July/2005
the summaries are primarily useful for CC's that are still alive a month later even though plenty of notices have been sent to the relevant NOC's. in other words it's sort of like defcon's wall of sheep. i like the approach. Wall of sheep certainly is humorous, but IL CERT using this data as a shaming mechanism is, well, a shame. Once the NOC engages in an excercise of futility based on that list, it will never be read again and the effort ends up being more futile, which is another shame. It's a good project, but it got ripe before it was ready, IMO. BTW, are you vouching for the report?
Re: zotob - blocking tcp/445
On Tue, 16 Aug 2005, Gadi Evron wrote: Randy Bush wrote: I'm not nearly confident enough to decide on behalf of almost billion other people how they should benefit from the Internet and how not to. thanks for that! Indeed. Also see http://www.iab.org/documents/docs/2003-10-18-edge-filters.html as i just replied to a private message from an enterprise op, o backbone isps can not set their customers' security policy - some customers want to run billyware shares over the wan whether we advise it or not - some of us host security researchers, who have a taste for 445 and other nasty traffic o enterprise / site ops can set their users' security policies as that's part of their job and charter randy I actually agree with you Chris and Steven. Point is though, that in a HUGE outbreak - sometimes you might even have to cause a self-DDoS and kill some of your services to parts of your networks or at all, to keep your net alive, not to mention secure. This decision (to block port X or not in a large outbreak) is still a network by network decision... Smaller or 'more tightly bound' networks might have an easier time making that call, I'd bet that almost all of the very large networks will look at each case and come to the same conclusion: 1) our network isn't affected by this problem 2) our customers will be affected by a block 3) our customers should deal with security on their own, unless they are paying for service which includes said blocking. As immediate critical measures, blocking tcp/445 might be an acceptable solution. Nobody is talking about censoring the Internet. see above. and recall that there were several respondents to this thread that were talking exactly about blocking tcp/445 to their customers, or on their network, which is censoring. The distinction Randy, and I and Steve, are making is that: 1) each network should decide on their own 2) each person deciding should understand the ramifications of that decision 3) each person deciding should keep in mind that they might not understand all of their customers requirements for traffic. I believe that blocking port 445 is Good, just like I believe it will not get done by most and for Good reasons. 'good' 'in the right situation' which isn't 'across the network as a whole'. Oh, do the current spate of tcp/445 problems also exist in the new netbios of tcp/80 incarnations MS has cooked up? I'd venture to guess they probably do... wanna block tcp/80 as well? :) Every solution has its good applications - sometimes short-term, even Bad long term solutions. Thing is, how do they remain temporary rather than becoming perm.? This last sentence is a long and hard learned lesson :) Once you block port X and people figure that out, they expect you to always block port X. They drop their guard and focus on other problems, they have a new 'firewall' :( it's you. From the Slammer incident we learned that blocking 1434 for even a short period of time made people complaicant. They didn't patch their broken servers/systems until we unblocked the traffic and they got re-infected again :( Do not become the internet firewall for your large customer base... it's bad.
Re: zotob - blocking tcp/445
On Tue, 16 Aug 2005 [EMAIL PROTECTED] wrote: On Mon, 15 Aug 2005 20:05:30 MDT, Shane Amante said: Leaf network filtering (or not) is largely solved. Ahem. :) If this was a solved problem, we'd not be having a thread about a zotob worm. thank you.
Re: zotob - blocking tcp/445
On Mon, 15 Aug 2005 20:05:30 MDT, Shane Amante said: Leaf network filtering (or not) is largely solved. Ahem. :) If this was a solved problem, we'd not be having a thread about a zotob worm. There's a *very* large gap between the clued know of a range of suitable solutions and the great unwashed have deployed appropriate solutions. pgpcensqsvB4C.pgp Description: PGP signature
Re: zotob CC servers
Michael Grinnell wrote: We haven't seen it yet on our network, but I was hoping somebody might have a text dump or packet capture of the CC traffic that they would be willing to send me so I can tune our IDS to recognize it.I already have exploit rules loaded, just wanted to see if the CC traffic varied significantly from the (relatively) standard *bot variety. Matt just got some signatures together: http://www.bleedingsnort.com/article.php?story=20050814131513212 Enjoy, Gadi.
Re: zotob - blocking tcp/445
[snip arguments] Do not become the internet firewall for your large customer base... it's bad. Okay, so please allow me to alter the argument a bit. Say we agreed on: 1. Security is THEIR (customers') problems, not yours. 2. You are not the Internet's firewall. That would mean you would still care about: 1. You being able to provide service. 2. Your own network being secure (?) In a big outbreak, not for the WHOLE Internet, I'd use whatever I can. It can easily become an issue of my network staying alive. Blocking that one port then might be a viable solution to get a handle on things and calm things down. Naturally though you are right again, it is a case-by-case issue and can not be discussed in generalities. Gadi.
Re: drone armies CC report - July/2005
On Aug 15, 2005, at 9:39 PM, Hannigan, Martin wrote: the summaries are primarily useful for CC's that are still alive a month later even though plenty of notices have been sent to the relevant NOC's. in other words it's sort of like defcon's wall of sheep. i like the approach. Wall of sheep certainly is humorous, but IL CERT using this data as a shaming mechanism is, well, a shame. Why you associate IL CERT with this is confusing to others. I am confident that you know there is little or no connection. We all have employers. You, me and Gadi included. ;-) Many of us choose to work to make the Internet a better place or at least make it as safe as it were before we signed on. I don't like having to worry about my mom being phished or my sisters' laptop taking part in a global botnet. If this kind of work falls within the guidelines of our employment; great. If not; that's why there are groups like this. For purely operational activities there are lists and fora to foster that. This is different. This is about turning the tide and not simply reacting and mitigating after the fact. I certainly don't speak for Gadi or the group so I'll stop there. Once the NOC engages in an excercise of futility based on that list, it will never be read again and the effort ends up being more futile, which is another shame. It's a good project, but it got ripe before it was ready, IMO. There was nothing actionable in the list posted. Any NOC that engages in anything besides a request to be notified in the future would be confounding. Thanks, David
