block_ssh_guessers - Security

This is a discussion on block_ssh_guessers - Security ; 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 49

Thread: block_ssh_guessers

  1. 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.


    Open port can be attacked.

    >
    >>>>> 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.


    HOW? There is NO OPEN PORT TO ATTACK! And if you use an implementation of
    port knocking that reads the syslogd output of netfilter, you would need to
    craft an attack against IP tables to change the output of IP tables so it
    would write a specific line that would enable you to do something specific
    against the knocking daemon.

    SO PLEASE EXPLAIN HOW YOUR ATTACK WOULD WORK.

    >
    >>>>> because of
    >>>>> cryptographic host authentication.
    >>>>
    >>>> Oh, it only guards against "authentication" attacks, not "virtually any
    >>>> attack" as you claim.
    >>>
    >>> Try to connect to my NIS or NFS server. Go on. I've bound portmapper and
    >>> the rest of RPC garbage to ipsec0 and I use X.509 certificates
    >>> for mandatory authentication (i.e. no opportunistic encryption).

    >>
    >> Sure its secure from buffer overflow attacks? Are you sure you want to
    >> leave port 500 open for EVERYONE IN THE WORLD TO TRY BUFFER OVERFLOW
    >> ATTACKS?

    >
    > Are you sure your port knocking daemon doesn't have buffer overflows in
    > pattern matching code? That's the same situation.


    Learn a bit more about port knocking. There are implementations in which the
    ONLY input is reading A FILE that contains the output from netfilter.

    So, tell me, how are you going to launch a buffer overflow attack using
    packets directed against closed port that will cause netfilter to over-ride
    its hard coded output formats to send messages to syslogd that get written
    to a file in such a specific way that it will cause a buffer overflow that
    you can exploit?

    Please, do give some details!

    BTW, you may want to understand what port-knocking is before you try to
    debate the subject.

    >



  2. Re: block_ssh_guessers

    On 25.04.2006, matt_left_coast wrote:
    > 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.

    >
    > Open port can be attacked.
    >
    >>
    >>>>>> 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.

    >
    > 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.

    > And if you use an implementation of
    > port knocking that reads the syslogd output of netfilter, you would need to
    > craft an attack against IP tables to change the output of IP tables so it
    > would write a specific line that would enable you to do something specific
    > against the knocking daemon.
    >
    > SO PLEASE EXPLAIN HOW YOUR ATTACK WOULD WORK.
    >

    [...]
    > BTW, you may want to understand what port-knocking is before you try to
    > debate the subject.


    Could I use your tone?
    You may want to understand what is a target of an attack before debate.

    --
    Feel free to correct my English
    Stanislaw Klekot

  3. 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:
    >>>> 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.

    >>
    >> Open port can be attacked.
    >>
    >>>
    >>>>>>> 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.

    >>
    >> 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?

    >> And if you use an implementation of
    >> port knocking that reads the syslogd output of netfilter, you would need
    >> to craft an attack against IP tables to change the output of IP tables so
    >> it would write a specific line that would enable you to do something
    >> specific against the knocking daemon.
    >>
    >> SO PLEASE EXPLAIN HOW YOUR ATTACK WOULD WORK.
    >>

    > [...]


    I see you have no method of attack that would work.

    >> BTW, you may want to understand what port-knocking is before you try to
    >> debate the subject.

    >
    > Could I use your tone?


    Sure.

    > You may want to understand what is a target of an attack before debate.
    >


    I do, it is clear the target this is intended to did not understand how port
    knocking works. Clearly you are unable to respond to my points.




  4. Re: block_ssh_guessers

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

    > matt_left_coast wrote:
    >> Stachu 'Dozzie' K. wrote:
    >>> matt_left_coast wrote:
    >>>> Stachu 'Dozzie' K. wrote:


    >>>>> I don't see how port knocking could help while IPsec couldn't.


    >>>> You can open port 22 for ssh and port 500 for IPsec so that EVERYONE IN


    or any other port in place of the obvious ones - "Well Known Ports" are
    there so that people can find a service without prior knowledge. If you
    DON'T want everyone to find it you don't HAVE to use the "common" port.

    >>>> 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.

    >>
    >> HOW? There is NO OPEN PORT TO ATTACK!


    Not only that, there isn't even a connection. If you want, you can even
    set the firewall to DROP rather than REJECT the attempt.

    >Do you really need to have an open port?


    No.

    >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? Simple version. Use nmap
    to scan this server. You find nothing is open (depending on the default
    rule, either all ports are closed, or all are non-responsive). Hmmm, I
    need some random numbers here...

    [compton ~]$ head -1 /dev/urandom | mimencode | tr -d '\!-\/\:-z' | column
    4117760258883121 99075073 2461
    [compton ~]$

    Now, use a client like telnet to try to connect to a secret port - let' say
    41777. The port is closed, so you get no response to the attempt. But the
    firewall on the server noted that host 192.0.2.15 tried to connect to port
    41777, and opens a hole for one minute for 192.0.2.15 to connect to 9907.
    Now depending on how paranoid I am, I could be running an SSH server on
    port 9907, or there could be another unsuccessful connection attempt required
    before a hole is opened on port 2461 where the SSH server might be hiding.
    The point is that the SSH server isn't even available until you've knocked,
    and the server is ONLY available to the IP address that did the knocking, AND
    is only there for one minute. You _still_ have to satisfy what ever
    authentication scheme that the SSH server is running before you actually
    get to do anything. As mentioned upthread, once you are connected, the
    firewall rule goes away in one minute no matter what. If you _have_ managed
    to satisfy the SSH authentication scheme, then the firewall 'ESTABLISHED'
    rule allows the "conversation" to continue.

    Assuming you have been logging all of the portscans _your_ server is being
    hit with (I don't), go review _your_ logs, and see how many remote systems
    tried to connect to ports 41777 followed by 9907. I don't think you'll see
    that many.

    >> And if you use an implementation of port knocking that reads the syslogd
    >> output of netfilter, you would need to craft an attack against IP tables
    >> to change the output of IP tables so it would write a specific line that
    >> would enable you to do something specific against the knocking daemon.


    An advantage of the log reading version is that you can configure your
    port-knocking "deamon" such that if the remote site tries to connect to
    any OTHER port besides 9907 in the above example, the hole to port 9907
    gets closed immediately. Just don't make things to complicated, or you
    will shoot yourself in the foot.

    Old guy

  5. Re: block_ssh_guessers

    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?

    >>> And if you use an implementation of
    >>> port knocking that reads the syslogd output of netfilter, you would need
    >>> to craft an attack against IP tables to change the output of IP tables so
    >>> it would write a specific line that would enable you to do something
    >>> specific against the knocking daemon.
    >>>
    >>> SO PLEASE EXPLAIN HOW YOUR ATTACK WOULD WORK.
    >>>

    >> [...]

    >
    > I see you have no method of attack that would work.


    You mean real exploit? No, I don't have. But do you have real exploit
    against, for example, Pluto from Openswan 2.4.5? No? Thank you.

    >>> BTW, you may want to understand what port-knocking is before you try to
    >>> debate the subject.

    >>
    >> Could I use your tone?

    >
    > Sure.
    >
    >> You may want to understand what is a target of an attack before debate.
    >>

    >
    > I do, it is clear the target this is intended to did not understand how port
    > knocking works. Clearly you are unable to respond to my points.


    The only thing clear is that you don't understand my points.

    --
    Feel free to correct my English
    Stanislaw Klekot

  6. Re: block_ssh_guessers

    On 25.04.2006, Moe Trin wrote:
    > On Tue, 25 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    >, 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? 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!

    --
    Feel free to correct my English
    Stanislaw Klekot

  7. Re: block_ssh_guessers

    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.

    Old guy

  8. Re: block_ssh_guessers

    I suppose it would be theoretically possible to attempt to overwhelm the
    port knocking daemon by sheer volume - say, an aggressive port scan that
    just didn't quit. It is remotely conceivable that *some* unpleasant
    behavior might result if you simply banged on every door incessantly.

    However, it seems highly unlikely that this would result in any sort of
    information disclosure or "exploit." Far more likely to result in a DOS
    due to, for example, the logs using up all available disk space. But a
    DOS while annoying, wouldn't disclose anything interesting - not to
    mention, if the victim of such an attack is even remotely competent, the
    attempt should have been noticed and responded to in SOME measure long
    before disk space became an issue.

    Long story short - unless you can demonstrate at least a REMOTELY
    plausible exploit scenario against a port knocking daemon - you really
    should consider just conceding gracefully.

    - Of course, I could just be full of it, it's happened before...

  9. Re: block_ssh_guessers

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

    [Your post is referring to my article, but the substance doesn't seem
    to relate to the contents. Not quoting what you are writing about makes
    it hard to follow.]

    >I suppose it would be theoretically possible to attempt to overwhelm the
    >port knocking daemon by sheer volume - say, an aggressive port scan that
    >just didn't quit. It is remotely conceivable that *some* unpleasant
    >behavior might result if you simply banged on every door incessantly.


    It's more likely to be a problem with the firewall or network stack. It
    obviously depends on how you implement the port-knocking daemon, but it's
    only interested in the fact that the "knock" occurred - normally not what
    might be in the packet (which after all is only going to be a SYN in most
    cases), or how many times the knock occurred. Depending on the paranoia
    level, the daemon may want to block access if the knocking host tries
    ports OTHER THAN the expected ones in the sequence As I stated, you don't
    want to make things to complex, as that is a good way to shoot yourself in
    the foot.

    >However, it seems highly unlikely that this would result in any sort of
    >information disclosure or "exploit." Far more likely to result in a DOS
    >due to, for example, the logs using up all available disk space.


    You're assuming the logs are written to disk. They don't have to be. In
    fact, logging "I blocked this - ain't I a good firewall" to disk is
    _usually_ a waste of time, CPU cycles, disk-space and bandwidth.

    >But a DOS while annoying, wouldn't disclose anything interesting


    Bingo

    >not to mention, if the victim of such an attack is even remotely competent,
    >the attempt should have been noticed and responded to in SOME measure long
    >before disk space became an issue.


    A lot depends on the mechanism of the attack. Example: windoze messenger
    spam - UDP packets to ports 1025-1035 typically, sized between 250 and 1400
    octets, flogging some wankers product (usually a "fix your windoze registry"
    application). Several years ago, we noted this as a huge waste of bandwidth
    and because the entire spam is in a single UDP packet, the spammers were
    usually using spoofed IP addresses. Sending an ICMP error, or RST is a
    waste of bandwidth - the "advertisement" has been delivered, and the ICMP
    or RST packet is likely to go to some innocent victim. Our solution was
    to use port-shifting to move _outbound_ UDP (almost always DNS queries)
    out of the source range of (say) 1025 to 1050, to some higher numbers.
    Thus, there should never be any legitimate packets _inbound_ to those
    ports - allowing our upstream to silently drop all inbound in that range.
    Last time I bothered looking at this, I was seeing _roughly_ a thousand
    messages per day per IP address - about a half Megabyte. Scale that to a
    /16, and it becomes a chunk of change for bandwidth you can spend paying
    for the boxes that do the filtering and port shifting.

    Old guy

  10. Re: block_ssh_guessers

    On Wed, 26 Apr 2006 14:41:42 -0500, Moe Trin wrote:

    > On Wed, 26 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in
    > article , sudo namei
    > wrote:
    >
    > [Your post is referring to my article, but the substance doesn't seem to
    > relate to the contents. Not quoting what you are writing about makes it
    > hard to follow.]


    My bad. But I find it most tedious scrolling through those messages
    with 72 levels of quotation indents just to finally get to the bottom of
    6 or 7 pages of the same thing for the 73rd time - just to see a
    one-liner that says, "Yeah! Neener neener!"

    > It's more likely to be a problem with the firewall or network stack. It
    > obviously depends on how you implement the port-knocking daemon, but
    > it's only interested in the fact that the "knock" occurred -


    Yes, but also from where, and for a certain period of time. If you have
    it listen for the first special knock, followed buy a second, and then a
    third (for example) - then it follows that SOME kind of logging or
    tracking mechanism must be employed, else it would forget the very
    instant I knocked the first time, to listen for my second, etc.

    > You're assuming the logs are written to disk. They don't have to be. In
    > fact, logging "I blocked this - ain't I a good firewall" to disk is
    > _usually_ a waste of time, CPU cycles, disk-space and bandwidth.


    I could argue that last point, just to be an ass, but since I'm already
    one I'll stick to the first: SOME retention is necessary, and thus some
    commitment of resource (be it memory or disk) - otherwise what you have
    is not a "knock," but just an open port. If the daemon must remember
    that I tried at a certain port from some certain IP address, and
    continue to remember that for the next 60 seconds while waiting for the
    next, etc. - then SOME kind of logging or buffering has to be happening.
    And if it can remember ONE attempt, what of a few million?

    >>But a DOS while annoying, wouldn't disclose anything interesting

    >
    > Bingo


    Yeah, see, here's the thing: I was agreeing with you to begin with.
    The concession advice was for Stachu, who has yet to propose a plausible
    exploit or attack that would do anything more interesting to a port
    knocking solution than slow it down and annoy the server owner.

    Now, as to your "see what a good firewall I am" logging point - I'll
    save that argument for the next time I'm feeling ornery...

  11. Re: block_ssh_guessers

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

    >On Wed, 26 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    >, sudo namei wrote:
    >
    >>I suppose it would be theoretically possible to attempt to overwhelm the
    >>port knocking daemon by sheer volume - say, an aggressive port scan that
    >>just didn't quit. It is remotely conceivable that *some* unpleasant
    >>behavior might result if you simply banged on every door incessantly.

    >
    >It's more likely to be a problem with the firewall or network stack.


    At some point the incoming data will saturate the link (or net stack),
    and the user can do nothing more than drop traffic, not all of us can
    control upstream

    > It
    >obviously depends on how you implement the port-knocking daemon, but it's
    >only interested in the fact that the "knock" occurred - normally not what
    >might be in the packet (which after all is only going to be a SYN in most
    >cases), or how many times the knock occurred.


    I'm experimenting at the moment to see if random hits a fewer if given
    a reject vs DROP. Repeat unwanted hits from same source IP are DROPped.

    I count this activity out of curiosity: http://bugsplatter.mine.nu/junkshow/

    > Depending on the paranoia
    >level, the daemon may want to block access if the knocking host tries
    >ports OTHER THAN the expected ones in the sequence


    I find this a good approach for unwanted traffic.

    > As I stated, you don't
    >want to make things to complex, as that is a good way to shoot yourself in
    >the foot.


    I'm building slowly towards a daemon monitoring firewall activity,
    then I can do stuff in 'realtime'. At the moment I'm data collecting.


    >
    >>However, it seems highly unlikely that this would result in any sort of
    >>information disclosure or "exploit." Far more likely to result in a DOS
    >>due to, for example, the logs using up all available disk space.

    >
    >You're assuming the logs are written to disk. They don't have to be. In
    >fact, logging "I blocked this - ain't I a good firewall" to disk is
    >_usually_ a waste of time, CPU cycles, disk-space and bandwidth.


    /dev/hda5 256996 110780 146216 44% /var

    I have gzipped /var/messages going back to last September in there
    280k+ firewall drop records to play with...


    >>not to mention, if the victim of such an attack is even remotely competent,
    >>the attempt should have been noticed and responded to in SOME measure long
    >>before disk space became an issue.

    >
    >A lot depends on the mechanism of the attack. Example: windoze messenger
    >spam - UDP packets to ports 1025-1035 typically, sized between 250 and 1400
    >octets, flogging some wankers product (usually a "fix your windoze registry"
    >application).


    Crikey, I'm curious but not that curious Most of this type of junk
    comes from my local /16 ISP's block, along with the other windoze low
    ports.

    > Several years ago, we noted this as a huge waste of bandwidth
    >and because the entire spam is in a single UDP packet, the spammers were
    >usually using spoofed IP addresses. Sending an ICMP error, or RST is a
    >waste of bandwidth - the "advertisement" has been delivered, and the ICMP
    >or RST packet is likely to go to some innocent victim.


    Okay, a vote for DROP junk rather than reject.

    > Our solution was
    >to use port-shifting to move _outbound_ UDP (almost always DNS queries)
    >out of the source range of (say) 1025 to 1050, to some higher numbers.
    >Thus, there should never be any legitimate packets _inbound_ to those
    >ports - allowing our upstream to silently drop all inbound in that range.


    Is this something one (as in home user) may request an ISP do?

    >Last time I bothered looking at this, I was seeing _roughly_ a thousand
    >messages per day per IP address - about a half Megabyte. Scale that to a
    >/16, and it becomes a chunk of change for bandwidth you can spend paying
    >for the boxes that do the filtering and port shifting.


    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.

    Grant.
    --
    Memory fault -- brain fried

  12. Re: block_ssh_guessers

    sudo namei wrote:

    [Snip Moe Trin politely critiquing "sudo namei's" omission of context.]

    > ...I find it most tedious scrolling through those messages with 72
    > levels of quotation indents just to finally get to the bottom of 6 or
    > 7 pages of the same thing for the 73rd time - just to see a one-liner
    > that says, "Yeah! Neener neener!"


    Above you will see demonstrated two useful concepts called "trimming
    irrelevant text" and "summarising".

    Learn them. Live them. Love them. Usenet will figuratively thank you,
    and eschew further application of the Cluebat of Enlightenment.

    --
    Cheers, "Transported to a surreal landscape, a young girl kills the first
    Rick Moen woman she meets, and then teams up with three complete strangers
    rick@linuxmafia.com to kill again." -- Rick Polito's That TV Guy column,
    describing the movie _The Wizard of Oz_

  13. Re: block_ssh_guessers

    Rick Moen writes:

    >sudo namei wrote:


    >[Snip Moe Trin politely critiquing "sudo namei's" omission of context.]


    >> ...I find it most tedious scrolling through those messages with 72
    >> levels of quotation indents just to finally get to the bottom of 6 or
    >> 7 pages of the same thing for the 73rd time - just to see a one-liner
    >> that says, "Yeah! Neener neener!"


    >Above you will see demonstrated two useful concepts called "trimming
    >irrelevant text" and "summarising".


    The above is also a demonstartion of the usefulness of top posting. If the
    reply is a generic reply to the whole of the post, top posting is by far
    the best idea. The reader can read it, and decide whether or not reading
    the context is worthwhile or not. The example given is one where one can
    immediately decide it is not worth reading the context (or even the post)
    immediately without paging through anything. On the otherhand if specific
    answers to specific issues are being given then insert posting is best-- ie
    place the answer as near the stuff being commented on.

    Note that the net fascists should be just as upset by this as by top
    posting since one never reads books in that kind of jumbled up time order.

    They are not which shows that their usual complaint has no foundation.

    ON the trimming of posts, I am in conflict. It is always tempting to trim
    the post to just contain the stuff of immediate relevance to the answer.

    But that way you get posts that look like
    ....
    >>Is it?

    >Yes.


    One should keep at least enough context that the response is self
    contained. And usually not trimming is better than trimming, since you
    never know what part of the context is needed by the reader and which is
    superfluous, primarily because you have no idea what the level of
    knowledge, interest or memory of the reader is.


    Oh, and then there is the issue of hijacking a thread to run off on a
    tangent unrelated to the original posting. .......

    >Learn them. Live them. Love them. Usenet will figuratively thank you,
    >and eschew further application of the Cluebat of Enlightenment.


    Fortunately it hurts the applier more than the recipient.

  14. Re: block_ssh_guessers

    Unruh wrote (basically wasting our time):

    > The above is also a demonstartion of the usefulness of top posting. If the
    > reply is a generic reply to the whole of the post, top posting is by far
    > the best idea. The reader can read it, and decide whether or not reading
    > the context is worthwhile or not. The example given is one where one can
    > immediately decide it is not worth reading the context (or even the post)
    > immediately without paging through anything.


    Except quoted text was so brief that both it and following comments
    appear on the first screen of any likely output device.

    Clue: Your underlying assumption, that one cannot skip to concluding
    remarks if they follow what they comment on, is erroneous. Obviously.

    > ON the trimming of posts, I am in conflict.


    ObClaudeRains: "I am shocked! Shocked!"

    > But that way you get posts that look like
    > ...
    >>>Is it?

    >>Yes.


    Not if done competently.

    Try that, then. (Or, if you prefer to be widely ignored, not.)

    > Oh, and then there is the issue of hijacking a thread to run off on a
    > tangent unrelated to the original posting. .......


    Awww. Here, have a virtual hanky:

    ---
    | |
    ---


  15. Re: block_ssh_guessers

    On 2006-04-26, Unruh wrote:
    > Rick Moen writes:
    >
    >>sudo namei wrote:

    >
    >>[Snip Moe Trin politely critiquing "sudo namei's" omission of context.]

    >
    >>> ...I find it most tedious scrolling through those messages with 72
    >>> levels of quotation indents just to finally get to the bottom of 6 or
    >>> 7 pages of the same thing for the 73rd time - just to see a one-liner
    >>> that says, "Yeah! Neener neener!"

    >
    >>Above you will see demonstrated two useful concepts called "trimming
    >>irrelevant text" and "summarising".

    >
    > The above is also a demonstartion of the usefulness of top posting. If the
    > reply is a generic reply to the whole of the post, top posting is by far
    > the best idea.


    No, it's not. Summarizing and trimming irrelevant text is a much better
    idea. If trimming involves trimming *all* the text, that's fine, as
    long as it has been summarized accurately. The only way to determine
    that an author has top-posted, however, is to at least skim the entire
    post; if it turns out that the author top-posted over 800 lines, none of
    which were directly relevant to the author's post, that's a waste of 800
    lines.

    > But that way you get posts that look like
    > ...
    >>>Is it?

    >>Yes.

    >
    > One should keep at least enough context that the response is self
    > contained. And usually not trimming is better than trimming, since you
    > never know what part of the context is needed by the reader and which is
    > superfluous, primarily because you have no idea what the level of
    > knowledge, interest or memory of the reader is.


    I agree here, but all that means is that the hypothetical author who
    trimmed everything but "Is it?" trimmed more than just the irrelevant
    context. Obviously there's a gray area for what's relevant and what is
    not, but there's a lot of black-and-white area, too.

    > Oh, and then there is the issue of hijacking a thread to run off on a
    > tangent unrelated to the original posting. .......


    On usenet? Nah, that *never* happens.

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
    see X- headers for PGP signature information


  16. Re: block_ssh_guessers

    Rick Moen writes:


    >Awww. Here, have a virtual hanky:


    > ---
    >| |
    > ---



    Thanks. Needed that.


  17. Re: block_ssh_guessers

    Keith Keller writes:

    >On 2006-04-26, Unruh wrote:


    >> But that way you get posts that look like
    >> ...
    >>>>Is it?
    >>>Yes.

    >>
    >> One should keep at least enough context that the response is self
    >> contained. And usually not trimming is better than trimming, since you
    >> never know what part of the context is needed by the reader and which is
    >> superfluous, primarily because you have no idea what the level of
    >> knowledge, interest or memory of the reader is.


    The problem is that what the trimmer thinks is relevant may not be what the
    reader thinks is relevant. I have seen far too many posts where the trimmer
    trimmed down to exactly what he wanted to answer ( which might be some
    minor point in the original post) and what I wanted to know is what
    theoriginal question was, but it was trimmed. Sure I could go hunt down the
    original post, but that is precisely the problem, you do not want to put
    the reader to extra work. Youmight say that the trimmer trimmed too much,
    but again that is precisely my point. He obviously did not think so-- so
    the right amount of trimming is again in the eye of the reader.

    In short it is better to err in trimming too little.



    >I agree here, but all that means is that the hypothetical author who
    >trimmed everything but "Is it?" trimmed more than just the irrelevant
    >context. Obviously there's a gray area for what's relevant and what is
    >not, but there's a lot of black-and-white area, too.


    Yes, and I would far rather see too much of the original than too little.


    >> Oh, and then there is the issue of hijacking a thread to run off on a
    >> tangent unrelated to the original posting. .......


    >On usenet? Nah, that *never* happens.



    I know. It was purely a hypothetical.


  18. Re: block_ssh_guessers

    On Wed, 26 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , sudo namei wrote:
    >On Wed, 26 Apr 2006 14:41:42 -0500, Moe Trin wrote:


    >> Not quoting what you are writing about makes it hard to follow.]

    >
    >My bad. But I find it most tedious scrolling through those messages
    >with 72 levels of quotation indents just to finally get to the bottom of
    >6 or 7 pages of the same thing for the 73rd time - just to see a
    >one-liner that says, "Yeah! Neener neener!"


    The others have already responded, so I don't need to. I'm not
    familiar with pan, but some news readers have a key combination (I'm
    using slrn - it's the tab key) that jumps beyond the quoted text.

    >Yes, but also from where, and for a certain period of time. If you have
    >it listen for the first special knock, followed buy a second, and then a
    >third (for example) - then it follows that SOME kind of logging or
    >tracking mechanism must be employed, else it would forget the very
    >instant I knocked the first time, to listen for my second, etc.


    I haven't seen the need to go beyond a single knock - as I've only seen
    4 people even hit the knock port, and none of them then tried to connect
    to the the server. This compares to the thousands of hits a day on the
    default windoze ports. But obviously, YMMV.

    >> You're assuming the logs are written to disk. They don't have to be. In
    >> fact, logging "I blocked this - ain't I a good firewall" to disk is
    >> _usually_ a waste of time, CPU cycles, disk-space and bandwidth.

    >
    >I could argue that last point, just to be an ass, but since I'm already
    >one I'll stick to the first: SOME retention is necessary, and thus some
    >commitment of resource (be it memory or disk) - otherwise what you have
    >is not a "knock," but just an open port. If the daemon must remember
    >that I tried at a certain port from some certain IP address, and
    >continue to remember that for the next 60 seconds while waiting for the
    >next, etc. - then SOME kind of logging or buffering has to be happening.


    Depends on how you implement this. I've seen the "log reader" mode where
    the firewall sends the 'knock' data to a different '--log-level' than the
    "normal" logging efforts, and syslogd sends that data to pipe.

    >And if it can remember ONE attempt, what of a few million?


    Haven't seen the need. Next to nobody is hitting the ports now. Also,
    there are not that many who are allowed access to the network, so there
    aren't going to be that many legitimate attempts.

    >Now, as to your "see what a good firewall I am" logging point - I'll
    >save that argument for the next time I'm feeling ornery...


    Spend some time over in 'comp.security.firewalls' and you'll soon see
    the fact that every windoze personal firewall seems to default to popping
    up a huge blinking red warning screaming "WE'VE BEEN ATTACKED!!!" every
    time any packet doesn't exactly fit expectations. This includes that
    warning when a DNS server takes more than two or three seconds to respond.
    The "personal firewall" forgets that it had sent a DNS query several
    seconds ago, and become indignant when the server eventually responds. I
    keep wanting to respond and tell them to complain to their ISP. With any
    luck, the ISP will can their account - ending the noise problem for the
    rest of us.

    Old guy

  19. Re: block_ssh_guessers

    On Thu, 27 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , Grant wrote:
    > ibuprofin@painkiller.example.tld (Moe Trin) wrote:


    >At some point the incoming data will saturate the link (or net stack),
    >and the user can do nothing more than drop traffic, not all of us can
    >control upstream


    True but then, how fat is the pipe, compared to firewall device. The
    Ethernet may be 10 or 100 Megabit, but I've never heard of a _residential_
    setup ever getting anywhere near 25 Megabit peak. Got a T3 or OC-1? Still
    should be within the horsepower of a modern Pentium.

    >I'm experimenting at the moment to see if random hits a fewer if given
    >a reject vs DROP. Repeat unwanted hits from same source IP are DROPped.


    I honestly don't recall the stats - I did look at this several times. I
    think that for most attempts that are using the windoze stack, it wound up
    a wash, and what I assumed to be worms have also been mixed - some honor a
    FOAD packet - some retry no matter what.

    >> Depending on the paranoia level, the daemon may want to block access if
    >> the knocking host tries ports OTHER THAN the expected ones in the sequence

    >
    >I find this a good approach for unwanted traffic.


    It's common sense.

    >>You're assuming the logs are written to disk. They don't have to be. In
    >>fact, logging "I blocked this - ain't I a good firewall" to disk is
    >>_usually_ a waste of time, CPU cycles, disk-space and bandwidth.

    >
    >/dev/hda5 256996 110780 146216 44% /var
    >
    >I have gzipped /var/messages going back to last September in there
    >280k+ firewall drop records to play with...


    The logs from the firewall are running about 30k a week uncompressed. I
    only log successful connects and the like.

    >Crikey, I'm curious but not that curious Most of this type of junk
    >comes from my local /16 ISP's block, along with the other windoze low
    >ports.


    When it strikes my fancy, I'll run tcpdump watching for 'UDP and not port
    53' to a file - for later playback. I do this out of minor curiosity to see
    what site is being flogged, and casual interest of the TTLs and claimed
    source address.

    >Okay, a vote for DROP junk rather than reject.


    For messenger spam? Absolutely. The malware author isn't very careful with
    checking the IPs being spoofed. I see about 3 percent coming from IPs that
    IANA hasn't released to the RIRs, never mind actually being assigned to
    real networks. Seeing the same message come from all over hell and gone, but
    with the same TTL, and a progressive (or same) source port number is a big
    clue as well.

    >> [port shifting UDP] allowing our upstream to silently drop all inbound
    >> in that range.


    >Is this something one (as in home user) may request an ISP do?


    You might be able to ask - but I doubt it. We actually own the box that's
    doing the port-shifting/filtering at the upstream (I think it's an old
    P-II, but that's not my turf), and I think there is a space rental as
    well as paying for power, etc. We pay a bandwidth fee, so eliminating the
    crap before it hits the pipe inbound is saving us enough to pay for the
    filter.

    >I'm happy to not see that level of traffic, ignoring 800..1000 items per
    >day.


    It's a fairly large chunk of a T1. That's what got our attention in the
    first place.

    >I don't have ssh open to public access, when I did have the port open,
    >it was to known IPs only.


    That was normal here as well. I had to go to the port-knocking for
    a two week trip, and never bothered to set it back.

    >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.


    Not seeing a dictionary attack, because they can't connect to the server
    in the first place. Problem non-existent.

    Old guy

  20. Re: block_ssh_guessers

    On Thu, 27 Apr 2006 14:53:31 -0500, Moe Trin wrote:

    > On Wed, 26 Apr 2006, in the Usenet newsgroup comp.os.linux.security, in
    > article , sudo namei
    > wrote:
    >>On Wed, 26 Apr 2006 14:41:42 -0500, Moe Trin wrote:


    > Depends on how you implement this. I've seen the "log reader" mode where
    > the firewall sends the 'knock' data to a different '--log-level' than
    > the "normal" logging efforts, and syslogd sends that data to pipe.


    Fair enough, but...

    >>And if it can remember ONE attempt, what of a few million?

    >
    > Haven't seen the need. Next to nobody is hitting the ports now. Also,
    > there are not that many who are allowed access to the network, so there
    > aren't going to be that many legitimate attempts.


    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. 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? If it hangs around,
    then your DOS is to fill up the pipe until whatever resource is
    consumed, and if it gets flushed upon handling then your DOS is to
    overwhelm it with events so the queue grows faster than the handling.
    Either way, it's still just a DOS - and a bit of a stretch at that.

    >>Now, as to your "see what a good firewall I am" logging point - I'll
    >>save that argument for the next time I'm feeling ornery...

    >
    > Spend some time over in 'comp.security.firewalls' and you'll soon see
    > the fact that every windoze personal firewall seems to default to
    > popping up a huge blinking red warning screaming "WE'VE BEEN
    > ATTACKED!!!" every time any packet doesn't exactly fit expectations.
    > This includes that warning when a DNS server takes more than two or
    > three seconds to respond. The "personal firewall" forgets that it had
    > sent a DNS query several seconds ago, and become indignant when the
    > server eventually responds. I keep wanting to respond and tell them to
    > complain to their ISP. With any luck, the ISP will can their account -
    > ending the noise problem for the rest of us.


    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.

    As for my logs, I prefer to log practically everything, and then keep it
    pretty much forever. Text files compress nicely, and DVD's are cheap.
    And I have had occasion to go back to log files that were several years
    old - and the results proved quite valuable. Suppose for example that
    you discovered that a large portion of your Windows Popup message
    attempts were coming from an E-mail marketing company. That could be
    very handy fodder for the lawyers to chew on...

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