netfilter and port 635 connects

Hello,

During the last couple of weeks portsentry is producing a lot of alerts
on connects to ports 540 and 635:

<quote-syslog>
Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Connect from
host: <fqdn>/<ip> to TCP port: 635

Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
been blocked via wrappers with string: "ALL: <ip> : DENY"

Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
been blocked via dropped route using command: "/sbin/iptables -I INPUT
-s <ip> -j DROP && /sbin/iptables -I INPUT -s <ip> -m limit --limit
3/minute --limit-burst 5 -j LOG --log-level DEBUG --log-prefix
'Portsentry: dropping: '"
</quote-syslog>

The following rules were added to netfilter (iptables) to explicitly
block those ports (iptables-save output format):

-A INPUT -i eth0 -p tcp -m tcp --dport 635 -j LOG --log-prefix "TEST:
dport 635 drop." --log-level 7
-A INPUT -i eth0 -p tcp -m tcp --dport 635 -j DROP

However the rule doesn't seem to match (no TEST:... entries in the logs)
even though portsentry continues to report the same attack alerts.

Any idea on what kind of connect attempts are being made as reported by
the portsentry? Can those connects be blocked by the netfilter?

I didn't try the '-m state' extension yet.

We are running woody/2.4.24/x86.

Thanks,
Sarunas Burdulis

Sarunas Burdulis wrote:

> <quote-syslog>
> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Connect from
> host: <fqdn>/<ip> to TCP port: 635
>
> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
> been blocked via wrappers with string: "ALL: <ip> : DENY"
>
> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
> been blocked via dropped route using command: "/sbin/iptables -I INPUT
> -s <ip> -j DROP && /sbin/iptables -I INPUT -s <ip> -m limit --limit
> 3/minute --limit-burst 5 -j LOG --log-level DEBUG --log-prefix
> 'Portsentry: dropping: '"
> </quote-syslog>
>
> The following rules were added to netfilter (iptables) to explicitly
> block those ports (iptables-save output format):
>
> -A INPUT -i eth0 -p tcp -m tcp --dport 635 -j LOG --log-prefix "TEST:
> dport 635 drop." --log-level 7
> -A INPUT -i eth0 -p tcp -m tcp --dport 635 -j DROP
>
> However the rule doesn't seem to match (no TEST:... entries in the logs)
> even though portsentry continues to report the same attack alerts.

Firstly, try "iptables -L -n -x -v", to review Your current ruleset.

Then, find out about the "limit" match. If that rule persists _above_
Your LOG and DROP targets, it will never make it to the latter rules
since it is caught by this one. Chain traversal with iptables will
abort as soon as one rule matches (with exception of the LOG target),
so the packet in question may never make it to the LOG and DROP pair.

As for the orign of all that, google for "tcp port 635".

(Sorry for that, normally I would have, but... - not tnight.)


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:
> Sarunas Burdulis wrote:
>
>> <quote-syslog>
>> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Connect from
>> host: <fqdn>/<ip> to TCP port: 635
>>
>> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
>> been blocked via wrappers with string: "ALL: <ip> : DENY"
>>
>> Feb 17 10:04:11 <hostname> portsentry[949]: attackalert: Host <ip> has
>> been blocked via dropped route using command: "/sbin/iptables -I INPUT
>> -s <ip> -j DROP && /sbin/iptables -I INPUT -s <ip> -m limit --limit
>> 3/minute --limit-burst 5 -j LOG --log-level DEBUG --log-prefix
>> 'Portsentry: dropping: '"
>> </quote-syslog>
>>
>> The following rules were added to netfilter (iptables) to explicitly
>> block those ports (iptables-save output format):
>>
>> -A INPUT -i eth0 -p tcp -m tcp --dport 635 -j LOG --log-prefix "TEST:
>> dport 635 drop." --log-level 7
>> -A INPUT -i eth0 -p tcp -m tcp --dport 635 -j DROP
>>
>> However the rule doesn't seem to match (no TEST:... entries in the
>> logs) even though portsentry continues to report the same attack alerts.
>
>
> Firstly, try "iptables -L -n -x -v", to review Your current ruleset.
>
> Then, find out about the "limit" match. If that rule persists _above_
> Your LOG and DROP targets, it will never make it to the latter rules
> since it is caught by this one. Chain traversal with iptables will
> abort as soon as one rule matches (with exception of the LOG target),
> so the packet in question may never make it to the LOG and DROP pair.

Thanks, jack.

Yes, I'm using `iptables -L -nxv`. For the sake of experiment I switched
of portsentry gradually (first removed just the insertion of DROP rule,
then also the LOG). But there is still match my rules for ports 635. The
rules are at the top of `iptables -L...` listing and actually are the
first with DROP targets.

> As for the orign of all that, google for "tcp port 635".
Sure I did. Some rlzdatabase. But there probably is a much wider
portscan taking place. 540 and 635 are what portsentry is set to react
on. I started with 635 just to see if it would be possible to block it.

Sarunas Burdulis

Sarunas Burdulis wrote:

> Yes, I'm using `iptables -L -nxv`. For the sake of experiment I switched
> of portsentry gradually (first removed just the insertion of DROP rule,
> then also the LOG). But there is still match my rules for ports 635. The
> rules are at the top of `iptables -L...` listing and actually are the
> first with DROP targets.

Well, I don't quite understand You here: Firstly, if You have rules that
match tcp packets with --dport 635, then seeing that these rules are
matched is just what You would expect, isn't it? Having a DROP target
will not prevent those packets from hitting Your box, it will only pre-
vent them from being passed on to the kernel so that they cannot cause
any harm.

