Re: Postfix, dns, and hosts.allow
On Wednesday 14 November 2007 05:01:58 jekillen wrote: > Hello: > I have a question about Postfix and > hosts.allow: > Sendmail and exim are mentioned in the > file and I assume that Sendmail would > refer to Postfix sendmail as well as Sendmail. > But Since Postfix runs smtp.d, how would I > do Postfix in hosts.allow? I believe you would refer to it as "smtp" if that is what you have in /etc/services > > I also have a question about how postfix > would resolve names outside of the local > domain, Does it use resolve.conf, hosts.equiv, > nsswitch or does it need a local name server. The nameserver does not need to be local. It can use the ones in resolv.conf Make sure you use numeric hosts in resolv.conf I know that is obvious but I have seen people put textual hostnames in the file and then wonder why it does not work. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
re: Postfix, dns, and hosts.allow
Sorry: I sent this message by mistake before completing it. I had also sent the same message to the postfix user list. Thank you in adance for into Jeff K ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Postfix, dns, and hosts.allow
Hello: I have a question about Postfix and hosts.allow: Sendmail and exim are mentioned in the file and I assume that Sendmail would refer to Postfix sendmail as well as Sendmail. But Since Postfix runs smtp.d, how would I do Postfix in hosts.allow? I also have a question about how postfix would resolve names outside of the local domain, Does it use resolve.conf, hosts.equiv, nsswitch or does it need a local name server. I set it up and tried sending a test message from that host the the prodigy.net address (of this message) and it just seems to have disappeared. I was successful sending a message on internal network link from another machine. I was not successful sending a message to [EMAIL PROTECTED] from another machine (This address would have had to have been resolved by my name servers, whether it went all the way out to the isp's system and beyond, and then back, or just from one static ip address to the other, courtesy of my adsl router ). I did turn smtp 'on' in inetd.conf. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Sendmail ignores hosts.allow
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Maxim Khitrov > Sent: Monday, May 21, 2007 6:14 PM > To: freebsd-questions@freebsd.org > Subject: Re: Sendmail ignores hosts.allow > > however, I had a feeling that it was jail-related. But what about the > hosts.allow problem? I can run a firewall, of course, but hosts.allow > seems like a more efficient way of doing the same thing. I've already > got it configured and working with sshd, so I see no reason why > sendmail doesn't want to work the same way. > You said earlier that your sendmail was compiled with tcp wrapper support. How exactly did you go about doing this and installing it? In any case, since your not going to be using sendmail much, if your that paranoid I would suggest you simply disable it and run it out of inetd. Then use the usual tcpd method (in the man page) to run inetd. Ted ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Maxim Khitrov wrote: >Do you know > if there is a reason they chose to do it this way? Accept the > connection, but don't allow the client to do anything with it? If sendmail just dropped the connection, then the sending MTA would retry the message, potentially every 15 minutes for up to 5 days. The way sendmail does it, the sending MTA gets a 5xx permanent error message straight away, meaning it tries once and then fails. Of course, that assumes the MTAs involved are doing something like following the appropriate RFCs, which most of the spambots fail to do. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU9xj8Mjk52CukIwRCCUDAKCO6YUZ8TdFAQe7EVB7UcY7uzPYGwCfZL2u J6hLJvLN0DQnRJV9Z26Qdto= =IG3h -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On Tue, 22 May 2007 11:37:24 -0400 "Maxim Khitrov" <[EMAIL PROTECTED]>
wrote:
>On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> I suspect sendmail is reading /etc/hosts.allow
Why would anyone expect that? /etc/hosts.allow is one of the control
files for the TCP wrapper program, tcpd. (See "man tcpd".)
>>
>> # Start by allowing everything (this prevents the rest of the file
>> # from working, so remove it when you need protection).
>> # The rules here work on a "First match wins" basis.
>> #ALL : ALL : allow
>>
>> Did you comment out the above line?
>>
>> Steve
>
>Here's the entire file as it is right now:
>
># Deny sendmail to all clients (temporary)
>sendmail : all : deny
>
># Allow anything from localhost
>all : : allow
>
># Process SSH deny rules
>sshd : /etc/hosts.evil : deny
>
># Allow everything else
>all : all : allow
>
>Once I can get sendmail to block all connection requests, I'll move it
>below the second rule. That way, only local processes will be able to
>use it. For now, however, that rule is being ignored completely.
>
Okay. First off, as noted above, /etc/hosts.{allow,deny} are not
sendmail(8) control files. They are tcpd(8) control files.
Secondly, tcpd is normally interposed between inetd(8), which has
essentially no built-in means of deciding whether to accept or reject
TCP connections based upon the source address of the connection request.
Instead of listing a particular program in /etc/inetd.conf as the program
to run to service an incoming connection on a particular port, one lists
the tcpd program and provides *it* the path of the desired service program.
tcpd then looks at /etc/hosts.{allow,deny} to determine whether to close
the connection or to pass it along to the service program.
Third, it is possible to run sendmail in non-daemon mode. If one
does not wish to tie up kernel resources to keep a sendmail process in the
system all the time, for example, one can list sendmail in /etc/inetd.conf
for the SMTP port (25), so that an inbound connection will result in inetd(8)
forking off a sendmail process to handle it. (See "man sendmail", and try
"/usr/sbin/sendmail -bm" IIRC.) It is in this setup *only* that the
/etc/hosts.{allow,deny} files should have any effect whatsoever upon whether
incoming connections are handled by sendmail. N.B. even in this case, it
is tcpd reading those files and making the decisions, *not* sendmail.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at cs.niu.edu *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On May 22, 2007, at 1:21 PM, Maxim Khitrov wrote: Do you know if there is a reason they chose to do it this way? Accept the connection, but don't allow the client to do anything with it? There is some advantage to getting enough info from attempted spam to produce useful logging messages, even if you want your mail system to eventually return a 5xx permanent failure. Some people also find that accepting and tying up spammer connections can help reduce the rate that spam gets pumped out, although for that to be really effective, it helps to have a "teergrube" (German for "tarpit") in your MX list which is specially designed to very slowly accept traffic from potential spammers without tying down a lot of your own bandwidth. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On 5/22/07, Rob <[EMAIL PROTECTED]> wrote: Doug Hardie wrote: > On May 22, 2007, at 10:46, Maxim Khitrov wrote: >>> > # Deny sendmail to all clients (temporary) >>> > sendmail : all : deny > tcp wrappers must be coded into the application. The call which > actually checks the access permissions in the hosts.allow file is > hosts_access() (see man hosts_access). Checking through the sendmail I have to disagree with that. I run unmodified 8.13.8 on 6.2, and it DOES respect hosts.allow. Just not in the way you might assume. I can telnet to port 25, it allows connections from *anywhere*, and will respond to a HELO. It's not until I give it a "mail to:" that it protests with "550 5.0.0 Access denied". I use "FEATURE(delay_checks)" in the cf file, which may have some effect on this. The log file shows: May 22 14:56:47 cartman sm-mta[74026]: l4MIullh074026: tcpwrappers (unknown, 192.31.130.140) rejection The actual options & version look like: $ sendmail -bp -d0.1 Version 8.13.8 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG $ uname -rms FreeBSD 6.2-RELEASE i386 -RW You know, I could have sworn that I checked actually sending the message through telnet yesterday with the deny rule in place. You're right through, it fails right after I give it mail from command. Guess I didn't keep good track of what I was checking each time. Do you know if there is a reason they chose to do it this way? Accept the connection, but don't allow the client to do anything with it? I didn't find FEATURE(delay_checks) in any of my cf files, so I think it's something else. Well at any rate, thanks for your help. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Maxim Khitrov wrote: I'm not sure I understand what you mean... I'm not using inetd, and the default configuration doesn't block sendmail from all remote hosts. The ssh server is running all by itself, same as sendmail. The way I understand it is that as long as the server was compiled with tcp wrappers, it should follow the rules in hosts.allow. Sendmail is different from other network apps in that it does not block the connection when a deny rule is in effect, instead it send some kind of reject code (5xx) during the SMTP conversation. If you check /var/log/maillog you may well see this happening. If you search the mail archives (or try google) with some appropriate keywords then you should find a post from Matthew Seaman which explains it in detail You could also search the source code, if you are somewhat C literate. If you want to completely block connections from specific hosts (or only allow specific hosts) then I would suggest doing that with firewall rules. Didn't follow the start of the thread very closely so I hope I got the right end of the stick. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Doug Hardie wrote: On May 22, 2007, at 10:46, Maxim Khitrov wrote: > # Deny sendmail to all clients (temporary) > sendmail : all : deny tcp wrappers must be coded into the application. The call which actually checks the access permissions in the hosts.allow file is hosts_access() (see man hosts_access). Checking through the sendmail I have to disagree with that. I run unmodified 8.13.8 on 6.2, and it DOES respect hosts.allow. Just not in the way you might assume. I can telnet to port 25, it allows connections from *anywhere*, and will respond to a HELO. It's not until I give it a "mail to:" that it protests with "550 5.0.0 Access denied". I use "FEATURE(delay_checks)" in the cf file, which may have some effect on this. The log file shows: May 22 14:56:47 cartman sm-mta[74026]: l4MIullh074026: tcpwrappers (unknown, 192.31.130.140) rejection The actual options & version look like: $ sendmail -bp -d0.1 Version 8.13.8 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG $ uname -rms FreeBSD 6.2-RELEASE i386 -RW ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On May 22, 2007, at 10:46, Maxim Khitrov wrote: On 5/22/07, doug <[EMAIL PROTECTED]> wrote: On Tue, 22 May 2007, Maxim Khitrov wrote: > On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> I suspect sendmail is reading /etc/hosts.allow >> >> # Start by allowing everything (this prevents the rest of the file >> # from working, so remove it when you need protection). >> # The rules here work on a "First match wins" basis. >> #ALL : ALL : allow >> >> Did you comment out the above line? >> >> Steve > > Here's the entire file as it is right now: > > # Deny sendmail to all clients (temporary) > sendmail : all : deny > > # Allow anything from localhost > all : : allow > > # Process SSH deny rules > sshd : /etc/hosts.evil : deny > > # Allow everything else > all : all : allow > > Once I can get sendmail to block all connection requests, I'll move it > below the second rule. That way, only local processes will be able to > use it. For now, however, that rule is being ignored completely. The default configuration gives you what you want so I assume your goal is to see if you can make hosts.allow work within a jail. In general there are performance reasons not to use inetd to control ssh and sendmail. ssh under inetd causes more key generation. Sendmail has its own controls which give you the equivalent (or better) than can be done with inetd. I assume from an earlier post you are trying to make this work inside a jail. If thats true you must also have in the jail rc.conf inetd_flags="-wW -a your-ip-address" I assume you have this or you would not have been able to control ssh. All that said, I have only used inetd to control ftp/imap/pop3. It seems to me your specific question is: does this work inside a jail and is any special setup required to make it work with sendmail. Sorry I can not help more. Doug I'm not sure I understand what you mean... I'm not using inetd, and the default configuration doesn't block sendmail from all remote hosts. The ssh server is running all by itself, same as sendmail. The way I understand it is that as long as the server was compiled with tcp wrappers, it should follow the rules in hosts.allow. tcp wrappers must be coded into the application. The call which actually checks the access permissions in the hosts.allow file is hosts_access() (see man hosts_access). Checking through the sendmail source for version 8.13.8, there are no calls to hosts_access in the source code. You will need to patch sendmail to make it do what you want. There might be patches at www.sendmail.org for that, but I doubt it. openssh's sshd.c is probably a good template to use. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On 5/22/07, doug <[EMAIL PROTECTED]> wrote: On Tue, 22 May 2007, Maxim Khitrov wrote: > On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> I suspect sendmail is reading /etc/hosts.allow >> >> # Start by allowing everything (this prevents the rest of the file >> # from working, so remove it when you need protection). >> # The rules here work on a "First match wins" basis. >> #ALL : ALL : allow >> >> Did you comment out the above line? >> >> Steve > > Here's the entire file as it is right now: > > # Deny sendmail to all clients (temporary) > sendmail : all : deny > > # Allow anything from localhost > all : : allow > > # Process SSH deny rules > sshd : /etc/hosts.evil : deny > > # Allow everything else > all : all : allow > > Once I can get sendmail to block all connection requests, I'll move it > below the second rule. That way, only local processes will be able to > use it. For now, however, that rule is being ignored completely. The default configuration gives you what you want so I assume your goal is to see if you can make hosts.allow work within a jail. In general there are performance reasons not to use inetd to control ssh and sendmail. ssh under inetd causes more key generation. Sendmail has its own controls which give you the equivalent (or better) than can be done with inetd. I assume from an earlier post you are trying to make this work inside a jail. If thats true you must also have in the jail rc.conf inetd_flags="-wW -a your-ip-address" I assume you have this or you would not have been able to control ssh. All that said, I have only used inetd to control ftp/imap/pop3. It seems to me your specific question is: does this work inside a jail and is any special setup required to make it work with sendmail. Sorry I can not help more. Doug I'm not sure I understand what you mean... I'm not using inetd, and the default configuration doesn't block sendmail from all remote hosts. The ssh server is running all by itself, same as sendmail. The way I understand it is that as long as the server was compiled with tcp wrappers, it should follow the rules in hosts.allow. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On 5/22/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I suspect sendmail is reading /etc/hosts.allow # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. #ALL : ALL : allow Did you comment out the above line? Steve Here's the entire file as it is right now: # Deny sendmail to all clients (temporary) sendmail : all : deny # Allow anything from localhost all : : allow # Process SSH deny rules sshd : /etc/hosts.evil : deny # Allow everything else all : all : allow Once I can get sendmail to block all connection requests, I'll move it below the second rule. That way, only local processes will be able to use it. For now, however, that rule is being ignored completely. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Maxim Khitrov wrote: > On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: >> Maxim Khitrov wrote: >>> On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: >>>> Maxim Khitrov wrote: >>>>> Hello, >>>>> >>>>> I'm trying to restrict access to sendmail via hosts.allow. Don't need >>>>> a firewall, since I just want to block everyone but the localhost from >>>>> sending e-mail out. Anyway, it seems that sendmail ignores these >>>>> settings even though it was compiled with TCPWRAPPERS. I added >>>>> "sendmail : all : deny" as the very first line in hosts.allow, just to >>>>> see if it will let me connect from anywhere. It does - not just from >>>>> localhost, but from all remote locations as well. I have no problems >>>>> connecting and sending e-mail. Am I missing something? >>>> I followed your earlier thread (hopefully this is a related topic). This >>>> is strange. By default, sendmail is disabled. You don't even have to put >>>> anything into rc.conf: >>>> >>>> # grep sendmail /etc/defaults/rc.conf >>>> >>>> Sendmail listens and accepts local mail only. You can't connect to it >>>> from another machine: >>>> >>>> # telnet some.host.tld 25 >>>> Trying 1.2.3.4... >>>> telnet: connect to address 1.2.3.4: Connection refused >>>> telnet: Unable to connect to remote host >>>> >>>> You must've tweaked something to make it behave differently. >>>> >>>>> I tested the same setup with sshd, and that works properly. After a >>>>> quick search on google it seems that I'm not the only one with this >>>>> problem, but I couldn't find any solution to this. Any help is greatly >>>>> appreciated. >>>> Share with us your testing methodology. From previous thread, I >>>> understand that you just want something to submit your local mail (from >>>> daemons, scripts, etc). Then as others already said, a simple alias in >>>> /etc/mail/aliases and executing newaliases is sufficient. >>> Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf >>> (same as not having it there I guess), I've modified /etc/mail/aliases >>> to forward everything sent to root to my gmail account, and I added >>> "sendmail : all : deny" as the first line to /etc/hosts.allow while >>> I'm testing everything. Once I make sure that the deny rule works, >>> I'll allow access to sendmail only from localhost. This is all on >>> FreeBSD 6.2, but it's running in a jail, so that might have some >>> effect. >>> >>> >From my previous thread, sendmail is used only to accept messages sent >>> by processes running on the server, and send them to real e-mails >>> specified in /etc/aliases. That part works. However, even though >>> sendmail_enable is set to "NO" in rc.conf, sendmail still listens on >>> port 25, accepts mail from remote hosts, and the hosts.allow rule >>> doesn't seem to apply. Strange, isn't it? By the way, I just tried >>> removing sendmail_enable line from rc.conf completely and that had no >>> effect. >>> >>> All I do for testing is basically start/restart sendmail, then telnet >>> to the server from my workstation at home. I get a standard reply, and >>> can then do the usual HELO, MAIL FROM, RCPT TO, DATA, and so on. >>> Relaying doesn't work, but sending to and all other aliases works fine >>> (which in this case is bad). >>> >>> Think this might be some bug when sendmail is running in a jail? I >>> haven't modified anything beyond what's mentioned in this e-mail, and >>> I've checked all the settings. I can definitely connect to the server >>> from remote hosts despite the rc.conf and hosts.allow configuration. >> This is a different story now. On your host machine (as in jails' host), >> sendmail binds to localhost and never responds to outside world. This is >> expected. However, sendmail in a jail, binds to jail's IP address and >> that is why you can talk to it from outside. >> >> Run this on your host: >> >> # sockstat -4l | grep sendmail >> >> The output should look like this: >> >> root sendmail 1624 4 tcp4 1.2.3.5:25*:* >> root sendmail 1
Re: Sendmail ignores hosts.allow
On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: Maxim Khitrov wrote: > On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: >> Maxim Khitrov wrote: >>> Hello, >>> >>> I'm trying to restrict access to sendmail via hosts.allow. Don't need >>> a firewall, since I just want to block everyone but the localhost from >>> sending e-mail out. Anyway, it seems that sendmail ignores these >>> settings even though it was compiled with TCPWRAPPERS. I added >>> "sendmail : all : deny" as the very first line in hosts.allow, just to >>> see if it will let me connect from anywhere. It does - not just from >>> localhost, but from all remote locations as well. I have no problems >>> connecting and sending e-mail. Am I missing something? >> I followed your earlier thread (hopefully this is a related topic). This >> is strange. By default, sendmail is disabled. You don't even have to put >> anything into rc.conf: >> >> # grep sendmail /etc/defaults/rc.conf >> >> Sendmail listens and accepts local mail only. You can't connect to it >> from another machine: >> >> # telnet some.host.tld 25 >> Trying 1.2.3.4... >> telnet: connect to address 1.2.3.4: Connection refused >> telnet: Unable to connect to remote host >> >> You must've tweaked something to make it behave differently. >> >>> I tested the same setup with sshd, and that works properly. After a >>> quick search on google it seems that I'm not the only one with this >>> problem, but I couldn't find any solution to this. Any help is greatly >>> appreciated. >> Share with us your testing methodology. From previous thread, I >> understand that you just want something to submit your local mail (from >> daemons, scripts, etc). Then as others already said, a simple alias in >> /etc/mail/aliases and executing newaliases is sufficient. > > Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf > (same as not having it there I guess), I've modified /etc/mail/aliases > to forward everything sent to root to my gmail account, and I added > "sendmail : all : deny" as the first line to /etc/hosts.allow while > I'm testing everything. Once I make sure that the deny rule works, > I'll allow access to sendmail only from localhost. This is all on > FreeBSD 6.2, but it's running in a jail, so that might have some > effect. > >>From my previous thread, sendmail is used only to accept messages sent > by processes running on the server, and send them to real e-mails > specified in /etc/aliases. That part works. However, even though > sendmail_enable is set to "NO" in rc.conf, sendmail still listens on > port 25, accepts mail from remote hosts, and the hosts.allow rule > doesn't seem to apply. Strange, isn't it? By the way, I just tried > removing sendmail_enable line from rc.conf completely and that had no > effect. > > All I do for testing is basically start/restart sendmail, then telnet > to the server from my workstation at home. I get a standard reply, and > can then do the usual HELO, MAIL FROM, RCPT TO, DATA, and so on. > Relaying doesn't work, but sending to and all other aliases works fine > (which in this case is bad). > > Think this might be some bug when sendmail is running in a jail? I > haven't modified anything beyond what's mentioned in this e-mail, and > I've checked all the settings. I can definitely connect to the server > from remote hosts despite the rc.conf and hosts.allow configuration. This is a different story now. On your host machine (as in jails' host), sendmail binds to localhost and never responds to outside world. This is expected. However, sendmail in a jail, binds to jail's IP address and that is why you can talk to it from outside. Run this on your host: # sockstat -4l | grep sendmail The output should look like this: root sendmail 1624 4 tcp4 1.2.3.5:25*:* root sendmail 1624 4 tcp4 1.2.3.4:25*:* root sendmail 1624 4 tcp4 1.2.3.3:25*:* root sendmail 1624 4 tcp4 1.2.3.2:25*:* root sendmail 1208 3 tcp4 127.0.0.1:25 *:* The first four are jails. The last one is host's sendmail being "disabled". I'd suggest using a firewall to protect your jails instead of trying to completely disable sendmails. I cna't run that on my host, because I only have access to the jail (I'm paying for a vps server with another host). That makes sense however, I had a feeling that it was jail-related. But what about the hosts.allow problem? I can run a firewall, of course, but hosts.allow seems like a more efficient way of doing the same thing. I've already got it configured and working with sshd, so I see no reason why sendmail doesn't want to work the same way. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Maxim Khitrov wrote: > On 5/21/07, doug <[EMAIL PROTECTED]> wrote: >> sendmail_enable="NO" means there is no sendmail daemon running. You can >> verify >> this via "ps -aux | grep sendmail". Remove that statement. Without a reboot >> you >> can start sendmail by cd /etc/mail; make start. >> >> Unless you have changed the freebsd.mc file and done a 'make install' I do >> not >> believe sendmail will accept from any connections except except on 127.0.0.1 >> (localhost). This is what you want I think. If that's it as others have said, >> there is no reason to use the hosts.allow mechanism. This is independent of >> the >> jail environment. >> >>sockstat|grep sendmail >> >> and you can see whats going on. >> > > Not the case for me, having sendmail_enable="NO" and not having it in > rc.conf results in the same behavior. Here's sendmail rcvar output: Same behaviour because sendmail_enable="NO" is already present in /etc/defaults/rc.conf so putting in /etc/rc.conf or removing it from there is the same thing. > Without sendmail_enable in rc.conf: > # sendmail > $sendmail_enable=NO > # sendmail_submit > $sendmail_submit_enable=YES > # sendmail_clientmqueue > $sendmail_msp_queue_enable=YES > > With sendmail_enable="NO": > # sendmail > $sendmail_enable=NO > # sendmail_submit > $sendmail_submit_enable=YES > # sendmail_clientmqueue > $sendmail_msp_queue_enable=YES > > With sendmail_enable="NONE": > # sendmail > $sendmail_enable=NO > # sendmail_clientmqueue > $sendmail_msp_queue_enable=NO > > So the first two are identical (I don't see why they wouldn't be). As > for the sendmail daemon, here's what grep tells me after the server is > started: > > [EMAIL PROTECTED] [/]# ps -aux | grep sendmail > smmsp 16473 0.0 0.1 3384 2276 ?? IsJ 4:47PM 0:00.00 > sendmail: Queue [EMAIL PROTECTED]:30:00 for /var/spool/clientmqueue (sendmail > root 20951 0.0 0.1 3484 2480 ?? SsJ 5:37PM 0:00.00 > sendmail: accepting connections (sendmail) > root 21303 0.0 0.0 1592 912 pn S+J 5:37PM 0:00.00 grep sendmail > > And here's sockstat output: > > [EMAIL PROTECTED] [/]# sockstat -l4 > USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > root sendmail 20951 4 tcp4 :25 *:* > root syslogd45182 6 udp4 :514 *:* > root sshd 60371 3 tcp4 :22 *:* > > As you can see, sendmail is happily listening for all incoming > connections with the "NO" setting. If it would only listen on > localhost, then that would be the end of my problems. However, > remember that the jail environment doesn't have localhost. In other > words 127.0.0.1 does not refer to the jail. Loopback for me is the > server's wan ip (hey that rhymes :), which is why I think that not > having 127.0.0.1 may be confusing to sendmail. There you go. You just answered yourself. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
doug wrote: > > On Mon, 21 May 2007, Maxim Khitrov wrote: > >> On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: >>> Maxim Khitrov wrote: >>>> Hello, >>>> >>>> I'm trying to restrict access to sendmail via hosts.allow. Don't need >>>> a firewall, since I just want to block everyone but the localhost from >>>> sending e-mail out. Anyway, it seems that sendmail ignores these >>>> settings even though it was compiled with TCPWRAPPERS. I added >>>> "sendmail : all : deny" as the very first line in hosts.allow, just to >>>> see if it will let me connect from anywhere. It does - not just from >>>> localhost, but from all remote locations as well. I have no problems >>>> connecting and sending e-mail. Am I missing something? >>> I followed your earlier thread (hopefully this is a related topic). This >>> is strange. By default, sendmail is disabled. You don't even have to put >>> anything into rc.conf: >>> >>> # grep sendmail /etc/defaults/rc.conf >>> >>> Sendmail listens and accepts local mail only. You can't connect to it >>> from another machine: >>> >>> # telnet some.host.tld 25 >>> Trying 1.2.3.4... >>> telnet: connect to address 1.2.3.4: Connection refused >>> telnet: Unable to connect to remote host >>> >>> You must've tweaked something to make it behave differently. >>> >>>> I tested the same setup with sshd, and that works properly. After a >>>> quick search on google it seems that I'm not the only one with this >>>> problem, but I couldn't find any solution to this. Any help is greatly >>>> appreciated. >>> Share with us your testing methodology. From previous thread, I >>> understand that you just want something to submit your local mail (from >>> daemons, scripts, etc). Then as others already said, a simple alias in >>> /etc/mail/aliases and executing newaliases is sufficient. >> Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf >> (same as not having it there I guess), I've modified /etc/mail/aliases >> to forward everything sent to root to my gmail account, and I added >> "sendmail : all : deny" as the first line to /etc/hosts.allow while >> I'm testing everything. Once I make sure that the deny rule works, >> I'll allow access to sendmail only from localhost. This is all on >> FreeBSD 6.2, but it's running in a jail, so that might have some >> effect. > > sendmail_enable="NO" means there is no sendmail daemon running. You can > verify > this via "ps -aux | grep sendmail". Remove that statement. Without a reboot > you > can start sendmail by cd /etc/mail; make start. sendmail_enable="NO" tells sendmail to bind to localhost only (hence it becomes unreachable from the outside): # sockstat -4l | grep sendmail root sendmail 42310 4 tcp4 127.0.0.1:25 *:* sendmail_enable="YES" starts/adds the submit capability: # sockstat -4l | grep sendmail root sendmail 42262 4 tcp4 *:25 *:* root sendmail 42262 5 tcp4 *:587 *:* In both cases, executing ps -aux shows sendmail daemon is running. The first knob is the default as per /etc/defaults/rc.conf > Unless you have changed the freebsd.mc file and done a 'make install' I do > not > believe sendmail will accept from any connections except except on 127.0.0.1 > (localhost). This is what you want I think. If that's it as others have said, > there is no reason to use the hosts.allow mechanism. This is independent of > the > jail environment. > >sockstat|grep sendmail > > and you can see whats going on. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Maxim Khitrov wrote: > On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: >> Maxim Khitrov wrote: >>> Hello, >>> >>> I'm trying to restrict access to sendmail via hosts.allow. Don't need >>> a firewall, since I just want to block everyone but the localhost from >>> sending e-mail out. Anyway, it seems that sendmail ignores these >>> settings even though it was compiled with TCPWRAPPERS. I added >>> "sendmail : all : deny" as the very first line in hosts.allow, just to >>> see if it will let me connect from anywhere. It does - not just from >>> localhost, but from all remote locations as well. I have no problems >>> connecting and sending e-mail. Am I missing something? >> I followed your earlier thread (hopefully this is a related topic). This >> is strange. By default, sendmail is disabled. You don't even have to put >> anything into rc.conf: >> >> # grep sendmail /etc/defaults/rc.conf >> >> Sendmail listens and accepts local mail only. You can't connect to it >> from another machine: >> >> # telnet some.host.tld 25 >> Trying 1.2.3.4... >> telnet: connect to address 1.2.3.4: Connection refused >> telnet: Unable to connect to remote host >> >> You must've tweaked something to make it behave differently. >> >>> I tested the same setup with sshd, and that works properly. After a >>> quick search on google it seems that I'm not the only one with this >>> problem, but I couldn't find any solution to this. Any help is greatly >>> appreciated. >> Share with us your testing methodology. From previous thread, I >> understand that you just want something to submit your local mail (from >> daemons, scripts, etc). Then as others already said, a simple alias in >> /etc/mail/aliases and executing newaliases is sufficient. > > Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf > (same as not having it there I guess), I've modified /etc/mail/aliases > to forward everything sent to root to my gmail account, and I added > "sendmail : all : deny" as the first line to /etc/hosts.allow while > I'm testing everything. Once I make sure that the deny rule works, > I'll allow access to sendmail only from localhost. This is all on > FreeBSD 6.2, but it's running in a jail, so that might have some > effect. > >>From my previous thread, sendmail is used only to accept messages sent > by processes running on the server, and send them to real e-mails > specified in /etc/aliases. That part works. However, even though > sendmail_enable is set to "NO" in rc.conf, sendmail still listens on > port 25, accepts mail from remote hosts, and the hosts.allow rule > doesn't seem to apply. Strange, isn't it? By the way, I just tried > removing sendmail_enable line from rc.conf completely and that had no > effect. > > All I do for testing is basically start/restart sendmail, then telnet > to the server from my workstation at home. I get a standard reply, and > can then do the usual HELO, MAIL FROM, RCPT TO, DATA, and so on. > Relaying doesn't work, but sending to and all other aliases works fine > (which in this case is bad). > > Think this might be some bug when sendmail is running in a jail? I > haven't modified anything beyond what's mentioned in this e-mail, and > I've checked all the settings. I can definitely connect to the server > from remote hosts despite the rc.conf and hosts.allow configuration. This is a different story now. On your host machine (as in jails' host), sendmail binds to localhost and never responds to outside world. This is expected. However, sendmail in a jail, binds to jail's IP address and that is why you can talk to it from outside. Run this on your host: # sockstat -4l | grep sendmail The output should look like this: root sendmail 1624 4 tcp4 1.2.3.5:25*:* root sendmail 1624 4 tcp4 1.2.3.4:25*:* root sendmail 1624 4 tcp4 1.2.3.3:25*:* root sendmail 1624 4 tcp4 1.2.3.2:25*:* root sendmail 1208 3 tcp4 127.0.0.1:25 *:* The first four are jails. The last one is host's sendmail being "disabled". I'd suggest using a firewall to protect your jails instead of trying to completely disable sendmails. Regards, Mikhail. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On 5/21/07, doug <[EMAIL PROTECTED]> wrote: sendmail_enable="NO" means there is no sendmail daemon running. You can verify this via "ps -aux | grep sendmail". Remove that statement. Without a reboot you can start sendmail by cd /etc/mail; make start. Unless you have changed the freebsd.mc file and done a 'make install' I do not believe sendmail will accept from any connections except except on 127.0.0.1 (localhost). This is what you want I think. If that's it as others have said, there is no reason to use the hosts.allow mechanism. This is independent of the jail environment. sockstat|grep sendmail and you can see whats going on. Not the case for me, having sendmail_enable="NO" and not having it in rc.conf results in the same behavior. Here's sendmail rcvar output: Without sendmail_enable in rc.conf: # sendmail $sendmail_enable=NO # sendmail_submit $sendmail_submit_enable=YES # sendmail_clientmqueue $sendmail_msp_queue_enable=YES With sendmail_enable="NO": # sendmail $sendmail_enable=NO # sendmail_submit $sendmail_submit_enable=YES # sendmail_clientmqueue $sendmail_msp_queue_enable=YES With sendmail_enable="NONE": # sendmail $sendmail_enable=NO # sendmail_clientmqueue $sendmail_msp_queue_enable=NO So the first two are identical (I don't see why they wouldn't be). As for the sendmail daemon, here's what grep tells me after the server is started: [EMAIL PROTECTED] [/]# ps -aux | grep sendmail smmsp 16473 0.0 0.1 3384 2276 ?? IsJ 4:47PM 0:00.00 sendmail: Queue [EMAIL PROTECTED]:30:00 for /var/spool/clientmqueue (sendmail root 20951 0.0 0.1 3484 2480 ?? SsJ 5:37PM 0:00.00 sendmail: accepting connections (sendmail) root 21303 0.0 0.0 1592 912 pn S+J 5:37PM 0:00.00 grep sendmail And here's sockstat output: [EMAIL PROTECTED] [/]# sockstat -l4 USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sendmail 20951 4 tcp4 :25 *:* root syslogd45182 6 udp4 :514 *:* root sshd 60371 3 tcp4 :22 *:* As you can see, sendmail is happily listening for all incoming connections with the "NO" setting. If it would only listen on localhost, then that would be the end of my problems. However, remember that the jail environment doesn't have localhost. In other words 127.0.0.1 does not refer to the jail. Loopback for me is the server's wan ip (hey that rhymes :), which is why I think that not having 127.0.0.1 may be confusing to sendmail. - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On Mon, 21 May 2007, Maxim Khitrov wrote: On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: Maxim Khitrov wrote: > Hello, > > I'm trying to restrict access to sendmail via hosts.allow. Don't need > a firewall, since I just want to block everyone but the localhost from > sending e-mail out. Anyway, it seems that sendmail ignores these > settings even though it was compiled with TCPWRAPPERS. I added > "sendmail : all : deny" as the very first line in hosts.allow, just to > see if it will let me connect from anywhere. It does - not just from > localhost, but from all remote locations as well. I have no problems > connecting and sending e-mail. Am I missing something? I followed your earlier thread (hopefully this is a related topic). This is strange. By default, sendmail is disabled. You don't even have to put anything into rc.conf: # grep sendmail /etc/defaults/rc.conf Sendmail listens and accepts local mail only. You can't connect to it from another machine: # telnet some.host.tld 25 Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection refused telnet: Unable to connect to remote host You must've tweaked something to make it behave differently. > I tested the same setup with sshd, and that works properly. After a > quick search on google it seems that I'm not the only one with this > problem, but I couldn't find any solution to this. Any help is greatly > appreciated. Share with us your testing methodology. From previous thread, I understand that you just want something to submit your local mail (from daemons, scripts, etc). Then as others already said, a simple alias in /etc/mail/aliases and executing newaliases is sufficient. Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf (same as not having it there I guess), I've modified /etc/mail/aliases to forward everything sent to root to my gmail account, and I added "sendmail : all : deny" as the first line to /etc/hosts.allow while I'm testing everything. Once I make sure that the deny rule works, I'll allow access to sendmail only from localhost. This is all on FreeBSD 6.2, but it's running in a jail, so that might have some effect. sendmail_enable="NO" means there is no sendmail daemon running. You can verify this via "ps -aux | grep sendmail". Remove that statement. Without a reboot you can start sendmail by cd /etc/mail; make start. Unless you have changed the freebsd.mc file and done a 'make install' I do not believe sendmail will accept from any connections except except on 127.0.0.1 (localhost). This is what you want I think. If that's it as others have said, there is no reason to use the hosts.allow mechanism. This is independent of the jail environment. sockstat|grep sendmail and you can see whats going on. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
On 5/21/07, Mikhail Goriachev <[EMAIL PROTECTED]> wrote: Maxim Khitrov wrote: > Hello, > > I'm trying to restrict access to sendmail via hosts.allow. Don't need > a firewall, since I just want to block everyone but the localhost from > sending e-mail out. Anyway, it seems that sendmail ignores these > settings even though it was compiled with TCPWRAPPERS. I added > "sendmail : all : deny" as the very first line in hosts.allow, just to > see if it will let me connect from anywhere. It does - not just from > localhost, but from all remote locations as well. I have no problems > connecting and sending e-mail. Am I missing something? I followed your earlier thread (hopefully this is a related topic). This is strange. By default, sendmail is disabled. You don't even have to put anything into rc.conf: # grep sendmail /etc/defaults/rc.conf Sendmail listens and accepts local mail only. You can't connect to it from another machine: # telnet some.host.tld 25 Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection refused telnet: Unable to connect to remote host You must've tweaked something to make it behave differently. > I tested the same setup with sshd, and that works properly. After a > quick search on google it seems that I'm not the only one with this > problem, but I couldn't find any solution to this. Any help is greatly > appreciated. Share with us your testing methodology. From previous thread, I understand that you just want something to submit your local mail (from daemons, scripts, etc). Then as others already said, a simple alias in /etc/mail/aliases and executing newaliases is sufficient. Ok, so here's my current setup. I have sendmail_enable="NO" in rc.conf (same as not having it there I guess), I've modified /etc/mail/aliases to forward everything sent to root to my gmail account, and I added "sendmail : all : deny" as the first line to /etc/hosts.allow while I'm testing everything. Once I make sure that the deny rule works, I'll allow access to sendmail only from localhost. This is all on FreeBSD 6.2, but it's running in a jail, so that might have some effect. From my previous thread, sendmail is used only to accept messages sent by processes running on the server, and send them to real e-mails specified in /etc/aliases. That part works. However, even though sendmail_enable is set to "NO" in rc.conf, sendmail still listens on port 25, accepts mail from remote hosts, and the hosts.allow rule doesn't seem to apply. Strange, isn't it? By the way, I just tried removing sendmail_enable line from rc.conf completely and that had no effect. All I do for testing is basically start/restart sendmail, then telnet to the server from my workstation at home. I get a standard reply, and can then do the usual HELO, MAIL FROM, RCPT TO, DATA, and so on. Relaying doesn't work, but sending to and all other aliases works fine (which in this case is bad). Think this might be some bug when sendmail is running in a jail? I haven't modified anything beyond what's mentioned in this e-mail, and I've checked all the settings. I can definitely connect to the server from remote hosts despite the rc.conf and hosts.allow configuration. - Maxim Khitrov ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sendmail ignores hosts.allow
Maxim Khitrov wrote: > Hello, > > I'm trying to restrict access to sendmail via hosts.allow. Don't need > a firewall, since I just want to block everyone but the localhost from > sending e-mail out. Anyway, it seems that sendmail ignores these > settings even though it was compiled with TCPWRAPPERS. I added > "sendmail : all : deny" as the very first line in hosts.allow, just to > see if it will let me connect from anywhere. It does - not just from > localhost, but from all remote locations as well. I have no problems > connecting and sending e-mail. Am I missing something? I followed your earlier thread (hopefully this is a related topic). This is strange. By default, sendmail is disabled. You don't even have to put anything into rc.conf: # grep sendmail /etc/defaults/rc.conf Sendmail listens and accepts local mail only. You can't connect to it from another machine: # telnet some.host.tld 25 Trying 1.2.3.4... telnet: connect to address 1.2.3.4: Connection refused telnet: Unable to connect to remote host You must've tweaked something to make it behave differently. > I tested the same setup with sshd, and that works properly. After a > quick search on google it seems that I'm not the only one with this > problem, but I couldn't find any solution to this. Any help is greatly > appreciated. Share with us your testing methodology. From previous thread, I understand that you just want something to submit your local mail (from daemons, scripts, etc). Then as others already said, a simple alias in /etc/mail/aliases and executing newaliases is sufficient. Regards, Mikhail. -- Mikhail Goriachev Webanoide Telephone: +61 (0)3 62252501 Mobile Phone: +61 (0)4 38255158 E-Mail: [EMAIL PROTECTED] Web: www.webanoide.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sendmail ignores hosts.allow
Hello, I'm trying to restrict access to sendmail via hosts.allow. Don't need a firewall, since I just want to block everyone but the localhost from sending e-mail out. Anyway, it seems that sendmail ignores these settings even though it was compiled with TCPWRAPPERS. I added "sendmail : all : deny" as the very first line in hosts.allow, just to see if it will let me connect from anywhere. It does - not just from localhost, but from all remote locations as well. I have no problems connecting and sending e-mail. Am I missing something? I tested the same setup with sshd, and that works properly. After a quick search on google it seems that I'm not the only one with this problem, but I couldn't find any solution to this. Any help is greatly appreciated. - Maxim Khitrov ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What to write in a secure hosts.allow file? Please advise
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 VeeJay wrote: Uhm... a) Why did you include the example file? b) Didn't you understand the examples? I think you need to sit down with a Unix book and figure out what's going on.. - -Garrett -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.1 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqAyBEnKyINQw/HARAvfaAJ9NuOhIBH8nkfQmgAcqllN6/KmGOACdHehT MfQhrcLXhKXdSK62atI2U94= =m0yj -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What to write in a secure hosts.allow file? Please advise
This is a sample file... What to REMOVE and What to ADD or KEEP? # cat /etc/hosts.allow # # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.19.8.1 2006/02/19 14:57:01 ume Exp $ # # NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. #_ _ _ # | | __ __ __ _ _ __ ____ __ | | ___ | | # | _| \ \/ / / _` | | '_ ` _ \ | '_ \ | | / _ \ | | # | |___ > < | (_| | | | | | | | | |_) | | | | __/ |_| # |_| /_/\_\ \__,_| |_| |_| |_| | .__/ |_| \___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. ALL : ALL : allow # Wrapping sshd(8) is not normally a good idea, but if you # need to do it, here's how #sshd : .evil.cracker.example.com : deny # Protect against simple DNS spoofing attacks by checking that the # forward and reverse records for the remote host match. If a mismatch # occurs, access is denied, and any positive ident response within # 20 seconds is logged. No protection is afforded against DNS poisoning, # IP spoofing or more complicated attacks. Hosts with no reverse DNS # pass this rule. ALL : PARANOID : RFC931 20 : deny # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). ALL : localhost 127.0.0.1 : allow # Comment out next line if you build libwrap with NO_INET6=yes. ALL : [::1] : allow ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s ALL : [fe80::%fxp0]/10 : allow ALL : [fe80::]/10 : deny ALL : [2001:db8:2:1:2:3:4:3fe1] : deny ALL : [2001:db8:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers sendmail : localhost : allow sendmail : .nice.guy.example.com : allow sendmail : .evil.cracker.example.com : deny sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow exim : .nice.guy.example.com : allow exim : .evil.cracker.example.com : deny exim : ALL : allow # Rpcbind is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) rpcbind : 192.0.2.32/255.255.255.224 : allow rpcbind : 192.0.2.96/255.255.255.224 : allow rpcbind : ALL : deny # NIS master server. Only local nets should have access ypserv : localhost : allow ypserv : .unsafe.my.net.example.com : deny ypserv : .my.net.example.com : allow ypserv : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow ftpd : .nice.guy.example.com : allow ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a "finger war". fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s "tcpd\: [EMAIL PROTECTED] fingered me!" root) & \ : deny # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." -- Thanks! BR / vj ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on hosts.allow
Hello, Well, You will always see the attempts in security logs. As Derek Wrote, you have to allow your IP and deny the rest. Also, you may set in /etc/ssh/sshd_config a line in the bottom of the file which reads AllowUsers YOUR_USER_HERE In this case, you will make sure your ip and the specific username(s). -- Marwan Sultan. I can't say if it will read your other file, I use explicit lines such as: sshd: 192.168.1.20 : allow sshd: 82.165.182.220 : deny sshd: ALL: DENY This allows ONLY access from good known IP's. You will still see the attempts in the security logs. -Derek At 11:04 PM 12/20/2006, David Banning wrote: I have been running denyhosts to stop attacks on my ssh port. The attacks continue after protection is put in place. Here is what I have in the tail of my /etc/hosts.allow as per the installation instructions; - ... sshd : /etc/hosts.deniedssh : deny sshd : ALL : allow - and in /etc/hosts.deniedssh I have; - sshd: 82.165.182.220 : deny sshd: 200.52.90.100 : deny - but I am still receiving attacks from the last IP address. So I am wondering what program actually -reads- hosts.allow May be it has to be reset, or restarted? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on hosts.allow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Banning wrote: > I have been running denyhosts to stop attacks on my ssh port. > > The attacks continue after protection is put in place. > > Here is what I have in the tail of my /etc/hosts.allow > as per the installation instructions; > - > ... > sshd : /etc/hosts.deniedssh : deny > sshd : ALL : allow > - > > and in /etc/hosts.deniedssh I have; > > - > sshd: 82.165.182.220 : deny > sshd: 200.52.90.100 : deny > - This isn't quite right. This file should contain IP addresses, one per line, without any of the extraneous stuff - the `sshd' and `deny' bits are taken care of by the sshd : /etc/hosts.deniedssh : deny line in /etc/hosts.allow. (Effectively, with your current setup, your hosts.allow rules expand to something like this: sshd : sshd : 82.165.182.220 : deny : deny which doesn't make much sense!) At a guess, your BLOCK_SERVICE is set to something other than an empty value. It needs to be "BLOCK_SERVICE =" (without the quotes, of course...) to ensure that only offending IP addresses get written out to the auxiliary file. > > but I am still receiving attacks from the last IP address. So I am wondering > what program actually -reads- hosts.allow It should be read by anything that's built with tcpwrappers support. In this case, it would be sshd. > May be it has to be reset, or restarted? No, I don't think so. I would imagine the problem is the screwy syntax of your config. Try setting BLOCK_SERVICE in /usr/local/etc/denyhosts.conf, restart DenyHosts and see what happens... Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFio/rixf5fBYiFmoRAqQGAJ9USWP47e9nC6ChfhL8BzdxX7tFRwCgvUA9 U/pe3iiTdjkKzBctcaAU50k= =QmiM -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: question on hosts.allow
I can't say if it will read your other file, I use explicit lines such as: sshd: 192.168.1.20 : allow sshd: 82.165.182.220 : deny sshd: ALL: DENY This allows ONLY access from good known IP's. You will still see the attempts in the security logs. -Derek At 11:04 PM 12/20/2006, David Banning wrote: I have been running denyhosts to stop attacks on my ssh port. The attacks continue after protection is put in place. Here is what I have in the tail of my /etc/hosts.allow as per the installation instructions; - ... sshd : /etc/hosts.deniedssh : deny sshd : ALL : allow - and in /etc/hosts.deniedssh I have; - sshd: 82.165.182.220 : deny sshd: 200.52.90.100 : deny - but I am still receiving attacks from the last IP address. So I am wondering what program actually -reads- hosts.allow May be it has to be reset, or restarted? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
question on hosts.allow
I have been running denyhosts to stop attacks on my ssh port. The attacks continue after protection is put in place. Here is what I have in the tail of my /etc/hosts.allow as per the installation instructions; - ... sshd : /etc/hosts.deniedssh : deny sshd : ALL : allow - and in /etc/hosts.deniedssh I have; - sshd: 82.165.182.220 : deny sshd: 200.52.90.100 : deny - but I am still receiving attacks from the last IP address. So I am wondering what program actually -reads- hosts.allow May be it has to be reset, or restarted? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow and ssh problem
On May 19, 2006, at 7:33 PM, David Kelly wrote: On May 19, 2006, at 8:55 PM, jekillen wrote: I am trying to deny ftp access to my web site from out side. I have two nics on the server and access it from the inside network via one and serve to the public on the other. I tried to write a rule in hosts.allow to deny ftp connections to the public ip address which has worked. But a side effect is that I can now not connect from local machines via ssh. Your machine is connected to the outside world and you are not running a firewall? If I understand correctly hosts.allow (and the hosts_access library routines) operate in the applications themselves. The only reason you wish to keep the outside world from reaching your ftpd is out of fear that its somehow vulnerable and/or someone will come across your username/password combination. So, nip it in the bud with a firewall rule and never let them get that close. Simply deny port 21 incoming on your external interface. Everything should work as always on your internal interface. In ipfw where $nic_ext is fxp0 or whatever your extenal NIC is named: ipfw add deny ip from any to any ftp in via $nic_ext Yes, thank you, I do need to set up the fire wall, but I needed a quicker fix for the moment. posting to this list helped me unblock my brain, maybe we have biochemical firewalls built in that are programmed by morons. but I got a working set of rules for hosts.allow. Now I will proceed with the firewall set up. Thanks again. JK -- David Kelly N4HHE, [EMAIL PROTECTED] === = Whom computers would destroy, they must first drive mad. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow and ssh problem
jekillen wrote: Hello all; I am trying to deny ftp access to my web site from out side. I have two nics on the server and access it from the inside network via one and serve to the public on the other. I tried to write a rule in hosts.allow to deny ftp connections to the public ip address which has worked. But a side effect is that I can now not connect from local machines via ssh. I reverted back to 'ALL : all ; allow' to confirm that that was in deed why ssh started refusing connections, as it now will accept connections. I even ssh'd to one machine and while in that shell, ssh'd to the server and got in to the server via another machine on the local network. I am concerned because I have had repeated attempts to login to the server over ftp from outside. I do all the development and posting from local network so there is no reason whatsoever for anyone from the out side to get ftp access to my site. How can I do this in hosts.allow? A few nights ago I noticed odd activity on the router (leds going bananas) so I did tcpdump on the server and saw a great deal of ftp activity that didn't look right, from foreign addresses. I shut the web server and the secondary dns server down while I dug through Absolute FreeBSD to get some direction. I can live with ssh refusing local connections but I don't think it should be that way. Thanks in advance; JK ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" Default to denying everything... and then add rules to allow the few you would like to have access. Here is a snippet from my hosts.allow. sshd : A.B.C.D : allow sshd : SomeHostName : allow sshd : D.E.F.0/255.255.255.0 : allow sshd : H.I.J.0/255.255.255.0 : allow sshd : ALL : deny sendmail : localhost : allow sendmail : ALL : deny cupsd : localhost : allow cupsd : ALL : deny # ftpd does not have tcpwrappers :( # must run via inetd context ftpd : localhost : allow ftpd : A.B.C.D : allow ftpd : ALL : deny # DENY DENY DENY ALL : ALL : deny replace alpha chars with appropriate ip addresses. See 'man hosts.allow' Note that a firewall would be quite helpful as well. But that's another post. HTH, -- Regards, Eric ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow and ssh problem
On May 19, 2006, at 8:55 PM, jekillen wrote: I am trying to deny ftp access to my web site from out side. I have two nics on the server and access it from the inside network via one and serve to the public on the other. I tried to write a rule in hosts.allow to deny ftp connections to the public ip address which has worked. But a side effect is that I can now not connect from local machines via ssh. Your machine is connected to the outside world and you are not running a firewall? If I understand correctly hosts.allow (and the hosts_access library routines) operate in the applications themselves. The only reason you wish to keep the outside world from reaching your ftpd is out of fear that its somehow vulnerable and/or someone will come across your username/password combination. So, nip it in the bud with a firewall rule and never let them get that close. Simply deny port 21 incoming on your external interface. Everything should work as always on your internal interface. In ipfw where $nic_ext is fxp0 or whatever your extenal NIC is named: ipfw add deny ip from any to any ftp in via $nic_ext -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hosts.allow and ssh problem
Hello all; I am trying to deny ftp access to my web site from out side. I have two nics on the server and access it from the inside network via one and serve to the public on the other. I tried to write a rule in hosts.allow to deny ftp connections to the public ip address which has worked. But a side effect is that I can now not connect from local machines via ssh. I reverted back to 'ALL : all ; allow' to confirm that that was in deed why ssh started refusing connections, as it now will accept connections. I even ssh'd to one machine and while in that shell, ssh'd to the server and got in to the server via another machine on the local network. I am concerned because I have had repeated attempts to login to the server over ftp from outside. I do all the development and posting from local network so there is no reason whatsoever for anyone from the out side to get ftp access to my site. How can I do this in hosts.allow? A few nights ago I noticed odd activity on the router (leds going bananas) so I did tcpdump on the server and saw a great deal of ftp activity that didn't look right, from foreign addresses. I shut the web server and the secondary dns server down while I dug through Absolute FreeBSD to get some direction. I can live with ssh refusing local connections but I don't think it should be that way. Thanks in advance; JK ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> > Jerry McAllister wrote: > >> At Sun, 19 Mar 2006 it looks like Jerry McAllister composed: > >> > >>> One doesn't start anything from the rc.conf file - at least properly. > >>> Those things get started from /usr/local/etc/rc.d. > >>> > >>> What goes in /etc/rc.conf are environmental variable settings that > >>> those rc.d scripts look at to determine what to do. > >>> > >> I was under the impression that when one 'restarts' that the > >> service will "re-read" /etc/rc.conf > > > > I am not sure just at what point the rc.conf is read or re-read. > > Try putting something in the /usr/local/etc/rc.d/.sh script to > > check for a specific environmental variable that you make up and put > > in /etc/rc.conf and then running the .sh script manually to see > > what it knows about - even just put a printenv in the script. > > > > jerry > > From the source it's clear that rc.conf is read when the individual rc > script executes a load_rc_config $name (or equivalent). Sounds likely. I didn't actually check where it reads it. jerry > > HTH, > Micah > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Jerry McAllister wrote: At Sun, 19 Mar 2006 it looks like Jerry McAllister composed: One doesn't start anything from the rc.conf file - at least properly. Those things get started from /usr/local/etc/rc.d. What goes in /etc/rc.conf are environmental variable settings that those rc.d scripts look at to determine what to do. I was under the impression that when one 'restarts' that the service will "re-read" /etc/rc.conf I am not sure just at what point the rc.conf is read or re-read. Try putting something in the /usr/local/etc/rc.d/.sh script to check for a specific environmental variable that you make up and put in /etc/rc.conf and then running the .sh script manually to see what it knows about - even just put a printenv in the script. jerry From the source it's clear that rc.conf is read when the individual rc script executes a load_rc_config $name (or equivalent). HTH, Micah ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> > At Sun, 19 Mar 2006 it looks like Jerry McAllister composed: > > > One doesn't start anything from the rc.conf file - at least properly. > > Those things get started from /usr/local/etc/rc.d. > > > > What goes in /etc/rc.conf are environmental variable settings that > > those rc.d scripts look at to determine what to do. > > > > I was under the impression that when one 'restarts' that the > service will "re-read" /etc/rc.conf I am not sure just at what point the rc.conf is read or re-read. Try putting something in the /usr/local/etc/rc.d/.sh script to check for a specific environmental variable that you make up and put in /etc/rc.conf and then running the .sh script manually to see what it knows about - even just put a printenv in the script. jerry > > ### > > [EMAIL PROTECTED] ~]-> uname -r > 6.0-RELEASE > > [EMAIL PROTECTED] ~]-> /etc/rc.d/sshd restart > > ### > > -- > Bill Schoolcraft | http://wiliweld.com > > "If your life was full of nothing but > sunshine, you would just be a desert." > > > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> Just out of curiosity, why can 'sshd' not be started from the > '/etc/rc.conf' file? Sure you can. Just add a line into /etc/rc.conf like this: sshd_enable="YES" sshd should be started automatically during next boot. Regards, Anthony M. Rasat PT. Kalteng Pos Press Palangkaraya - Indonesia.- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> I'm not sure this is correct. If you read sshd(8), you'll see in the > FILES section that sshd will read /etc/hosts.allow and /etc/hosts.deny > on its own (i.e. it's compiled/linked with libwrap). Looking at > /usr/src/crypto/openssh/Makefile.in for the sshd target verifies this. That and sshd will re-read the file at each new connection or as soon as the file is changed. You don't need any signal/restarting of sshd to make the new wrapping policy effective. Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
At Sun, 19 Mar 2006 it looks like Jerry McAllister composed: > One doesn't start anything from the rc.conf file - at least properly. > Those things get started from /usr/local/etc/rc.d. > > What goes in /etc/rc.conf are environmental variable settings that > those rc.d scripts look at to determine what to do. > I was under the impression that when one 'restarts' that the service will "re-read" /etc/rc.conf ### [EMAIL PROTECTED] ~]-> uname -r 6.0-RELEASE [EMAIL PROTECTED] ~]-> /etc/rc.d/sshd restart ### -- Bill Schoolcraft | http://wiliweld.com "If your life was full of nothing but sunshine, you would just be a desert." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> > Chris Maness wrote: > > > Daniel A. wrote: > > > On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: > > >> My denyhost script is doing it's job by adding: > > >> > > >> sshd: 62.149.232.105 : deny > > >> > > >> to the hosts.allow file, but I see that this host is still making > > >> attempts to get into my box. Is there a cron job or something > > >> that has to re-read the hosts.allow file before it the IP will be > > >> blocked? ___ > > >> freebsd-questions@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > >> To unsubscribe, send any mail to > > >> "[EMAIL PROTECTED]" > > > > > > Offtopic, but > > > How did you set up denyhosts? Daemon? Cron? > > > > p.s. > > > > OK, I was able to get to work by just starting out with a blank > > hosts.allow. Everything is allowed by default, so when denyhosts > > adds a deny line to the file, it will deny access to that host. > > > > Also, sshd can't be started in rc.conf, it has to be started in > > inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you > > make changes. > > Just out of curiosity, why can 'sshd' not be started from the=20 > '/etc/rc.conf' file? Hmmm. Do you want sshd or inetd listening on the port and being the first one to screen things? Anyway, inetd provides some front end checking and doesn't even start it if it isn't from an acceptable place. jerry > > =2D-=20 > Gerard Seibert > [EMAIL PROTECTED] > > PGP: http://www.seibercom.net/sig/gerard.asc > > --nextPart3654328.GjrC4HtVEj > Content-Type: application/pgp-signature > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (FreeBSD) > > iD8DBQBEHXmFchM2dIO+3uMRAhLqAJ4yUlAdv8F4iOR6XroOBGA1gfmx2wCghmaI > JA15rhv79wmvbeNUMHdZzXY= > =irtd > -END PGP SIGNATURE- > > --nextPart3654328.GjrC4HtVEj-- > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
> > --nextPart3654328.GjrC4HtVEj > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > Chris Maness wrote: > > > Daniel A. wrote: > > > On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: > > >> My denyhost script is doing it's job by adding: > > >> > > >> sshd: 62.149.232.105 : deny > > >> > > >> to the hosts.allow file, but I see that this host is still making > > >> attempts to get into my box. Is there a cron job or something > > >> that has to re-read the hosts.allow file before it the IP will be > > >> blocked? ___ > > >> freebsd-questions@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > >> To unsubscribe, send any mail to > > >> "[EMAIL PROTECTED]" > > > > > > Offtopic, but > > > How did you set up denyhosts? Daemon? Cron? > > > > p.s. > > > > OK, I was able to get to work by just starting out with a blank > > hosts.allow. Everything is allowed by default, so when denyhosts > > adds a deny line to the file, it will deny access to that host. > > > > Also, sshd can't be started in rc.conf, it has to be started in > > inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you > > make changes. > > Just out of curiosity, why can 'sshd' not be started from the=20 > '/etc/rc.conf' file? One doesn't start anything from the rc.conf file - at least properly. Those things get started from /usr/local/etc/rc.d. What goes in /etc/rc.conf are environmental variable settings that those rc.d scripts look at to determine what to do. jerry > > =2D-=20 > Gerard Seibert > [EMAIL PROTECTED] > > PGP: http://www.seibercom.net/sig/gerard.asc > > --nextPart3654328.GjrC4HtVEj > Content-Type: application/pgp-signature > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.2.1 (FreeBSD) > > iD8DBQBEHXmFchM2dIO+3uMRAhLqAJ4yUlAdv8F4iOR6XroOBGA1gfmx2wCghmaI > JA15rhv79wmvbeNUMHdZzXY= > =irtd > -END PGP SIGNATURE- > > --nextPart3654328.GjrC4HtVEj-- > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Karol Kwiatkowski wrote: > Gerard Seibert wrote: >> Chris Maness wrote: >> >>> Also, sshd can't be started in rc.conf, it has to be started in >>> inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you >>> make changes. >> Just out of curiosity, why can 'sshd' not be started from the >> '/etc/rc.conf' file? > > Because Chris wants to limit sshd's connections with 'hosts.allow' > thing. Correct me if I'm wrong but my understanding is that inetd will > start ssh daemon every time new connection is made and that's why it's > not recommended (as written in default hosts.allow file). The > alternative is running sshd as a daemon and limit connections with, > say, pf's overload, max-src-conn and max-src-conn-rate. I'm not sure this is correct. If you read sshd(8), you'll see in the FILES section that sshd will read /etc/hosts.allow and /etc/hosts.deny on its own (i.e. it's compiled/linked with libwrap). Looking at /usr/src/crypto/openssh/Makefile.in for the sshd target verifies this. That's not to say that some work to sshd isn't required to get it to work outside of inetd.conf. After hosts.allow is updated, you may need to send a persistent sshd daemon a HUP to re-read config files, or something along those lines. I'm not familiar with whether or not the functions in libwrap automatically detect changes to the hosts.allow file, or it's read only when the initialize routines in the library are called. Cheers, - -Wes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iQIVAwUBRB2Ykorq8W17hxGfAQhLbQ//YUH/5DRkecpzl/EwJvwjv0n7N5T3+wU9 u4nzk8We4RGvChcdic5lIbFZxzZbdPQnm9iICAkqgrwC120yTukyD8eb33Awmrdc CO6FvXnJegvFmf14QONiQRpKj9W6T7RSUq/vhcJJytWSbsYY75JLM7ZEntxp77c6 qQuIYxMpWkopr97xKTw2rGHQbsKW4LxI4ES7U8iAN208F71f9JcFQVB4KiTMdnxD BdZ+XFHATvHX9OlUTuNE18XP5DrqTJ0n1jPlSH3JuhknaVt+WOVEcG7Zpmewgy+w GoZJzNJU5+3uLHVUE3APqbQFaBcIZz4VRYVsW0cYWnluQwJcFNF7xwojApvNbGQ+ ojByLHx1Zo3lWdH50us6Cvddrep5iFF03xNpNDxHKDyIq9QopF00uYGCNBU/j238 B/pEj4XlBgduBUsiL7lgegGi95i2XvfIUSJuVQ2gHdvG+DWiFKpMVhumM5E6gj0G JvKwsfnlBtjzdQ7IeDMrMb0Hlb1x2j4yy7S5xskM/NRcm3dkkVU9kNL9Dwxh5gS0 kA/Sm83hSNaT/Lc11Tqmd2GbQc9jFKhI7l5SM0Camc6ibRK6V2zlMMWWMfT1midQ qw3gYqXqJ3bxLp5ekvfStbJUG760ILABalytPIDDzK+jfnBRgH7tVBx+Gc2yHest ayn1YC28zig= =TMQo -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Gerard Seibert wrote: > Chris Maness wrote: > >> OK, I was able to get to work by just starting out with a blank >> hosts.allow. Everything is allowed by default, so when denyhosts >> adds a deny line to the file, it will deny access to that host. >> >> Also, sshd can't be started in rc.conf, it has to be started in >> inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you >> make changes. > > Just out of curiosity, why can 'sshd' not be started from the > '/etc/rc.conf' file? Because Chris wants to limit sshd's connections with 'hosts.allow' thing. Correct me if I'm wrong but my understanding is that inetd will start ssh daemon every time new connection is made and that's why it's not recommended (as written in default hosts.allow file). The alternative is running sshd as a daemon and limit connections with, say, pf's overload, max-src-conn and max-src-conn-rate. Regards, Karol -- Karol Kwiatkowski OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc signature.asc Description: OpenPGP digital signature
Re: hosts.allow ?
On 3/19/06, Gerard Seibert <[EMAIL PROTECTED]> wrote: > Chris Maness wrote: > > > Daniel A. wrote: > > > On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: > > >> My denyhost script is doing it's job by adding: > > >> > > >> sshd: 62.149.232.105 : deny > > >> > > >> to the hosts.allow file, but I see that this host is still making > > >> attempts to get into my box. Is there a cron job or something > > >> that has to re-read the hosts.allow file before it the IP will be > > >> blocked? ___ > > >> freebsd-questions@freebsd.org mailing list > > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > >> To unsubscribe, send any mail to > > >> "[EMAIL PROTECTED]" > > > > > > Offtopic, but > > > How did you set up denyhosts? Daemon? Cron? > > > > p.s. > > > > OK, I was able to get to work by just starting out with a blank > > hosts.allow. Everything is allowed by default, so when denyhosts > > adds a deny line to the file, it will deny access to that host. > > > > Also, sshd can't be started in rc.conf, it has to be started in > > inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you > > make changes. > > Just out of curiosity, why can 'sshd' not be started from the > '/etc/rc.conf' file? > > -- > Gerard Seibert > [EMAIL PROTECTED] > > PGP: http://www.seibercom.net/sig/gerard.asc > > > Yeah, why is that exactly? I can. Care to explain? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Chris Maness wrote: > Daniel A. wrote: > > On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: > >> My denyhost script is doing it's job by adding: > >> > >> sshd: 62.149.232.105 : deny > >> > >> to the hosts.allow file, but I see that this host is still making > >> attempts to get into my box. Is there a cron job or something > >> that has to re-read the hosts.allow file before it the IP will be > >> blocked? ___ > >> freebsd-questions@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >> To unsubscribe, send any mail to > >> "[EMAIL PROTECTED]" > > > > Offtopic, but > > How did you set up denyhosts? Daemon? Cron? > > p.s. > > OK, I was able to get to work by just starting out with a blank > hosts.allow. Everything is allowed by default, so when denyhosts > adds a deny line to the file, it will deny access to that host. > > Also, sshd can't be started in rc.conf, it has to be started in > inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you > make changes. Just out of curiosity, why can 'sshd' not be started from the '/etc/rc.conf' file? -- Gerard Seibert [EMAIL PROTECTED] PGP: http://www.seibercom.net/sig/gerard.asc pgpE358JemODS.pgp Description: PGP signature
Re: hosts.allow ?
Daniel A. wrote: On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Is there a cron job or something that has to re-read the hosts.allow file before it the IP will be blocked? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" Offtopic, but How did you set up denyhosts? Daemon? Cron? p.s. OK, I was able to get to work by just starting out with a blank hosts.allow. Everything is allowed by default, so when denyhosts adds a deny line to the file, it will deny access to that host. Also, sshd can't be started in rc.conf, it has to be started in inetd.conf. Make sure you do a /etc/rc.d/inetd restart after you make changes. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Daniel A. wrote: On 3/19/06, Chris Maness <[EMAIL PROTECTED]> wrote: My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Is there a cron job or something that has to re-read the hosts.allow file before it the IP will be blocked? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" Offtopic, but How did you set up denyhosts? Daemon? Cron? install security/denyhost add: # Mmonitor logfiles for suspcious activity @reboot root /usr/local/bin/denyhosts.py --daemon -c /etc/denyhosts.cfg to /etc/crontab I'm still playing with hosts.allow to get it to work right. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Kris Kennaway wrote: On Sat, Mar 18, 2006 at 06:01:31PM -0800, Chris Maness wrote: Kris Kennaway wrote: On Sat, Mar 18, 2006 at 05:48:29PM -0800, Chris Maness wrote: Sounds like something else is wrong with your hosts.allow then. # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. ALL : ALL : allow Kris Sorry guys, that was the stupidist mistake... No worries, we've all been there :-D Kris How would I allow all sshd except those denied from the bottom of the file (since it is first match wins)? The denyhost app adds entries at the bottom of the file. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
On Sat, Mar 18, 2006 at 06:01:31PM -0800, Chris Maness wrote: > Kris Kennaway wrote: > >On Sat, Mar 18, 2006 at 05:48:29PM -0800, Chris Maness wrote: > > > > > >>>Sounds like something else is wrong with your hosts.allow then. > >>> > > > > > >># Start by allowing everything (this prevents the rest of the file > >># from working, so remove it when you need protection). > >># The rules here work on a "First match wins" basis. > >>ALL : ALL : allow > >> > > > >Kris > > > Sorry guys, that was the stupidist mistake... No worries, we've all been there :-D Kris pgpfLFnEax2pw.pgp Description: PGP signature
Re: hosts.allow ?
Kris Kennaway wrote: On Sat, Mar 18, 2006 at 05:48:29PM -0800, Chris Maness wrote: Sounds like something else is wrong with your hosts.allow then. # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. ALL : ALL : allow Kris Sorry guys, that was the stupidist mistake... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris Maness wrote: >> > I tried running sshd off of inetd instead of in daemon mode. It still > didn't work. > > here is the file: Notice anything strange about the top? > # Start by allowing everything (this prevents the rest of the file > # from working, so remove it when you need protection). > # The rules here work on a "First match wins" basis. > ALL : ALL : allow You haven't set your hosts.allow policy...this is just letting everything connect. Cheers, - -Wes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iQIVAwUBRBy60orq8W17hxGfAQifJQ/6A6hyzDX4lRU4V0ruCatIWU4pYBG2UkOX J/zK4ywpjeueUCbpqHYjMZi2SV2xluYgdTgw0ycK6XYme0g5S5jn5N5bo3oemmVQ 8Ba8bnDG533VSKndgbVknfJVGZ3Xg9fE1vyYPgElFECdTUXb5vZLM6sYpZrrAxj+ l4iD5nPVJ/ik57ztYzFTEdxdVn5G006Cmif2mBRiufiYkKJPGgOfAjEderPrs4Ql OX0IbwLqJbiZTe+ALZu4mWrGG9aARczLzCsQI1f5a+MhMzB4E1Qb0lotHLlb2djM vPncFhqru14UWIzku/ekvOYfVKCnFhuNRYgZ2SFjGkxbVx0PCH6EFFhfUb1fpPr5 oBdwOEjErP9iYc3OFlvibWTOY6GtQ+fBlREo6fd2kgdFfUHDZMK2htWsPG0NXfgP ySw9axWrejqYlirC4QC0z6ooau3jPG0it/qVUBxx99ivCzmOCRTUWQ3F9lR3q6f/ QQ/0WIp7fpXAMCvyQkahZLTeYa8cFLyFpRr0KyaDsnAl5s3NvMNTls+AYdE/zl4B mIP5nFcGKIW5/w0boUwJ//ZXywUamnVSx0sSeKNG73/RxFPmSxnXfK4hi6uEwmv1 M0U8QMHlU3b8Z7NTWgf94aR8tu6seiL51YPylaMRy2RV0krWiLoq5TA3Gpje8hps kgJGJkzHw/E= =3vxM -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
On Sat, Mar 18, 2006 at 05:48:29PM -0800, Chris Maness wrote: > >Sounds like something else is wrong with your hosts.allow then. > # Start by allowing everything (this prevents the rest of the file > # from working, so remove it when you need protection). > # The rules here work on a "First match wins" basis. > ALL : ALL : allow Kris pgpvEXVki87si.pgp Description: PGP signature
Re: hosts.allow ?
Kris Kennaway wrote: On Sat, Mar 18, 2006 at 05:24:40PM -0800, Chris Maness wrote: Kris Kennaway wrote: On Sat, Mar 18, 2006 at 04:12:41PM -0800, Chris Maness wrote: My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Where do you see this (i.e. logged by what)? hosts.allow doesn't block the IP from connecting to the port, it blocks the application that listens on the port from allowing this IP to authenticate. e.g. your firewall may still log the connection. p.s. I tried a test from another one of my host by adding a line just like the one above and it still allows me to login. Sounds like something else is wrong with your hosts.allow then. Kris I tried running sshd off of inetd instead of in daemon mode. It still didn't work. here is the file: # # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.19 2004/08/03 08:58:34 ume Exp $ # # NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. #_ _ _ # | | __ __ __ _ _ __ ____ __ | | ___ | | # | _| \ \/ / / _` | | '_ ` _ \ | '_ \ | | / _ \ | | # | |___ > < | (_| | | | | | | | | |_) | | | | __/ |_| # |_| /_/\_\ \__,_| |_| |_| |_| | .__/ |_| \___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. ALL : ALL : allow # Wrapping sshd(8) is not normally a good idea, but if you # need to do it, here's how #sshd : .evil.cracker.example.com : deny # Protect against simple DNS spoofing attacks by checking that the # forward and reverse records for the remote host match. If a mismatch # occurs, access is denied, and any positive ident response within # 20 seconds is logged. No protection is afforded against DNS poisoning, # IP spoofing or more complicated attacks. Hosts with no reverse DNS # pass this rule. ALL : PARANOID : RFC931 20 : deny # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). ALL : localhost 127.0.0.1 [::1] : allow ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s ALL : [fe80::%fxp0]/10 : allow ALL : [fe80::]/10 : deny ALL : [2001:db8:2:1:2:3:4:3fe1] : deny ALL : [2001:db8:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers sendmail : localhost : allow sendmail : .nice.guy.example.com : allow sendmail : .evil.cracker.example.com : deny sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow exim : .nice.guy.example.com : allow exim : .evil.cracker.example.com : deny exim : ALL : allow # Rpcbind is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) rpcbind : 192.0.2.32/255.255.255.224 : allow rpcbind : 192.0.2.96/255.255.255.224 : allow rpcbind : ALL : deny # NIS master server. Only local nets should have access ypserv : localhost : allow ypserv : .unsafe.my.net.example.com : deny ypserv : .my.net.example.com : allow ypserv : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow ftpd : .nice.guy.example.com : allow ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a "finger war". fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s "tcpd\: [EMAIL PROTECTED] fingered me!" root) & \ : deny # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \ : twist /bin/echo "You are not welcome to use %d from %h." sshd: 131.113.74.44 : deny sshd: 219.235.52.5 : deny sshd: 211.215.16.60 : deny sshd: 211.144.8.211 : deny sshd: 62.149.232.105 : deny sshd: 208.179.97.3 : deny ftpd : 208.179.97.3 : deny ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
On Sat, Mar 18, 2006 at 05:24:40PM -0800, Chris Maness wrote: > Kris Kennaway wrote: > >On Sat, Mar 18, 2006 at 04:12:41PM -0800, Chris Maness wrote: > > > >>My denyhost script is doing it's job by adding: > >> > >>sshd: 62.149.232.105 : deny > >> > >>to the hosts.allow file, but I see that this host is still making > >>attempts to get into my box. > >> > > > >Where do you see this (i.e. logged by what)? hosts.allow doesn't > >block the IP from connecting to the port, it blocks the application > >that listens on the port from allowing this IP to authenticate. > >e.g. your firewall may still log the connection. > > > > > p.s. I tried a test from another one of my host by adding a line just > like the one above and it still allows me to login. Sounds like something else is wrong with your hosts.allow then. Kris pgpHuZgRlYF39.pgp Description: PGP signature
Re: hosts.allow ?
Kris Kennaway wrote: On Sat, Mar 18, 2006 at 04:12:41PM -0800, Chris Maness wrote: My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Where do you see this (i.e. logged by what)? hosts.allow doesn't block the IP from connecting to the port, it blocks the application that listens on the port from allowing this IP to authenticate. e.g. your firewall may still log the connection. p.s. I tried a test from another one of my host by adding a line just like the one above and it still allows me to login. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
Kris Kennaway wrote: On Sat, Mar 18, 2006 at 04:12:41PM -0800, Chris Maness wrote: My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Where do you see this (i.e. logged by what)? hosts.allow doesn't block the IP from connecting to the port, it blocks the application that listens on the port from allowing this IP to authenticate. e.g. your firewall may still log the connection. in auth.log ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow ?
On Sat, Mar 18, 2006 at 04:12:41PM -0800, Chris Maness wrote: > My denyhost script is doing it's job by adding: > > sshd: 62.149.232.105 : deny > > to the hosts.allow file, but I see that this host is still making > attempts to get into my box. Where do you see this (i.e. logged by what)? hosts.allow doesn't block the IP from connecting to the port, it blocks the application that listens on the port from allowing this IP to authenticate. e.g. your firewall may still log the connection. > Is there a cron job or something that has > to re-read the hosts.allow file before it the IP will be blocked? No. Kris pgpbQDQ8NJVdJ.pgp Description: PGP signature
hosts.allow ?
My denyhost script is doing it's job by adding: sshd: 62.149.232.105 : deny to the hosts.allow file, but I see that this host is still making attempts to get into my box. Is there a cron job or something that has to re-read the hosts.allow file before it the IP will be blocked? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hosts.allow
On a FreeBSD 4.10 server I'm trying to allow certain ip's ssh access to my server. In hosts.allow I have: sshd: 192.168. /etc/icanonips.hosts and in the icanonips.hosts file for the range of ips from 67.62.xxx.130 to 67.62.xxx.159 I have: sshd: 67.62.xxx.130/255.255.255.224 67.62.xxx.131/255.255.255.224 sshd: 67.62.xxx.132/255.255.255.224 67.62.xxx.133/255.255.255.224 sshd: 67.62.xxx.134/255.255.255.224 67.62.xxx.135/255.255.255.224 sshd: 67.62.xxx.136/255.255.255.224 67.62.xxx.137/255.255.255.224 sshd: 67.62.xxx.138/255.255.255.224 67.62.xxx.139/255.255.255.224 sshd: 67.62.xxx.140/255.255.255.224 67.62.xxx.141/255.255.255.224 sshd: 67.62.xxx.142/255.255.255.224 67.62.xxx.143/255.255.255.224 sshd: 67.62.xxx.144/255.255.255.224 67.62.xxx.145/255.255.255.224 sshd: 67.62.xxx.146/255.255.255.224 67.62.xxx.147/255.255.255.224 sshd: 67.62.xxx.148/255.255.255.224 67.62.xxx.149/255.255.255.224 sshd: 67.62.xxx.150/255.255.255.224 67.62.xxx.151/255.255.255.224 sshd: 67.62.xxx.152/255.255.255.224 67.62.xxx.153/255.255.255.224 sshd: 67.62.xxx.154/255.255.255.224 67.62.xxx.155/255.255.255.224 sshd: 67.62.xxx.156/255.255.255.224 67.62.xxx.157/255.255.255.224 sshd: 67.62.xxx.158/255.255.255.224 67.62.xxx.159/255.255.255.224 192.168 is my internal network(which works). It's just that the outside range of IP's don't work. I've replaced a portion of the real ip with xxx for this message. Basically, I'm not sure of the syntax when you use an external file. thx, -- -Jim McIver ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow
> BIND version 9.x (not sure on the exact version) and up supports ACLs.
>
> example named.conf
>
> acl china {
> 218.19.160.163; } ;
>
> options {
>blackhole {china;};
> };
thanks ... that looks like a solution...
>
> - jeff
>
--
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow
On Wed, 23 Feb 2005 19:20:11 -0500 (EST), kalin mintchev <[EMAIL PROTECTED]>
wrote:
> >> Feb 23 17:21:05 bigdaddy named[85641]: client 218.19.160.163#64057:
> no such chances. the machine is not on my local network. on the network
> where this machine is there is no windows machines. and the 218.19.160.163
> is somewhere in china
>
> is there any other way to block it? except ipfw rules...
>
BIND version 9.x (not sure on the exact version) and up supports ACLs.
example named.conf
acl china {
218.19.160.163; } ;
options {
blackhole {china;};
};
- jeff
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow
>> Feb 23 17:21:05 bigdaddy named[85641]: client 218.19.160.163#64057: >> update 'bigdaddy.com/IN' denied >> >> so i put: >> >> ALL : 218.19.160.163 : deny >> >> in my hosts.allow but i still get that log piling up > > Named isn't built with tcpwrapper support; it would probably cause too > much overhead. Chances are the machine at 218.19.160.163 is a windows > XP machine at your location, with Dynamic DNS updating enabled. Just > go into the TCP/IP prefs and disable it. no such chances. the machine is not on my local network. on the network where this machine is there is no windows machines. and the 218.19.160.163 is somewhere in china is there any other way to block it? except ipfw rules... thanks > > -- > Dan Nelson > [EMAIL PROTECTED] > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow
In the last episode (Feb 23), kalin mintchev said: > i have some crap in my log like: > > Feb 23 16:56:45 bigdaddy named[85641]: client 218.19.160.163#63869: update > 'bigdaddy.com/IN' denied > Feb 23 16:56:46 bigdaddy named[85641]: client 218.19.160.163#62855: update > 'bigdaddy.com/IN' denied > Feb 23 17:02:10 bigdaddy named[85641]: client 218.19.160.163#63999: update > 'bigdaddy.com/IN' denied > Feb 23 17:16:20 bigdaddy named[85641]: client 218.19.160.163#62723: update > 'bigdaddy.com/IN' denied > Feb 23 17:16:59 bigdaddy named[85641]: client 218.19.160.163#63975: update > 'bigdaddy.com/IN' denied > Feb 23 17:20:38 bigdaddy named[85641]: client 218.19.160.163#63873: update > 'bigdaddy.com/IN' denied > Feb 23 17:21:05 bigdaddy named[85641]: client 218.19.160.163#64057: update > 'bigdaddy.com/IN' denied > > so i put: > > ALL : 218.19.160.163 : deny > > in my hosts.allow but i still get that log piling up Named isn't built with tcpwrapper support; it would probably cause too much overhead. Chances are the machine at 218.19.160.163 is a windows XP machine at your location, with Dynamic DNS updating enabled. Just go into the TCP/IP prefs and disable it. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hosts.allow
hi all... i have some crap in my log like: Feb 23 16:56:45 bigdaddy named[85641]: client 218.19.160.163#63869: update 'bigdaddy.com/IN' denied Feb 23 16:56:46 bigdaddy named[85641]: client 218.19.160.163#62855: update 'bigdaddy.com/IN' denied Feb 23 17:02:10 bigdaddy named[85641]: client 218.19.160.163#63999: update 'bigdaddy.com/IN' denied Feb 23 17:16:20 bigdaddy named[85641]: client 218.19.160.163#62723: update 'bigdaddy.com/IN' denied Feb 23 17:16:59 bigdaddy named[85641]: client 218.19.160.163#63975: update 'bigdaddy.com/IN' denied Feb 23 17:20:38 bigdaddy named[85641]: client 218.19.160.163#63873: update 'bigdaddy.com/IN' denied Feb 23 17:21:05 bigdaddy named[85641]: client 218.19.160.163#64057: update 'bigdaddy.com/IN' denied so i put: ALL : 218.19.160.163 : deny in my hosts.allow but i still get that log piling up isn't the that line in hosts.allow avoiding that? should i restart something? thanks... -- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Valid statement in hosts.allow
> Is this valid in hosts.allow: >ALL : 151.103.xxx.xxx-151.103.xxx.xxx : allow Not that I know. i ue the configuration net-address/netmask would be: > allow a range of ip's like 192.168.0.1-192.168.64.254. 192.168.0.0/255.255.192.0 for the range 192.168.0.0 to 192.168.63.255 192.168.64.0/255.255.255 for the range 192.168.64.0 to 192.168.64.255 Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Valid statement in hosts.allow
Is this valid in hosts.allow: ALL : 151.103.xxx.xxx-151.103.xxx.xxx : allow The x's are just hiding the other part of the ip address. I need to allow a range of ip's like 192.168.0.1-192.168.64.254. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hosts.allow and netatalk/cups
On Tue, Jan 11, 2005 at 02:31:47AM -0500, Bob Hall wrote: > Three questions: > > How do I cause changes in the hosts.allow file to take effect without > rebooting? Everything I've seen says to restart inetd, but I'm not using > inetd. I searched with different keywords and found the answer to this in the archives. Searching the archives, Googling, and experimentation still haven't turned up an answer to the two below. > How do I compile netatalk without CUPS? I don't see any obvious > switches, but there has to be something that tells Make to use CUPS, > because it gives a message saying that it's checking if CUPS can be > included. > > How do I get netatalk to use the dbd cnid scheme? It ignores the > path name cnidscheme:dbd > setting in AppleVolumes.default and the > - -cnidserver localhost:4700 > setting in afpd.conf. Regardless of what the cnidscheme setting is, it > announces that's there's no cnid scheme selected and uses the default. > > Bob Hall > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hosts.allow and netatalk/cups
On Tue, Jan 11, 2005 at 02:37:23PM +0700, Olivier Nicole wrote: > To my knowledge, the effects in /etc/hosts.allow are immediate as soon > as you save the modified file. > > And I have been using it that way for many years. > > No need to killall -HUP inetd, no need to reboot. > > If after a change the service is still not available: > > - you did not allow the right thing > > - the servcie would not be working even without tcp wrapper > > Try to add ALL : ALL : allow at the top of /etc/hosts/allow. Does the > service work? Then you made a mistake when trying to open tcp wrapper > for that specific service. Else the problem is not with tcp wrapper / > hosts.allow. Thanks for the comments, but changes to /etc/hosts.allow don't take effect until the system is rebooted. And when the system is rebooted, they definitely take effect. Two entries that take effect if and only if the system is rebooted: smbd : .krig.net : allow afpd : .krig.net : allow Commenting these out and saving the file has no effect. Rebooting the system stops Windows and Mac file sharing. Uncommenting them and saving the file has no effect. Rebooting the system restores Windows and Mac file sharing. uname -a FreeBSD kongemord.krig.net 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Sep 13 00 :17:04 EDT 2004 kongemord.krig.net:/usr/obj/usr/src/sys/KONGEMORD0 i386 Bob Hall ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Hosts.allow and netatalk/cups
To my knowledge, the effects in /etc/hosts.allow are immediate as soon as you save the modified file. And I have been using it that way for many years. No need to killall -HUP inetd, no need to reboot. If after a change the service is still not available: - you did not allow the right thing - the servcie would not be working even without tcp wrapper Try to add ALL : ALL : allow at the top of /etc/hosts/allow. Does the service work? Then you made a mistake when trying to open tcp wrapper for that specific service. Else the problem is not with tcp wrapper / hosts.allow. Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Hosts.allow and netatalk/cups
Three questions: How do I cause changes in the hosts.allow file to take effect without rebooting? Everything I've seen says to restart inetd, but I'm not using inetd. How do I compile netatalk without CUPS? I don't see any obvious switches, but there has to be something that tells Make to use CUPS, because it gives a message saying that it's checking if CUPS can be included. How do I get netatalk to use the dbd cnid scheme? It ignores the path name cnidscheme:dbd setting in AppleVolumes.default and the - -cnidserver localhost:4700 setting in afpd.conf. Regardless of what the cnidscheme setting is, it announces that's there's no cnid scheme selected and uses the default. Bob Hall ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ssh security with hosts.allow
I moved sshd off the standard port of 22, added a AllowUsers line, added a AllowGroups line, added a MaxStartups 8:30:10, I'd say taking the service to a nonstandard port helped more than anything. Logs have not shown an attempt after the move. On Mon, Oct 25, 2004 at 10:38:44AM -0700, Steve Warwick wrote: > Hi All, > > Since implementing a hosts.allow "deny" on SSHD for all but my IP I am > seeing a slew of ssh attempts from overseas. > > My questions are: > > Is a good password and hosts.allow enough to keep out the bad guys? > > Is this normal? (I assume these attempts are automated) > > Thanks > > Steve > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- == The information contained in this communication is confidential, private, proprietary, or otherwise privileged and is intended only for the use of the addressee. Unauthorized use, disclosure, distribution or copying is strictly prohibited and may be unlawful. If you have received this communication in error, please notify the sender immediately. == ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ssh security with hosts.allow
Hi All, Since implementing a hosts.allow "deny" on SSHD for all but my IP I am seeing a slew of ssh attempts from overseas. My questions are: Is a good password and hosts.allow enough to keep out the bad guys? Is this normal? (I assume these attempts are automated) Thanks Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail ignores hosts.allow
Can anyone confirm this behavior on their machine? Doing an ldd /usr/libexec/sendmail/sendmail shows: /usr/libexec/sendmail/sendmail: libutil.so.3 => /usr/lib/libutil.so.3 (0x280fd000) libwrap.so.3 => /usr/lib/libwrap.so.3 (0x28106000) libssl.so.3 => /usr/lib/libssl.so.3 (0x2810e000) libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x2813e000) libc.so.4 => /usr/lib/libc.so.4 (0x2823e000) so it's clearly linked with libwrap. What's going on here?? According to Rich Winkel: > According to Ruben de Groot: > > On Sun, Aug 29, 2004 at 11:53:55PM -0500, Rich Winkel typed: > > > I'm running 4.10-release-p2. Sendmail is ignoring hosts.allow. > > > Is this a known problem? > > > > AFAIK, no. Could you post your hosts.allow? Are you using sendmail from > > the base system? > > Hi, sorry I was burnt out from lack of sleep and beating my head > against the wall :) I'm using the base system sendmail. > I just put (as an example): > sendmail : 127.0.0.1 : deny > as the first line of /etc/hosts.allow, > kill and restart sendmail (just in case) and do a > telnet localhost 25 > and it still connects: > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > 220 crusty.math.missouri.edu ESMTP Sendmail 8.12.11/8.12.11; Mon, 30 Aug 2004 > 09:35:29 -0500 (CDT) > quit > 221 2.0.0 crusty.math.missouri.edu closing connection > > Do I need anything special in sendmail.cf? I don't think I used to ... > Can anyone confirm this on their system? > > Thanks!!! > Rich > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sendmail ignores hosts.allow
I'm running 4.10-release-p2. Sendmail is ignoring hosts.allow. Is this a known problem? Thanks, Rich ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hosts.allow Question (help)
Hello everyone. Im on FreeBSD 4.8R. In my hosts.allow file, i have set my IPs to :allow and the last line is to deny all by default. so the server accepts only my incoming IPs. the problem is I have a webmail running so the mails also start to be rejected! i cannot see any new emails..although i set a line as follow in my hosts.allow sendmail : ALL : allow Any help? ideas please? How i can tune my hosts.allow to deny IPs and make the incoming emails outging just to be accepted from everywhere.? Marwan. _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Long Story wrote: | Hello everyone, | |Because of the MASS failure tries to connect to my server using | random passwords |I decided to allow only my IP to access the server. http://www.die.net/doc/linux/man/man5/hosts.allow.5.html - -- Siddhartha Jain (CISSP) Consulting Engineer Netmagic Solutions Pvt Ltd Bombay - 400063 Phone: +91-22-26850001 Ext.128 Fax : +91-22-26850002 http://www.netmagicsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBIiUDOGaxOP7knVwRAtiQAJsEwRrkHHHpP40dauJxv7eUPduKVQCgi/RZ TGzrLReOco2hhbo4L52Pu78= =UDqD -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hosts.allow Question
Hello everyone, Because of the MASS failure tries to connect to my server using random passwords I decided to allow only my IP to access the server. I didnot do this before cuz i was worried this restriction will effect any services running.. a question: If i change hosts.allow to accept only my ip adrs and next line is ALL : ALL : deny is this will effect any performance? such as webmail, smtp or other connections/services? After fixing those lines, I used the webMail to send mail, then an SMTP error came saying (access denied) hmm any hint? Example (The IP is an Example): ALL : 192.168.0. : allow ALL : ALL : deny One more stupid question. If i want to allow a whole class of ips, shall i write as ALL : 192.168.0.* : allow(using the star) OR ALL : 192.168.0. : allow (leave it empty) Thanks for the help. Marwan. _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow not always working... misses some IPs
On Tue, Dec 02, 2003 at 12:54:32AM -0500, Kerry B. Rogers wrote: > I received an e-mail with the following header fragment: > > ===V=== cut here ===V > Received: from priv-edtnes11-hme0.telusplanet.net (outbound03.telus.net > [199.185.220.222]) > by tinkertoys.net (8.12.10/8.11.6) with ESMTP id hANMNpKS021237; > Sun, 23 Nov 2003 15:23:51 -0700 (MST) > ===^=== cut here ===^==== > > In my hosts.allow file (which usually rejects domains just fine) I have: > smtp : 199.185.220.0/255.255.251.0 : deny ---^^^ > The above listed e-mail should have been rejected but it wasn't. Is this a > bug? Is a 975K host.allow file creating this problem? Please help... I added your rule to my hosts.allow and tested it using: tcpdmatch smtp 199.185.220.222 The rule was not triggered. Changing the rule to a valid netmask (255.255.255.0) did trigger the rule & denied access. Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow not always working... misses some IPs
> I received an e-mail with the following header fragment: > > ===V=== cut here ===V > Received: from priv-edtnes11-hme0.telusplanet.net (outbound03.telus.net > [199.185.220.222]) > by tinkertoys.net (8.12.10/8.11.6) with ESMTP id hANMNpKS021237; > Sun, 23 Nov 2003 15:23:51 -0700 (MST) > ===^=== cut here ===^==== > > In my hosts.allow file (which usually rejects domains just fine) I have: > > ===V=== cut here ===V > smtp : 199.185.220.0/255.255.251.0 : deny > ===^=== cut here ===^ Are you sure about the netmask? I think it should be something like 255.255.255.0 or 255.255.252.0. Simon signature.asc Description: Digital signature
hosts.allow not always working... misses some IPs
Dear Whomever, I've already sent this last week but no one is responding. Once more... I received an e-mail with the following header fragment: ===V=== cut here ===V Received: from priv-edtnes11-hme0.telusplanet.net (outbound03.telus.net [199.185.220.222]) by tinkertoys.net (8.12.10/8.11.6) with ESMTP id hANMNpKS021237; Sun, 23 Nov 2003 15:23:51 -0700 (MST) ===^=== cut here ===^ In my hosts.allow file (which usually rejects domains just fine) I have: ===V=== cut here ===V smtp : 199.185.220.0/255.255.251.0 : deny ===^=== cut here ===^ The above listed e-mail should have been rejected but it wasn't. Is this a bug? Is a 975K host.allow file creating this problem? Please help... Thanks, Kerry B. Rogers [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD - Secure by DEFAULT ?? [hosts.allow]
Hi, I need to know what the implications are to make use of the hosts.allow file on a FreeBSD Production Server (ISP Setup)? The reason I'm asking, is that I've recently decommisioned a Linux SendMail Server to a FreeBSD Exim Server, but with no Firewall (IPTABLES) yet. Besides the fact that it only runs EXIM and Apache, is it necessary to Configure rc.Firewall? or can I only make use of the hosts.allow file? Currently I would only like to allow SSH access from my Home Network, instead of allowing the WORLD. I've seen OpenBSD Servers using hosts.deny and hosts.allow files, but based on the new "Access Control File", it is all merged together in one file: # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.8.2.7 2002/04/17 19:44:22 dougb Exp $ # I take that I should allow the other Services, in this order: sshd : myhomepc : allow exim : ALL : allow httpd : ALL : allow ftpd : ALL : allow ALL : ALL : deny What kind of protection does FreeBSD need by Default? Since OpenBSD goes around saying: "SECURE BY DEFAULT" !? Just asking. Regards Schalk Erasmus Incredible Networks Windhoek, Namibia ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD - Secure by DEFAULT ?? [hosts.allow]
On Thu, 2003-08-07 at 19:24, Schalk Erasmus wrote: > Hi, > > I need to know what the implications are to make use of the hosts.allow file > on a FreeBSD Production Server (ISP Setup)? The reason I'm asking, is that > I've recently decommisioned a Linux SendMail Server to a FreeBSD Exim > Server, but with no Firewall (IPTABLES) yet. > > Besides the fact that it only runs EXIM and Apache, is it necessary to > Configure rc.Firewall? or can I only make use of the hosts.allow file? Only applications that honour tcp_wrappers use hosts.allow. Therefore to ensure that your machine is secure it would be wise to use a firewall of some kind. > Currently I would only like to allow SSH access from my Home Network, > instead of allowing the WORLD. > > I've seen OpenBSD Servers using hosts.deny and hosts.allow files, but based > on the new "Access Control File", it is all merged together in one file: > > # hosts.allow access control file for "tcp wrapped" applications. > # $FreeBSD: src/etc/hosts.allow,v 1.8.2.7 2002/04/17 19:44:22 dougb Exp $ > # > > I take that I should allow the other Services, in this order: > > sshd : myhomepc : allow > exim : ALL : allow > httpd : ALL : allow > ftpd : ALL : allow > ALL : ALL : deny That would limit ssh only from myhomepc. So thats correct. > What kind of protection does FreeBSD need by Default? Since OpenBSD goes > around saying: "SECURE BY DEFAULT" !? Hmm, I don't think OpenBSD runs a firewall by default. Basically they start you off with a very restrictive setup. FreeBSD is reasonably secure "by default" to. But, if you plan to have this box running in a ISP environment a firewall would be highly recommended. -- --byron signature.asc Description: This is a digitally signed message part
OpenSSH + hosts.allow ?
Hi all, Somehow I can't search the mailing list anymore, so apology if this has been asked before. In hosts.allow, it is written that wrapping ssh is not a good idea. (Why, can anyone tell me the reason ?) However, I found that to use ssh, I got to uncomment the ssh line in the wrapper, which implying it's not the most appropriate way of doing things. So, what's actually should be done to use ssh 'properly' ? Thank's __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changes to hosts.allow do no affect to inetd daemons some times
On Mon, Jun 02, 2003 at 01:11:55PM +0200, Alexander wrote:
> I really know what tcp wrappers is. I just can't exactly get your point.
> I'm telling you that I shut the ftpd totaly, I've left just one line at
> /etc/hosts.allow: ALL : ALL : deny
>
> and when I simply telnet-ed my.host.com 21 it opened a connection.
Ah. If TCP wrappers is working correctly, you should see the
connection open and then close either almost immediately or as soon as
you try and pass any traffic. A port scanner, like nmap(1) will show
the port as open. You certainly shouldn't see any FTP banners or
other FTP traffic if you telnet to the port though, and you should see
a log message from TCP wrappers showing that it denied access. If you
want to run an ftp service hidden completely from certain remote
sites, then ipfw(8) or ipf(8) is your friend.
What does 'tcpdmatch' say if you test it with various daemon names and
client addresses?
> I have also auth, pop3, smtp (qmail actually)
>
> I've shutted the qmail totaly. The pop3 wasn't in use so it leaves to
> auth. According to you if the auth service is active while I change
> /etc/hosts.allow, there might be a problem with auth only ... but what
> about the others ?! Does this affect them too ? As I said, I tried even to
> kill inetd. Nothing helped
If you kill inetd entirely, then all of the ports managed by inetd
should be closed, as 'netstat -a' should show.
There are 5 different example lines for the 'auth' service in
/etc/inetd.conf, 4 of which are internal inetd services using
'nowait'. Just use one or more of those, rather than the external
identd.
'auth' is meant to be a security thing, but honestly it's pretty much
useless --- correctly paranoid system administrators will worry that
it reveals entirely too much about the internal setup of their systems
and either shut it off or configure it to lie by default. Personally
I tend to set up my firewalls to just reset connections to port 113
(nb. not drop, as that will lead to annoying delays) and not run any
auth service at all:
% grep 113 /etc/happy-idiot-talk.ipfw
add 1300 reset tcp from any to 81.2.69.216/29{218,219} 113 setup in recv de0
> Again, it's not happening just to a single wrapped daemon, it's happening
> to all in /etc/inetd.conf
What flags are you supplying when you start up inetd? The default is:
inetd_flags="-wW"
which turns on the TCP wrappers for internal (W) and external (w)
services via inetd. If you've modified the inetd_flags setting in
/etc/rc.conf, you should make sure you include those two letters. If
you're still flummoxed, try running inetd with the '-d' (debug) flag
and test making some connections.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
pgp0.pgp
Description: PGP signature
Re: Changes to hosts.allow do no affect to inetd daemons some times
Hello I really know what tcp wrappers is. I just can't exactly get your point. I'm telling you that I shut the ftpd totaly, I've left just one line at /etc/hosts.allow: ALL : ALL : deny and when I simply telnet-ed my.host.com 21 it opened a connection. I have also auth, pop3, smtp (qmail actually) I've shutted the qmail totaly. The pop3 wasn't in use so it leaves to auth. According to you if the auth service is active while I change /etc/hosts.allow, there might be a problem with auth only ... but what about the others ?! Does this affect them too ? As I said, I tried even to kill inetd. Nothing helped Again, it's not happening just to a single wrapped daemon, it's happening to all in /etc/inetd.conf Thanks On Mon, 2 Jun 2003, Matthew Seaman wrote: > On Mon, Jun 02, 2003 at 10:46:25AM +0200, Alexander wrote: > > So what you say is that if I had opened identd socket for example then > > updating /etc/hosts.allow and changing rules for ftpd won't take affect on > > ftpd after new connection ? (assuming that noone is using my ftpd at all) > > Uh -- no. The ftpd lines in /etc/inetd.conf look like this by default: > > ftpstream tcp nowait root/usr/libexec/ftpd ftpd -l > ftpstream tcp6nowait root/usr/libexec/ftpd ftpd -l > > Since the service is marked 'nowait', inetd will handle all incoming > connections to the ftp port and spawn a new copy of ftpd to service > each different session. inetd will apply the changed tcp wrappers > filters to each new ftp connection as it occurs. It won't > retrospectively modify any active ftp sessions. > > Most things in /etc/inetd.conf are marked 'nowait', and of the things > that are marked 'wait' the vast majority are either 'internal' -- > built into inetd -- or they are for RPC based services, in which case > the TCP wrappers support built into portmap(8) (aka rpcbind(8) on > FreeBSD 5.x) will be what's important. In the default inetd.conf > file, there are only 7 exceptions: > > % grep '\bwait' /etc/inetd.conf | grep -v 'internal\|rpc' > #comsat dgram udp waittty:tty /usr/libexec/comsat comsat > #ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd > #tftp dgram udp waitroot/usr/libexec/tftpd tftpd -s > /tftpboot > #tftp dgram udp6waitroot/usr/libexec/tftpd tftpd -s > /tftpboot > #bootps dgram udp waitroot/usr/libexec/bootpd bootpd > #auth stream tcp waitroot/usr/local/sbin/identd identd -w -t120 > #netbios-ns dgram udp waitroot/usr/local/sbin/nmbd nmbd > > So only if you have enabled one or more of those services and there > are instances of those processes running should you need to kill and > restart them to be sure that your modifications to /etc/hosts.allow > will be applied. Nb. you don't need to restart inetd itself, just > kill the running instances of ntalkd, bootpd etc. inetd will cope with > starting new ones as required. > > For more info about TCP wrappers, look at > > ftp://ftp.porcupine.org/pub/security/tcp_wrapper.ps.Z -or- > ftp://ftp.porcupine.org/pub/security/tcp_wrapper.txt.Z > >(Wietse Venema's presentation to the 3rd Unix Security Symposium) > > -plus- > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcp_wrappers/README?rev=1.1.1.1.2.1&content-type=text/x-cvsweb-markup > > but bear in mind that the FreeBSD inetd has the tcp_wrappers stuff > built in, so no need for the separate tcpd program. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks > Savill Way > PGP: http://www.infracaninophile.co.uk/pgpkey Marlow > Tel: +44 1628 476614 Bucks., SL7 1TH UK > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changes to hosts.allow do no affect to inetd daemons some times
On Mon, Jun 02, 2003 at 10:46:25AM +0200, Alexander wrote: > So what you say is that if I had opened identd socket for example then > updating /etc/hosts.allow and changing rules for ftpd won't take affect on > ftpd after new connection ? (assuming that noone is using my ftpd at all) Uh -- no. The ftpd lines in /etc/inetd.conf look like this by default: ftpstream tcp nowait root/usr/libexec/ftpd ftpd -l ftpstream tcp6nowait root/usr/libexec/ftpd ftpd -l Since the service is marked 'nowait', inetd will handle all incoming connections to the ftp port and spawn a new copy of ftpd to service each different session. inetd will apply the changed tcp wrappers filters to each new ftp connection as it occurs. It won't retrospectively modify any active ftp sessions. Most things in /etc/inetd.conf are marked 'nowait', and of the things that are marked 'wait' the vast majority are either 'internal' -- built into inetd -- or they are for RPC based services, in which case the TCP wrappers support built into portmap(8) (aka rpcbind(8) on FreeBSD 5.x) will be what's important. In the default inetd.conf file, there are only 7 exceptions: % grep '\bwait' /etc/inetd.conf | grep -v 'internal\|rpc' #comsat dgram udp waittty:tty /usr/libexec/comsat comsat #ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp waitroot/usr/libexec/tftpd tftpd -s /tftpboot #tftp dgram udp6waitroot/usr/libexec/tftpd tftpd -s /tftpboot #bootps dgram udp waitroot/usr/libexec/bootpd bootpd #auth stream tcp waitroot/usr/local/sbin/identd identd -w -t120 #netbios-ns dgram udp waitroot/usr/local/sbin/nmbdnmbd So only if you have enabled one or more of those services and there are instances of those processes running should you need to kill and restart them to be sure that your modifications to /etc/hosts.allow will be applied. Nb. you don't need to restart inetd itself, just kill the running instances of ntalkd, bootpd etc. inetd will cope with starting new ones as required. For more info about TCP wrappers, look at ftp://ftp.porcupine.org/pub/security/tcp_wrapper.ps.Z -or- ftp://ftp.porcupine.org/pub/security/tcp_wrapper.txt.Z (Wietse Venema's presentation to the 3rd Unix Security Symposium) -plus- http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/tcp_wrappers/README?rev=1.1.1.1.2.1&content-type=text/x-cvsweb-markup but bear in mind that the FreeBSD inetd has the tcp_wrappers stuff built in, so no need for the separate tcpd program. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Changes to hosts.allow do no affect to inetd daemons some times
So what you say is that if I had opened identd socket for example then updating /etc/hosts.allow and changing rules for ftpd won't take affect on ftpd after new connection ? (assuming that noone is using my ftpd at all) Thanks On Mon, 2 Jun 2003, Matthew Seaman wrote: > On Mon, Jun 02, 2003 at 05:26:15AM +0200, Alexander wrote: > > Hello ! > > > > Sometimes when I change my /etc/hosts.allow and kill and start again > > inetd, there is no difference. It's like I haven't edited > > /etc/hosts.allow. If I continue making changes and stop/start inetd there > > are no affections to the inetd daemons, they allow or deny as > > /etc/hosts.allow isn't modified since inetd was first started after the > > system bootstrapped. > > So what I do now is edit /etc/hosts.allow and then reboot. (Pretty ugly) > > But I noticed that this happens only to the /etc/inetd.conf daemons. > > Stand alone daemons like sshd haven't got such problem the changes occur > > immediately. > > You don't need to restart inetd(8) when you edit /etc/hosts.allow. > TCP wrappers will immediately pick up any changes to that file and > apply them to all subsequent processes connecting to a wrapped > service. > > You are probably seeing the effect of persistent connections: either > connections that are still ongoing or processes spawned by inetd > marked as 'wait', which take over the socket and can accept new > connections if they happen to be running already. Since the TCP > wrappers function is provided by inetd, it can only be applied at the > point that incoming network traffic causes inetd to start up the > wrapped process. Generally processes managed by inetd are fairly > short lived but there are occasional exceptions: nmbd from the samba > suite always seems to start up one time and then run continuously for > ever after. > > Note that long running services with the TCP wrappers functionality > compiled in to them (sendmail, sshd etc) will pick up changes to > hosts.allow instantaneously. Of course, samba software is itself > generally linked against TCP wrappers in exactly this manner. > > Cheers, > > Matthew > > -- > Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks > Savill Way > PGP: http://www.infracaninophile.co.uk/pgpkey Marlow > Tel: +44 1628 476614 Bucks., SL7 1TH UK > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Changes to hosts.allow do no affect to inetd daemons some times
On Mon, Jun 02, 2003 at 05:26:15AM +0200, Alexander wrote: > Hello ! > > Sometimes when I change my /etc/hosts.allow and kill and start again > inetd, there is no difference. It's like I haven't edited > /etc/hosts.allow. If I continue making changes and stop/start inetd there > are no affections to the inetd daemons, they allow or deny as > /etc/hosts.allow isn't modified since inetd was first started after the > system bootstrapped. > So what I do now is edit /etc/hosts.allow and then reboot. (Pretty ugly) > But I noticed that this happens only to the /etc/inetd.conf daemons. > Stand alone daemons like sshd haven't got such problem the changes occur > immediately. You don't need to restart inetd(8) when you edit /etc/hosts.allow. TCP wrappers will immediately pick up any changes to that file and apply them to all subsequent processes connecting to a wrapped service. You are probably seeing the effect of persistent connections: either connections that are still ongoing or processes spawned by inetd marked as 'wait', which take over the socket and can accept new connections if they happen to be running already. Since the TCP wrappers function is provided by inetd, it can only be applied at the point that incoming network traffic causes inetd to start up the wrapped process. Generally processes managed by inetd are fairly short lived but there are occasional exceptions: nmbd from the samba suite always seems to start up one time and then run continuously for ever after. Note that long running services with the TCP wrappers functionality compiled in to them (sendmail, sshd etc) will pick up changes to hosts.allow instantaneously. Of course, samba software is itself generally linked against TCP wrappers in exactly this manner. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Changes to hosts.allow do no affect to inetd daemons some times
> Sometimes when I change my /etc/hosts.allow and kill and start again > inetd, there is no difference. It's like I haven't edited > /etc/hosts.allow. If I continue making changes and stop/start inetd there > are no affections to the inetd daemons, they allow or deny as > /etc/hosts.allow isn't modified since inetd was first started after the > system bootstrapped. My guess would be that some of the servers started with inetd are still up-and running. Remember that tcpwrapper will filter connection initiated through inetd. If, say, your ftp server is runing and handling requests, it will not be affected by your changes in hosts.allow. Your FTP server does not know that tcpwrapper is ther actually. So at same time you kill -HUp inetd, you should also kill all the services started by inetd and that are running. SSH does access tcpwrapper by itself, so it is not affected by this behaviour. Bests, olivier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Changes to hosts.allow do no affect to inetd daemons some times
Hello ! Sometimes when I change my /etc/hosts.allow and kill and start again inetd, there is no difference. It's like I haven't edited /etc/hosts.allow. If I continue making changes and stop/start inetd there are no affections to the inetd daemons, they allow or deny as /etc/hosts.allow isn't modified since inetd was first started after the system bootstrapped. So what I do now is edit /etc/hosts.allow and then reboot. (Pretty ugly) But I noticed that this happens only to the /etc/inetd.conf daemons. Stand alone daemons like sshd haven't got such problem the changes occur immediately. I'm running FreeBSD 4.8-STABLE #9: Mon Apr 7 14:16:26 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AMOUR i386 If you know what might be the problem please email me. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts.allow
On Thu, Jul 25, 2002 at 03:02:50PM +0200, Dave Raven wrote: > Hello all, > This seems to be a fairly simple questions, but has > been bothering me for a while now. > I want to specify whole IP classes instead of single ips > in my hosts.allow config file. > > These are the methods I have tried (unsuccessfully): > > sshd : 192.168.0.0/255.255.255.0 : allow > sshd : 192.168.0. : allow > sshd : 192.168.0/24 : allow > sshd : 192.168.0.024 : allow > > What is the actuall way of doing this? It seems there are a few ways of doing it - take a look at the section headed PATTERNS in man 5 hosts_access Dan -- Daniel Bye PGP Key: ftp://ftp.slightlystrange.org/pgpkey/dan.asc PGP Key fingerprint: 3D73 AF47 D448 C5CA 88B4 0DCF 849C 1C33 3C48 2CDC _ ASCII ribbon campaign ( ) - against HTML, vCards and X - proprietary attachments in e-mail / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
hosts.allow
Hello all, This seems to be a fairly simple questions, but has been bothering me for a while now. I want to specify whole IP classes instead of single ips in my hosts.allow config file. These are the methods I have tried (unsuccessfully): sshd : 192.168.0.0/255.255.255.0 : allow sshd : 192.168.0. : allow sshd : 192.168.0/24 : allow sshd : 192.168.0.024 : allow What is the actuall way of doing this? Thanks, Dave. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
hosts.allow
Hello all, This seems to be a fairly simple questions, but has been bothering me for a while now. I want to specify whole IP classes instead of single ips in my hosts.allow config file. These are the methods I have tried (unsuccessfully): sshd : 192.168.0.0/255.255.255.0 : allow sshd : 192.168.0. : allow sshd : 192.168.0/24 : allow sshd : 192.168.0.024 : allow What is the actuall way of doing this? Thanks, Dave. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
