- Test - lists.nanog.org

Re: Firewall stateful handling of ICMP packets
by Jamie Reid 04 Dec '03

04 Dec '03

Personal view: This was a problem when filtering Nachi while it pinged networks to their knees. Sometimes I wonder if there is any legitimate reason to allow pings from users at all. If the user really needed to use ping, that is, if they were in a position to do anything about the results of the ping tests, then they would know enough to use traceroute in UDP mode or some other tool. There are lots of other useful ICMP types to handle all the other ICMP needs, but ping seems to be something that was created for the convenience of a kind of user that is effectively extinct in todays Internet. ICMP echo is unique among ICMP types in that it is the only one that elicits it's own response. What I mean by this is that source-quench, <foo>-unreachables, and others are all generated by hosts and routers in response to relatively stateful traffic. There is nothing that echos do that SNMP (I know, I know) and traceroute don't accomplish in a more controlled fashion, no? It would kill alot of DDoS attacks and render their zombie networks useless, retire legacy backdoors and viruses, up the ante for network management tools, and slow down some virus propagation substantially. ICMP echos are a bit of a hack and, quite literally, noise, and I wonder if it may be time to consider unofficially retiring them using filters. -- Jamie.Reid, CISSP, jamie.reid(a)mbs.gov.on.ca Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 >>> "Sean Donelan" <sean(a)donelan.com> 12/03/03 05:12pm >>> You could drop ICMP packets at your firewall if the firewalls properly implemented stateful inspection of ICMP packets. The problem is few firewalls include ICMP responses in their statefull analysis. So you are left with two bad choices, permit "all" ICMP packets or deny "all" ICMP packets.

9 10

Re: new nasty email virus trick to bypass scanners
by Mike Tancsa 04 Dec '03

04 Dec '03

At 09:53 PM 03/12/2003, Jamie Reid wrote: >If an attacker can convince a user to do anything, all bets >are off. > >It is conceptually similar to using SSL to evade a network IDS. > >This is also an intrusion test trick. As system owners, there >is only so much we can do to prevent and detect compromises. >What matters is how we respond. True enough. However, we also have to protect naive and vulnerable users to some degree. Think about elderly folk. They are not necessarily as quick to spot the scam. The ability to stop the virus before it gets to them is important. The other thing that worries me is that those who rely on their ISP to scan for viruses, a false sense of security can come into play. In the case of these types of email viruses, the user might think the file is OK because it was scanned. ---Mike

6 5

Re: AOL rejecting mail from IP's w/o reverse DNS ?
by Michael.Dillon＠radianz.com 04 Dec '03

04 Dec '03

>the whole blocking w/o IN PTR >records had come up, Interestingly, there was a time when access to FTP servers was considered important and many FTP servers blocked access if the IN PTR records did not match the IN A records. >with people saying they were on hosting where they >couldn't change PTR records, and the clients who couldn't get mail from >small offices with Exchange servers on DSL lines where the ISP hadn't >configured reverse DNS. Sometimes SMTP relaying is good. If your ISP has good reason to not configure matching IN PTR records for your mail server then ask them to relay all your outgoing SMTP. The end result is the same; you won't be able to set up a working SMTP server without your ISP's cooperation. > Then there was the comment on how reverse DNS was >meaningless, and did you still run identd ? It's not the reverse DNS itself that is meaningful. It is the fact that the SMTP server operator with proper IN PTR records probably has the cooperation of their ISP. Proper configuration of in-addr.arpa is a "good idea" TM. However, it isn't the right way for large mail server operators to go. Instead, they should start exchanging their SMTP sessions on a port other than 25, i.e. NIMTP (New Improved MTP). The NIMTP servers would not accept incoming connections from unknown servers. In order to join the club, you would have to certify that you will only send mail from known senders or relay mail from organizations which will make the same certification. In this way, we create an overlay mail transport network in which the members have some sort of one-to-one mail peering relationship that allows them to enforce an AUP on each other as well as maintain good contact info. Peering relationships work for BGP (lots of rules) and they worked for USENET (not many rules). Why can't the same principles be applied to email or IM services? --Michael Dillon

4 3

RE: MTU path discovery and IPSec
by Arjan Hulsebos 04 Dec '03

04 Dec '03

> On Wed, 03 Dec 2003 16:05:39 GMT, jgraun(a)comcast.net said: > > > 1) I assume MTU path discovery has to been in enabled on > each router in the path in order for it work correctly?! > > Actually, no. All that's required is that: You also need an OS that does not set the DF-bit on every packet it sends out. IIRC, out-of-the-box Solaris 8 is excellent at doing that. No matter how many icmp messages it gets, it happily ignores them by insisting on sending out frames of 1500 bytes with the DF-bit set. Makes trouble-shooting IPSec connections, uhm.... interesting. Cheers, Arjan H --- This message is confidential and may be privileged. Any review, retransmission, dissemination or other use of, or taking any action with reference to this information by persons other than the intended recipient is prohibited. If you received this message in error, please notify the sender by reply e-mail and delete this message from all computers. Please note that e-mails are susceptible to change. The sender will not accept liability for the improper or incomplete transmission of the information contained in this message.

1 0

Re: [Re: Firewall stateful handling of ICMP packets]
by joshua sahala 04 Dec '03

04 Dec '03

