[leaf-devel] Suggestion for ETC.LRP
I have been working on a Shorewall logfile beautifier based on parsefw.c from the Shorewall website. I currently have it working with Weblet under Bering. Formats the netfilter log to look more like the old ipchains style log. Easier to understand for us noobies (I think ;)) I've been testing it on a Mandrake box, and then moved it to my Bering box. The first thing I noticed was the calls to getservbyport() wasn't returning the same information. I took a look at the services file, and saw why. ITS FROM 1997. A bit out of date. I suggest we update this to something a little more 21st Century. My log beautifier is trying to return the dest port #, and whatever nice human-readable description of the services that are usually on that port. Might cut down on "What does this log entry mean" type questions. Also, how should I go about integrating this into Weblet? Sean --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF.net Tip of the Week
Everyone, This is a reminder to add "&content-type=application/octet-stream" to the end of ViewCVS URLs. This is necessary for proper downloading of binary files from our cvs repository. Bad example: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitarlynn/udhcp.lrp?rev=HEAD Good example: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitarlynn/udhcp.lrp?rev=HEAD&content-type=application/octet-stream -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF.net Tip of the Week
On Tue, 2003-02-25 at 07:41, Mike Noyes wrote: > Everyone, > This is a reminder to add "&content-type=application/octet-stream" to > the end of ViewCVS URLs. This is necessary for proper downloading of > binary files from our cvs repository. > > Bad example: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitarlynn/udhcp.lrp?rev=HEAD > > Good example: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitarlynn/udhcp.lrp?rev=HEAD&content-type=application/octet-stream Everyone, This breakdown of the url may make things easier to understand. Please let me know if further explanation is necessary. Standard prefix: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/ This is the section of the url that refers to your file: devel/guitarlynn/udhcp.lrp Standard section to download current revision as binary: ?rev=HEAD&content-type=application/octet-stream> The name of the download you wish to appear on the website yourfilename -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF.net Tip of the Week
On Tuesday 25 February 2003 09:41 am, Mike Noyes wrote: > Everyone, > This is a reminder to add "&content-type=application/octet-stream" to > the end of ViewCVS URLs. This is necessary for proper downloading of > binary files from our cvs repository. > > Bad example: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitar >lynn/udhcp.lrp?rev=HEAD > > Good example: > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/devel/guitar >lynn/udhcp.lrp?rev=HEAD&content-type=application/octet-stream Sorry Mike, this is fixed now. -- ~Lynn Avants Linux Embedded Appliance Firewall developer http://leaf.sourceforge.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] config-db framework
Matt S., Greg M. et. al., There is a nearly finished version of the proposed core framework for the config-db, templating system and event/trigger system in my tree in cvs http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ccarr/devel/leaf-tools/ The tools are named cdb, tmpl and trig, and are currently installed in /leaf/bin (this is subject to change, as is the interface, functionality and anything else about them after some user feedback). There are pretty good manpage-style help files for cdb and tmpl (*.help), and the usage statement of trig (and looking at the 15 lines of source) should probably be enough (it is pretty simplistic). There is also a shot at laying out the big picture of the core config-db, hier.help (but I think it will need quite a bit of adjustment in practice) Please play around with these and let me know if they will do the job. I am more than willing to add features if you find them really necessary and the current interface/feature set will not do the job. I believe that they can be used equally effectively (with some creativity) for both on-LEAF, shell- or web-based configuration and off-LEAF java-, perl- or python-based preconfiguration. It is possible that you could even stick with your XML plan off-LEAF and easily transform it to the hierarchical filesystem config-db format before burning the CD, floppy or CF card. Also, it is quite possible that if we find ourselves transforming the output or behavior of these utilities in the same or similar ways over and over again, if the utilities cannot be modified to produce the desired results, we may be able to write a nice shlib with functions to do the job. Let me know what you think and where you would like me to proceed from here. Also, I quite appreciate code review and feedback from any of you /bin/sh gurus out there; you know who you are ;-) I have tried to comment the code and lay it out so that it is easily understood, so it should not be too hard to grasp what I am trying to do, but feel free to ask whether or not I was smoking crayons when I wrote some construct! -- --- Chad Carr [EMAIL PROTECTED] --- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Support Requests-693075 ] Karlnet
Support Requests item #693075, was opened at 2003-02-25 18:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=213751&aid=693075&group_id=13751 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Butcher (tbutcher) Assigned to: Nobody/Anonymous (nobody) Summary: Karlnet Initial Comment: How do I configure Karlnet on WISP-Dist? Does it require a license? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=213751&aid=693075&group_id=13751 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Package Repository
Everyone, I apologize for the long delay (8+ months) in completing initial population of our packages repository. Project members may commit to the following directories: bin/packages/glibc-2.1 bin/packages/glibc-2.2 bin/packages/uclibc Commits are acceptable for packages beginning with A-R in: bin/packages/glibc-2.0 Please do not commit any packages to the following directory yet. bin/packages/nolibc Submitted packages in our SF tracker will be attended to after initial population of our repository is complete. They are not being ignored. Patches https://sourceforge.net/tracker/?group_id=13751&atid=313751 -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Linux certification preparation tutorials
Everyone, LinuxDevices has a story about IBM DeveloperWorks releasing LPI certification tutorials. Linux certification preparation tutorials http://www.linuxdevices.com/news/NS9210834394.html -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Suggestion for ETC.LRP
On 25 Feb 2003 09:53:25 -0500 "Sean E. Covel" <[EMAIL PROTECTED]> wrote: > I've been testing it on a Mandrake box, and then moved it to my > Bering box. The first thing I noticed was the calls to > getservbyport() wasn't returning the same information. I took > a look at the services file, and saw why. ITS FROM 1997. A > bit out of date. I suggest we update this to something a > little more 21st Century. I have (or had) a file called services.lrp (or something like it) which contained the extra large services file from (I think) nmap. You could try that, but it is at least an order of magnitude larger than the current /etc/services file. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
RE: [leaf-devel] Suggestion for ETC.LRP
Well, that might be overkill... SizeFile 19004 services (Mandrake 9) 11077 services (Bering 1.0) 101481 nmap-services (nmap 3.00) What I was looking for is a services file with the service ports that are currently being commonly exploited. I'm using my Mandrake services file on my Bering firewall at the moment. 1433, 1434, 445, 53, 80, 443, 8080, 8081, 3128, 25 Some of these are new (newer than 1997) service ports, and new exploits. I would suspect that a pretty logfile with some human readable information might cut down on the posts from newbies thinking they have been hacked. I know this is not going to work, but here is a cut-and-paste of my current logfile. It is in a nice HTML table with the columns lined up. The Dest Port column has | Description (port#) | Date Time Firewall RuleAction In I/F Out I/F From IP Target IP Protocol Src Port Dest Port Feb 21 06:42:11 firewall all2all REJECT local eth012.243.225.129 192.43.244.18 TCP 1772 time (37) Feb 21 06:55:22 firewall net2all DROP eth0 local 211.222.248.167 12.243.225.129 TCP 2006 17300 Feb 21 06:55:28 firewall net2all DROP eth0 local 211.222.248.167 12.243.225.129 TCP 2006 17300 Feb 21 06:55:38 firewall net2all DROP eth0 local 211.222.248.167 12.243.225.129 TCP 2006 17300 Feb 21 06:55:50 firewall net2all DROP eth0 local 211.222.248.167 12.243.225.129 TCP 2006 17300 Feb 21 11:59:00 firewall net2all DROP eth0 local 212.64.132.107 12.243.225.129 TCP 42527microsoft-ds (445) Feb 21 12:41:09 firewall net2all DROP eth0 local 38.112.96.157 12.243.225.129 UDP 1309 ms-sql-m (1434) Feb 21 13:54:32 firewall net2all DROP eth0 local 202.178.156.229 12.243.225.129 UDP 2046 ms-sql-m (1434) Feb 21 17:46:56 firewall net2all DROP eth0 local 160.33.16.238 12.243.225.129 UDP 1233 ms-sql-m (1434) Feb 21 21:43:14 firewall net2all DROP eth0 local 64.124.142.92 12.243.225.129 UDP 3004 ms-sql-m (1434) Feb 21 23:33:59 firewall net2all DROP eth0 local 24.158.21.53 12.243.225.129 TCP 3187 ftp (21) Feb 22 00:09:21 firewall net2all DROP eth0 local 67.210.111.63 12.243.225.129 UDP 2241 ms-sql-m (1434) Feb 22 00:55:09 firewall net2all DROP eth0 local 218.239.215.222 12.243.225.129 TCP 4207 12346 Feb 22 01:32:22 firewall net2all DROP eth0 local 128.242.107.15 12.243.225.129 UDP 5domain (53) Feb 22 03:59:27 firewall net2all DROP eth0 local 216.118.6.173 12.243.225.129 UDP 1773 ms-sql-m (1434) Feb 22 05:44:21 firewall net2all DROP eth0 local 66.196.20.36 12.243.225.129 UDP 3241 ms-sql-m (1434) Some ports are well know for being exploited (see FAQ: Firewall Forensics (What am I seeing?) for a nice list). Those would be good to add to the services file. Others we just might want to drop. Either way, we might want to start with a more modern version of the file. I guess one question I need answered is, is their a "maintainer" of ETC.lrp and Weblet.lrp? If so, should I submit my changes to them? Or should I just drop it in patch manager? Who decides if this is a "good" change? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Douthitt Sent: Tuesday, February 25, 2003 5:26 PM To: [EMAIL PROTECTED] Subject: Re: [leaf-devel] Suggestion for ETC.LRP On 25 Feb 2003 09:53:25 -0500 "Sean E. Covel" <[EMAIL PROTECTED]> wrote: > I've been testing it on a Mandrake box, and then moved it to my Bering > box. The first thing I noticed was the calls to > getservbyport() wasn't returning the same information. I took a look > at the services file, and saw why. ITS FROM 1997. A bit out of date. > I suggest we update this to something a little more 21st Century. I have (or had) a file called services.lrp (or something like it) which contained the extra large services file from (I think) nmap. You could try that, but it is at least an order of magnitude larger than the current /etc/services file. --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
