- Test - lists.nanog.org

Despamming wholesale dialup
by Harold Willison 02 Nov '98

02 Nov '98

Greetings, Let me explain the situation and see if I can get anyone to tell me how they are handling it. We are offering wholesale dialup ports. When a user connects he is authenticated and can do whatever it is he/she wants to do on the net. Unfortuantely some have decided that they will relay spam off of other servers. To address this i have proposed installing filters that will only allow these folks to connect to port 25 of the ISP that has bought the ports. This way they are not able to relay off of anyone elses machine that is using port 25 and the buyer of the ports should have the correct measures set up to prevent bulk mail from going out. Will this be sufficient, providing that the server they are allowed to connect to has set up his mail server to prevent massmailing..? Suggestions/comments? *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* | Harold Willison AGIS Network Engineering | * Senior Network Engineer 313-730-5151 * | noc(a)agis.net 313-730-1130 x-5649 | | harold(a)agis.net 24 hours a day, 7 days a week | | <bold><italic> <underline>http://www.agis.net</underline></italic></bold> |<bold><italic> </italic></bold>\*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

7 11

routing table in backbone router
by Yixin Jin 02 Nov '98

02 Nov '98

Hi, Does anybody know where I can get routing tables used in backbone routers? I'd like to see how address prefixes look like and don't care about AS. Thanks in advance. Yixin Jin UCLA, Computer Science Dept.

1 0

Re: Rootshell pages hacked
by John Hawkinson 02 Nov '98

02 Nov '98

This thread has the typical "useless thread on NANOG" problem. It attepts to be tangentially relevent but really it just is not. Certainly, the initial thought -- to communicate that www.rootshell.com was compromised -- was not relevent to north american network operators. Next, a discussion of what it means to be secure, and of course this wasn't relevent for NANOG either, but some well-meaning competant individuals got roped in, presumably in the hope that the discussion would terminate. After all, a little bit of off-topic discussion is fine and useful -- if we tried to find the right mailing list for absolutely *everything*, no one would ever get anything done. But we went long past that point. Discussion of compromises in application programs (ssh), even ones widely used in the network community, is not very appropriate for NANOG either. We could discuss compromises every time Sun released a security patch, or every time rootshell.com posted an exploit -- we'd have more traffic than bugtraq (not hard, it's a moderated list...)! The latest stuff about ftping through SSH tunnels just kicks the bucket even further, beneath the lower standard of conduct to which some of us hold NANOG (because the community seems to be comprised of a more-childish and less-responsible set of individuals than most other communities, so it's foolhardy to try and hold it to high standards). Please try not to dignify any of the traffic in this thread with a reply. If you really feel that your commentary is useful and relevent, please direct it to the authors in private email. Similarly, if you feel a burning need to know the resolution of an issue raised by some individual, please send them private email and I'm sure they'll be happy to forward you the relevent discourse they've received, or direct you to a venue more suited for the discussion. I, for one, am disgusted, but you already knew that. --jhawk

1 0

Re: Rootshell pages hacked
by Adam D. McKenna 02 Nov '98

02 Nov '98

scp user@fromhost:file user@tohost:file Enter passphrase for RSA key: :) The coolest thing about scp is that you don't have to be ON fromhost to copy files between it and tohost. If passwords or RSA authentication passphrases are needed you will be prompted for them by scp. It's also interesting to note that there is no unix password needed for ssh with RSA auth. Your password field in /etc/shadow can be "*" or "!" or whatever your particular OS uses to signify an account which has a locked password. --Adam -----Original Message----- From: Adam Rothschild <asr(a)millburn.net> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, November 02, 1998 10:05 AM Subject: Re: Rootshell pages hacked On Mon, 2 Nov 1998, Alex P. Rudnev wrote: > problem, UNIX one-time passwords are real problem. Another bad problem is > _the same UNIX password for all purposes_ - I can sniff your FTP password > and use it for SSH access (for example). Very true. Then again, FTP'ing in cleartext is kinda stupid in and of itself. Why not just FTP thru an SSH tunnel? Or, if you're up for an adventure (and a not-totally-complete(TM) spec), try the secure file xfer stuff in SSH2...

1 0

Re: Despamming wholesale dialup
by Scott Gifford 02 Nov '98

02 Nov '98

