From karlp at ourldsfamily.com Sat Oct 11 05:22:38 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Fri, 10 Oct 2008 23:22:38 -0600 (MDT) Subject: Sendmail? Message-ID: <1fe1d7d2d4b30bf2b7049d15b0823bfd.squirrel@webmail.ourldsfamily.com> What can I do so email from my server that fails doesn't have MAILER_DAEMON at NODOMAIN as the return address. The problem is these emails get hammered by Spamassassin... I probably missed something in setting up this new server because this wasn't an issue on the old one. I thought it was something in /etc/mail/sendmail.mc but can't see it... Fedora Core 4 vs Fedora 8 Sendmail Majordomo ... TIA --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- From ricks at nerd.com Mon Oct 13 16:53:18 2008 From: ricks at nerd.com (Rick Stevens) Date: Mon, 13 Oct 2008 09:53:18 -0700 Subject: Sendmail? In-Reply-To: <1fe1d7d2d4b30bf2b7049d15b0823bfd.squirrel@webmail.ourldsfamily.com> References: <1fe1d7d2d4b30bf2b7049d15b0823bfd.squirrel@webmail.ourldsfamily.com> Message-ID: <48F37CFE.1040706@nerd.com> Karl Pearson wrote: > What can I do so email from my server that fails doesn't have > MAILER_DAEMON at NODOMAIN as the return address. > > The problem is these emails get hammered by Spamassassin... I probably missed > something in setting up this new server because this wasn't an issue on the > old one. I thought it was something in /etc/mail/sendmail.mc but can't see > it... > > Fedora Core 4 vs Fedora 8 > Sendmail > Majordomo The "MAILER-DAEMON" stuff in error messages comes from the "Dn" option in sendmail.cf. I can't recall what the .mc thing is called and I don't have my bat book handy. The "NODOMAIN" stuff sounds like the domain isn't set for the mailer. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Grabel's Law: 2 is not equal to 3--not even for large values of 2. - ---------------------------------------------------------------------- From Andy.Q.Wu at seagate.com Mon Oct 13 16:56:18 2008 From: Andy.Q.Wu at seagate.com (Andy.Q.Wu at seagate.com) Date: Tue, 14 Oct 2008 00:56:18 +0800 Subject: Andy Q Wu/Seagate is out of the office. Message-ID: I will be out of the office starting 10/14/2008 and will not return until 10/16/2008. I will be on leave on Oct 14&15. Please contact EHunt for field tools software issue, Carlo for Disc Depot and STI issue. Any urgent issue please call my handphone 91776398. From karlp at ourldsfamily.com Mon Oct 13 17:23:32 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Mon, 13 Oct 2008 11:23:32 -0600 (MDT) Subject: Sendmail? In-Reply-To: <48F37CFE.1040706@nerd.com> References: <1fe1d7d2d4b30bf2b7049d15b0823bfd.squirrel@webmail.ourldsfamily.com> <48F37CFE.1040706@nerd.com> Message-ID: On Mon, 13 Oct 2008, Rick Stevens wrote: > Karl Pearson wrote: >> What can I do so email from my server that fails doesn't have >> MAILER_DAEMON at NODOMAIN as the return address. >> >> The problem is these emails get hammered by Spamassassin... I probably >> missed >> something in setting up this new server because this wasn't an issue on the >> old one. I thought it was something in /etc/mail/sendmail.mc but can't see >> it... >> >> Fedora Core 4 vs Fedora 8 >> Sendmail >> Majordomo > > The "MAILER-DAEMON" stuff in error messages comes from the "Dn" option > in sendmail.cf. I can't recall what the .mc thing is called and I don't > have my bat book handy. And I can't find mine... I guess that's about the same thing as not having it 'handy' for me. > > The "NODOMAIN" stuff sounds like the domain isn't set for the mailer. All other emails generated at the OS level have the correct domain. I'll go check and if I have to, I'll just modify sendmail.cf... Thanks, klp > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Grabel's Law: 2 is not equal to 3--not even for large values of 2. - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- From ricks at nerd.com Mon Oct 13 17:54:55 2008 From: ricks at nerd.com (Rick Stevens) Date: Mon, 13 Oct 2008 10:54:55 -0700 Subject: Sendmail? In-Reply-To: References: <1fe1d7d2d4b30bf2b7049d15b0823bfd.squirrel@webmail.ourldsfamily.com> <48F37CFE.1040706@nerd.com> Message-ID: <48F38B6F.8040900@nerd.com> Karl Pearson wrote: > On Mon, 13 Oct 2008, Rick Stevens wrote: > >> Karl Pearson wrote: >>> What can I do so email from my server that fails doesn't have >>> MAILER_DAEMON at NODOMAIN as the return address. >>> >>> The problem is these emails get hammered by Spamassassin... I >>> probably missed >>> something in setting up this new server because this wasn't an issue >>> on the >>> old one. I thought it was something in /etc/mail/sendmail.mc but >>> can't see >>> it... >>> >>> Fedora Core 4 vs Fedora 8 >>> Sendmail >>> Majordomo >> >> The "MAILER-DAEMON" stuff in error messages comes from the "Dn" option >> in sendmail.cf. I can't recall what the .mc thing is called and I don't >> have my bat book handy. > > And I can't find mine... I guess that's about the same thing as not > having it 'handy' for me. I put mine in a box in the garage when I changed jobs and haven't had a need for it here. Guess it's time to plow through that stuff again. The "Dn" option is the user name for error reporting. >> The "NODOMAIN" stuff sounds like the domain isn't set for the mailer. > > All other emails generated at the OS level have the correct domain. I'll > go check and if I have to, I'll just modify sendmail.cf... I'll find ye ol' bat book and report back tomorrow. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "Swap memory error: You lose your mind" - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Thu Oct 16 06:40:29 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 16 Oct 2008 00:40:29 -0600 (MDT) Subject: TCP? Message-ID: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> I have a new problem on my server. TCP connections are very slow. For example, if I # telnet localhost 25 I get the sendmail prompt immediately. But, if I do # telnet 172.20.20.2 25 I get connected immediately, but the sendmail prompt comes up about 2 minutes later. Same for 10.0.0.1. Both IPs are on the same host, different NICs. If I ssh to the machine, it's the same thing. This is causing email to time-out and is not sent. I've checked DNS and bad NICs, but nothing looks bad. Nothing has changed from my standpoint. I've rebooted my switches and firewall and still nothing changes. I ran chkrootkit and see nothing different from when things were running smoothly. I do have a lot of things in my iptables, so I did iptables -F and tried sending an email. It still timed out... Any thoughts? --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Thu Oct 16 17:22:16 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 16 Oct 2008 10:22:16 -0700 Subject: TCP? In-Reply-To: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> Message-ID: <48F77848.5020305@nerd.com> Karl Pearson wrote: > I have a new problem on my server. TCP connections are very slow. > > For example, if I > > # telnet localhost 25 > > I get the sendmail prompt immediately. But, if I do > > # telnet 172.20.20.2 25 > > I get connected immediately, but the sendmail prompt comes up about 2 minutes > later. Same for 10.0.0.1. Both IPs are on the same host, different NICs. > > If I ssh to the machine, it's the same thing. This is causing email to > time-out and is not sent. > > I've checked DNS and bad NICs, but nothing looks bad. Nothing has changed from > my standpoint. I've rebooted my switches and firewall and still nothing > changes. I ran chkrootkit and see nothing different from when things were > running smoothly. > > I do have a lot of things in my iptables, so I did > > iptables -F > > and tried sending an email. It still timed out... > > Any thoughts? This is a DNS issue. Both sendmail and ssh are trying to find out where the connection is coming from by doing a reverse DNS lookup on the client IP. If there is no DNS service OR there's no "PTR" records in DNS which correspond with the IP the client is presenting, the system will take a LONG time before they time out and operations continue. For ssh, you can edit the /etc/ssh/sshd_config file and set UseDNS no (the default is "UseDNS yes"). There is a similar type of option in sendmail, but I don't have my bat book handy to tell you what it is. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - If you can't beat your computer at chess...try kickboxing! - ---------------------------------------------------------------------- From ricks at nerd.com Thu Oct 16 17:31:36 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 16 Oct 2008 10:31:36 -0700 Subject: TCP? In-Reply-To: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> Message-ID: <48F77A78.3030501@nerd.com> I should have mentioned that you'll need to "service sshd restart" after making the change to sshd_config. You'll need to restart sendmail as well if you change its config. And if you're asking "why doesn't it fail when I specify 'localhost'?" remember that localhost is in your /etc/hosts file. When you "ssh localhost" or "telnet localhost 25", the host AND CLIENT IPs are 127.0.0.1 which corresponds to "localhost" in /etc/hosts. I try to give full explanations when I post and I missed it that time. Sorry! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - When you don't know what to do, walk fast and look worried. - ---------------------------------------------------------------------- From Travis.R.Waldher at boeing.com Thu Oct 16 17:38:20 2008 From: Travis.R.Waldher at boeing.com (Waldher, Travis R) Date: Thu, 16 Oct 2008 10:38:20 -0700 Subject: Performance reporting issues. Message-ID: I'm having an odd issue where SAR is reporting wildly different stats than what the system is doing. I'm not sure where sa is pulling it's numbers from but I definitely don't and haven't had the CPUs running 36% for users and 63% for system for a long time. It's more likely the system had been idle. Any ideas? $ sar -H -t -u -f /var/log/sa/sa16 ;600;2008-10-16 09:10:01;-1;33.36;0.00;66.25;0.40;0.00 ;599;2008-10-16 09:20:01;-1;34.35;0.00;65.21;0.44;0.00 ;600;2008-10-16 09:30:01;-1;34.51;0.00;65.06;0.42;0.00 $ top top - 09:38:52 up 130 days, 3:08, 2 users, load average: 0.07, 0.03, 0.01 Tasks: 129 total, 1 running, 127 sleeping, 0 stopped, 1 zombie Cpu0 : 0.1% us, 0.3% sy, 0.0% ni, 99.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 0.2% us, 0.3% sy, 0.0% ni, 99.5% id, 0.0% wa, 0.0% hi, 0.0% si Cpu2 : 0.1% us, 0.3% sy, 0.0% ni, 99.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.1% us, 0.1% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si Cpu4 : 0.1% us, 0.1% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si Cpu5 : 0.1% us, 0.1% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si Cpu6 : 0.0% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si Cpu7 : 0.1% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlp at ourldsfamily.com Thu Oct 16 17:47:50 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 16 Oct 2008 11:47:50 -0600 (MDT) Subject: TCP? In-Reply-To: <48F77A78.3030501@nerd.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> <48F77A78.3030501@nerd.com> Message-ID: <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> On Thu, October 16, 2008 11:31 am, Rick Stevens wrote: > I should have mentioned that you'll need to "service sshd restart" after > making the change to sshd_config. You'll need to restart sendmail as > well if you change its config. > > And if you're asking "why doesn't it fail when I specify 'localhost'?" > remember that localhost is in your /etc/hosts file. When you "ssh > localhost" or "telnet localhost 25", the host AND CLIENT IPs are > 127.0.0.1 which corresponds to "localhost" in /etc/hosts. > > I try to give full explanations when I post and I missed it that time. > Sorry! I had already tried DNS settings. I edited nsswitch.conf and changed it to files first, then dns, with this line: hosts: files dns [NOTFOUND=return] files and made sure the IPs are in /etc/hosts, which they already were. One email went out with alpine from another PC, but nothing more and it took just about long enough to time out. Watching it in ps ax showed startup with 172.20.20.100 then cmd read: 172.20.20.100 but all the other ones show the startup line only, then when it times out on the client, it changes from the IP to the entry in the hosts file. It's like something is preventing things from moving. I'm wondering if I have a bad cable or switch. I am going to try sshd_config right now and see if that works. Remember, this is the box that got duplicate libs which I had to manually delete. There are a few duplicates again. It may not be related.... Okay, changing UseDNS no didn't help at all. Still taking a couple minutes to connect via ssh. Karl > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - When you don't know what to do, walk fast and look worried. - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Thu Oct 16 18:05:45 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 16 Oct 2008 11:05:45 -0700 Subject: TCP? In-Reply-To: <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> <48F77A78.3030501@nerd.com> <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> Message-ID: <48F78279.3060403@nerd.com> Karl Pearson wrote: > On Thu, October 16, 2008 11:31 am, Rick Stevens wrote: >> I should have mentioned that you'll need to "service sshd restart" after >> making the change to sshd_config. You'll need to restart sendmail as >> well if you change its config. >> >> And if you're asking "why doesn't it fail when I specify 'localhost'?" >> remember that localhost is in your /etc/hosts file. When you "ssh >> localhost" or "telnet localhost 25", the host AND CLIENT IPs are >> 127.0.0.1 which corresponds to "localhost" in /etc/hosts. >> >> I try to give full explanations when I post and I missed it that time. >> Sorry! > > I had already tried DNS settings. I edited nsswitch.conf and changed it to > files first, then dns, with this line: > hosts: files dns [NOTFOUND=return] files > > and made sure the IPs are in /etc/hosts, which they already were. One email > went out with alpine from another PC, but nothing more and it took just about > long enough to time out. Watching it in ps ax showed > > startup with 172.20.20.100 > then > cmd read: 172.20.20.100 > > but all the other ones show the startup line only, then when it times out on > the client, it changes from the IP to the entry in the hosts file. It's like > something is preventing things from moving. I'm wondering if I have a bad > cable or switch. > > I am going to try sshd_config right now and see if that works. Remember, this > is the box that got duplicate libs which I had to manually delete. There are a > few duplicates again. It may not be related.... > > Okay, changing UseDNS no didn't help at all. Still taking a couple minutes to > connect via ssh. Ok, then check your default routes, "netstat -rn" and verify that the one with "UG" is indeed your default gateway. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Hard work has a future payoff. Laziness pays off now. - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Thu Oct 16 18:22:27 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 16 Oct 2008 12:22:27 -0600 (MDT) Subject: TCP? In-Reply-To: <48F78279.3060403@nerd.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> <48F77A78.3030501@nerd.com> <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> <48F78279.3060403@nerd.com> Message-ID: <1e6e078e7582798115571b13c4cdea61.squirrel@webmail.ourldsfamily.com> On Thu, October 16, 2008 12:05 pm, Rick Stevens wrote: > Karl Pearson wrote: >> On Thu, October 16, 2008 11:31 am, Rick Stevens wrote: >>> I should have mentioned that you'll need to "service sshd restart" after >>> making the change to sshd_config. You'll need to restart sendmail as >>> well if you change its config. >>> >>> And if you're asking "why doesn't it fail when I specify 'localhost'?" >>> remember that localhost is in your /etc/hosts file. When you "ssh >>> localhost" or "telnet localhost 25", the host AND CLIENT IPs are >>> 127.0.0.1 which corresponds to "localhost" in /etc/hosts. >>> >>> I try to give full explanations when I post and I missed it that time. >>> Sorry! >> >> I had already tried DNS settings. I edited nsswitch.conf and changed it to >> files first, then dns, with this line: >> hosts: files dns [NOTFOUND=return] files >> >> and made sure the IPs are in /etc/hosts, which they already were. One email >> went out with alpine from another PC, but nothing more and it took just >> about >> long enough to time out. Watching it in ps ax showed >> >> startup with 172.20.20.100 >> then >> cmd read: 172.20.20.100 >> >> but all the other ones show the startup line only, then when it times out on >> the client, it changes from the IP to the entry in the hosts file. It's like >> something is preventing things from moving. I'm wondering if I have a bad >> cable or switch. >> >> I am going to try sshd_config right now and see if that works. Remember, >> this >> is the box that got duplicate libs which I had to manually delete. There are >> a >> few duplicates again. It may not be related.... >> >> Okay, changing UseDNS no didn't help at all. Still taking a couple minutes >> to >> connect via ssh. > > Ok, then check your default routes, "netstat -rn" and verify that the > one with "UG" is indeed your default gateway. It checks out okay. I'm not sure how, but it works fine. Let me 'splain... In checking for things in /etc/mail/sendmail.mc and /etc/mail/submit.mc I found that one can just type make (or make -C /etc/mail) in /etc/mail and submit.mc will be transferred to submit.cf as if m4 had been run. Same with sendmail.mc I've also seen that using make restart works on some distros, and so tried it, and that works, too. In any case, that's not the apparent solution, which IS DNS related, but not in the way you or I thought. I changed the line in sendmail.mc: FEATURE(`accept_unresolvable_domains')dnl to dnl FEATURE(`accept_unresolvable_domains')dnl and things started working again as they had several days ago. Now then, please understand that nothing had been changed on the server at all. Nothing. That's why I still think there may be a hardware issue somewhere. The feature above has been enabled since the system was installed 7 weeks ago. Thoughts? Karl > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Hard work has a future payoff. Laziness pays off now. - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Thu Oct 16 19:03:03 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 16 Oct 2008 12:03:03 -0700 Subject: TCP? In-Reply-To: <1e6e078e7582798115571b13c4cdea61.squirrel@webmail.ourldsfamily.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> <48F77A78.3030501@nerd.com> <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> <48F78279.3060403@nerd.com> <1e6e078e7582798115571b13c4cdea61.squirrel@webmail.ourldsfamily.com> Message-ID: <48F78FE7.1080005@nerd.com> Karl Pearson wrote: > On Thu, October 16, 2008 12:05 pm, Rick Stevens wrote: >> Karl Pearson wrote: >>> On Thu, October 16, 2008 11:31 am, Rick Stevens wrote: >>>> I should have mentioned that you'll need to "service sshd restart" after >>>> making the change to sshd_config. You'll need to restart sendmail as >>>> well if you change its config. >>>> >>>> And if you're asking "why doesn't it fail when I specify 'localhost'?" >>>> remember that localhost is in your /etc/hosts file. When you "ssh >>>> localhost" or "telnet localhost 25", the host AND CLIENT IPs are >>>> 127.0.0.1 which corresponds to "localhost" in /etc/hosts. >>>> >>>> I try to give full explanations when I post and I missed it that time. >>>> Sorry! >>> I had already tried DNS settings. I edited nsswitch.conf and changed it to >>> files first, then dns, with this line: >>> hosts: files dns [NOTFOUND=return] files >>> >>> and made sure the IPs are in /etc/hosts, which they already were. One email >>> went out with alpine from another PC, but nothing more and it took just >>> about >>> long enough to time out. Watching it in ps ax showed >>> >>> startup with 172.20.20.100 >>> then >>> cmd read: 172.20.20.100 >>> >>> but all the other ones show the startup line only, then when it times out on >>> the client, it changes from the IP to the entry in the hosts file. It's like >>> something is preventing things from moving. I'm wondering if I have a bad >>> cable or switch. >>> >>> I am going to try sshd_config right now and see if that works. Remember, >>> this >>> is the box that got duplicate libs which I had to manually delete. There are >>> a >>> few duplicates again. It may not be related.... >>> >>> Okay, changing UseDNS no didn't help at all. Still taking a couple minutes >>> to >>> connect via ssh. >> Ok, then check your default routes, "netstat -rn" and verify that the >> one with "UG" is indeed your default gateway. > > It checks out okay. Okey doke. Just checking. With updates and such (and that goddamn POS called "NetworkManager"), anything's possible. > I'm not sure how, but it works fine. Let me 'splain... > > In checking for things in /etc/mail/sendmail.mc and /etc/mail/submit.mc I > found that one can just type > > make (or make -C /etc/mail) > > in /etc/mail and submit.mc will be transferred to submit.cf as if m4 had been > run. Same with sendmail.mc Actually, sendmail.cf is the output of m4 after processing sendmail.mc (and others). > I've also seen that using make restart works on some distros, and so tried it, > and that works, too. Most of them to a "cd /etc/mail;make" before they actually start sendmail (either in a "restart" or a "start" scenario). > In any case, that's not the apparent solution, which IS DNS related, but not > in the way you or I thought. I changed the line in sendmail.mc: > > FEATURE(`accept_unresolvable_domains')dnl > > to > > dnl FEATURE(`accept_unresolvable_domains')dnl > > and things started working again as they had several days ago. Now then, > please understand that nothing had been changed on the server at all. Nothing. > That's why I still think there may be a hardware issue somewhere. The feature > above has been enabled since the system was installed 7 weeks ago. Yes, anything that's to be put into the sendmail.cf must begin with "dnl". Things without "dnl" are directives to m4 itself. BTW, m4 is a right pain in the arse...why sendmail.org decided to standardize on it is beyond my comprehension. As far as DNS issues are concerned...well, there's much to check. Verify that /etc/resolv.conf has the actual DNS servers in it and verify you can ping them from the host in question. In some cases, your router does DNS for you via a proxy. Next, verify that you have TCP and UDP port 53 open so DNS queries can be handled, both in the iptables config and in your external firewall (amazing how many of them block DNS). You can use "related,established" in your iptables rules if you are concerned about security. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Polygon: A dead parrot (With apologies to John Cleese) - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Thu Oct 16 19:23:21 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 16 Oct 2008 13:23:21 -0600 (MDT) Subject: TCP? In-Reply-To: <48F78FE7.1080005@nerd.com> References: <873be29d4b02aed5fa5faa8b3c21b967.squirrel@webmail.ourldsfamily.com> <48F77A78.3030501@nerd.com> <72e6a89a0194265e6066941148ee2ee8.squirrel@webmail.ourldsfamily.com> <48F78279.3060403@nerd.com> <1e6e078e7582798115571b13c4cdea61.squirrel@webmail.ourldsfamily.com> <48F78FE7.1080005@nerd.com> Message-ID: On Thu, 16 Oct 2008, Rick Stevens wrote: > Karl Pearson wrote: >> On Thu, October 16, 2008 12:05 pm, Rick Stevens wrote: >>> Karl Pearson wrote: >>>> On Thu, October 16, 2008 11:31 am, Rick Stevens wrote: >>>>> I should have mentioned that you'll need to "service sshd restart" after >>>>> making the change to sshd_config. You'll need to restart sendmail as >>>>> well if you change its config. >>>>> >>>>> And if you're asking "why doesn't it fail when I specify 'localhost'?" >>>>> remember that localhost is in your /etc/hosts file. When you "ssh >>>>> localhost" or "telnet localhost 25", the host AND CLIENT IPs are >>>>> 127.0.0.1 which corresponds to "localhost" in /etc/hosts. >>>>> >>>>> I try to give full explanations when I post and I missed it that time. >>>>> Sorry! >>>> I had already tried DNS settings. I edited nsswitch.conf and changed it >>>> to >>>> files first, then dns, with this line: >>>> hosts: files dns [NOTFOUND=return] files >>>> >>>> and made sure the IPs are in /etc/hosts, which they already were. One >>>> email >>>> went out with alpine from another PC, but nothing more and it took just >>>> about >>>> long enough to time out. Watching it in ps ax showed >>>> >>>> startup with 172.20.20.100 >>>> then >>>> cmd read: 172.20.20.100 >>>> >>>> but all the other ones show the startup line only, then when it times out >>>> on >>>> the client, it changes from the IP to the entry in the hosts file. It's >>>> like >>>> something is preventing things from moving. I'm wondering if I have a bad >>>> cable or switch. >>>> >>>> I am going to try sshd_config right now and see if that works. Remember, >>>> this >>>> is the box that got duplicate libs which I had to manually delete. There >>>> are >>>> a >>>> few duplicates again. It may not be related.... >>>> >>>> Okay, changing UseDNS no didn't help at all. Still taking a couple >>>> minutes >>>> to >>>> connect via ssh. >>> Ok, then check your default routes, "netstat -rn" and verify that the >>> one with "UG" is indeed your default gateway. >> >> It checks out okay. > > Okey doke. Just checking. With updates and such (and that goddamn > POS called "NetworkManager"), anything's possible. I disable NetworkMangler on my servers at install time. > >> I'm not sure how, but it works fine. Let me 'splain... >> >> In checking for things in /etc/mail/sendmail.mc and /etc/mail/submit.mc I >> found that one can just type >> >> make (or make -C /etc/mail) >> >> in /etc/mail and submit.mc will be transferred to submit.cf as if m4 had >> been >> run. Same with sendmail.mc > > Actually, sendmail.cf is the output of m4 after processing sendmail.mc > (and others). Yes, nice, huh? Why doesn't sendmail.cf actually act like a .conf file one can just modify? Like I haven't manually modified them for years anyway :) > >> I've also seen that using make restart works on some distros, and so tried >> it, >> and that works, too. > > Most of them to a "cd /etc/mail;make" before they actually start > sendmail (either in a "restart" or a "start" scenario). Yes, but new to me. > >> In any case, that's not the apparent solution, which IS DNS related, but >> not >> in the way you or I thought. I changed the line in sendmail.mc: >> >> FEATURE(`accept_unresolvable_domains')dnl >> >> to >> >> dnl FEATURE(`accept_unresolvable_domains')dnl >> >> and things started working again as they had several days ago. Now then, >> please understand that nothing had been changed on the server at all. >> Nothing. >> That's why I still think there may be a hardware issue somewhere. The >> feature >> above has been enabled since the system was installed 7 weeks ago. > > Yes, anything that's to be put into the sendmail.cf must begin with > "dnl". Things without "dnl" are directives to m4 itself. dnl is the starting line of a not-to-be-used feature, so adding dnl turned it off. Or am I missing something? > > BTW, m4 is a right pain in the arse...why sendmail.org decided to standardize > on it is beyond my comprehension. Yes it is. Which is why I was happy to see that 'make' does the same thing now. > > As far as DNS issues are concerned...well, there's much to check. > Verify that /etc/resolv.conf has the actual DNS servers in it and verify > you can ping them from the host in question. In some cases, your router > does DNS for you via a proxy. I had checked that stuff before emailing the list. I should have mentioned it. The solution isn't a real solution as some email still times out, but the majority is able to be delivered to port 25 > > Next, verify that you have TCP and UDP port 53 open so DNS queries can > be handled, both in the iptables config and in your external firewall > (amazing how many of them block DNS). You can use "related,established" > in your iptables rules if you are concerned about security. DNS is open. I do my own DNS and my ISP 'secondary's my changes on a schedule based on serial. iptables is set to related,established already. That's been in place for a few years now across server upgrades. But, like email sending, ssh is now slow again... But not as slow as before. I'm still leaning toward hardware being the issue, though I haven't been able to track it down yet. One thing I just tried for grins and giggles is to switch nsswitch.conf from: hosts: dns files to hosts: files dns and things seem much faster again. But, that was at dns files forever (okay, seven weeks on this server). Karl > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Polygon: A dead parrot (With apologies to John Cleese) - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- From karlp at ourldsfamily.com Tue Oct 21 00:54:23 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Mon, 20 Oct 2008 18:54:23 -0600 (MDT) Subject: IPTables limits? Message-ID: I'm curious if there's a limit on how many iptables entries it takes to hammer a system. Okay, a better question: When am I running the risk of messing up my IP traffic if I add DROP entries in the INPUT rule of iptables? The machine in question acts as a small gateway for one subnet behind a Smoothwall 3.0 gateway that is the gateway for it and the rest of the network. The machine is a single core AMD 64 3200+ with 2GB of ram running 32-bit Fedora 8. --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- From ricks at nerd.com Tue Oct 21 17:16:15 2008 From: ricks at nerd.com (Rick Stevens) Date: Tue, 21 Oct 2008 10:16:15 -0700 Subject: IPTables limits? In-Reply-To: References: Message-ID: <48FE0E5F.1000806@nerd.com> Karl Pearson wrote: > I'm curious if there's a limit on how many iptables entries it takes to > hammer a system. Okay, a better question: When am I running the risk of > messing up my IP traffic if I add DROP entries in the INPUT rule of > iptables? You do ask the damndest questions, Karl! :-) I've never seen a document that describes any rule limits. It is a kernel module, so one must assume there is some limit. It may be that a spelunking sesion through the source might answer that. I've got lots of drop entries on my rules and haven't had any issues, but I'm always guided by the concept that the more rules a packet must traverse, the slower the connection will be at startup. Therefore I order my rules carefully putting the more generic rules at the top of the list and the more specific ones at the bottom. That may not work for you...every network is a little different (for example, we blacklist entire /8 networks in some cases because of DOS or hack attacks from those countries). > The machine in question acts as a small gateway for one subnet behind a > Smoothwall 3.0 gateway that is the gateway for it and the rest of the > network. > > The machine is a single core AMD 64 3200+ with 2GB of ram running 32-bit > Fedora 8. Should have plenty of headroom to do what you want with that. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - The gene pool could use a little chlorine. - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Tue Oct 21 17:34:02 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Tue, 21 Oct 2008 11:34:02 -0600 (MDT) Subject: IPTables limits? In-Reply-To: <48FE0E5F.1000806@nerd.com> References: <48FE0E5F.1000806@nerd.com> Message-ID: On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: > Karl Pearson wrote: >> I'm curious if there's a limit on how many iptables entries it takes >> to >> hammer a system. Okay, a better question: When am I running the risk >> of >> messing up my IP traffic if I add DROP entries in the INPUT rule of >> iptables? > > You do ask the damndest questions, Karl! :-) > > I've never seen a document that describes any rule limits. It is a > kernel module, so one must assume there is some limit. It may be that > a spelunking sesion through the source might answer that. > > I've got lots of drop entries on my rules and haven't had any issues, > but I'm always guided by the concept that the more rules a packet must > traverse, the slower the connection will be at startup. Therefore I > order my rules carefully putting the more generic rules at the top of > the list and the more specific ones at the bottom. That may not work > for you...every network is a little different (for example, we blacklist > entire /8 networks in some cases because of DOS or hack attacks from > those countries). I'd love a list of those IPs and how you inserted the rule. I also wonder about DROP vs REJECT. I know the difference, but what's the theory behind using one over the other? I have thought it is about them knowing the IP is there vs just a hang. But, I'm wondering if the DROP (hang) causes me any headaches in IP traffic limiting? I know, another annoying question. All my DROPs are in the first rule, so they are immediately acted on, or in this case, DROPped. I used to use sshblack, but the way the logfiles are written now make it ineffective for inbound, however I wrote my own blacklist scripts which I use with it, so it does do aging checks, which for DDNS is okay, I think. I have installed fail2ban, which blacklists for a shorter amount of time, I suspect under the theory that ssh attacks are almost random, and will pass. > >> The machine in question acts as a small gateway for one subnet behind >> a >> Smoothwall 3.0 gateway that is the gateway for it and the rest of the >> network. >> >> The machine is a single core AMD 64 3200+ with 2GB of ram running >> 32-bit >> Fedora 8. I suspected it might be okay, but since my desktop is a quad-core with 2GB of ram and 32-bit (Linux Mint on it) I wondered if it would have enough horse power to keep the iptables rules happy. Karl > > Should have plenty of headroom to do what you want with that. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - The gene pool could use a little chlorine. - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Tue Oct 21 18:12:15 2008 From: ricks at nerd.com (Rick Stevens) Date: Tue, 21 Oct 2008 11:12:15 -0700 Subject: IPTables limits? In-Reply-To: References: <48FE0E5F.1000806@nerd.com> Message-ID: <48FE1B7F.1030503@nerd.com> Karl Pearson wrote: > On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: >> Karl Pearson wrote: >>> I'm curious if there's a limit on how many iptables entries it takes >>> to >>> hammer a system. Okay, a better question: When am I running the risk >>> of >>> messing up my IP traffic if I add DROP entries in the INPUT rule of >>> iptables? >> You do ask the damndest questions, Karl! :-) >> >> I've never seen a document that describes any rule limits. It is a >> kernel module, so one must assume there is some limit. It may be that >> a spelunking sesion through the source might answer that. >> >> I've got lots of drop entries on my rules and haven't had any issues, >> but I'm always guided by the concept that the more rules a packet must >> traverse, the slower the connection will be at startup. Therefore I >> order my rules carefully putting the more generic rules at the top of >> the list and the more specific ones at the bottom. That may not work >> for you...every network is a little different (for example, we blacklist >> entire /8 networks in some cases because of DOS or hack attacks from >> those countries). > > I'd love a list of those IPs and how you inserted the rule. Oh, man, I'd have to go through our firewall configs to dig up the addresses involved. As far as the rule insertion, it's pretty much a standard iptables insert, but we add a "--syn" for TCP and just simply block UDP. These are interim...eventually we migrate these rules out to our Foundry or Cisco routers and remove them from the individual servers. > I also > wonder about DROP vs REJECT. I know the difference, but what's the > theory behind using one over the other? I have thought it is about them > knowing the IP is there vs just a hang. But, I'm wondering if the DROP > (hang) causes me any headaches in IP traffic limiting? I know, another > annoying question. We use DROP. If we're under attack or someone's probing, why let them know they found a machine? If anything, a DROP is easier on the system than a REJECT since all the system does is drop the connection...it doesn't send anything back. And if the prober/attacker's connection hangs at his end, good! Screw them in the first place. Attackers and probers deserve absolutely no consideration in any way and should be prosecuted in the same manner as someone trying to break into my home or office. > All my DROPs are in the first rule, so they are immediately acted on, or > in this case, DROPped. > > I used to use sshblack, but the way the logfiles are written now make it > ineffective for inbound, however I wrote my own blacklist scripts which > I use with it, so it does do aging checks, which for DDNS is okay, I > think. For SSH issues, I have a standard ruleset. Here it is from the /etc/sysconfig/iptables file: # This rejects ssh attempts more than twice in 180 seconds... # First, mark attempts as part of the "sshattack" group... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set # Optional: Include this line if you want to log these attacks... #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " # Finally, reject the connection if more than one attempt is made in 180 seconds... -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset So, you only get to try to SSH once every 3 minutes. You can tweak the "--hitcount" value and "--seconds" value to customize it for your use. It foils most of the script kiddies out there. > I have installed fail2ban, which blacklists for a shorter amount of > time, I suspect under the theory that ssh attacks are almost random, and > will pass. Yeah, it works. Mine has minimal impact on the rulesets, but either is fine. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Death is nature's way of dropping carrier - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Tue Oct 21 18:55:45 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Tue, 21 Oct 2008 12:55:45 -0600 (MDT) Subject: IPTables limits? In-Reply-To: <48FE1B7F.1030503@nerd.com> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> Message-ID: <935eb6d5192f8f323aff3ee437028821.squirrel@webmail.ourldsfamily.com> On Tue, October 21, 2008 12:12 pm, Rick Stevens wrote: > Karl Pearson wrote: >> On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: >>> Karl Pearson wrote: >>>> I'm curious if there's a limit on how many iptables entries it takes >>>> to >>>> hammer a system. Okay, a better question: When am I running the risk >>>> of >>>> messing up my IP traffic if I add DROP entries in the INPUT rule of >>>> iptables? >>> You do ask the damndest questions, Karl! :-) >>> >>> I've never seen a document that describes any rule limits. It is a >>> kernel module, so one must assume there is some limit. It may be >>> that >>> a spelunking sesion through the source might answer that. >>> >>> I've got lots of drop entries on my rules and haven't had any issues, >>> but I'm always guided by the concept that the more rules a packet >>> must >>> traverse, the slower the connection will be at startup. Therefore I >>> order my rules carefully putting the more generic rules at the top of >>> the list and the more specific ones at the bottom. That may not work >>> for you...every network is a little different (for example, we >>> blacklist >>> entire /8 networks in some cases because of DOS or hack attacks from >>> those countries). >> >> I'd love a list of those IPs and how you inserted the rule. > > Oh, man, I'd have to go through our firewall configs to dig up the > addresses involved. As far as the rule insertion, it's pretty much > a standard iptables insert, but we add a "--syn" for TCP and just > simply block UDP. These are interim...eventually we migrate these > rules out to our Foundry or Cisco routers and remove them from the > individual servers. > >> I also >> wonder about DROP vs REJECT. I know the difference, but what's the >> theory behind using one over the other? I have thought it is about >> them >> knowing the IP is there vs just a hang. But, I'm wondering if the DROP >> (hang) causes me any headaches in IP traffic limiting? I know, another >> annoying question. > > We use DROP. If we're under attack or someone's probing, why let them > know they found a machine? If anything, a DROP is easier on the system > than a REJECT since all the system does is drop the connection...it > doesn't send anything back. And if the prober/attacker's connection > hangs at his end, good! Screw them in the first place. Attackers > and probers deserve absolutely no consideration in any way and should > be prosecuted in the same manner as someone trying to break into my home > or office. > >> All my DROPs are in the first rule, so they are immediately acted on, >> or >> in this case, DROPped. >> >> I used to use sshblack, but the way the logfiles are written now make >> it >> ineffective for inbound, however I wrote my own blacklist scripts >> which >> I use with it, so it does do aging checks, which for DDNS is okay, I >> think. > > For SSH issues, I have a standard ruleset. Here it is from the > /etc/sysconfig/iptables file: > > # This rejects ssh attempts more than twice in 180 seconds... > # First, mark attempts as part of the "sshattack" group... > -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set > # Optional: Include this line if you want to log these attacks... > #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck > --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " > # Finally, reject the connection if more than one attempt is made in 180 > seconds... > -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck > --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset The iptables file doesn't exist, so is it checked only if it's there? I have /etc/sysconfig/iptables-config which doesn't look like I ought to mess with. I like your rule better than using sshblack or fail2ban. it's simple and doesn't require a daemon to be running all the time, other than the already running iptables. Thanks... > > So, you only get to try to SSH once every 3 minutes. You can tweak the > "--hitcount" value and "--seconds" value to customize it for your use. > It foils most of the script kiddies out there. > >> I have installed fail2ban, which blacklists for a shorter amount of >> time, I suspect under the theory that ssh attacks are almost random, >> and >> will pass. > > Yeah, it works. Mine has minimal impact on the rulesets, but either > is fine. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Death is nature's way of dropping carrier - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Tue Oct 21 21:40:55 2008 From: ricks at nerd.com (Rick Stevens) Date: Tue, 21 Oct 2008 14:40:55 -0700 Subject: IPTables limits? In-Reply-To: <935eb6d5192f8f323aff3ee437028821.squirrel@webmail.ourldsfamily.com> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> <935eb6d5192f8f323aff3ee437028821.squirrel@webmail.ourldsfamily.com> Message-ID: <48FE4C67.1060008@nerd.com> Karl Pearson wrote: > On Tue, October 21, 2008 12:12 pm, Rick Stevens wrote: >> Karl Pearson wrote: >>> On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: >>>> Karl Pearson wrote: >>>>> I'm curious if there's a limit on how many iptables entries it takes >>>>> to >>>>> hammer a system. Okay, a better question: When am I running the risk >>>>> of >>>>> messing up my IP traffic if I add DROP entries in the INPUT rule of >>>>> iptables? >>>> You do ask the damndest questions, Karl! :-) >>>> >>>> I've never seen a document that describes any rule limits. It is a >>>> kernel module, so one must assume there is some limit. It may be >>>> that >>>> a spelunking sesion through the source might answer that. >>>> >>>> I've got lots of drop entries on my rules and haven't had any issues, >>>> but I'm always guided by the concept that the more rules a packet >>>> must >>>> traverse, the slower the connection will be at startup. Therefore I >>>> order my rules carefully putting the more generic rules at the top of >>>> the list and the more specific ones at the bottom. That may not work >>>> for you...every network is a little different (for example, we >>>> blacklist >>>> entire /8 networks in some cases because of DOS or hack attacks from >>>> those countries). >>> I'd love a list of those IPs and how you inserted the rule. >> Oh, man, I'd have to go through our firewall configs to dig up the >> addresses involved. As far as the rule insertion, it's pretty much >> a standard iptables insert, but we add a "--syn" for TCP and just >> simply block UDP. These are interim...eventually we migrate these >> rules out to our Foundry or Cisco routers and remove them from the >> individual servers. >> >>> I also >>> wonder about DROP vs REJECT. I know the difference, but what's the >>> theory behind using one over the other? I have thought it is about >>> them >>> knowing the IP is there vs just a hang. But, I'm wondering if the DROP >>> (hang) causes me any headaches in IP traffic limiting? I know, another >>> annoying question. >> We use DROP. If we're under attack or someone's probing, why let them >> know they found a machine? If anything, a DROP is easier on the system >> than a REJECT since all the system does is drop the connection...it >> doesn't send anything back. And if the prober/attacker's connection >> hangs at his end, good! Screw them in the first place. Attackers >> and probers deserve absolutely no consideration in any way and should >> be prosecuted in the same manner as someone trying to break into my home >> or office. >> >>> All my DROPs are in the first rule, so they are immediately acted on, >>> or >>> in this case, DROPped. >>> >>> I used to use sshblack, but the way the logfiles are written now make >>> it >>> ineffective for inbound, however I wrote my own blacklist scripts >>> which >>> I use with it, so it does do aging checks, which for DDNS is okay, I >>> think. >> For SSH issues, I have a standard ruleset. Here it is from the >> /etc/sysconfig/iptables file: >> >> # This rejects ssh attempts more than twice in 180 seconds... >> # First, mark attempts as part of the "sshattack" group... >> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set >> # Optional: Include this line if you want to log these attacks... >> #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck >> --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " >> # Finally, reject the connection if more than one attempt is made in 180 >> seconds... >> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck >> --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset > > The iptables file doesn't exist, so is it checked only if it's there? I > have /etc/sysconfig/iptables-config which doesn't look like I ought to > mess with. /etc/sysconfig/iptables is the normal spot for rules to go in. The /etc/sysconfig/iptables-config specifies what happens on startup and shutdown. I did change the following parameters: IPTABLES_SAVE_ON_STOP="yes" IPTABLES_SAVE_ON_RESTART="yes" The defaults are "no". Now, with those set up, I put my rules in /etc/sysconfig/iptables and they're loaded with iptables starts up. Consequently, if I do any iptables commands, the config changes I made above will make the system save what is NOW in iptables into that file so they'll be restored on the next boot or "service iptables restart" command. The format of the /etc/sysconfig/iptables file is different from the normal command, as it's actually the input (or output) of the iptables-save (or iptables-restore) command. Essentially, you introduce a table (such as "nat" or "filter") with an "*" and the filter name. For example, *filter introduces rules for the filter table. From this point in the file until the next "*" or end of file, all rules affect the "filter" table. To set the default policy for a chain, you use ":" followed by the chain name, then the default policy. You can also use square brackets to set the input and output counters ("[input-ctr:output-ctr]"). Example, to set a default policy of DROP for the INPUT chain in the filter table and clear its input counter to 12 and its output to 0: *filter :INPUT DROP [12:0] To add rules to it, use the normal iptables command syntax, but without the actual iptables command and without the "-t tablename" stuff (since you're in the section of the file for that table): *filter -A INPUT (insert regular rule here) -A INPUT (insert regular rule here) and so on. Blank lines and anything following a "#" are considered comments. > I like your rule better than using sshblack or fail2ban. it's simple and > doesn't require a daemon to be running all the time, other than the > already running iptables. It does have that charm as well. :-) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - When all else fails, try reading the instructions. - ---------------------------------------------------------------------- From ricks at nerd.com Tue Oct 21 21:44:22 2008 From: ricks at nerd.com (Rick Stevens) Date: Tue, 21 Oct 2008 14:44:22 -0700 Subject: IPTables limits? In-Reply-To: <935eb6d5192f8f323aff3ee437028821.squirrel@webmail.ourldsfamily.com> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> <935eb6d5192f8f323aff3ee437028821.squirrel@webmail.ourldsfamily.com> Message-ID: <48FE4D36.9010405@nerd.com> I should have added that you can manually do your "iptables" commands to get things the way you want, then as root you can: iptables-save >/etc/sysconfig/iptables to save what you have now. You can then edit the file and tweak things as you wish, then either iptables-restore References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> Message-ID: <1224661282.4272.18.camel@thegrind> On Tue, 2008-10-21 at 11:12 -0700, Rick Stevens wrote: > Karl Pearson wrote: > > On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: > >> Karl Pearson wrote: > >>> I'm curious if there's a limit on how many iptables entries it takes > >>> to > >>> hammer a system. Okay, a better question: When am I running the risk > >>> of > >>> messing up my IP traffic if I add DROP entries in the INPUT rule of > >>> iptables? > >> You do ask the damndest questions, Karl! :-) > >> > >> I've never seen a document that describes any rule limits. It is a > >> kernel module, so one must assume there is some limit. It may be that > >> a spelunking sesion through the source might answer that. > >> > >> I've got lots of drop entries on my rules and haven't had any issues, > >> but I'm always guided by the concept that the more rules a packet must > >> traverse, the slower the connection will be at startup. Therefore I > >> order my rules carefully putting the more generic rules at the top of > >> the list and the more specific ones at the bottom. That may not work > >> for you...every network is a little different (for example, we blacklist > >> entire /8 networks in some cases because of DOS or hack attacks from > >> those countries). > > > > I'd love a list of those IPs and how you inserted the rule. > > Oh, man, I'd have to go through our firewall configs to dig up the > addresses involved. As far as the rule insertion, it's pretty much > a standard iptables insert, but we add a "--syn" for TCP and just > simply block UDP. These are interim...eventually we migrate these > rules out to our Foundry or Cisco routers and remove them from the > individual servers. > > > I also > > wonder about DROP vs REJECT. I know the difference, but what's the > > theory behind using one over the other? I have thought it is about them > > knowing the IP is there vs just a hang. But, I'm wondering if the DROP > > (hang) causes me any headaches in IP traffic limiting? I know, another > > annoying question. > > We use DROP. If we're under attack or someone's probing, why let them > know they found a machine? If anything, a DROP is easier on the system > than a REJECT since all the system does is drop the connection...it > doesn't send anything back. And if the prober/attacker's connection > hangs at his end, good! Screw them in the first place. Attackers > and probers deserve absolutely no consideration in any way and should > be prosecuted in the same manner as someone trying to break into my home > or office. > > > All my DROPs are in the first rule, so they are immediately acted on, or > > in this case, DROPped. > > > > I used to use sshblack, but the way the logfiles are written now make it > > ineffective for inbound, however I wrote my own blacklist scripts which > > I use with it, so it does do aging checks, which for DDNS is okay, I > > think. > > For SSH issues, I have a standard ruleset. Here it is from the > /etc/sysconfig/iptables file: > > # This rejects ssh attempts more than twice in 180 seconds... > # First, mark attempts as part of the "sshattack" group... > -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set > # Optional: Include this line if you want to log these attacks... > #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck > --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " > # Finally, reject the connection if more than one attempt is made in 180 > seconds... > -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck > --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset > > So, you only get to try to SSH once every 3 minutes. You can tweak the > "--hitcount" value and "--seconds" value to customize it for your use. > It foils most of the script kiddies out there. Unfortunately, it also foils legitimate accesses often enough. This is a very effective set up, but it comes with the caveat that "connection requests" are counted, and not "connection requests from IP address such-and-such". When I'm at work and need to access one of my boxes, no problem. I have an accept rule for my LAN immediately in front of the gauntlet. But when I'm at home and need to do something for whatever reason, I'm coming in on a dynamic IP addy and almost always hit the wall because the scripts have been there before me. It's not a show-stopper, but it gets annoying having to first take a detour to a quieter box that is covered under the ACCEPT rule. Andy > > I have installed fail2ban, which blacklists for a shorter amount of > > time, I suspect under the theory that ssh attacks are almost random, and > > will pass. > > Yeah, it works. Mine has minimal impact on the rulesets, but either > is fine. > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Death is nature's way of dropping carrier - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe From ricks at nerd.com Wed Oct 22 18:30:19 2008 From: ricks at nerd.com (Rick Stevens) Date: Wed, 22 Oct 2008 11:30:19 -0700 Subject: IPTables limits? In-Reply-To: <1224661282.4272.18.camel@thegrind> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> <1224661282.4272.18.camel@thegrind> Message-ID: <48FF713B.2040403@nerd.com> Andrew Kelly wrote: > On Tue, 2008-10-21 at 11:12 -0700, Rick Stevens wrote: >> Karl Pearson wrote: >>> On Tue, October 21, 2008 11:16 am, Rick Stevens wrote: >>>> Karl Pearson wrote: >>>>> I'm curious if there's a limit on how many iptables entries it takes >>>>> to >>>>> hammer a system. Okay, a better question: When am I running the risk >>>>> of >>>>> messing up my IP traffic if I add DROP entries in the INPUT rule of >>>>> iptables? >>>> You do ask the damndest questions, Karl! :-) >>>> >>>> I've never seen a document that describes any rule limits. It is a >>>> kernel module, so one must assume there is some limit. It may be that >>>> a spelunking sesion through the source might answer that. >>>> >>>> I've got lots of drop entries on my rules and haven't had any issues, >>>> but I'm always guided by the concept that the more rules a packet must >>>> traverse, the slower the connection will be at startup. Therefore I >>>> order my rules carefully putting the more generic rules at the top of >>>> the list and the more specific ones at the bottom. That may not work >>>> for you...every network is a little different (for example, we blacklist >>>> entire /8 networks in some cases because of DOS or hack attacks from >>>> those countries). >>> I'd love a list of those IPs and how you inserted the rule. >> Oh, man, I'd have to go through our firewall configs to dig up the >> addresses involved. As far as the rule insertion, it's pretty much >> a standard iptables insert, but we add a "--syn" for TCP and just >> simply block UDP. These are interim...eventually we migrate these >> rules out to our Foundry or Cisco routers and remove them from the >> individual servers. >> >>> I also >>> wonder about DROP vs REJECT. I know the difference, but what's the >>> theory behind using one over the other? I have thought it is about them >>> knowing the IP is there vs just a hang. But, I'm wondering if the DROP >>> (hang) causes me any headaches in IP traffic limiting? I know, another >>> annoying question. >> We use DROP. If we're under attack or someone's probing, why let them >> know they found a machine? If anything, a DROP is easier on the system >> than a REJECT since all the system does is drop the connection...it >> doesn't send anything back. And if the prober/attacker's connection >> hangs at his end, good! Screw them in the first place. Attackers >> and probers deserve absolutely no consideration in any way and should >> be prosecuted in the same manner as someone trying to break into my home >> or office. >> >>> All my DROPs are in the first rule, so they are immediately acted on, or >>> in this case, DROPped. >>> >>> I used to use sshblack, but the way the logfiles are written now make it >>> ineffective for inbound, however I wrote my own blacklist scripts which >>> I use with it, so it does do aging checks, which for DDNS is okay, I >>> think. >> For SSH issues, I have a standard ruleset. Here it is from the >> /etc/sysconfig/iptables file: >> >> # This rejects ssh attempts more than twice in 180 seconds... >> # First, mark attempts as part of the "sshattack" group... >> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set >> # Optional: Include this line if you want to log these attacks... >> #-A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck >> --seconds 180 --hitcount 2 -j LOG --log-prefix "SSH REJECT: " >> # Finally, reject the connection if more than one attempt is made in 180 >> seconds... >> -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --rcheck >> --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset >> >> So, you only get to try to SSH once every 3 minutes. You can tweak the >> "--hitcount" value and "--seconds" value to customize it for your use. >> It foils most of the script kiddies out there. > > Unfortunately, it also foils legitimate accesses often enough. This is a > very effective set up, but it comes with the caveat that "connection > requests" are counted, and not "connection requests from IP address > such-and-such". No, it tracks the source IP. Two attempts from the same source IP trigger the lockout. > When I'm at work and need to access one of my boxes, no problem. I have > an accept rule for my LAN immediately in front of the gauntlet. But when > I'm at home and need to do something for whatever reason, I'm coming in > on a dynamic IP addy and almost always hit the wall because the scripts > have been there before me. It's not a show-stopper, but it gets annoying > having to first take a detour to a quieter box that is covered under the > ACCEPT rule. That works, but again, the ipt_recent module tracks source IPs. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Memory is the second thing to go, but I can't remember the first! - ---------------------------------------------------------------------- From akelly at corisweb.org Thu Oct 23 11:52:47 2008 From: akelly at corisweb.org (Andrew Kelly) Date: Thu, 23 Oct 2008 13:52:47 +0200 Subject: IPTables limits? In-Reply-To: <48FF713B.2040403@nerd.com> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> <1224661282.4272.18.camel@thegrind> <48FF713B.2040403@nerd.com> Message-ID: <1224762767.7373.2.camel@thegrind> On Wed, 2008-10-22 at 11:30 -0700, Rick Stevens wrote: > Andrew Kelly wrote: > > Unfortunately, it also foils legitimate accesses often enough. This is a > > very effective set up, but it comes with the caveat that "connection > > requests" are counted, and not "connection requests from IP address > > such-and-such". > > No, it tracks the source IP. Two attempts from the same source IP > trigger the lockout. Mea Culpa, Rick, you're absolutely right. I just discovered that my rules weren't even using the recent mod. (Homer Simpson sound) Thanks, man. Andy From ricks at nerd.com Thu Oct 23 16:41:58 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 23 Oct 2008 09:41:58 -0700 Subject: IPTables limits? In-Reply-To: <1224762767.7373.2.camel@thegrind> References: <48FE0E5F.1000806@nerd.com> <48FE1B7F.1030503@nerd.com> <1224661282.4272.18.camel@thegrind> <48FF713B.2040403@nerd.com> <1224762767.7373.2.camel@thegrind> Message-ID: <4900A956.8000900@nerd.com> Andrew Kelly wrote: > On Wed, 2008-10-22 at 11:30 -0700, Rick Stevens wrote: >> Andrew Kelly wrote: > > >>> Unfortunately, it also foils legitimate accesses often enough. This is a >>> very effective set up, but it comes with the caveat that "connection >>> requests" are counted, and not "connection requests from IP address >>> such-and-such". >> No, it tracks the source IP. Two attempts from the same source IP >> trigger the lockout. > > Mea Culpa, Rick, you're absolutely right. I just discovered that my > rules weren't even using the recent mod. (Homer Simpson sound) Heheheheh! I often have "D'oh!" moments myself, usually followed by maniacal laughter from the people in the immediate vicinity! > Thanks, man. Anytime. BTW, "D'oh!" is now in the Oxford American English dictionary. Go figure! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Linux is like a wigwam...no windows, no gates...and apache inside! - ---------------------------------------------------------------------- From Travis.R.Waldher at boeing.com Thu Oct 23 22:10:39 2008 From: Travis.R.Waldher at boeing.com (Waldher, Travis R) Date: Thu, 23 Oct 2008 15:10:39 -0700 Subject: Performance reporting issues. (update) In-Reply-To: References: Message-ID: Ok, here's the output from sar -P ALL 02:40:01 PM all 28.47 0.00 70.92 0.61 0.00 02:40:01 PM 0 5.30 0.00 13.28 0.05 81.37 02:40:01 PM 1 1.39 0.00 4.07 0.08 94.47 02:40:01 PM 2 5.26 0.00 12.63 0.07 82.03 02:40:01 PM 3 1.31 0.00 3.06 0.09 95.54 02:50:01 PM all 27.33 0.00 72.27 0.40 0.00 02:50:01 PM 0 3.48 0.00 9.91 0.03 86.57 02:50:01 PM 1 1.22 0.00 3.80 0.05 94.94 02:50:01 PM 2 3.10 0.00 7.58 0.02 89.31 02:50:01 PM 3 1.06 0.00 2.14 0.03 96.77 Please note, the individual CPU time and combination is not making any sense. That is from today. Let's go back to where it was working on October 19th. 04:40:01 AM all 0.75 0.00 2.32 0.01 96.92 04:40:01 AM 0 0.90 0.00 4.11 0.02 94.98 04:40:01 AM 1 0.84 0.00 3.37 0.01 95.78 04:40:01 AM 2 0.75 0.00 1.15 0.02 98.08 04:40:01 AM 3 0.52 0.00 0.62 0.00 98.85 04:50:01 AM all 2.49 0.00 6.60 0.03 90.88 04:50:01 AM 0 1.24 0.00 4.42 0.02 94.32 04:50:01 AM 1 0.76 0.00 3.31 0.00 95.92 04:50:01 AM 2 1.22 0.00 1.60 0.02 97.16 04:50:01 AM 3 0.60 0.00 0.77 0.01 98.63 05:00:01 AM all 29.22 0.00 70.35 0.43 0.00 05:00:01 AM 0 1.50 0.00 4.32 0.02 94.16 05:00:01 AM 1 0.81 0.00 3.11 0.01 96.08 05:00:01 AM 2 1.48 0.00 2.04 0.03 96.45 05:00:01 AM 3 0.57 0.00 1.02 0.01 98.41 05:10:01 AM all 28.77 0.00 70.90 0.33 0.00 05:10:01 AM 0 1.58 0.00 4.91 0.02 93.49 05:10:01 AM 1 0.89 0.00 3.52 0.01 95.58 05:10:01 AM 2 1.56 0.00 2.05 0.02 96.37 05:10:01 AM 3 0.61 0.00 0.94 0.01 98.44 I'm still not sure how it is figuring an average or whatever it is figuring for "ALL", but it appears to at least be more accurate up until 0500. Sysstat version sysstat-5.0.5-1 Anyone have any advice? From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Waldher, Travis R Sent: Thursday, October 16, 2008 10:38 AM To: Getting started with Red Hat Linux Subject: Performance reporting issues. I'm having an odd issue where SAR is reporting wildly different stats than what the system is doing. I'm not sure where sa is pulling it's numbers from but I definitely don't and haven't had the CPUs running 36% for users and 63% for system for a long time. It's more likely the system had been idle. Any ideas? $ sar -H -t -u -f /var/log/sa/sa16 ;600;2008-10-16 09:10:01;-1;33.36;0.00;66.25;0.40;0.00 ;599;2008-10-16 09:20:01;-1;34.35;0.00;65.21;0.44;0.00 ;600;2008-10-16 09:30:01;-1;34.51;0.00;65.06;0.42;0.00 $ top top - 09:38:52 up 130 days, 3:08, 2 users, load average: 0.07, 0.03, 0.01 Tasks: 129 total, 1 running, 127 sleeping, 0 stopped, 1 zombie Cpu0 : 0.1% us, 0.3% sy, 0.0% ni, 99.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 0.2% us, 0.3% sy, 0.0% ni, 99.5% id, 0.0% wa, 0.0% hi, 0.0% si Cpu2 : 0.1% us, 0.3% sy, 0.0% ni, 99.6% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.1% us, 0.1% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si Cpu4 : 0.1% us, 0.1% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si Cpu5 : 0.1% us, 0.1% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si Cpu6 : 0.0% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si Cpu7 : 0.1% us, 0.0% sy, 0.0% ni, 99.9% id, 0.0% wa, 0.0% hi, 0.0% si -------------- next part -------------- An HTML attachment was scrubbed... URL: From karlp at ourldsfamily.com Thu Oct 23 23:01:33 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 23 Oct 2008 17:01:33 -0600 (MDT) Subject: dovecot Outlook failure Message-ID: I'm in a client office, and they use Outlook. I installed a new server after theirs was hacked into from China (story for another time). I've installed Fedora 8 and everything is working, except dovecot from inside the network (it's not going to work from outside anymore :) ). If I sit at an XP PC and telnet 10.0.0.240 110 it just hangs for awhile, then times out and ends up back at a DOS prompt. Same for 143 (IMAP). I can telnet 10.0.0.240 25 and send email all day long. I setup an Evolution account for both POP3 and IMAP on the server and it works fine. I have configured 2 other PCs with Fedora 8 in the last 2 months and they both work fine. What am I missing here? --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." --- From ricks at nerd.com Thu Oct 23 23:21:20 2008 From: ricks at nerd.com (Rick Stevens) Date: Thu, 23 Oct 2008 16:21:20 -0700 Subject: dovecot Outlook failure In-Reply-To: References: Message-ID: <490106F0.6030104@nerd.com> Karl Pearson wrote: > I'm in a client office, and they use Outlook. I installed a new server > after theirs was hacked into from China (story for another time). I've > installed Fedora 8 and everything is working, except dovecot from inside > the network (it's not going to work from outside anymore :) ). > > If I sit at an XP PC and telnet 10.0.0.240 110 it just hangs for awhile, > then times out and ends up back at a DOS prompt. Same for 143 (IMAP). > > I can telnet 10.0.0.240 25 and send email all day long. > > I setup an Evolution account for both POP3 and IMAP on the server and it > works fine. > > I have configured 2 other PCs with Fedora 8 in the last 2 months and > they both work fine. What am I missing here? Uh, really dumb question, but did you "chkconfig dovecot on" to make sure it starts on boot? Did you start it via "service dovecot start"? Does "netstat -lpn" show dovecot listening on ports 110 and 143? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Careful! Ugly strikes 9 out of 10 people! - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Fri Oct 24 05:46:41 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Thu, 23 Oct 2008 23:46:41 -0600 (MDT) Subject: dovecot Outlook failure In-Reply-To: <490106F0.6030104@nerd.com> References: <490106F0.6030104@nerd.com> Message-ID: On Thu, 23 Oct 2008, Rick Stevens wrote: > Karl Pearson wrote: >> I'm in a client office, and they use Outlook. I installed a new server >> after theirs was hacked into from China (story for another time). I've >> installed Fedora 8 and everything is working, except dovecot from inside >> the network (it's not going to work from outside anymore :) ). >> >> If I sit at an XP PC and telnet 10.0.0.240 110 it just hangs for awhile, >> then times out and ends up back at a DOS prompt. Same for 143 (IMAP). >> >> I can telnet 10.0.0.240 25 and send email all day long. >> >> I setup an Evolution account for both POP3 and IMAP on the server and it >> works fine. >> >> I have configured 2 other PCs with Fedora 8 in the last 2 months and >> they both work fine. What am I missing here? > > Uh, really dumb question, but did you "chkconfig dovecot on" to make > sure it starts on boot? Did you start it via "service dovecot start"? > Does "netstat -lpn" show dovecot listening on ports 110 and 143? No, that's not the least bit dumb. I didn't and it wasn't, but that wasn't the problem because I did that pretty early on, and fixed it. The server had been rebooted a few times since. I did find the problem, though hadn't come across it before. It was iptables not 'trusting' those services to be accessed from a remote IP address. Thus, it worked on the server, but not from anywhere else. I did iptables -F and turned it off. The server is behind a very nice Linux-based firewall, and those services aren't NATted anyway. Only 25, 80 and 22 are open, and 22 to root is forbidden. The old server had been on a DMZ, with Samba and everything else open for the world to see. When I install other servers, I typically disable iptables from starting at boot because I have my own scripts to do it for me. With the information you gave in the last thread I started, I may be re-thinking that strategy. It bit me big this time. Thanks, Karl > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Careful! Ugly strikes 9 out of 10 people! - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- From ricks at nerd.com Fri Oct 24 17:21:59 2008 From: ricks at nerd.com (Rick Stevens) Date: Fri, 24 Oct 2008 10:21:59 -0700 Subject: dovecot Outlook failure In-Reply-To: References: <490106F0.6030104@nerd.com> Message-ID: <49020437.8040905@nerd.com> Karl Pearson wrote: > On Thu, 23 Oct 2008, Rick Stevens wrote: > >> Karl Pearson wrote: >>> I'm in a client office, and they use Outlook. I installed a new server >>> after theirs was hacked into from China (story for another time). I've >>> installed Fedora 8 and everything is working, except dovecot from inside >>> the network (it's not going to work from outside anymore :) ). >>> >>> If I sit at an XP PC and telnet 10.0.0.240 110 it just hangs for awhile, >>> then times out and ends up back at a DOS prompt. Same for 143 (IMAP). >>> >>> I can telnet 10.0.0.240 25 and send email all day long. >>> >>> I setup an Evolution account for both POP3 and IMAP on the server and it >>> works fine. >>> >>> I have configured 2 other PCs with Fedora 8 in the last 2 months and >>> they both work fine. What am I missing here? >> >> Uh, really dumb question, but did you "chkconfig dovecot on" to make >> sure it starts on boot? Did you start it via "service dovecot start"? >> Does "netstat -lpn" show dovecot listening on ports 110 and 143? > > No, that's not the least bit dumb. I didn't and it wasn't, but that > wasn't the problem because I did that pretty early on, and fixed it. The > server had been rebooted a few times since. > > I did find the problem, though hadn't come across it before. It was > iptables not 'trusting' those services to be accessed from a remote IP > address. Thus, it worked on the server, but not from anywhere else. I > did iptables -F and turned it off. The server is behind a very nice > Linux-based firewall, and those services aren't NATted anyway. Only 25, > 80 and 22 are open, and 22 to root is forbidden. The old server had been > on a DMZ, with Samba and everything else open for the world to see. Ah! Yeah, that'd block them for sure. iptables was going to be my next question, but you beat me to it! Heheheheheh! > When I install other servers, I typically disable iptables from starting > at boot because I have my own scripts to do it for me. > > With the information you gave in the last thread I started, I may be > re-thinking that strategy. It bit me big this time. I'll help if I can. I just finished my PCI-hardening stuff so I've got a pretty good grip on security stuff now...iptables, external firewalls, ssh restrictions, session timeouts, authentication and sudo off LDAP, the lot. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I never drink water because of the disgusting things that fish do - - in it. - - -- WC. Fields - ---------------------------------------------------------------------- From karlp at ourldsfamily.com Sat Oct 25 07:09:42 2008 From: karlp at ourldsfamily.com (Karl Pearson) Date: Sat, 25 Oct 2008 01:09:42 -0600 (MDT) Subject: dovecot Outlook failure In-Reply-To: <49020437.8040905@nerd.com> References: <490106F0.6030104@nerd.com> <49020437.8040905@nerd.com> Message-ID: On Fri, 24 Oct 2008, Rick Stevens wrote: > Karl Pearson wrote: >> On Thu, 23 Oct 2008, Rick Stevens wrote: >> >>> Karl Pearson wrote: >>>> I'm in a client office, and they use Outlook. I installed a new server >>>> after theirs was hacked into from China (story for another time). I've >>>> installed Fedora 8 and everything is working, except dovecot from inside >>>> the network (it's not going to work from outside anymore :) ). >>>> >>>> If I sit at an XP PC and telnet 10.0.0.240 110 it just hangs for awhile, >>>> then times out and ends up back at a DOS prompt. Same for 143 (IMAP). >>>> >>>> I can telnet 10.0.0.240 25 and send email all day long. >>>> >>>> I setup an Evolution account for both POP3 and IMAP on the server and it >>>> works fine. >>>> >>>> I have configured 2 other PCs with Fedora 8 in the last 2 months and >>>> they both work fine. What am I missing here? >>> >>> Uh, really dumb question, but did you "chkconfig dovecot on" to make >>> sure it starts on boot? Did you start it via "service dovecot start"? >>> Does "netstat -lpn" show dovecot listening on ports 110 and 143? >> >> No, that's not the least bit dumb. I didn't and it wasn't, but that wasn't >> the problem because I did that pretty early on, and fixed it. The server >> had been rebooted a few times since. >> >> I did find the problem, though hadn't come across it before. It was >> iptables not 'trusting' those services to be accessed from a remote IP >> address. Thus, it worked on the server, but not from anywhere else. I did >> iptables -F and turned it off. The server is behind a very nice Linux-based >> firewall, and those services aren't NATted anyway. Only 25, 80 and 22 are >> open, and 22 to root is forbidden. The old server had been on a DMZ, with >> Samba and everything else open for the world to see. > > Ah! Yeah, that'd block them for sure. iptables was going to be my next > question, but you beat me to it! Heheheheheh! > >> When I install other servers, I typically disable iptables from starting at >> boot because I have my own scripts to do it for me. >> >> With the information you gave in the last thread I started, I may be >> re-thinking that strategy. It bit me big this time. > > I'll help if I can. I just finished my PCI-hardening stuff so I've got > a pretty good grip on security stuff now...iptables, external firewalls, > ssh restrictions, session timeouts, authentication and sudo off LDAP, > the lot. Since I'm 'out of work' at the moment and back to consulting, I really ought to learn what PCI is really all about. I understand the basics, but the requirements are just about overwhelming to one as annoyingly self-taught as I am. Thanks for your help again. Karl > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - I never drink water because of the disgusting things that fish do - > - in it. - > - -- WC. Fields - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > --- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP at ourldsfamily.com --- http://consulting.ourldsfamily.com --- "To mess up your Linux PC, you have to really work at it; to mess up a microsoft PC you just have to work on it." ---