Re: OT: Security....

From: Scot L. Harris (webid_at_cfl.rr.com)
Date: 11/04/04

  • Next message: Mike Noble: "No sound after install"
    To: Fedora List <fedora-list@redhat.com>
    Date: Thu, 04 Nov 2004 10:49:41 -0500
    
    

    On Sun, 2004-10-31 at 18:19, James Wilkinson wrote:
    > Joel wrote (about SSH attacks):
    > > The guys that are not smart enough to spoof the IP when they try to
    > > climb in are usually on DHCP, or at a netcafe, or at a school where they
    > > are more than half likely to get kicked out.
    >
    > I refer the honourable Joel to my previous response.
    >
    > In particular, you can't really spoof IP addresses on SSH sessions. The
    > server needs to be able to get packets back to the (possibly attacking)
    > client, which means the client's IP address must be routable.
    >
    > James.

    At what point does the system log the ssh attempt? If it is after the
    initial 3 way handshake then I think an ssh attempt could be spoofed
    without having to receive packets back from the target system. From
    what I can tell it appears that when you initiate an ssh attempt the
    standard 3 way handshake is started. You send a SYN packet, the target
    sends a SYN ACK packet. Normally since you would not get the SYN ACK
    packet the connection would not be completed. However if you
    manufacture a ACK packet and send that a few seconds after you send the
    SYN packet I think you would have a good chance of completing the
    handshake. If that gets logged as an SSH attempt then the active
    response system in place may block the spoofed sender IP address.

    True, the sender would never get any packets back but that would not
    matter if they are simply trying to DOS a system using its own tools.

    There are two questions I don't know the answers to without doing some
    testing: 1. When is the SSH attempt logged, after the initial handshake
    or later on in the conversation. 2. what happens when the machine who's
    address is spoofed gets a SYN ACK that is did not send?

    I does not make any sense for the spoofed machine to send any kind of
    response to an unsolicited SYN ACK. I guess it might send a RST but
    since it is not waiting for a SYN ACK I think it would just drop the
    packet. This would work to the spoofers benefit since the machines
    who's address is being spoofed would not step on the spoofed packets
    being sent to the target machine.

    So that leaves the question of how far down the sequence do you need to
    spoof the traffic to get the system to log an SSH attempt?

    I agree that you would not be able to establish a complete connection
    with the system but then the topic that was being discussed was having a
    malicious hacker simply cause your own system to block important
    addresses from your own system.

    -- 
    Scot L. Harris
    webid@cfl.rr.com
    Stinginess with privileges is kindness in disguise.
    		-- Guide to VAX/VMS Security, Sep. 1984 
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Mike Noble: "No sound after install"

    Relevant Pages

    • Re: OT: Security....
      ... >> what I can tell it appears that when you initiate an ssh attempt the ... Normally since you would not get the SYN ACK ... >> packet the connection would not be completed. ... >> SYN packet I think you would have a good chance of completing the ...
      (Fedora)
    • Re: Cross Realm MIT <-> Windows Close But No Cigar
      ... Info about the two domains and ssh / smbclient test results follows. ... I created some principals and it confirmed the enctype was archfour-hmac: ... debug2: we sent a gssapi-with-mic packet, ...
      (comp.protocols.kerberos)
    • Cross Realm MIT <-> Windows Close But No Cigar
      ... Info about the two domains and ssh / smbclient test results follows. ... I created some principals and it confirmed the enctype was archfour-hmac: ... debug2: we sent a gssapi-with-mic packet, ...
      (comp.protocols.kerberos)
    • Re: PuTTY internals
      ... > command line sessions and found that PuTTY appears to be sending each ... PuTTY can certainly be expected to send two SSH messages per ... the next character before sending a packet. ...
      (comp.security.ssh)