This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Date: Mon, 02 Oct 2000 10:10:20 -0700 To: svlug@svlug.org From: Roger Lynker <rlynker@mindspring.com> Subject: [svlug] Pac Bell system attacks Hello, Does anyone know who to email about the constant attempted attacks to my system? I have a Pac Bell account and the attacks are (mostly) coming from another Pac Bell account. There's no danger of this person succeeding as I have everything turned off except SSH (and he/she keeps probing port 161....SNMP), but when someone tries then gets blocked then relogs in to try again.....that's just stupidity....and that person should be punished....even if all they're doing to me is making my hosts.deny file bigger. I tried abuse@pacbell.net but got no response.....I will probably try that address again unless someone knows of another? Thanks. === To: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks Date: Mon, 02 Oct 2000 10:32:55 -0700 From: J C Lawrence <claw@kanga.nu> On Mon, 02 Oct 2000 10:10:20 -0700 Roger Lynker <rlynker@mindspring.com> wrote: > There's no danger of this person succeeding as I have everything > turned off except SSH (and he/she keeps probing port > 161....SNMP)... I'd wager that they are not attacks, but are instead a mis-addressed SNMP monitoring service ala Mon, Cricket, etc. There's not been that much history of SNMP cracks and it seems a mite unlikely that you'd get harped on for that alone. === Date: Mon, 02 Oct 2000 10:42:57 -0700 To: svlug@svlug.org From: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks Thanks for the help. I couldn't quite figure out why it was going to port 161 only...and not 111 or the BO port (forget the number). Is there a list somewhere of ports I should closely? I mean I have them all turned off, but I like to know what ports they're scanning (for those that aren't listed in /etc/services). Thanks again. === Date: Mon, 2 Oct 2000 10:45:12 -0700 (PDT) From: "Brian W." <bri@sonicboom.org> To: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks usually security@domainname is the first thing to try for security type things. === Date: Mon, 2 Oct 2000 10:58:27 -0700 From: Don Marti <dmarti@zgp.org> To: Roger Lynker <rlynker@mindspring.com> Cc: svlug@svlug.org Subject: Re: [svlug] Pac Bell system attacks begin Roger Lynker quotation of Mon, Oct 02, 2000 at 10:10:20AM -0700: > Does anyone know who to email about the constant attempted attacks to my > system? "abuse" addresses are almost always a "thank you for the spam complaint" autoresponder. You'll need to pick up the phone and work your way through menus and voicemail crap to get the network operations center. Be sure to have all your info, logs, etc. on the probing available. Try the phone number in the whois record before the one on the web site, if they're different. === Date: Mon, 2 Oct 2000 11:13:18 -0700 (PDT) From: Bill Selmeier <bills@mast.right-net.com> To: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks The contact point for this domain according to whois is" trouble@PBI.NET === Date: Mon, 2 Oct 2000 11:20:39 -0700 To: svlug@svlug.org Subject: Re: [svlug] Pac Bell system attacks From: Rick Moen <rick@linuxmafia.com> begin Roger Lynker quotation: > There's no danger of this person succeeding as I have everything > turned off except SSH (and he/she keeps probing port 161....SNMP), but > when someone tries then gets blocked then relogs in to try > again.....that's just stupidity....and that person should be punished. So, Roger, welcome to monitoring for network probes. You'll find that (1) genuine probes happen many times a day, (2) contacts that could be innocent or not depending on your perspective happen even more often (which one might classify as "twisting the doorknob"), and (3) both are sometimes difficult to distinguish from 100% innocent traffic. Even if you're successful at distinguishing true, aggressive, intensive probes (e.g., heavy port-scanning), you're going to be a really busy guy if you try to go after them all. === Date: Mon, 2 Oct 2000 11:22:13 -0700 (PDT) From: "Brian W." <bri@sonicboom.org> To: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks I use http://www.isi.edu/in-notes/iana/assignments/port-numbers for a port number directory.. === To: Roger Lynker <rlynker@mindspring.com> Subject: Re: [svlug] Pac Bell system attacks Date: Mon, 02 Oct 2000 11:30:22 -0700 From: J C Lawrence <claw@kanga.nu> On Mon, 02 Oct 2000 10:42:57 -0700 Roger Lynker <rlynker@mindspring.com> wrote: > Is there a list somewhere of ports I should closely? Tough call. I generally get twitchy about the following: Anything below 20 21 (FTP) 23 (telnet) 53 (DNS) 69 (tftpd) 79 (finger) 88 (kerberos) 98 (linuxconf) 109 (pop2) 111 (sunrpc) 113 (auth) 137-139 (netbios) 1080 (socks) 3306 (mysql) I certainly watch more than that to be sure, but that's not a bad starting point. Portsentry IIRC correctly comes with some decent defaults in this area. Certainly the Debian package isn't terrible in either its defaults or suggestions: # Un-comment these if you are really anal: #TCP_PORTS="1,7,9,11,15,70,79,80,109,110,111,119,138,139,143,512,513,514,515,540,635,1080,1524,2000,2001,4000,4001,5742,6000,6001,6667,12345,12346,20034,30303,32771,32772,32773,32774,31337,40421,40425,49724,54320" #UDP_PORTS="1,7,9,66,67,68,69,111,137,138,161,162,474,513,517,518,635,640,641,666,700,2049,32770,32771,32772,32773,32774,31337,54321" # # Use these if you just want to be aware: #TCP_PORTS="1,11,15,79,111,119,143,540,635,1080,1524,2000,5742,6667,12345,12346,20034,31337,32771,32772,32773,32774,40421,49724,54320" #UDP_PORTS="1,7,9,69,161,162,513,635,640,641,700,32770,32771,32772,32773,32774,31337,54321" # # Use these for just bare-bones #TCP_PORTS="1,11,15,110,111,143,540,635,1080,524,2000,12345,12346,20034,32771,32772,32773,32774,49724,54320" #UDP_PORTS="1,7,9,69,161,162,513,640,700,32770,32771,32772,32773,32774,31337,54321" === Date: Mon, 2 Oct 2000 11:33:34 -0700 To: svlug@svlug.org Subject: Re: [svlug] Pac Bell system attacks From: Rick Moen <rick@linuxmafia.com> begin Roger Lynker quotation: > Is there a list somewhere of ports I should [monitor] closely? Good luck on _that_. If you want just a fairly comprehensive list of official TCP/UDP port number assignments, start here: http://www.iana.org/ Link "Protocol Numbers and Assignment Servers" goes to http://www.iana.org/numbers.htm Link "port numbers" goes to http://www.isi.edu/in-notes/iana/assignments/port-numbers There are better-organised listings elsewhere (e.g., the one linked from http://www.networksorcery.com/enp/), but that's the easiest to find, and has IANA's imprimatur. Want to know _which_ ports are security-sensitive? Welcome to the study of security. You'll have fun reading Craig Hunt's _TCP/IP Network Administration_, Nemeth and Frisch's sysadmin manuals, and a sampling of the better books on Unix security. ==== Date: Mon, 2 Oct 2000 12:50:34 -0700 To: svlug@svlug.org Subject: Re: [svlug] Pac Bell system attacks From: Rick Moen <rick@linuxmafia.com> begin J C Lawrence quotation: > Tough call. I generally get twitchy about the following: As usual, there a question of policy: Do you care only about security-sensitive services you _actually_ run? Do you care about ones that others run on your OS, but that you don't? Do you care about ones operated only on exotic platforms you don't have? Do you care about detecting attempts to exploit known flaws in daemon software you _don't_ run? What do you call a security-sensitive service, and why? What are you trying to detect, and towards what end? How are you going to distinguish between innocent and suspicious contacts? > Anything below 20 Echo, discard, daytime, qotd, and chargen are pretty tame, as DOS weapons go. > 113 (auth) With knowledge of the many mundane reasons your auth port might be queried, I assume. But, unless the guy reads up on what all this is and what its significance is, all he's going to gain is an object lesson in the distinction between data and information. === To: Rick Moen <rick@linuxmafia.com> Subject: Re: [svlug] Pac Bell system attacks Date: Mon, 02 Oct 2000 13:06:35 -0700 From: J C Lawrence <claw@kanga.nu> On Mon, 2 Oct 2000 12:50:34 -0700 Rick Moen <rick@linuxmafia.com> wrote: > begin J C Lawrence quotation: >> Anything below 20 > Echo, discard, daytime, qotd, and chargen are pretty tame, as DOS > weapons go. Very. However connects to them are both rare and worthy of examination in my book. >> 113 (auth) > With knowledge of the many mundane reasons your auth port might be > queried, I assume. Yep. === Date: 2 Oct 2000 22:22:42 -0000 Subject: Re: [svlug] Pac Bell system attacks From: John Conover <conover@rahul.net> To: svlug@lists.svlug.org Crack attempts are just the contemporary nature of the Internet, and one has to live with it, unfortunately, (and it has created a big market for Linux/BSD consultants installing boxes in the enterprise as specialized gateways/NATs/firewalls-not to mention a lucrative market for the likes of Cisco, etc.) However, be advised, the /var/log/syslog entries from ipchains can be misleading. Look at the -S option to nmap(1) as an example. I have traced back crack packets, like the ones you mentioned, and most/many are initiated in Korea, China, and Russia, in that order, (university students in the US follow at a distant fourth, Japan a very distant fifth.) And, the vandals target ISP's PPP lines, too, (there is usually a lot of mis-configured junk hanging on ISP's dial in lines-so its easy prey. Ditto *DSL.) There just isn't much one can do, other than be vigilant with comprehensive firewall rules and NAT/masquerading, and run something like portsentry(1) from Psionic, (http://www.psionic.com/,) to automagically configure ipchains to DENY/REJECT nefarious rogue sites dynamically, (i.e., on the fly, as soon as a rogue packet hits a port,) and always make sure the gateway has the capability to out run anything that comes down the pipe-which can be a big issue if the pipe has high bandwidth, and the gateway gets loaded down with other stuff, (like running SMTP, WWW, and DNS services on the gateway, too.) At any rate, its not going to go away, so one has to live with it. ===