Linksys dsl-cable-router----->macosx syslogging
 

Hi all
I've configured my Linksys DSL/Cable router to send logging to my macos x box behind itself...now how do I tell the macos x box to ACCEPT the router's logging?

it seems, from the documentation, that you tell the router to log to an IP address (static, not dynamic), but where it gets to isn't clear, nor is it clear how to enable your rig to accept the log.

google: [ linksys router logging ] found some interesting things. it uses SNMPTraps. which could mean the end of your dilemma, as in your poop out of luck.

http://www.practicallynetworked.com/...g4.htm#logging

you'll need to solve the snmptrap problem. i don't see snmptrapd in /etc/inetd , and i don't know of a solution for OSX. so, you may be pooh out of luck.

hmmmmmm
 

The bit about snmp is a stumper

I think I'll look over at the FreeBSD area...they might have a solutiion.
The only part I'm fuzzy about is how to have a daemon listening on the macosx box to accept the inbound logging.....dunno if that has to be snmp or not.
Thanx fer yer help tho

ok I got half an answer
 

In linux to get a designated syslog server to listen you do:

On the log server:
- Kill syslogd and restart it with the following command:
syslogd -r -m 0
This will allow remote connections to syslog, and remove the
annoying --MARK-- lines.
- Edit the startup scripts to start syslogd with that command.

now according to the macosx man page these are the only flags available:
-d Enable debugging to the standard output, and do not disassociate
from the controlling terminal.

-f Specify the pathname of an alternate configuration file; the
default is /etc/syslog.conf.

-m Select the number of minutes between ``mark'' messages; the
default is 20 minutes.

-u Select the historical ``insecure'' mode, in which syslogd will
accept input from the UDP port. Some software wants this, but
you can be subjected to a variety of attacks over the network,
including attackers remotely filling logs.

-p Specify the pathname of an alternate log socket; the default is
/dev/log.

jamesk @ /Users/jamesk@HOME-->syslogd -r
syslogd: illegal option -- r
usage: syslogd [-f conffile] [-m markinterval] [-p logpath]
jamesk @ /Users/jamesk@HOME-->
eeeewwww macosx didn't like that

Well I'm stuck....

yeah, it isn't going to work like that. i don't think syslog is your facility.

there needs to be an entry in /etc/inetd.conf for the snmptrap facility...
inetd is the superserver, it listens for requests on ports and launches the
appropriate service. the snmptrap service has no facility, ergo, is unsupported in
this rev of OSX.

i see that snort will detect snmptrap requests. perhaps snort can trigger some
logging there for you. the downside is in the overhead that snort inspects every
packet, i think.

http://www.snort.org/

NetSNMP is available
 

You could get NetSNMP and compile and install it on your machine. It is open source and has been verified to work on OS X according to the FAQ: http://www.netsnmp.com/FAQ.html
Of course you will need to learn about how to use it but that'a all covered in the FAQ.

hey hayne! excellent. thanks, that's some good sleuthing.

there you go, jim. wrangle that snmp agent [ correction: not agent but the
server/daemon "snmptrapd" ] in and fire her up and let her buck. she'll sling yer router logs somewhere.

snmptrapd is what you want
 

Actually, in SNMP parlance, an "agent" is the program that send out the messages. An "agent" sits on the device - in this case the router. A "manager" is the program that listens to (and reacts to) these messages. The "manager" can be somewhere else on the network. In this case, the program you want from the NetSNMP distribution is called 'snmptrapd'.

right right. thanks for the catch. snmptrapd - the daemon, or manager, or server, or service, or wench. in any service parlance.

i looked thru the faq a bit, but it didn't mention the inetd.conf business above. but it did mention logging thru syslog.

jim, this is a good thread; i would like to upgrade to a logging router, and this may be very useful to others, too. so, if you elect to proceed, we could see your efforts here? perhaps i will co-pilot and get it going here, too.

hayne, do you think the correct approach would be to configure snmptrapd in inetd.conf ?

I haven't much experience in using inetd but I know that the services that it starts are usually written specifically for use with inetd - it handles making them run as daemons, redirects stdin, stdout, etc.
I certainly wouldn't fool around with inetd until I was sure it was working and doing what I wanted by trying it out after starting the daemon manually (in the Terminal). And even then, I'd need to learn more about what inetd expects.

I note the existence of an OS X specific site on NetSNMP:
http://www.dartware.com/net-snmp/index.html
which offers pre-compiled binaries.

Their installation seems to use a "startup item" to start the snmptrapd daemon.

I have wondered this question for a while also. I config my LinkSys to send the logs to a specific OS X box on our LAN, and tried several SNMP managers (including Etherpeek) and I never heard a peep from the router. I am not so sure the LinkSys SNMP Agent is really reliable. I wish someone would prvie me wrong on this one.

hope this helps...

http://homepage.mac.com/levanj/LinkSys/

http://idisk.mac.com/levanj/Public/L...0Me%20or%20Die

snmp eeeewwww
 

Guys
I' reaaallly hesitant about enabling snmpd on my mac. There's been a recent CERT advisory about snmp back a couple of months ago. A university in Finland evidently released several thousand exploits against the most recent version of snmp....at work we had a rush of customers requesting we turn it off shut it down and kill it...our customers have in turn been turning it off their border routers and internal routers as well....I'm gonna have to think about this and get back to you all after I get back from MacWorld.
jim

jim,

a) your linksys runs NAT ?

b) the snmptrap port (162) on your router is blocked

c) so, the only snmp packets your rig will see are from the router

d) you've got to break some eggs to make a quiche

i may be wrong about all that. if you'd like, we could set up some experimentation.

i turned on tcpdump and noticed snmptrap packets coming from my router. i'll install netsnmp and see if i can get anywhere. i'm confident that my rig is secure.

you should be too. test you router for open ports...

shields up

ok ok
 

I'll give it a whirl after I get back from MacWorld and post the results here....

point well taken Merv...just call me paranoid ;-)

no what am I saying....I'm fully noid

Merv - thx for the great link to the Linksys perl scripts. I have always been a bit bitter about the interactivity PC user can have with their Linksys products. Looks like these scripts help us OS X users get a leg up.

bluehz, yeah, a little google finesse finally got me something maybe useful. let us know your results.

i'm going to see if i can read my snmptrap port strums. someday.

beware, macubergeek pointed out all those security exploits. i read a bit about them, but need to dig deeper. so make sure your shields are up with the above site ref.

shields up is good
 

Merv
shields up is good, I think it's a web interface infront of nmap.....I'm old school, I'm testing my rig with nmap;-)
I'm currently running a snort box behind the linksys, but I've designated the snort box as my dmz host in the linksys. According to linksys, the dmz host is directly exposed to the internet without filtering. When I nmap my cable internet assigned ip, the traceroute logs and kicks up snmp alerts...all that means is that when nmap hits the snmp ports, snort goes crazy.

In case anyone is interested here is an excellant set of instructions for building a snort box on redhat linux http://www.entropy.ie/research/snort4-latest.pdf
I'm sure with a little work, someone could massage them to work on macosx

Silly Question
 

I'm sure this is a silly question but what do the numbers in red mean?

Thanks,
Hugh

those are the paired port numbers. there's in-ports and out-ports and they're paired. read about the tcp/ip protocol. and maybe examine % netstat -na

Thanks merv.

Hugh