>> To address this i have proposed installing filters that will only allow >these >> folks to connect to >> port 25 of the ISP that has bought the ports. This way they are not able to >> relay off of anyone elses machine > > >The problem is for companies like ours that live by selling mail acounts to >users of other ISPs. They need POP and SMTP access to our mail servers, from >whereever they are calling. We are running sendmail v8.9.1 with all the >anti-relay stuff and RBL besides. The problem you have is the same one we have >for secured SMTP, maybe easier. How do you tell the site is secure? In this >case testing for open relays is well known. > >What I really suggest, and this takes some work on your part, is to contact >the >site's admin and inform them of their open-relay status. If they won't close >the relay, block them. Alternatively, you can assume that if they haven't >gotten their relays closed by now they are too clue-less to do so and block >them immediately, with notification. The problem is when the spam-bastard isn't relaying. We've been getting thousands of messages every week from spammers who buy dialup from various places, then connect directly to the destination mail server to deliver the mail. That's what this prevents. I don't know of any other method that does. An interesting answer to the problem you discussed above was suggested by somebody from the EFF at a spam BOF at USENIX this summer. He suggested that by default, you filter on port 25. But if somebody needs access for legitimate reasons, or even if they don't, have a letter they can fill out, sign, and send in which states that they will not send spam, subject to a $500/message penalty. Then if they do, just bill them. An alternative for you would be to run a mail server on a different port... -------Scott.

11 15

Important information about IBM-ERS' "ssh" advisory
by David A. Curry 02 Nov '98

02 Nov '98

-----BEGIN PGP SIGNED MESSAGE----- On Friday, Oct. 30th, IBM-ERS sent out a draft advisory to be released on Monday, Nov. 2nd that described a buffer overflow condition in Version 1.2.x "sshd." This draft was sent to the Forum of Incident Response and Security Teams, and also to the "ssh-bugs" list for their comment/review. The draft was identified as ERS-SVA-E01-1998:005.1. Rootshell has unfortunately chosen to include a copy of this draft advisory in their recent newsletter, apparently for the purposes of defending itself against charges that it was unfairly disparaging "sshd." Use of IBM-ERS's draft advisory in this manner was not approved or authorized by IBM-ERS, and does a disservice to all. Here are the facts about this advisory: 1. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was never issued publicly by IBM. 2. In response to a telephone query from Kit Knox of Rootshell, IBM-ERS attempted to contact Kit on Friday evening, and was unable to reach him. Specific contact information for IBM-ERS, as well as a brief status update, were left on Mr. Knox's voice mail. Mr. Knox never contacted IBM-ERS after that time. 3. IBM has been working closely with Tatu Ylonen, author of "ssh," to make sure that the potential vulnerability described in the advisory is not exploitable. Upon further investigation, the problem originally described appears to have been influenced by outside factors and does not appear to be an exploitable problem in "sshd." 4. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was CANCELLED on the morning of Sunday, Nov. 1st, *before* Mr. Knox issued his newsletter. 5. At this time, IBM-ERS has NO KNOWLEDGE of any security vulnerabilities, exploitable or otherwise, in the "sshd" program. We hope that this clarifies IBM's involvement in this situation. - --------------------------------------------------------------------------- The information in this document is provided as a service to customers of the IBM Emergency Response Service. Neither International Business Machines Corporation, nor any of its employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, complete- ness, or usefulness of any information, apparatus, product, or process contained herein, or represents that its use would not infringe any privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by IBM or its subsidiaries. The views and opinions of authors expressed herein do not necessarily state or reflect those of IBM or its subsidiaries, and may not be used for advertising or product endorsement purposes. -----BEGIN PGP SIGNATURE----- Version: 2.7.1 iQCVAwUBNj12ufWDLGpfj4rlAQGbNAQAhxLTKJh8H0s9uS0KbUVO3IxjfAYrcSuf TTpwZjQ3qciBr+8+LVU/WIk4OLGX7WLl2ZLqisUzNkBra4k0xPd2vKbKp6Pfd+6o DlNwfiwpty1wzPD/7eiu4xclHt0emMpDC6QMkJldk4/lv7iQmPltpeXdGqRVYja8 fXtGXZO90UM= =hlDX -----END PGP SIGNATURE-----

1 0

