lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: mohit.muthanna at gmail.com (Mohit Muthanna)
Subject: 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/tcp    empire-empuma
>         empire-empuma   1691/udp    empire-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."


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