Re: [Full-Disclosure] SNMP Broadcasts
> No, not at all. There's a big difference between a *standardized service* > and it's underlying protocols. In order to be SSH, it must comply with > all of the standards for SSH. Otherwise, you get a M$ Windows product. I was trying to stay away from this thread, but anyhow: If you've ever read RFCs before, you would be familiar with terms like MUST, SHOUD, MAY, MANDATORY etc. There is no document that says that in order to be "standard" SSH the listen port MUST be 22. Or tcp/22 is the MANDATORY port for SSH. The document only says that SSH "normally" uses port 22. The IANA has assigned port 22 for ssh, but this doesn't mean that you're not complying with the SSH standard by listening on an alternate port. That's it. For all practical purposes, no matter what port the daemon listen's on, it _IS_ SSH. -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SNMP Broadcasts
>> Not much you can do to stop the >> portscans. > Like hell there isn't. F-I-R-E-W-A-L-L. Agreed... they "block" the port scans... but they don't "stop" it (which was my point). The portscans will continue for as long as the trojan/scanner/scumoftheearth is running. > > > SNMP goes to ports 161 and 162, *only*. > > > > No... those are just the default ports for the stock agents. Sysedge > > (for example) uses 1691 for Get/Set requests. > > This is not, *technically* SNMP, as it is not using it's assigned ports. > This is a variant, and interestingly, that port is assigned to It is SNMP. Not a variant. It's just running on a different port. In any case, sometimes the different applications running on a server are SNMP enabled. And when you have the stock OS SNMP daemon listening for SNMP requests on udp161, the applications cannot use that port. They therefore resort to their own high port numbers. System Edge is an extensible SNMP agent similar in many ways to net-snmp. It provides more information than an OS's stock agent, but it's still SNMP and not a variant. > > empire-empuma 1691/tcpempire-empuma > empire-empuma 1691/udpempire-empuma > > Unless Sysedge is the decendant of "empire-empuma", it doesn't belong > there either. That is the case... Empire makes (made) sysedge: http://www.empire.com/products/systemedge/index.htm > > > > Could this be some kind of SNMP DoS as I get several/second ? > > > > I'll tell you what it could (likely) be: > > > > - An unconfigured SNMP agent on the network (on a Linux or Windows box maybe). > > More specific: a misconfigured agent ont the LOCAL network segment. agreed. > > - Your service providers actual switch is misconfigured. > > Not at all likely. I've worked with (and currently work for) different service providers in the Telco and IP space. The above is entirely likely. Even with the most sophisticated network management tools, large service providers still screw up bad. It's unfortunate. > > I haven't heard of SNMP DoS's but hey... anythings possible. > > I have, and have seen them, but that's not relevent here, as this guy's > entire post made obvious that SNMP was not involved. okay. > > > I know I shouldn't be asking this, but... Do you know how to use > > > Ethereal? > > > > Good Call. It'll answer most of your questions. > > Unfortunately, the odds of this kind of newbie being able to successfully > utilize it are slim. Still, if he is going to ask for help with odd > packets, he must be able to document them, and this is the standard way to > do so. agreed. -- Mohit Muthanna, CISSP [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SNMP Broadcasts
> > Subject: [Full-Disclosure] SNMPBroadcasts > > SNMP doesn't "broadcast" Sure it does. Most older "default" SNMP devices broadcast traps. This is so that any SNMP manager on the network can collect the traps for a specified SNMP community. This is also so that the SNMP enabled device can just be placed on the network and managed without any special configuration. Newer SNMP agents let you specify a management host to send traps to. > > For the past 12 hours my external IP has been bombarded with SNMP > > "Bombarded"? Below you state it was only "several per second". Are you > on a dial connection? > > > Broadcasts, I have sent complaints to my ISP and the ISP of the originating > > IP. > > And both are likely laughing their asses off right about now. Why? Depending on the service provider configures the network and assigns IP address to customers, the switch can easily forward broadcast packets to all hosts on the subnetwork. This includes Windows LM broadcasts, SNMP broadcasts, or just any packet destined to a broadcast address. Have you noticed that for certain service providers, you can browse the windows/samba shares on your neighbours machine? > > > The attacking IP must have some sort of worm or automated script to go > > through all the port numbers as his remote port starts at 60001 and goes up > > to 64087 but it hits my local ports 1-highest port # (65535) if I let my > > logs record that much. You're (BillyBob) being port scanned. Not much you can do to stop the portscans. All you can do is be invisible to it. It's most likely a trojaned machine searching for more victims. Make sure you're behind a cable/dsl router (or have a good firewall in place) (or both). Keep up with all your software and firmware patches. Note that some ISPs deliberately port-scan customer machines to search for webservers, mailservers etc. > SNMP goes to ports 161 and 162, *only*. No... those are just the default ports for the stock agents. Sysedge (for example) uses 1691 for Get/Set requests. > > Could this be some kind of SNMP DoS as I get several/second ? I'll tell you what it could (likely) be: - An unconfigured SNMP agent on the network (on a Linux or Windows box maybe). - A cable/dsl router on the subnet that's spewing SNMP traps (I've seen this a lot). - Your service providers actual switch is misconfigured. I haven't heard of SNMP DoS's but hey... anythings possible. > I know I shouldn't be asking this, but... Do you know how to use > Ethereal? Good Call. It'll answer most of your questions. -- Mohit Muthanna, CISSP [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] server administration
> I have to throw cfengine into this mix, too. > > http://www.cfengine.com/ > Of course... how could I forget cfengine. Another godsend. Also just remembered: syslog-ng is a good replacement for syslog. Thx, Mohit. -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] server administration
> Having said that, you're going to be disappointed in what snmp will > provide unless you want to start writing MIBs (you don't). So you will > be doing some sort of client/server model maybe with *NIX tools like > vmstat and traceroute and wget. We did something similar in 1998 I > recall. I wouldn't discount SNMP so easily. A good SNMP agent will provide a lot of useful information related to the system. Eg. see net-snmp (opensource) or sysedge (Commercial). You don't _ever_ have to write a MIB unless you're developing an SNMP agent/layer for a custom application. I've worked in environments (ISPs and Telecos) where we've had to manange servers with numbers in the thousands. And generally the first question we ask when a new device comes in is: "Is it SNMP enabled?" Standard UNIX tools vmstat, traceroute, etc. are cool when you're trying to debug a problem on a machine. Or when you have only a few machines to maintain. But as soon as you hit about 30 - 40 machines, your'e going to have problems. SNMP (v1 and v2c) does, OTOH, have security drawbacks since the packets pretty much "in the air". But with good host and network security, you can work around them. SNMPv3 addresses most of the security issues with the earlier versions. Mohit. -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] server administration
Harry, What you're talking about falls under the realm of Systems / Network Management. Generally when you have large numbers of servers / devices to manage you need an effective tool. You can write your own scripts, but you'd just be duplicating the efforts of a number of available tools out there. I'd suggest you read up on SNMP. And check out the following tools (google them): - net-snmp ( an SNMP agent ) - nagios ( very sophisticated network management tool ) - nmap ( good discovery tool ) - ntop ( traffic analysis, RMON agent, performance monitoring ) - sar ( system performance monitoring ) - argus (network performance monitornig) - rsync (distributed configurations, files etc.) - openssh (if you don't know what this is, you're in trouble) - rcs, cvs or subversion (change control) There are also a number of commercial tools availabe, but the above list encompasses most of what you will need. Hope this helps, Mohit. -- Mohit Muthanna, CISSP mohit (at) muthanna (uhuh) com "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] M$ - so what should they do?
like duh... have you _not_ heard of "edlin" ??? On Tue, 22 Jun 2004 09:04:37 +1200, Stuart Fox (DSL AK) <[EMAIL PROTECTED]> wrote: > > > > > > > How about changing the ".exe" convention? Making a file > > executable by it's "extension" probably causes a lot of > > opportunities for problems, doesn't it? > > > > Also, the magic file names, like "CON" and "AUX" should go away. > > > > No way! Am I the only person who still uses "copy con filename.txt" to > create scripts and such at the command line? Please tell me I'm not? > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] MS Anti Virus?
> You really expect us to believe that the M$ AV team won't leverage off the > fact that they could know about that API, and all the others in Windows? in addition, given that they have the sources to their own OS, i doubt they really have to do much manual reversing... i'm sure the debugging tools they have developed over the years would quite easily aid them in determining precisely what the viruses do and how they do it. Mohit. Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] MASS spam emails from .tw and . BL domains
hmmm... sounds like spammers rerouting in response to comcast blocking port 25 on a large number of subscribers. that (i.e., comcast's actions) _did_ have a significant effect on the amount of spam being sent out. and as expected, it's effects were short term... if only more service providers would put a little more effort into securing / monitoring their own customer networks. Mohit. On Thu, 17 Jun 2004 15:51:16 -0400, MIKE TOLBERT <[EMAIL PROTECTED]> wrote: > > Over the last two days we have received an increase in SPAM from Taiwan, > it has since moved to Latin America. > The emails contain: > MAIL From: <[EMAIL PROTECTED]>and other names > Subject: (high bit characters) > > Body of the email contains Base64 encoding. > All originating from a .tw domain. > It looks like it has spread origins now to come from Latin America this > after noon. > > Mike Tolbert > > Long and Foster > Network Security Administrator > > (703) 359-1878 > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > > -- Mohit Muthanna [mohit (at) muthanna (uhuh) com] "There are 10 types of people. Those who understand binary, and those who don't." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