Sean Donelan <sean(a)donelan.com> wrote: > > Did news stories about this get other people in New Zealand to fix their > computers, apply patches, use anti-virus? Or were were lots of stories > about the "evil" telco ruining grandmothers and orphans? and the telco > eventually waived the charges? probably a little of each - and each will likely be temporary. users will keep updated for the near-term, and telcos/isps might waive charges. however, relying on either will lead to further problems (as we have seen, and will continue to see). > Toll charges do encourage PBX owners and cordless phone makers to > improve the security of their products? Most cordless phones (unlike > WiFi) now have automatic authentication between the handset and base > (not encryption, just authentication). Most PBX's block outside to > outside phone connections (the telephone version of proxy/relay) by > default now. enough pain will eventually cause a change (and/or a higher pain tolerance). so far, pain tolerance by most users is rising, but not much is changing. users are still ignorant as to what is wrong or how to fix it (as you have pointed out to me in previous emails), no matter how many news stories there are, or how many 'helpful' emails are sent by isps or manufacturers. > If ISPs charged customers $0.000001/email message, would it cure spam > or would the spammers just continue to use third-party victims to spam > and there would be lots of news stories about grandmothers and orphans > getting huge ISP bills? IANAL, but many spammers are already breaking > a law by using victim machines without authorization; but would law > enforcement be more likely to do something if the victims now had a > $50,000 bill from their ISP due to the unauthorized traffic? it still comes down to figuring out who is doing it, and then getting enough evidence to 'stop' them. even the ones we know are spammers have gotten pretty good at using fronts for their operations: and when you have tens-of-thousands of vulnerable computers with 'fast' connections, you don't have to try very hard. we keep beating this same horse from different angles and hoping for different results. unless someone out there has a crystal ball and can predict the next exploit (and then magically fix it), we will beat it again next week...so until then, i am off to remind my less clueful friends and family members, again, not to apply the 'newest security patch' email from foo(a)microsoft.com (not even worth $0.02 today) /joshua "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

Standard/recommended formats for network information
by Bruno Quoitin 04 Dec '03

04 Dec '03

Looking for advice. I would like to know if there are standard or widely used file formats to represent the following information: * intradomain topology (including IGP costs, bandwidths, delays, SRLG) * BGP peerings * traffic matrices Thanks in advance Bruno -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~bqu

1 0

Re: new nasty email virus trick to bypass scanners
by Damian Gerow 04 Dec '03

04 Dec '03

On Wed, 3 Dec 2003, Steven M. Bellovin wrote: > Is this in the wild yet? Any other details worth looking for? > Symantec's AV site apparently has nothing on it. I would say so - I got it in my inbox earlier this afternoon, and I traditionally get about three viruses a month. The virus itself is *exactly* like Mmimail.M, as reported by Symantec. Except that wendy.zip was definitely password protected. - Damian

2 1

new nasty email virus trick to bypass scanners
by Mike Tancsa 04 Dec '03

04 Dec '03

OK, here is a nasty virus trick. The message gets sent in a password protected zip file. The text of the messages says here are my pics and enter in the passwd xxxx to view the archive. The big problem is that normal avscanners cannot open the zip file to scan the contents since it is password protected. However, the user can be easily socially engineered to open the file and blam. The text of the message is nice and enticing making it look like private email with dirty pictures accidentally sent to the user... ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

2 1

Re: new nasty email virus trick to bypass scanners
by J. Oquendoy 04 Dec '03

04 Dec '03

> However, the user can be easily socially engineered to open the file and > blam. The text of the message is nice and enticing making it look like > private email with dirty pictures accidentally sent to the user... <opinion> Someone should create some form of standard 'README' document for the layperson using the internet in regards to viruses, maybe template it and send it to ISP's, so when new users sign up, they'll have a `slight' clue as to why they're now getting those "RPC WARNING YOUR COMPUTER WILL SHUT DOWN IN 60 SECOND" messages. Then again many people wouldn't read it, unless of course an ISP stated something silly to the extent that 'You will be held responsible* * *", of which would be a horrible policy. It would be a nice thing for both the user, and the network engineers/admins to have something in place to minizmize the reach of viruses and trojans. Hell it would have been nice for MS to invest in creating safer products as opposed to paying `bounty hunters'. </opinion> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D sil @ politrix . org http://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net "I watch gangster flicks and root for the bad guy and turn it off before it ends because the bad guy dies" 50 Cents - 'Assassins' This is a farce confidential disclaimer intended to make you aware that even though this may be priveledged information, being it will become Google cache in the future, my original intentions of keeping this message restricted and/or private are thrown out the door. If you have received this e-mail in error, please enjoy this signature and destroy this message by dousing it in gasoline.

2 1

Re: Does any know where the link is for
by Richard Irving 04 Dec '03

04 Dec '03

John Starta wrote: > If you locate this, please forward the link along. I haven't found the original, it was dated about 97-99... NLANR, perhaps ???? But, there are more recent write ups... Here are two I encountered: <http://www.inetdaemon.com/tools/ping_is_not.html> This one explains why PING -may- be bad, but regular performance, OK... (Call it the end user explanation of ACL-CAR intervention) :) And this one,( more what I was looking for..) a detailed explanation of the caveats of clever tracerouting providing Bogus Data. <http://homepage.ntlworld.com/robin.d.h.walker/cmtips/traceroute.html> I needed something for a rookie tech who was "whining" about a site tracerouting with an intervening router - appearing - slow (An exchange BGP router, go figure), but an end to end of -38 ms-, -consistent- and with -no- loss. He didn't believe the explanation of the BGP rumble... and I was growing frustrated with the need for detail, when it just wasn't registering ! :( "When the Judge is a blind man, it can be -exasperating- trying defend your choice of the Winner of the Art fair." :P

1 1