Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Edwin

Yes, I have this rule and is responsible for the
established/related connections. This rule is almost
at the very end of the INPUT chain.

*>> (...) before the rule that logs/drops your packets?*

Do you mean those strange packages mentioned in the first
mail, right? Frankly, not; This rule is behind rules blocking those
packets. It is something wrong?

Re: NULL Scan issues or something else?

[Török Edwin]

On 02/08/2013 11:16 PM, Daniel Curtis wrote:
> Hi Mr Erwan
> 
> Let's summarize: these logs are normal and are not
> something... /bad/. Even if there are many IP's connections
> (/INVALID/) probes.
> I understand, that I should have not contact with the servers.
> Okay, but if those servers are providing e.g. a website, which
> I visit? How to avoid them? I apologize for my naive questions.
> 
> 

Do you have an iptables rule like this one *before* the rule that logs/drops 
your packets?
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED

--Edwin


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51157248.4070...@etorok.net

Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Erwan

Let's summarize: these logs are normal and are not
something... *bad*. Even if there are many IP's connections
(*INVALID*) probes.
I understand, that I should have not contact with the servers.
Okay, but if those servers are providing e.g. a website, which
I visit? How to avoid them? I apologize for my naive questions.

Re: NULL Scan issues or something else?

[Erwan David]

On Fri, Feb 08, 2013 at 02:06:48PM CET, Daniel Curtis  
said:
> Hi Mr Erwan
> 
> So, everything is okay? Even these strange logs
> mentioned earlier? I'm still curious about this rule;
> SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK,
> FIN,PSH,URG
> 
> What do you mean by writing, that I should not contact servers?
> 
> Best regards!

Those packets are normal answers from servers whttp://lists.debian.org/20130208131005.gp3...@rail.eu.org

Re: NULL Scan issues or something else?

[Daniel Curtis]

Hi Mr Erwan

So, everything is okay? Even these strange logs
mentioned earlier? I'm still curious about this rule;
*SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK,
FIN,PSH,URG*

What do you mean by writing, that I should not contact servers?

Best regards!

Re: NULL Scan issues or something else?

[Erwan David]

Le 07/02/2013 21:22, Daniel Curtis a écrit :

Hi,

>>//(...)/Nothing that should bother you.
/
Okay, so far so good. But what about the rest of
IP addresses, which occurred in logs? You have
mentioned about a /bendel.debian.org / website.
I wonder why?

Because that's the source of the packet you showed us


I noticed, that all the logged events relating to this
strange rule** mentioned earlier, are related to
/SPT=80/ and /IN=eth0/. Literally all of the connections.
What does it mean?

Those are packets sents by web servers (source port 80) in answer to 
your requests.


If you do not want to receive them you must not contact the servers.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51141b97.2080...@rail.eu.org

Re: NULL Scan issues or something else?

[Erwan David]

Le 07/02/2013 19:34, Daniel Curtis a écrit :

Hi

Thank you all for your answers. They are very helpful.
I have to mention some thing, which I forgot to write;

  * no running services
  * all ports are closed (according to e.g. nmap)
  * iptables has concerning rules about /INVALID/ packets
  * flags filtering for /--tcp-flags /and use /--ctstate/.

Now this computer is used for a various test etc. Maybe, in
the future this machine will be something else, more important.
So, should I afraid of these scans attempts, despite that, there
are _not enabled_ any service? Blocking (/DROP/) these connections
is sufficient? In that case, what is the type of scan, that uses these
flags; SYN,RST,ACK,FIN,PSH,URG SYN,RST,ACK, FIN,PSH,URG?

Why this type of scan occurs when all ports are closedand none of
the services are not running? Sorry for the naive question, but I'm
surprised, because I was never in a similar situation. Especially with
closed ports and no services.

Again sorry for so many questions, and thanks for all the answers.
If you can, please answer to the above questions. They are very
important for me.

*Some part of the log:
*SCAN: IN=eth0 OUT= MAC=_mac_addresses
SRC=82.195.75.100 DST=192.168.10.X
LEN=1500 TOS=0x00 PREC=0x00
TTL=52 ID=14512 DF
PROTO=TCP SPT=80 DPT=54790
WINDOW=6432 RES=0x00 ACK URGP=0

...and many more...

Best regards! 


