block_ssh_guessers - Security

This is a discussion on block_ssh_guessers - Security ; On Thu, 27 Apr 2006 21:51:29 GMT, sudo namei wrote: > I haven't > really played with logging data to pipes... Does the data "go away" > after some sort of handling, or does it continue to consume resources > ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 49 of 49

Thread: block_ssh_guessers

  1. Re: block_ssh_guessers

    On Thu, 27 Apr 2006 21:51:29 GMT, sudo namei wrote:

    > I haven't
    > really played with logging data to pipes... Does the data "go away"
    > after some sort of handling, or does it continue to consume resources
    > (disk or memory) as additional events are added?


    Depends on how you manage it, I run a daemon with FIFO interface:

    ~$ ls -l /var/run/ip2c*
    -rw-r--r-- 1 root root 4 2006-04-27 17:56 /var/run/ip2c.pid
    prw-rw---- 1 root wheel 0 2006-04-28 08:03 /var/run/ip2c_query|
    prw-rw---- 1 root wheel 0 2006-04-28 08:03 /var/run/ip2c_reply|



    Grant.
    --
    Memory fault -- brain fried

  2. Re: block_ssh_guessers

    On Thu, 27 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , sudo namei wrote:

    >Well, remember we aren't talking about a "need" in any
    >performance-related sense of the word, but rather in the context of this
    >hypothetical exploit that someone else was [erroneously, I think]
    >claiming a port-knocking daemon could be vulnerable to.


    OK - I was talking of "practical" implementations that I've seen in use.
    Again, you need to define the threat model that is to be defended against.
    If someone kicks of a Distributed Denial Of Service attack (DDOS) such
    that your pipe to the world is full, that's one thing. It doesn't matter
    if they are trying to knock over the fence around your SSH daemon, or are
    the result of a vicious rumor that you have these wonderful pictures on
    your web/ftp server of a St. Bernard wearing fish-net stockings being
    assaulted by a dachshund wearing only an eye patch and white shirt. Most
    "attacks" targeting SSH (and before that, telnet and the Berkeley 'r'
    commands) that I've seen have been relatively unsophisticated stuff run
    by skript kiddiez. Port scans, etc. tend to be slow - slower still when
    the target hunkers down into "ignore" mode.

    >I haven't really played with logging data to pipes... Does the data "go
    >away" after some sort of handling, or does it continue to consume resources
    >(disk or memory) as additional events are added?


    Depends on what you are doing with it. If you are just running the data
    past a filter such as 'grep', then only the "selected" data remains and
    that only if you aren't using -q. Even then, the remaining data only goes
    to stdout of the command, and if nothing is watching that, it's gone.

    >OK, see, I assumed when I started reading this thread that we were all
    >going to be playing with big kids' toys... *grin* I haven't really put
    >my hands on any Windows-based firewall product that I would ever trust
    >in an Internet-facing scenario. Which is not to say that they might not
    >exist, I just haven't had the [dubious?] pleasure.


    I'm not sure how much details you're going to see. Some of us are under
    those nasty things called Non-Disclosure-Agreements - which is why I'm
    posting from a residential account rather than work. As far as windoze
    boxes go, I tend to agree with you - and most seem to be quite limited
    in capability.

    >Suppose for example that you discovered that a large portion of your
    >Windows Popup message attempts were coming from an E-mail marketing
    >company.


    Coming from? That would be difficult to prove. My opinion is that most, if
    not all, source addresses are spoofed, and my _guess_ is that these are,
    in reality, zombies on wide bandwidth hookups - such as windoze boxes on
    cable networks. Back in November 2005, Matthias Leisi released a paper
    titled "A day in the life of a spammer" (don't know if it's still at
    http://matthias.leisi.net/archives/1...a-spammer.html)
    indicating that was a main mechanism for _mail_ delivery of spam. (A
    google search for "a-day-in-the-life-of-a-spammer" does turn up the page.)

    Normally, the more productive technique is to "follow the money". This
    means following the registrations of the sites being advertised. Another
    hit on the same google search notes that many spammers use false names
    and addresses, and a lot of the domains are 'throw-away'. When I looked
    at this last June, _every_ domain advertised was registered no more than
    fifteen days before being used in spam, and most of them no longer resolved
    in October.

    >That could be very handy fodder for the lawyers to chew on...


    Maybe, maybe not.

    Old guy

  3. Re: block_ssh_guessers

    Lawrence D'Oliveiro wrote:
    > In article ,
    > Bill Davidsen wrote:
    >
    >> Lawrence D'Oliveiro wrote:
    >>> In article ,
    >>> ibuprofin@painkiller.example.tld (Moe Trin) wrote:
    >>>
    >>>> If you absolutely MUST allow connections from the world, and you can't
    >>>> be bothered to set up certificates, google for port knocking.
    >>> port-knocking--don't be bloody stupid.

    >> Care to share why you think port-knocking is stupid?

    >
    > Ever heard of the term "replay attack"?


    Unless my ISP is actively cooperating with the attacker, those packets
    are not readily available, and need to be captured at the client end.
    And assuming any or all of that is possible, it buys a single connect to
    my ssh daemon which can still be configured to do whatever
    authentication is appropriate.

    And that assumes the very simplest knocking, of the "connect here then
    there" variety. You can go to time dependent ports, sequences of ports,
    etc. The paranoid can go to ping packets with forged source IP,
    encrypted payload giving the real IP, and ping reply to the real IP with
    encrypted source and destination ports to use. I set that up as a proof
    of concet, but I haven't actually used it yet.

    The value of even the simple port knocking is that you reduce the
    overhead of stupid attacks, and increase the chances of finding an
    attack by requiring probes to locate the knock port(s), unless you
    assume the complicit ISP and a simple knock implementation vulnerable to
    replay.

    YOU may have enemies who can subvert your ISP, I just have run of the
    mill enemies to consider.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

  4. Re: block_ssh_guessers

    Moe Trin wrote:
    > On Tue, 25 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    > , Stachu 'Dozzie' K. wrote:
    >> Moe Trin wrote:
    >>> Stachu 'Dozzie' K. wrote:

    >
    >>>> For me, it should be enough to pass data to daemon. It's not a port what
    >>>> is an attack target, it's a daemon.
    >>> Do you really understand what port-knocking is?

    >> I do. But do *you* understand what I am talking about?

    >
    > No - you aren't saying anything.
    >
    >> Consider following scenario: pick up random host. Port scanning gives
    >> nothing? Then assume there is port knocking daemon and try exploits
    >> against it. Note no attack against sshd!

    >
    > Great - what are the exploits that you are going to try? There isn't
    > anything to connect to. You aren't connecting to the "port-knocking"
    > daemon, because it isn't listening to anything from outside. It's only
    > listening to the firewall reporting attempts. That is rate limited on
    > a per address basis, so what _can_ you do? The only thing you can attack
    > is the kernel networking stack and the firewall, and it's kinda hard to
    > do that when you can't even connect to the computer.
    >
    > By the way, my home system is set like that. The logging system records
    > when someone hits the knocking port, and when they (invariably) hit any
    > other port other than where the SSH daemon is hiding. This is the 116th
    > day of the year, and there have been exactly four hits on the knocking
    > port so far _this_year_ and none found the SSH port. Last time I bothered
    > to log attempts at port 22 (which has nothing running), I was seeing
    > an average of 20 attempts a day.
    >

    From my firewall, one day of probes by protocol and port:

    Top TCP prts probed (10 of 7212)
    Count Port
    2348 80
    129 26
    46 4899
    27 389
    25 22
    16 8080
    14 7212
    10 3372
    9 5900
    7 21

    Top UDP prts probed (10 of 3242)
    Count Port
    470 1026
    49 1025
    43 1027
    21 2
    20 1030
    19 1029
    16 4081
    16 1031
    16 1033
    14 1032


    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

  5. Re: block_ssh_guessers

    Stachu 'Dozzie' K. wrote:
    > On 25.04.2006, matt_left_coast wrote:
    >>>>> ...so that EVERYONE IN THE WORLD CAN TRY BUFFER ATTACKS against port
    >>>>> knocking daemon. Great.
    >>>> HOW? There is NO OPEN PORT TO ATTACK!
    >>> Do you really need to have an open port? For me, it should be enough to
    >>> pass data to daemon. It's not a port what is an attack target, it's
    >>> a daemon.
    >>>

    >> HOW? How would the attack work?

    >
    > Is it really that hard to imagine some sequence of packets which uses
    > bug in daemon regardless of sequence expected by daemon?


    If the packets are not in the right sequence they are not examined,
    therefore no content is examined.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

  6. Re: block_ssh_guessers

    Grant wrote:
    > On Wed, 26 Apr 2006 14:41:42 -0500, ibuprofin@painkiller.example.tld (Moe Trin) wrote:


    > I'm happy to not see that level of traffic, ignoring 800..1000 items per
    > day.
    >
    > I don't have ssh open to public access, when I did have the port open,
    > it was to known IPs only. Not seeing dictionary attacks here since a
    > repeat unwanted hit is dropped using iptables --recent --update until
    > attacker src_ip gives up for a few hours.
    >
    > A two-step approach, allowing a few login attempts within a minute or
    > so then lockout src_ip for an hour or so would be a strategy I'd try.
    >
    > Linux iptables can be talked into FSA (state machine) function for this
    > sort of stuff.
    >

    What I haven't been able to do is SNAT a REJECT. If I connect to a port
    and get back a "host unreachable" from that IP, I know I've hit a
    firewall. If I get it from the upstream router I think I can'r reach the
    host. If I don't look at the source IP on the unreachable message, and
    most don't, then faking it doesn't matter.

    But I'd love to send a reject with source IP of an upstream router, I
    just can't quite see how to do it with iptables.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

  7. Re: block_ssh_guessers

    Stachu 'Dozzie' K. wrote:
    > On 25.04.2006, matt_left_coast wrote:
    >> Stachu 'Dozzie' K. wrote:
    >>
    >>> On 25.04.2006, matt_left_coast wrote:
    >>>> Ertugrul Soeylemez wrote:
    >>>>
    >>>>> Still something like IPsec (which I use in my LAN) is a lot better than
    >>>>> port-knocking.
    >>>> How so? The two secure different things. If I secure my port with
    >>>> portknocking I can STILL use IPsec. The fact that you do act as if they
    >>>> are exclusionary methods makes me wonder if you know what you are talking
    >>>> about.
    >>> Have you already configured any IPsec tunnel? Especially with KLIPS
    >>> (Openswan) implementation.

    >> Read the topic of the tread: "Re: block_ssh_guessers" But hey, in order for
    >> IPsec to work, traffic has to be ALLOWED from an IP address.

    >
    > But hey, it doesn't have to be allowed if it's SSH traffic. Just ESP
    > and, maybe, IKE traffic.
    >
    >>>>> It defeats virtually any attack,
    >>>> Other that buffer-overflow attacks that your "leave the port open to the
    >>>> world" clearly allows but port-knocking helps defend against.
    >>> I don't see how port knocking could help while IPsec couldn't.

    >> Never claimed IPsec couldn't help, but the SUBJECT OF THE THREAD IS
    >> "block_ssh_guessers" I was talking about securing ssh. If you are only
    >> connecting from well known addresses, then you can lock down to the known
    >> addresses. The issue for both ssh and IPsec is when you are travailing with
    >> a laptop and need to connect from ANY address anywhere in the world. You
    >> can open port 22 for ssh and port 500 for IPsec so that EVERYONE IN THE
    >> WORLD CAN TRY BUFFER ATTACKS AGAINST THEM, or you can use port-knocking to
    >> open the ports

    >
    > ...so that EVERYONE IN THE WORLD CAN TRY BUFFER ATTACKS against port
    > knocking daemon. Great.
    >

    Except that the port is not a well known port, so I eliminate some large
    number of attackers, script kiddies, etc, who look for less protected
    systems. And of course probing in some way gives me one more layer to
    detect attack and just drop everything from that source.

    --
    -bill davidsen (davidsen@tmr.com)
    "The secret to procrastination is to put things off until the
    last possible moment - but no longer" -me

  8. Re: block_ssh_guessers

    On Fri, 12 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , Bill Davidsen wrote:

    > From my firewall, one day of probes by protocol and port:
    >
    >Top TCP prts probed (10 of 7212)


    Your provider is blocking 135-9/445/1433?

    > Count Port
    > 2348 80
    > 129 26


    What the heck are they looking for there? 26 is not a well known port.
    Otherwise, your TCP list looks fairly common.

    >Top UDP prts probed (10 of 3242)
    > Count Port
    > 470 1026
    > 49 1025
    > 43 1027
    > 21 2


    First three look like messenger spam - although looking at the rest of the
    listing, you are missing 1028, and the numbers are on the low side for a
    24/7 connection. Wonder what the port 2/udp is - again, it's not a common
    well known port.

    Old guy

  9. Re: block_ssh_guessers

    On Fri, 12 May 2006, in the Usenet newsgroup comp.os.linux.security, in article
    <0_49g.131$Vv7.127@newssvr24.news.prodigy.net>, Bill Davidsen wrote:

    >What I haven't been able to do is SNAT a REJECT. If I connect to a port
    >and get back a "host unreachable" from that IP, I know I've hit a
    >firewall.


    run by someone who hasn't the foggiest idea what they are doing. At
    least one of the "popular" "personal firewall" products has an apparent
    radio button option to reply that way. Makes you wonder about the rest
    of the design, and what else has been screwed up.

    >If I get it from the upstream router I think I can'r reach the host. If I
    >don't look at the source IP on the unreachable message, and most don't,
    >then faking it doesn't matter.


    Agreed - but if I have a suspicion, I may try using other protocols/ports
    with other tools.

    >But I'd love to send a reject with source IP of an upstream router, I
    >just can't quite see how to do it with iptables.


    I suspect you'd have to hack some code to do so, and the spoofed packet
    may run afoul of the upstream router that is at least glancing at the
    IP header. Well run ISPs (and they are becoming a vanishing breed) may
    notice something while running RFC2827/3704 filtering.

    Old guy

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3