Two things: 1.) He was incorrect on some of what he stated. His "god like" ego and attitude does no one any good. 2.) His little wee-wee is no reason to put down and make fun of others. 3.) I appreciate everyone's help, but not from someone who represents 1 & 2 above. Anne -----Original Message----- From: redhat-list-bounces@xxxxxxxxxx [mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Bill Tangren Sent: Wednesday, December 05, 2007 3:18 PM To: General Red Hat Linux discussion list Subject: RE: red hat firewall question > <<The correct fix is to lart the sekuritee moron and change the > default keep alive value.>> > > ROFL! You poor guy, you must have a small little wee-wee to be so > pissed off at life. Why not get one of those wee-wee pump's to help > you?? > Anne, I read through what this person sent to you back-channel, and it seems that he was providing you with good ammunition to take to the firewall people to make the case that they shouldn't be so restrictive. He seems to be trying to help you. I don't understand 1) the ad hominem personal attack, and 2) why it was posted to the entire list. Personal attacks will make it less likely that people will take time out from their busy schedules to help you in the future. Just my $0.02. Take it for what it is worth to you. > > -----Original Message----- > From: redhat-list-bounces@xxxxxxxxxx > [mailto:redhat-list-bounces@xxxxxxxxxx] > On Behalf Of Steve Phillips > Sent: Tuesday, December 04, 2007 7:39 PM > To: General Red Hat Linux discussion list > Subject: Re: red hat firewall question > > Anne Moore wrote: >> Hi Marshall >> >> Well I've already determined that this will fix the issues. The >> problem is indeed with our firewall and it cannot be changed due to >> our security policy. Thus, I created a script that continually pings >> every 30 seconds and that keeps the logons alive. > > This is part of the problem with 'sekuritee people' that don't > actually understand the protocols. > > TCP Keepalives are supposed to work to allow servers to figure out > that persistent connections that have not sent data are still there - > the RFC states that this should not default to anything less than 2 > hours (its possible, but not advised) > > http://www.uic.rsu.ru/doc/inet/tcp_stevens/tcp_keep.htm for a good, > easy to read writeup > > http://www.faqs.org/rfcs/rfc1122.html is the host requirements RFC, > section > 4.2.3.6 deals with keep alives. > > There are a number of reasons for this default (explained nicely in > the first link) and most sekuritee people cause no end of headaches > for systems/network people when they start fiddling with this value in > the name of 'sekuritee !' > > It is completely normal for a TCP session to be idle, and it is also > completely normal for it to wake up hours later and send data, this is > simply how stuff works in the IP world, and what it appears is > happening is that your ssh sessions are (as would be expected) idle > for a few minutes and due to some sekuritee 'professional' deciding > that this could NEVER happen, your user sessions are being > disconnected. The correct fix is to lart the sekuritee moron and > change the default keep alive value. If they want to enforce logoff on > idle sessions then install or enable this on the servers. > Changing these values on a firewall can have some VERY undesirable and > difficult to fault-find consequences. (I had one instance where > someone had set the value to 30 mins, oracle was timing out > connections and things would sporadically work, not work, then semi > work - took the best part of a day to fault find.) > > The primary purpose of keep alives is to enable the host to not > exhaust its resources by having 65500 dead yet open telnet/ssh/tcp > sessions and being able to close these after a defined period., the > firewall not working in sync with the host just compounds this > problem, and depending on the number of users/types of processes, can > actually cause the problem that keep alives are supposed to prevent. > > > -- Bill Tangren U.S. Naval Observatory Ad eundum quo nemo ante iit -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
