possible SMTP attack: command=HELO/EHLO, count=3 (fwd)

possible SMTP attack: command=HELO/EHLO, count=3 (fwd)

[terry white]

... ciao:

    i'm starting to see a lot of the following.

    and i'm not thinking it a good thing ...


muedsl-82-207-247-115.citykom.de [82.207.247.115]: possible SMTP attack:
command=HELO/EHLO, count=3
IGLD-83-130-135-36.inter.net.il [83.130.135.36]: possible SMTP attack:
command=HELO/EHLO, count=3
bzq-88-153-185-136.red.bezeqint.net [88.153.185.136]: possible SMTP attack:
command=HELO/EHLO, count=3
bzq-88-152-204-198.red.bezeqint.net [88.152.204.198]: possible SMTP attack:
command=HELO/EHLO, count=3
89.1.170.41.dynamic.barak-online.net [89.1.170.41]: possible SMTP attack:
command=HELO/EHLO, count=3


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: possible SMTP attack: command=HELO/EHLO, count=3 (fwd)

[Adrian C.]

Welcome to the real world :)

No really, have RBL checking w/ or w/o spamassassin and 
you're ok. If you don't use SMTP AUTH disable that too.

--Adrian C.

terry white wrote:
> ... ciao:
> 
>     i'm starting to see a lot of the following.
> 
>     and i'm not thinking it a good thing ...
> 
> 
> muedsl-82-207-247-115.citykom.de [82.207.247.115]: possible SMTP attack:
> command=HELO/EHLO, count=3
> IGLD-83-130-135-36.inter.net.il [83.130.135.36]: possible SMTP attack:
> command=HELO/EHLO, count=3
> bzq-88-153-185-136.red.bezeqint.net [88.153.185.136]: possible SMTP attack:
> command=HELO/EHLO, count=3
> bzq-88-152-204-198.red.bezeqint.net [88.152.204.198]: possible SMTP attack:
> command=HELO/EHLO, count=3
> 89.1.170.41.dynamic.barak-online.net [89.1.170.41]: possible SMTP attack:
> command=HELO/EHLO, count=3
> 
> 

Re: possible SMTP attack: command=HELO/EHLO, count=3 (fwd)

[Glynn Clements]

terry white wrote:

>     i'm starting to see a lot of the following.
> 
>     and i'm not thinking it a good thing ...
> 
> 
> muedsl-82-207-247-115.citykom.de [82.207.247.115]: possible SMTP attack:
> command=HELO/EHLO, count=3
> IGLD-83-130-135-36.inter.net.il [83.130.135.36]: possible SMTP attack:
> command=HELO/EHLO, count=3
> bzq-88-153-185-136.red.bezeqint.net [88.153.185.136]: possible SMTP attack:
> command=HELO/EHLO, count=3
> bzq-88-152-204-198.red.bezeqint.net [88.152.204.198]: possible SMTP attack:
> command=HELO/EHLO, count=3
> 89.1.170.41.dynamic.barak-online.net [89.1.170.41]: possible SMTP attack:
> command=HELO/EHLO, count=3

Nothing worth worrying about. If you run your own inbound mail server,
it will inevitably be subjected to various attacks.