Linux router (don't laugh) WAS:Re: test
by John Fraizer 02 Nov '98

02 Nov '98

Routing 3 /24's and a /26 using 3 3c905's. eth0 goes to the cisco->world. eth1, eth1:0 and eth1:1 go to an ethernet switch that is serving machines from the three /24's. eth2 goes to a hub for one of our co-location clients. Attached is an mrtg graph from someone decided to throw about 8MB of garbage our way for a few hours. This little linux router just sat there and idled through it. [root@core0-eth0]:~ # /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface Gateway-NET * 255.255.255.252 U 0 0 5 eth0 EZone-CoLo-2xx- * 255.255.255.192 U 0 0 97 eth2 2xx.xx.2xx.0 * 255.255.255.0 U 0 0 6189 eth1 xx6.28.xx.0 * 255.255.255.0 U 0 0 17 eth1:0 xx9.201.1x8.0 * 255.255.255.0 U 0 0 27 eth1:1 loopback * 255.0.0.0 U 0 0 0 lo default core1-eth0-Ente 0.0.0.0 UG 1 0 286496 eth0 [root@core0-eth0]:~ # /sbin/ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth0 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.1xx.xx7.xx Bcast:2xx.1xx.xx7.xx Mask:255.255.255.252 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:27965989 errors:0 dropped:0 overruns:0 frame:0 TX packets:60325424 errors:0 dropped:0 overruns:0 carrier:0 coll:81 Interrupt:11 Base address:0x6100 eth1 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.4x.xx4.1 Bcast:2xx.4x.xx4.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:60459559 errors:0 dropped:0 overruns:0 frame:0 TX packets:28096141 errors:0 dropped:0 overruns:0 carrier:10 coll:26 Interrupt:10 Base address:0x6200 eth1:0 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:2xx.x8.2x.1 Bcast:2xx.x8.2x.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth1:1 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:1x9.xx1.xx8.1 Bcast:1x9.xx1.xx8.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1500 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0 eth2 Link encap:Ethernet HWaddr 00:60:08:A2:XX:XX inet addr:xx9.1x5.xx0.xx9 Bcast:xx9.1x5.xx0.191 Mask:255.255.255.192 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:135534 errors:0 dropped:0 overruns:0 frame:0 TX packets:62097 errors:0 dropped:0 overruns:0 carrier:0 coll:4 Interrupt:9 Base address:0x6300 At 11:24 AM 10/27/98 -0800, you wrote: >>>Other lessons learned, >>> Linux won't route between multiple NICs, using multiple aliases, >>> even with ip-forwarding enabled. >> >> >>Someone needs to tell one of our routers this. It has been routing between >>multiple NICs for well over a year without any problem. > >In that case, I would dearly love to hear how it was done. ------- John Fraizer | __ _ The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

15 17

Oct 31: Chicago backhoe incident
by Sean Donelan 02 Nov '98

02 Nov '98

http://www.cnn.com/US/9810/31/gas.main.break.ap/ Today's backhoe incident involved a 24 inch natural gas pipeline. 10 people with minor injuries. There is some dispute between the excavation company and the pipeline operator whether the pipeline was properly marked or of the backhoe was operating in the marked area with due care. State officials are investigating. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 3

Re: Rootshell pages hacked
by themonk＠lower.org 01 Nov '98

01 Nov '98

Hey morons argueing over the ssh bug, rootshell just posted an email advisory, they have written code on an ssh-1.2.26 exploit. They were hacked via ssh, and they have stated so on their web page as well. Dave McKay themonk(a)lower.org Systems/Security Admin

1 0

Re: Rootshell pages hacked
by Paul Vixie 01 Nov '98

01 Nov '98

> Moral.. Don't trust ssh. > > -Ryan > Net Access Corporation what idiocy. given write access to a binary, one can use the binary as a trojan horse. if it has privileges or is executed by someone who has privileges, then your trojan will have those privileges. ssh is not the problem. writable / mutable binaries are the problem, and letting someone break into your system far enough to write or mutate your binaries is the problem, and using versions of SSH (or any other privileged tool) whose signatures you have not verified out-of-band is the problem. ssh is a fine program as such things go. security is fundamentally more about the procedures for key use and key management than it is about the quality of one's locks. in other words it's the people not the technology.

2 1