[NTLUG:Discuss] Strange iptables problem on CentOS 4.4

Leroy Tennison leroy_tennison at prodigy.net
Tue Feb 20 22:27:36 CST 2007


. Daniel wrote:
>> Chris Cox wrote:
>>     
>>> . Daniel wrote:
>>>
>>>       
>>>> That's an interesting question.  I had seen something like that not 
>>>>         
> too
>   
>>>> long ago.  It too was CentOS 4.4 in fact.  I think when I saw the 
>>>>         
> error, I
>   
>>>> hadn't yes corrected a router configuration mistake I had made.  I was
>>>> attempting to forward all data for a given IP address to a specific 
>>>>         
> machine
>   
>>>> within the firewall.  What I failed to do was make the machines 
>>>>         
> responses
>   
>>>> MASQ through the same IP address.  Once I made the Masq correction, it
>>>> worked just fine.
>>>>
>>>> My first impression was that "hey, this must be the 'secure' part of 
>>>>         
> ssh."
>   
>>>> I still don't understand why ssh is better than telnet... other than 
>>>>         
> the
>   
>>>> plain text thing, but then again, who will be sniffing in average
>>>> situations?
>>>>
>>>>         
>>> You would be surprised.  Think of the poor folks on cable (a giant
>>> neighborhood ethernet hub).... very easy to sniff out passwords
>>> and such.
>>>
>>>
>>> _______________________________________________
>>> http://www.ntlug.org/mailman/listinfo/discuss
>>>
>>>
>>>       
>> A couple of other things to consider:  Maybe the question shouldn't be
>> "Who will be sniffing?" but "What damage could be done if they do?"
>> Another way to view this is to ask "What is the cost/benefit?"  The
>> "cost" for using ssh seems to be pretty low - a little setup and some
>> performance hit for the encryption (which may not matter depending on
>> what you are doing).  The benefit is in greatly reduced worry about
>> "what if".  If you are sniffed how much damage could be done by gaining
>> the user name and password?  Another consideration may be your
>> reputation.  Depending on the context, using an insecure protocol,
>> regardless if anything happens, may be perceived negatively.
>>
>> Not knowing your situation I can't answer any of these questions.  I do
>> believe that they should be given serious consideration though.
>>     
>
> I guess I can sort of understand what you're trying to say, but I don't 
> fully understand the benefits.  For example, at a previous job, I couldn't 
> telnet into most of the Linux boxen, but ssh was available.  By default, 
> even when telnet is available, root isn't available as a user.  However, 
> with ssh, it is.  I have never set up ssh before.  It either is or it isn't 
> as far as I know.  So as far as I am concerned, ssh is rather like https.  
> The two points have established an encrypted link.
>
> But fundamentally, I have to wonder about perceptions.  Is it better to use 
> something you don't fully understand simply because other people do?  Or is 
> it better to understand what you're doing?  I have always subscribed to the 
> latter as the former never made much sense to me.  Been like that since I 
> was a little boy though, so maybe it's just me.
>
> _________________________________________________________________
> 大切なあの人、気になるあの人とケータイでチャット! 
> http://messenger.live.jp/mobile.htm 
>
>
> _______________________________________________
> http://www.ntlug.org/mailman/listinfo/discuss
>
>   
The perception in this case is for a reason. I have used a "packet
analyzer" (= Sniffer or Etherreal or any of the other packet capture
tools) and the user name and password are extremely obvious in the
packet displays. In doing a packet trace against secure ftp (a whole
different story but the same basic idea: encrypt the transmission) all
you see is "mush" and you don't even necessarily know what part of it to
attempt to decipher. If the ID being used has any privilege then the
risk of damage is basically equal to that privilege. There are ways to
make insecure transmissions more or less risk free by crippling the
account (very limited access to the destination file system, quotas on
disk space, execute privileges almost non-existent) but you never know
if you (or a programmer of part of the system) missed something.

I would never discourage anyone from wanting to understand what they are
doing but all of us have limits. I don't have the time to learn
everything I want. I have also found that there are some things that I
just "don't get" (like some of the cryptography stuff I'm currently
reading). You have to "pick your battles" and decide what you really
want to know and what you're going to just accept.



More information about the Discuss mailing list