The above indicates that a client sent 3 or more HELO/EHLO commands
(which shouldn't occur in normal use), so sendmail has started
throttling the connection.

Once a command is issued too many times, sendmail adds a delay to each
command that it processes. The delay starts at one second then doubles
with each subsequent command, up to a maximum of four minutes. This
prevents you getting DoS'd by brute-force attacks.

I'm not entirely sure what an attacker can achieve through multiple
HELO/EHLO commands. It might be a DoS against a third-party's DNS, or
it might be attempting to exploit a flaw in specific MTA software.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: possible SMTP attack: command=HELO/EHLO, count=3 (fwd)

[terry white]

... ciao:

: on "10-16-2006" "Glynn Clements" writ:

: If you run your own inbound mail server
: ... (which shouldn't occur in normal use)
: ... I'm not entirely sure what an attacker can achieve

    neither could i.  but then, when i think sendmail, bane and existence
come to mind.  i've run sendmail as an mx for a little over four years,
and have 'never' seen this sort of alert.

    let's hope it's 'much ado about noting' ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Compressed Tar : stop on first occurrence

[Mauricio Silveira]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Hi all,


I'm wondering if there's any way to get tar to stop immediately after 
the extraction of a file on compressed tar files. eg: I pack a big tgz 
with the file index.txt first so that when I run "tar xf file.tgz 
--occurrence index.txt" it extracts "index.txt" but proceeds reading the 
file. I wish tar stopped after extracting the intended file.

I know it works for non-compressed tar archives....

Any way of achieving this with compressed files... maybe a patch lying 
around the net!?

My distribution is slackware.

Thanks in advance,
Mauricio

[-- Attachment #2: msilveira.vcf --]
[-- Type: text/x-vcard, Size: 321 bytes --]

begin:vcard
fn:Mauricio Silveira
n:Silveira;Mauricio
org;quoted-printable:FSN do Brasil - Consultoria em Inform=C3=A1tica;Software Development / Networking
adr:;;;;;;Brazil
email;internet:msilveira@linuxbr.com
title:Linux Consultant / Developer
tel;cell:11-9949-1040
url:http://www.fsndobrasil.com
version:2.1
end:vcard

Re: Compressed Tar : stop on first occurrence

[Hendrik Visage]

On 10/20/06, Mauricio Silveira <msilveira@linuxbr.com> wrote:
> Hi all,
>
>
> I'm wondering if there's any way to get tar to stop immediately after
> the extraction of a file on compressed tar files. eg: I pack a big tgz
> with the file index.txt first so that when I run "tar xf file.tgz
> --occurrence index.txt" it extracts "index.txt" but proceeds reading the
> file. I wish tar stopped after extracting the intended file.
>
> I know it works for non-compressed tar archives....

Perhaps try something like:
gzcat filename.tgz | tar .... and see if that "works", else the issue
is the piping effect
of the gzip/bzip2 for tar.

>
> Any way of achieving this with compressed files... maybe a patch lying
> around the net!?
>
> My distribution is slackware.
>
> Thanks in advance,
> Mauricio
>
>
>


-- 
Hendrik Visage

Re: Compressed Tar : stop on first occurrence

[terry white]

... ciao:

: on "10-20-2006" "Mauricio Silveira" writ:
: I'm wondering if there's any way to get tar to stop immediately after
: the extraction of a file on compressed tar files. eg: I pack a big tgz

    'man tar' offers:

       -T, --files-from F
              get names to extract or create from file F


: when I run "tar xf file.tgz --occurrence index.txt"

    HOWEVER , i'm using a gnu flavour 'tar', which does "not" list
'--occurrence' as an option, so, the suggestion above may not apply ...


-- 
... i'm a man, but i can change,
    if i have to , i guess ...

Re: Compressed Tar : stop on first occurrence

[Mauricio Silveira]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

terry white wrote:
> ... ciao:
>
> : on "10-20-2006" "Mauricio Silveira" writ:
> : I'm wondering if there's any way to get tar to stop immediately after
> : the extraction of a file on compressed tar files. eg: I pack a big tgz
>
>     'man tar' offers:
>
>        -T, --files-from F
>               get names to extract or create from file F
>
>
> : when I run "tar xf file.tgz --occurrence index.txt"
>
>     HOWEVER , i'm using a gnu flavour 'tar', which does "not" list
> '--occurrence' as an option, so, the suggestion above may not apply ..
I know 1.13 doesn't have this option (at least on command line help).

I did some research on the source code for tar 1.15.1 and found a place 
to insert a simple exit() when using "--occurrence filename" to force 
tar to quit on a "match".

I think this is the way tar should behave... compressed or non 
compressed files, tar actions behavior should be the same.
I think I should send tar this issue as a bug... as far as tar waits for 
its child "compress program" pipe to end.

Attached file "tar-1.15.1-compressed-archive-quit-on-ocurrence.diff" 
(such a long name huh?).


Thanks,

Mauricio

[-- Attachment #2: tar-1.15.1-compressed-archive-quit-on-ocurrence.diff --]
[-- Type: text/plain, Size: 275 bytes --]

--- list.c.org	2006-10-20 15:09:17.000000000 -0200
+++ list.c	2006-10-20 15:07:51.000000000 -0200
@@ -199,6 +199,7 @@
     }
   while (!all_names_found (&current_stat_info));
 
+  exit(EXIT_SUCCESS);
   close_archive ();
   names_notfound ();		/* print names not found */
 }

[-- Attachment #3: msilveira.vcf --]
[-- Type: text/x-vcard, Size: 321 bytes --]

begin:vcard
fn:Mauricio Silveira
n:Silveira;Mauricio
org;quoted-printable:FSN do Brasil - Consultoria em Inform=C3=A1tica;Software Development / Networking
adr:;;;;;;Brazil
email;internet:msilveira@linuxbr.com
title:Linux Consultant / Developer
tel;cell:11-9949-1040
url:http://www.fsndobrasil.com
version:2.1
end:vcard

Re: Compressed Tar : stop on first occurrence

[Glynn Clements]

Mauricio Silveira wrote:

> I'm wondering if there's any way to get tar to stop immediately after 
> the extraction of a file on compressed tar files. eg: I pack a big tgz 
> with the file index.txt first so that when I run "tar xf file.tgz 
> --occurrence index.txt" it extracts "index.txt" but proceeds reading the 
> file. I wish tar stopped after extracting the intended file.
> 
> I know it works for non-compressed tar archives....

--occurrence only works on files. When you extract a compressed
archive, tar spawns a separate gzip process connected via a pipe. The
effect is identical to:

	gzip -dc archive.tar.gz | tar xf - ...

Terminating while reading from a pipe will cause the writing process
to terminate abnormally (SIGPIPE, or if that is caught, EPIPE). This
can have undesirable side effects, so tar always reads until EOF when
reading from a pipe or socket.

You could disable this behaviour by removing the call to
sys_drain_input_pipe() from close_archive() in src/buffer.c.

The sys_drain_input_pipe() function (in src/system.c) is preceded by
the comment:

/* Manage to fully drain a pipe we might be reading, so to not break it on
   the producer after the EOF block.  FIXME: one of these days, GNU tar
   might become clever enough to just stop working, once there is no more
   work to do, we might have to revise this area in such time.  */

If you regularly want to extract individual members from an archive,
consider using an archive format which was designed for random access,
e.g. zip.

terry white wrote:

>     'man tar' offers:
> 
>        -T, --files-from F
>               get names to extract or create from file F
> 
> 
> : when I run "tar xf file.tgz --occurrence index.txt"
> 
>     HOWEVER , i'm using a gnu flavour 'tar', which does "not" list
> '--occurrence' as an option, so, the suggestion above may not apply ...

The --occurrence switch is relatively new; it's present in GNU tar
1.15.1. The -T switch has been around as long as I can remember, but
it doesn't help here.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Compressed Tar : stop on first occurrence

[Glynn Clements]

Mauricio Silveira wrote:

> terry white wrote:
> > ... ciao:
> >
> > : on "10-20-2006" "Mauricio Silveira" writ:
> > : I'm wondering if there's any way to get tar to stop immediately after
> > : the extraction of a file on compressed tar files. eg: I pack a big tgz
> >
> >     'man tar' offers:
> >
> >        -T, --files-from F
> >               get names to extract or create from file F
> >
> >
> > : when I run "tar xf file.tgz --occurrence index.txt"
> >
> >     HOWEVER , i'm using a gnu flavour 'tar', which does "not" list
> > '--occurrence' as an option, so, the suggestion above may not apply ..
> I know 1.13 doesn't have this option (at least on command line help).
> 
> I did some research on the source code for tar 1.15.1 and found a place 
> to insert a simple exit() when using "--occurrence filename" to force 
> tar to quit on a "match".
> 
> I think this is the way tar should behave... compressed or non 
> compressed files, tar actions behavior should be the same.

The issue isn't compressed vs non-compressed. tar doesn't read
compressed files, ever; if you use -z, -j, or --use-compress-program,
tar spawns a child process to perform [de]compression. tar itself only
ever reads or writes uncompressed archives.

The issue is reading an archive from a file vs reading it from a pipe
or socket. In the latter case, it *intentionally* reads the entire
stream to avoid causing abnormal termination in the process which is
producing the data (e.g. gzip, in the case of -x).

> I think I should send tar this issue as a bug... as far as tar waits for 
> its child "compress program" pipe to end.

If you read any of what I wrote, you will realise that it isn't a bug,
it's quite intentional behaviour.

> --- list.c.org	2006-10-20 15:09:17.000000000 -0200
> +++ list.c	2006-10-20 15:07:51.000000000 -0200
> @@ -199,6 +199,7 @@
>      }
>    while (!all_names_found (&current_stat_info));
>  
> +  exit(EXIT_SUCCESS);
>    close_archive ();
>    names_notfound ();		/* print names not found */
>  }

This "fix" is wrong on so many levels. If you don't want to drain the
pipe, then don't drain the pipe, as I explained last time. There's no
reason to bypass the rest of the termination process, all of which is
there for one reason or another.

-- 
Glynn Clements <glynn@gclements.plus.com>