To me it looks like an acknowledgement of a packet you sent to the web 
server on bendel.debian.org ML and archive server for debian...


Nothing that should bother you.


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5113f565.20...@rail.eu.org

RE: NULL Scan issues or something else?

[Boursin Olivier]

Hello Daniel,

As far as I understand well, an INVALID state is applied on packet that 
shouldn't exist according to the conntrack engine. 

Null scan packets should look like --tcp-flags ALL NONE.

Your rule will match with packets that are invalid AND that are not full flag, 
which seem to me almost all invalid packets !

My advice is that you should consider 3 rules :

One that drop every INVALID packets (... -m conntrack --ctstate INVALID ... -j 
DROP)

One that log every NULL SCAN (...--tcp-flags ALL NONE ... -j LOG --log-prefix 
"NULL Scan ")

One that drop every NULL SCAN (...--tcp-flags ALL NONE ... -j DROP)

I hope that this will help you.

 

OB

 

De : Daniel Curtis [mailto:sidetripp...@gmail.com] 
Envoyé : mardi 5 février 2013 18:52
À : debian-security@lists.debian.org
Objet : NULL Scan issues or something else?

 

Hi

I've added a rule to my iptables script, which is responsible for 
filtering --tcp-flags and INVALID state. After addition of this rule, 
I've noticed , that many IP addresses are trying to scan(?) my 
computer, but it is not so obvious, because, for me, from iptables 
rule point of view, NULL Scan is something different (see below). 
This rule looks this way and is related to the incoming connections: 

... -m conntrack --ctstate INVALID -p tcp ! --tcp-flags SYN,RST,
ACK,FIN, PSH,URG, SYN,RST,ACK, FIN,PSH,URG -j DROP

Also, I've added the ability to log this rule with -j LOG --log-prefix 
"NULL Scan ". But something is not as it should be. As we know an 
attacker uses a TCP NULL Scan to determine if ports are closed on 
the target machine by sending a TCP segments with no flag in 
the packet header, right? 
So, I wonder if the above rule is okay, because if NULL Scan does not 
use flags, iptables rule should/could look this way: --tcp-flags ALL NONE 
instead of all these flags mentioned above. So, for what is responsible 
the above rule?

What should I do with this issue? I'm so confused. Maybe it is a normal 
behavior, because of INVALID option? I would like to get some advice 
from You. Generally, I would like to get some advices etc.

## Debian version: 
Wheezy/Sid.

## Example logs entries: 
kernel: [ 9973.043847] NULL SCAN:
IN=eth0 OUT= MAC=mac_addresses_ 
SRC=82.195.75.100 DST=192.168.10.32
LEN=1500 TOS=0x00 PREC=0x00 TTL=52 ID=27355 DF
PROTO=TCP SPT=80 DPT=41464 
WINDOW=6432 RES=0x00 ACK URGP=0

Mostly all of the log entries related to the NULL Scan are the same - the same 
SPT, TTL and PROTO values. Of course, sometimes IP addresses were changed.

Best regards!

Re: NULL Scan issues or something else?

[Jason R McGinn]

That with openvpn ;-)

Jay

On Feb 5, 2013, at 19:33, Kees de Jong  wrote:

> That, or just use OpenVPN.

Re: NULL Scan issues or something else?

[Noah Meyerhans]

On Tue, Feb 05, 2013 at 10:45:39PM +, Jérémie Marguerie wrote:
>You'll be scanned, many times a day, you'll also be bruteforced and
>however not normal, this is just "noise".

See also http://en.wikipedia.org/wiki/Internet_background_radiation



signature.asc
Description: Digital signature

Re: NULL Scan issues or something else?

[Kees de Jong]

That, or just use OpenVPN.

Re: NULL Scan issues or something else?

[Jason R McGinn]

If you want to be extra paranoid, hide your open ports with port knocking and 
have your clients run from a script that knocks the proper sequence before 
making the connection :-)

Jay

On Feb 5, 2013, at 19:10, Jérémie Marguerie  wrote:

> Le 5 févr. 2013 23:03, "Bartek Krajnik"  a écrit :
> >
> > Hi,
> > For ssh login attempts you can use program authfail (after 4 wrong login 
> > attempts it adds proper IP to netfilter with DROP rule sending notification 
> > to IP class owner from whois database).
> 
> It sounds a bit overkill. 
> Am I the only one sometimes typing my password incorrectly because I forgot 
> it?
> 
> Fail2ban does pretty much the same job but only ban for a few minutes. It's 
> just a way to slow down bruteforce. Having 20 guesses per 10 minutes makes a 
> bruteforce useless if the passwords are decent.
> 
> And it will not annoy too much your users but will annoy stupid bots.
> 
> -- 
> Jérémie Marguerie

Re: NULL Scan issues or something else?

[Jason Fergus]

On Tue, 2013-02-05 at 23:10 +, Jérémie Marguerie wrote:
> Le 5 févr. 2013 23:03, "Bartek Krajnik"  a écrit :
> >
> > Hi,
> > For ssh login attempts you can use program authfail (after 4 wrong
> login attempts it adds proper IP to netfilter with DROP rule sending
> notification to IP class owner from whois database).
> 
> It sounds a bit overkill. 
> Am I the only one sometimes typing my password incorrectly because I
> forgot it? 
> 
> Fail2ban does pretty much the same job but only ban for a few minutes.
> It's just a way to slow down bruteforce. Having 20 guesses per 10
> minutes makes a bruteforce useless if the passwords are decent. 
> 
> And it will not annoy too much your users but will annoy stupid bots.
> 
> -- 
> Jérémie Marguerie 
> 

I'll second Fail2Ban.  I use it all the time.  Though, funny story,
where I work we use PBX in a Flash as our PBX.  It is installed by
default with fail2ban, but one day we were having random issues with the
network and our VoIP phones (Aastra 57i) kept trying to connect, I
finally realized that fail2ban had blocked it, as soon as I restarted
the service (clearing the bans) the phone connected and worked just
fine.

So like anything similar, use the tool with care.  It's extremely
configurable though.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1360106090.3141.3.camel@localhost.localdomain

Re: NULL Scan issues or something else?

[Bartek Krajnik]

Hi,
For ssh login attempts you can use program authfail (after 4 wrong login 
attempts it adds proper IP to netfilter with DROP rule sending notification to 
IP class owner from whois database).

"Jérémie Marguerie"  wrote:

>Le 5 févr. 2013 17:52, "Daniel Curtis"  a écrit
>:
>> I've added a rule to my iptables script, which is responsible for
>> filtering --tcp-flags and INVALID state. After addition of this rule,
>> I've noticed , that many IP addresses are trying to scan(?) my
>> computer, but it is not so obvious, because, for me, from iptables
>> rule point of view, NULL Scan is something different (see below).
>> This rule looks this way and is related to the incoming connections:
>>
>> [...]
>>
>> Mostly all of the log entries related to the NULL Scan are the same -
>the
>same
>> SPT, TTL and PROTO values. Of course, sometimes IP addresses were
>changed.
>>
>> Best regards!
>
>Hi,
>
>Don't put too much time into those "strange packets"  received.
>
>There is a countless number of bots and scripts kiddies scanning the
>whole
>ipv4 range (and bruteforcing password also). They often use standard
>scanning like syn scan and sometime you find some people trying to
>exploit
>vulnerabilities quite old (ping of the death, Xmas tcp packets...).
>
>Should you worry? No, at least if you take simple precautions: block
>everything unless what you need (port 80? 22?...) and be as restricted
>as
>possible (from which network...).
>
>And use hard password.
>
>You'll be scanned, many times a day, you'll also be bruteforced and
>however
>not normal, this is just "noise".
>
>Respect usual security measures and you won't really be bothered by
>this
>noise (but by more advanced threat could :)).
>
>A simple iptables firewall with input dropped by default and allowing
>certain ports should work for most servers.
>
>-- 
>Jérémie Marguerie

Pozdrawiam,
   Bartek

Re: NULL Scan issues or something else?

[Jérémie Marguerie]

Le 5 févr. 2013 23:03, "Bartek Krajnik"  a écrit :
>
> Hi,
> For ssh login attempts you can use program authfail (after 4 wrong login
attempts it adds proper IP to netfilter with DROP rule sending notification
to IP class owner from whois database).

It sounds a bit overkill.
Am I the only one sometimes typing my password incorrectly because I forgot
it?

