Dear All,
I want to allow telnet in my server from local LAN from only one IP address, to fulfill the requirement what should I do from the following
[1] add an entry in /etc/host.allow like following
telnetd : xx.xx.xx.xx
or
[2] add an entry in /etc/host.deny like following
telnet : ALL except xxx.xxx.xxx.xxx
[3] or simply create a iptables rule to allow telnet from desired IP
what is the best option to go through ???
On Fri, 2010-10-01 at 18:09 +0530, Jatin K wrote:
what is the best option to go through ???
Well, you could do both. Allow/deny and iptables. That way, if you have to fiddle with one, the other is still there.
On Friday 01 October 2010 06:45 PM, Tim wrote:
On Fri, 2010-10-01 at 18:09 +0530, Jatin K wrote:
what is the best option to go through ???
Well, you could do both. Allow/deny and iptables. That way, if you have to fiddle with one, the other is still there.
what is the perfect way
only host.allow or host.deny file
or only iptables ??
On Fri, Oct 01, 2010 at 19:06:26 +0530, Jatin K ssh.fedora@gmail.com wrote:
what is the perfect way
only host.allow or host.deny file
or only iptables ??
I don't think there is one. It depends how you want to manage your system.
Personally, I like iptables, but using tcpwrappers is fine as well.
Jatin K <ssh.fedora <at> gmail.com> writes:
Dear All,
I want to allow telnet in my server from local LAN from only one IP address, to fulfill the requirement what should I do from the following
[1] add an entry in /etc/host.allow like following
telnetd : xx.xx.xx.xx
or
[2] add an entry in /etc/host.deny like following
telnet : ALL except xxx.xxx.xxx.xxx
[3] or simply create a iptables rule to allow telnet from desired IP
what is the best option to go through ???
Hi,
Be careful. 1. man 5 hosts_access ACCESS CONTROL FILES Read it multiple times :-) 2. Use iptables as well.
JB
On Fri, 2010-10-01 at 19:06 +0530, Jatin K wrote:
what is the perfect way
only host.allow or host.deny file
or only iptables ??
One could argue that this is no "perfect" way. And that multiple efforts to protect yourself is the best way.
Personally, I'd deny all, and just allow the known address. Then do the same with the firewall rule. Though, I wouldn't allow telnet, at all. Are you sure you need it?
On Sat, Oct 2, 2010 at 9:11 PM, Tim ignored_mailbox@yahoo.com.au wrote:
On Fri, 2010-10-01 at 19:06 +0530, Jatin K wrote:
what is the perfect way
only host.allow or host.deny file
or only iptables ??
One could argue that this is no "perfect" way. And that multiple efforts to protect yourself is the best way.
Personally, I'd deny all, and just allow the known address. Then do the same with the firewall rule. Though, I wouldn't allow telnet, at all. Are you sure you need it?
-- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists.
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Big agree with this. It's called defence in depth. However every security decision must be made while considering the trade-offs. Tradeoffs are the possible negative affects of having such strong security, and the most common one is having the security you implemented turn against it's purpose, blocking authorised and identified users.
On Saturday 02 October 2010 06:41 PM, Tim wrote:
On Fri, 2010-10-01 at 19:06 +0530, Jatin K wrote:
what is the perfect way
only host.allow or host.deny file
r only iptables ??
One could argue that this is no "perfect" way. And that multiple efforts to protect yourself is the best way.
Personally, I'd deny all, and just allow the known address. Then do the same with the firewall rule. Though, I wouldn't allow telnet, at all. Are you sure you need it?
I'm also thinking like you ... no need to allow telnet .....but customer is the king .... he says the he wants telnet to server ... nothing can be done ...!!!
finally I've used both host file and iptables ...
thnx for you help
Tim:
Though, I wouldn't allow telnet, at all. Are you sure you need it?
Jatin K:
I'm also thinking like you ... no need to allow telnet .....but customer is the king .... he says the he wants telnet to server ... nothing can be done ...!!!
I'd ask to make sure whether he knows about alternatives. He might be able to SSH, but doesn't know it even exists.
Telnet being completely unencrypted makes it easy for anyone snooping to capture passwords. Though, having said that, most people fetch their mail using a protocol that sends the passwords unencrypted, too.
finally I've used both host file and iptables ...
Since you're making this public, you might want to look at something like fail2ban, as well. It adds IPs to a deny list, for a while, when they make a few unsuccessful connection attempts.
On its own, telnet will allow someone to keep on hammering away at it until they chance upon a working password. The automatic banning script makes the chances of succeeding very difficult.
On Tuesday 05 October 2010 10:53 AM, Tim wrote:
Tim:
Though, I wouldn't allow telnet, at all. Are you sure you need it?
Jatin K:
I'm also thinking like you ... no need to allow telnet .....but customer is the king .... he says the he wants telnet to server ... nothing can be done ...!!!
I'd ask to make sure whether he knows about alternatives. He might be able to SSH, but doesn't know it even exists.
that also can be a good solution ..you are right
Telnet being completely unencrypted makes it easy for anyone snooping to capture passwords. Though, having said that, most people fetch their mail using a protocol that sends the passwords unencrypted, too.
finally I've used both host file and iptables ...
Since you're making this public
entire network is not connected to the Internet .... it's only on LAN only 60 to 65 computers on it
Tim:
Since you're making this public
Jatin K:
entire network is not connected to the Internet .... it's only on LAN only 60 to 65 computers on it
That could be public or private... Whether you want to be more secure against eavesdropping on traffic, and against malcontented people, is more of an issue about who can access it, and what they might do, regardless of whether they're on the internet or the same LAN.