KCLUG September 2005

kclug@kclug.org

29 participants
34 discussions

qmail installation needed (quick $100)
by David Nicol 09 Sep '05

09 Sep '05

http://www.rentacoder.com/RentACoder/misc/BidRequests/ShowBidRequest.asp?ln… -- David L Nicol http://cronos.advenge.com/pc/EmilyDickenson/SecondBook/p8.html There's a second stanza!

1 0

Re: debian kernels
by Don Erickson 08 Sep '05

08 Sep '05

On Wed, 7 Sep 2005, Justin Dugger wrote: > Certainly, there's good > reasons to build your own kernel and appreciate the complexity that > you can build yourself into, but we all love scripts to automate the > repetitive and boring parts =) Right, but there are already scripts to automate building the kernel in the standard kernel sources, and those work on anybody's machine. So, if you learn to buld kernels Linus' way, you can do it anywhere, on any architecture. Here's how to build a standard 2.6 kernel: Download the source. Generate the .config file that you wish. make install && make modules_install (if using grub) update-grub reboot It's not that tough. I frankly have never seen how the debian kernel build process was any improvement over this, and from the stories I have seen recently, I am even more solidly convinced that it's not really "easier", especially if you have to jump through the hoops that "Jack" has described just to build a stupid hardware module. That should be a trivial task, and the frustration he has endured should be a solid argument for enduring the learning curve to do it the "real" way in the first place. If you're running a kernel that you built in the above described manner, you can build any "non-standard" modules and load them without rebooting, loading any additional packages, or trying to untangle the debian (or anybody else's) kernel source package maze. Just my opinion. Regards, -Don

2 1

OT: Juniper Demo Truck
by Aaron M. Hirsch 08 Sep '05

08 Sep '05

Just thought some of you may be interested... I just wanted to advise you that we, UpTime, are sponsoring a visit from the "Juniper Demo Truck" on Sept. 12 at the Convention Center Courtyard in O.P. from noon to 5pm. The truck will be packed with firewall, intelligent routing, ssl vpn appliances, web acceleration, and WAN optimization equipment. Please feel free to spread the word with your network/security guys. Again, pass this info along and if any questions arise you can point them in my direction. p.s. An iPod Shuffle is being given away as a door prize.

1 0

ITEC Oct 26-27
by Chris Bier 08 Sep '05

08 Sep '05

This email is brought to you by the Kansas City Linux Users Group, a partner of Kansas City ITEC. The Kansas City Linux Users Group and Centric Events Group, organizers of the ITEC series of events, have created a special package – available only to KCLUG members – to support your participation in the Kansas City ITEC, scheduled for October 26-27 at the Overland Park Convention Center. Many of you are probably familiar with the Kansas City event. But, for those of you who are not, ITEC is the nation’s largest series of regional business-to-business IT events. The Kansas City event is designed specifically to meet the needs of qualified IT buyers and business decision-makers in the Kansas City region. For full information on the event, go to http://www.goitec.com/live/15/events/15KCM05/. For Attendees ITEC’s interactive show floor provide you with the best opportunity for you to experience products and solutions in a “hands on environment”, meet directly with prospective providers, ask specific questions and compare vendor’s customer relationship approaches. Instead of spending six months or more trying to contact and research all of the vendors that you can talk to them face-to-face at ITEC over the course of just two days. Click here to check out who's exhibiting. VoIP. Mobility and Wireless Networking. Network Security, Intrusion Prevention and Detection. Make a list of the hottest issues you deal and chances are your list includes at least one or more of the above topics. You can count on the all-new 2005 ITEC Fall Series Conference to provide you with up-to-the-minute information and education about new solutions, products, best practices and management strategy. We’ll spend time on the high-impact IT issues that matter most to you. The KCLUG will be taking part in the Kansas City ITEC as a Strategic Sponsor. As a KCLUG member you will be offered free admission to both the exhibition hall and the educational conference programs. Simply Register online at www.goitec.com/reg/kcm/ and enter Priority Code: TCNKC502 If you are interested in being an exhibitor, contact Mary Savelsbergh at ITEC, directly at 503.596.3611; toll-free at 1.866.784.6398 x3611, or by email at mary.savelsbergh(a)centricevents.com. This promises to be a great event, and we’re pleased to have worked with Centric to create this special package for you. We hope to see you at ITEC - the KCLUG will be in booth # 526. Sincerely, Chris Bier Event Coordinator Kansas City Linux Users Group The Kansas City ITEC, part of the nations largest series of regional business technology events, returns October 26-27 to the Overland Park Convention Center. ITEC enables small & medium business managers, executives & IT professionals to explore innovative technology solutions to extend IT capabilities and increase productivity while reducing costs. ITEC provides an educational platform featuring an interactive show floor, technology-specific Conference Tracks, Vendor Sessions, and Keynotes from industry experts. The Kansas City Linux Users Group and other leading technology organizations and companies, support Kansas City ITEC 2005. All KCLUG members can receive a free conference pass (valued at $295) to attend ITEC by registering online at www.goITEC.com using Priority Code TCNKC502.

1 0

RE: routing problem - fork on gateways
by Jeremy Fowler 08 Sep '05

08 Sep '05