Fail2ban does pretty much the same job but only ban for a few minutes. It's
just a way to slow down bruteforce. Having 20 guesses per 10 minutes makes
a bruteforce useless if the passwords are decent.

And it will not annoy too much your users but will annoy stupid bots.

-- 
Jérémie Marguerie

Re: NULL Scan issues or something else?

[Jérémie Marguerie]

Le 5 févr. 2013 17:52, "Daniel Curtis"  a écrit :
> I've added a rule to my iptables script, which is responsible for
> filtering --tcp-flags and INVALID state. After addition of this rule,
> I've noticed , that many IP addresses are trying to scan(?) my
> computer, but it is not so obvious, because, for me, from iptables
> rule point of view, NULL Scan is something different (see below).
> This rule looks this way and is related to the incoming connections:
>
> [...]
>
> Mostly all of the log entries related to the NULL Scan are the same - the
same
> SPT, TTL and PROTO values. Of course, sometimes IP addresses were changed.
>
> Best regards!

Hi,

Don't put too much time into those "strange packets"  received.

There is a countless number of bots and scripts kiddies scanning the whole
ipv4 range (and bruteforcing password also). They often use standard
scanning like syn scan and sometime you find some people trying to exploit
vulnerabilities quite old (ping of the death, Xmas tcp packets...).

Should you worry? No, at least if you take simple precautions: block
everything unless what you need (port 80? 22?...) and be as restricted as
possible (from which network...).

And use hard password.

You'll be scanned, many times a day, you'll also be bruteforced and however
not normal, this is just "noise".

Respect usual security measures and you won't really be bothered by this
noise (but by more advanced threat could :)).

A simple iptables firewall with input dropped by default and allowing
certain ports should work for most servers.

-- 
Jérémie Marguerie

Re: NULL Scan issues or something else?

[Mike Mestnik]

This is exactly why a higher level interface should be considered.  If
you go about setting your own low level iptables rules then you would
also have the task of testing those rules.

I use shorewall and I've used firhol, both are good.  Please consult
there results(the tables they generate) for stable/widely used examples.
 Plus if you find that they are open to (insert your fav attack here)
then it's much more helpful for the community to get these tools fixed
then would be to fix up your mind enough so that you understand the
implications of iptable rules.

On 02/05/13 11:51, Daniel Curtis wrote:
> Hi
> 
> I've added a rule to my iptables script, which is responsible for
> filtering /--tcp-flags/ and /INVALID/ state. After addition of this rule,
> I've noticed , that many IP addresses are trying to scan(?) my
> computer, but it is not so obvious, because, for me, from iptables
> rule point of view, NULL Scan is something different (see below).
> This rule looks this way and is related to the incoming connections:
> 
> ... -m conntrack --ctstate INVALID -p tcp ! --tcp-flags SYN,RST,
> ACK,FIN, PSH,URG, SYN,RST,ACK, FIN,PSH,URG -j DROP
> 
> Also, I've added the ability to log this rule with/-j LOG --log-prefix
> "NULL Scan /". But something is not as it should be. As we know an
> attacker uses a TCP NULL Scan to determine if ports are closed on
> the target machine by sending a TCP segments with *no flag* in
> the packet header, right?
> So, I wonder if the above rule is okay, because if NULL Scan does not
> use flags, iptables rule should/could look this way: /--tcp-flags ALL NONE/
> instead of all these flags mentioned above. So, for what is responsible
> the above rule?
> 
> What should I do with this issue? I'm so confused. Maybe it is a normal
> behavior, because of /INVALID/ option? I would like to get some advice
> from You. Generally, I would like to get some advices etc.
> 
> *## Debian version:*
> Wheezy/Sid.
> *
> ## Example logs entries: *
> kernel: [ 9973.043847] NULL SCAN:
> IN=eth0 OUT= MAC=mac_addresses_
> SRC=82.195.75.100 DST=192.168.10.32
> LEN=1500 TOS=0x00 PREC=0x00 TTL=52 ID=27355 DF
> PROTO=TCP SPT=80 DPT=41464
> WINDOW=6432 RES=0x00 ACK URGP=0
> 
> Mostly all of the log entries related to the NULL Scan are the same -
> the same /
> SPT/, /TTL/ and /PROTO/ values. Of course, sometimes IP addresses were
> changed.
> 
> Best regards!


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51118875.2000...@mikemestnik.net