Firewall blocking lo scan port 783 to 1524

Firewall blocking lo scan port 783 to 1524

Post by Graham Vincen » Sat, 19 Oct 2002 05:01:50



Hello.

My ipchains firewall logged the message below about 10 times this
morning while on line to get the mail:

Oct 18 08:13:24 stargate kernel: Packet log: input DENY
lo PROTO=6 127.0.0.1:783 127.0.0.1:1524 L=60 S=0x00 I=56508 F=0x4000
T=64 (#9)

line #9 of the firewall script is part of the IP spoofing detection:

# Enable IP spoofing protection
# turn on Source Address Verification
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
    echo 1 > $f
done    ### this is actually line 9 (excluding comments & blanks)

As far as I'm aware I don't have the hp alarm manager running on the
system and I have no idea what ingreslock is for so can anyone tell me
what is happening here?

Thanks,

Graham

 
 
 

Firewall blocking lo scan port 783 to 1524

Post by Whoeve » Sat, 19 Oct 2002 05:35:40



> Hello.

> My ipchains firewall logged the message below about 10 times this
> morning while on line to get the mail:

> Oct 18 08:13:24 stargate kernel: Packet log: input DENY
> lo PROTO=6 127.0.0.1:783 127.0.0.1:1524 L=60 S=0x00 I=56508 F=0x4000
> T=64 (#9)

> line #9 of the firewall script is part of the IP spoofing detection:

It's not LINE 9 of your firewall rules, it is RULE 9 of your INPUT chain
that is causing the packets to be denied. Run:
/sbin/ipchains --list INPUT
to see the rules and look for the 9th rule. It may well be the last rule
(drop anything that has not already been accepted).

You probably need to allow packets into and out of interface lo without
restriction. Put the following at the END of your firewall rules:
/sbin/ipchains -I INPUT -i lo -j ACCEPT
/sbin/ipchains -I OUTPUT -i lo -j ACCEPT

Put these at the END of the file, and because they specify Insert, they
will end up as the first rules in the INPUT and OUTPUT chains.

If you are using Netfilter/iptables, modify the rules for the appropriate
syntax.

 
 
 

Firewall blocking lo scan port 783 to 1524

Post by Lionel Bouto » Sat, 19 Oct 2002 06:05:15



> [...]
> You probably need to allow packets into and out of interface lo without
> restriction.

To explain further :

As lo is the internal interface for intra-communications, you'd only
break programs on your firewall attempting to communicate between them
with TCP/IP sockets (those using "localhost" as the name of a host to
contact for example).

There's no security enhancement brought by lo restrictions but only
usability restrictions...

 
 
 

Firewall blocking lo scan port 783 to 1524

Post by Graham Vincen » Sat, 19 Oct 2002 14:47:22




>> Hello.

>> My ipchains firewall logged the message below about 10 times this
>> morning while on line to get the mail:

>> Oct 18 08:13:24 stargate kernel: Packet log: input DENY lo PROTO=6
>> 127.0.0.1:783 127.0.0.1:1524 L=60 S=0x00 I=56508 F=0x4000 T=64 (#9)

>> line #9 of the firewall script is part of the IP spoofing detection:

> It's not LINE 9 of your firewall rules, it is RULE 9 of your INPUT chain
> that is causing the packets to be denied. Run: /sbin/ipchains --list
> INPUT
> to see the rules and look for the 9th rule. It may well be the last rule
> (drop anything that has not already been accepted).

Thanks for the correction. Rule #9 was blocking port 1524 as part of a
set of rules to protect against trin00.

I have found that port 783 is being used by the spamd portion of Spam
Assassin but I'm still not sure why it decided to talk to port 1524 this
morning?

Cheers.

Graham

 
 
 

Firewall blocking lo scan port 783 to 1524

Post by Whoeve » Sat, 19 Oct 2002 16:21:20



> Thanks for the correction. Rule #9 was blocking port 1524 as part of a
> set of rules to protect against trin00.

> I have found that port 783 is being used by the spamd portion of Spam
> Assassin but I'm still not sure why it decided to talk to port 1524 this
> morning?

Graham,

Firstly, your statement above implies that you have written your firewall
rules as "allow anything that is not explicitly prohibited". This is not
the ideal which is "allow only that which is explicitly permitted"

Secondly, you have to understand that in any communication there is a
source port and a destination port. A process that acts as a server
listens on a known port (25 for SMTP, 783 for spamd, etc.). The process or
machine that is connecting to that port chooses a source port for the
outgoing packets -- and then is listens for the returning packets on that
chosen port (source and destination ports will be reversed for returning
packets).

In the case above, the outgoing packets had a destination port of 783 and
a source port of 1524. Had there been any returning packets, those packets
would have had a destination port of 1524 and a source port of 783.

In most cases, the source port can be any port, subject to a few
limitations: most unix-like OSs restrict ports 0-1023 such that only root
can use. Other than that, the source port of the outgoing packet can be
anything and it will change each time a new connection is made. It just
happened that in this case, port 1524 was chosen as the source port when
the communication with spamd was made.

The bottom line is that you need to get some better rules in place. There
are many examples on the web.

 
 
 

Firewall blocking lo scan port 783 to 1524

Post by Fredderi » Mon, 21 Oct 2002 18:15:47


Quote:> In most cases, the source port can be any port, subject to a few
> limitations: most unix-like OSs restrict ports 0-1023 such that only
> root can use. Other than that, the source port of the outgoing packet
> can be anything and it will change each time a new connection is
> made. It just happened that in this case, port 1524 was chosen as
> the source port when the communication with spamd was made.

Out of curiosity, can either inetd or xinetd tie up a port without actually
running a server on it?  Or would it be better to just shove the discard
service (built into both) onto any port >1024 which you intend to block with
your firewall, so nothing else decides to try using it?