Then, the order of the rules is significant (but that seems to be OK
in Your setup): Except for the LOG target, traversing of Your chains
will end immediately after one rule matched the packet. So, if You have
a DROP rule before on with LOG target, the packet will never make it
to the LOG target because the earlier DROP match ends the process.

Lastly, You were talking about Your logs. See "man syslog.conf" to
understand what log-levels are and how You can configure where differ-
ent priorities shall be logged (perhaps You can find where those
minor levels, "info", "debug" and "notice" go on Your system an find
the expected entries there).


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:
> Sarunas Burdulis wrote:
>
>> Yes, I'm using `iptables -L -nxv`. For the sake of experiment I
>> switched of portsentry gradually (first removed just the insertion of
>> DROP rule, then also the LOG). But there is still match my rules for
>> ports 635. The rules are at the top of `iptables -L...` listing and
>> actually are the first with DROP targets.
>
>
> Well, I don't quite understand You here: Firstly, if You have rules that
> match tcp packets with --dport 635, then seeing that these rules are
> matched is just what You would expect, isn't it? Having a DROP target
> will not prevent those packets from hitting Your box, it will only pre-
> vent them from being passed on to the kernel so that they cannot cause
> any harm.
>
> Then, the order of the rules is significant (but that seems to be OK
> in Your setup): Except for the LOG target, traversing of Your chains
> will end immediately after one rule matched the packet. So, if You have
> a DROP rule before on with LOG target, the packet will never make it
> to the LOG target because the earlier DROP match ends the process.
>
> Lastly, You were talking about Your logs. See "man syslog.conf" to
> understand what log-levels are and how You can configure where differ-
> ent priorities shall be logged (perhaps You can find where those
> minor levels, "info", "debug" and "notice" go on Your system an find
> the expected entries there).
>
Jack, thanks for all the info.
Sorry, I mistyped my first paragraph! I actually meant the opposite:
there is still no match for the '--dport 635' rule. I'm looking at the
results in:
1) the sysylog by having the same rule with the LOG target (just in
front of the DROP rule), --log-level 7);
2) byte/packet counters produced by iptables -L -nxv.

Sarunas

Sarunas Burdulis wrote:
> Sorry, I mistyped my first paragraph! I actually meant the opposite:
> there is still no match for the '--dport 635' rule. I'm looking at the
> results in:
> 1) the sysylog by having the same rule with the LOG target (just in
> front of the DROP rule), --log-level 7);
> 2) byte/packet counters produced by iptables -L -nxv.

So if I get You correctly, You see a packet count other than "0" when
listing Your rules, but You cannot find the corresponding lines starting
with "TEST: ..." in Your log.

Again, if this is the case, it may be because Your syslogd is set up
to ignore log messages with log level 7, "debug". Try to edit Your
/etc/syslog.conf like so:

<start /etc/syslog.conf>

#"Panic": Wall - users are notified immediately
*.emerg *

#"Warn": Goes into one warn file
*.warning /var/log/warn

#Put all mail and news related things into separate files
mail.* -/var/log/mail
news.* -/var/log/news

#Everything but news and mail into the "messages" file,
#but only with priority info or above
*.info;mail.none;news.none /var/log/messages

#THE INTERESTING PART HERE
#Put all messages with priority "debug", and only those, into one
#file. (So especially those messages that come from the iptables
#LOG rule with "--log-level 7".
*.=debug -/var/log/firewall.log

<end /etc/syslog.d>

Don't forget to restart Your syslogd (like "kill -HUP $(pidof \
syslogd)". Then, watch Your iptables logs with like "tail -f \
/var/log/firewall.log" or whatever You wish to name that file.

Before doing all this, You might want to check whether You can see
any of these "TEST: ..." messages in the kernel buffer with the
command "dmesg".


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack wrote:
> Sarunas Burdulis wrote:
>
>> Sorry, I mistyped my first paragraph! I actually meant the opposite:
>> there is still no match for the '--dport 635' rule. I'm looking at the
>> results in:
>> 1) the sysylog by having the same rule with the LOG target (just in
>> front of the DROP rule), --log-level 7);
>> 2) byte/packet counters produced by iptables -L -nxv.
>
>
> So if I get You correctly, You see a packet count other than "0" when
> listing Your rules, but You cannot find the corresponding lines starting
> with "TEST: ..." in Your log.
>
No, it is "0" packet counts for rules with both LOG and DROP targets,
i.e. for INPUT at dest. port 635.

Sarunas

Sarunas Burdulis wrote:
>> So if I get You correctly, You see a packet count other than "0" when
>> listing Your rules, but You cannot find the corresponding lines starting
>> with "TEST: ..." in Your log.
>>
> No, it is "0" packet counts for rules with both LOG and DROP targets,
> i.e. for INPUT at dest. port 635.

So, lean back and relax. The "attack" stopped.

Return to normal operations.

And since, You needn't wonder why You don't see any LOG entries.

But: If You are absolutely convinced that there must be connection
attempts to 635/TCP, and You have the suspicion that those are, in some
way, circumventing Your firewall, go out and generate connections to
Your box from the outside and see whether You can identify them in Your
logs or counters. - That's the first thing I do after applying signi-
ficant changes to any of my firewalls (after extensive testing, of
course): Go to the next Internet Cafe an try to break in; go to a
different linux box and try from there (most of those parlours don't
have linux, so You don't get the entire palette of tools to test).


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...