> Ummm... no. Wrong on both accounts. > See Jeremy's post about source-routing for one method. > The firewall rules are never bypassed, that's why you need > rules to specifically allow "established" > connections. It is also why when writing your rules you want > to put those rules near the top so that established > connections don't have to run the entire gamut of the ruleset > to get an up/down vote on whether to accept. Now maybe some > firewalls resort the rules to get this behavior, but I > haven't seen this with any Linux software firewalls. Actually, I think what David is thinking about is the PREROUTING chain in the Linux Netfilter nat table. It only checks the first packet of each stream. <rant> Let's leave the "Ummm... No" out from now on. We're all learning here. I know it may sound stupid, but I find it rude. I went off on some guy last week about it - which I do feel bad about. I got a little out of line on one of my replies. Anyway, lets try and keep the respect for one another going here. Feel free to correct people, myself included, but lets try to keep it polite. </rant>

2 1

debian kernels
by Jack 08 Sep '05

08 Sep '05

Anyone ever successfully installed a debian kernel pacakge? I've been trying to compile a specific kernel module. So far no luck. So now I'm compiling and installing a kernel from sources. All because I want my scanner to work in debian. Funny it used to work out of the box in other distros, but in debian it is installing some funky wrong module. Granted it is a parallel port scanner. <rant> I have another scanner, which I just bought, but it won't work in Linux, so I need to build a M$ box so I can scan in my medium format negatives. Then I'll start working on finishing the experimental driver for the scanner. </rant> Thanks, Brian JD

4 5

RE: routing problem - fork on gateways
by Jeremy Fowler 07 Sep '05

07 Sep '05

> > what gets bypassed with established TCP connections is the firewall > > rules, as an optimization for reducing CPU load on firewall > machines. > > That's TCP connections, not routes. > > Routes must involve routers unless there is direct connection, (or > > faking of direct connection through VPN bridging or something like > > that) > > Nope, you can always source route a packet. Unless a host > along the path filters them. However, in the case there is > nothing to stop a application from source routing directly to > the firewall and bypassing the router. However, the > application would have to specifically do this as it is not > done automatically. One other way that I forgot about is ICMP type 5 Redirects. This is the more automatic approach and is probably what Brian (Jack?) is referring to. The router basically sends the host a message saying there is a better route and to update your routing table. However, the host must accept these packets, some disable redirects for obvious security reasons. RFC 792, page 13: The gateway sends a redirect message to a host in the following situation. A gateway, G1, receives an internet datagram from a host on a network to which the gateway is attached. The gateway, G1, checks its routing table and obtains the address of the next gateway, G2, on the route to the datagram's internet destination network, X. If G2 and the host identified by the internet source address of the datagram are on the same network, a redirect message is sent to the host. The redirect message advises the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination. The gateway forwards the original datagram's data to its internet destination. For datagrams with the IP source route options and the gateway address in the destination address field, a redirect message is not sent even if there is a better route to the ultimate destination than the next address in the source route. Codes 0, 1, 2, and 3 may be received from a gateway. RFC 816, page 3: The ICMP "redirect" message indicates that the gateway to which the host sent the datagram is no longer the best gateway to reach the net in question. The gateway will have forwarded the datagram, but the host should revise its routing table to have a different immediate address for this net. RFC 1349, page 9: The ICMP Redirect message also includes a code, which specifies the class of datagrams to which the Redirect applies. There are currently four codes defined: 0 -- redirect datagrams for the network. 1 -- redirect datagrams for the host. 2 -- redirect datagrams for the type of service and network. 3 -- redirect datagrams for the type of service and host.

1 0

Decent site explaining Server firewalls
by Leo Mauler 07 Sep '05

07 Sep '05

I'm taking a class on RHCE and the instructor just passed on this website for server firewall info. Nice basic stuff for Linux beginners and it builds your knowledge from basic to advanced in the same site (such as creating a server firewall which blocks most traffic but which opens up enough for NFS, which is quite tricky). http://www.troubleshooters.com/lpm/200305/200305.htm ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

1 0

RE: routing problem - fork on gateways
by Jeremy Fowler 06 Sep '05

06 Sep '05

> > So your router and firewall are two separate machines? > Seems redundant to me, most firewalls do routing as well. > The only reason you would need a router is if the firewall > wasn't on the same subnet. > > No, it's standard practice for the ultraparanoid. > > The idea is, if your outer wall is compromised, hopefully you can > limit the damage > before Kevin Mitnick gets all the way into your shorts. > > You might want to put a honeypot in there too. Not in this scenario. The firewall is on the SAME subnet as the router and hosts. If the firewall was compromised, there would be nothing stopping it from attacking the rest of the hosts. In order to establish a DMZ, he needs to place the firewall on a separate subnet off from the rest of the network for it to be secured like in my second example. He would need to VLAN off that connection as well, or use a separate switch not connected to the LAN.

4 6

RE: routing problem - fork on gateways
by Jeremy Fowler 06 Sep '05

06 Sep '05

> what gets bypassed with established TCP connections > is the firewall rules, as an optimization for reducing CPU load > on firewall machines. That's TCP connections, not routes. > Routes must involve routers unless there is direct connection, > (or faking of direct connection through VPN bridging or something > like that) Nope, you can always source route a packet. Unless a host along the path filters them. However, in the case there is nothing to stop a application from source routing directly to the firewall and bypassing the router. However, the application would have to specifically do this as it is not done automatically.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

KCLUG September 2005