9:18 p.m.
So I've implemented the CSI (Security Policy) as previously posted by Mike
(http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-si...)
Now I'm seeing the following messages in /var/log/messages:
Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:16:01:41:10:5b:08:00 SRC=192.168.2.248
DST=192.168.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=137 DPT=137 LEN=58
Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:0e:3b:02:0e:b7:08:00 SRC=192.168.2.250
DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=138 DPT=138 LEN=209
192.168.2.248 is a NAS device
192.168.2.250 is a Hawking print server
I'm not an iptables expert. Usually I just leave it alone. Can
someone help me write one or more rules to eliminate the messages?
Frank
9:30 p.m.
On Sat, 31 Jan 2009, Frank Chiulli wrote:
So I've implemented the CSI (Security Policy) as previously
posted by Mike
(http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-si...)
Now I'm seeing the following messages in /var/log/messages:
Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:16:01:41:10:5b:08:00 SRC=192.168.2.248
DST=192.168.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=137 DPT=137 LEN=58
Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:0e:3b:02:0e:b7:08:00 SRC=192.168.2.250
DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
SPT=138 DPT=138 LEN=209
192.168.2.248 is a NAS device
192.168.2.250 is a Hawking print server
I'm not an iptables expert. Usually I just leave it alone. Can
someone help me write one or more rules to eliminate the messages?
I suspect that before you were blocking these messages but didn't notice.
You'll see the "DPT=137" and "DPT=138". Those are both ports that
the
various IP's are trying to hit on your machine. If you check out those
ports in /etc/services
In this case those devices seem to be using netbios. If you want to get
rid of them you can just remove the:
-A INPUT -j LOG --log-prefix "FW-REJECT "
Or setup netbios, or block the ports explicitly or allow it and let them
drop naturally.
-Mike
9:59 p.m.
On Sat, 2009-01-31 at 21:30 -0600, Mike McGrath wrote:
On Sat, 31 Jan 2009, Frank Chiulli wrote:
> So I've implemented the CSI (Security Policy) as previously posted by Mike
> (http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-si...)
>
> Now I'm seeing the following messages in /var/log/messages:
> Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:16:01:41:10:5b:08:00 SRC=192.168.2.248
> DST=192.168.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
> SPT=137 DPT=137 LEN=58
>
> Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:0e:3b:02:0e:b7:08:00 SRC=192.168.2.250
> DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
> SPT=138 DPT=138 LEN=209
>
>
> 192.168.2.248 is a NAS device
> 192.168.2.250 is a Hawking print server
>
> I'm not an iptables expert. Usually I just leave it alone. Can
> someone help me write one or more rules to eliminate the messages?
>
I suspect that before you were blocking these messages but didn't notice.
You'll see the "DPT=137" and "DPT=138". Those are both ports
that the
various IP's are trying to hit on your machine. If you check out those
ports in /etc/services
In this case those devices seem to be using netbios. If you want to get
rid of them you can just remove the:
-A INPUT -j LOG --log-prefix "FW-REJECT "
Or setup netbios, or block the ports explicitly or allow it and let them
drop naturally.
Those are windows/samba/cifs ports. if you've got samba running and/or a
windows (or now-adays even a mac) running on the same network you'll
probably find your culprit.
-sv
11:09 p.m.
On Sat, Jan 31, 2009 at 7:59 PM, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Sat, 2009-01-31 at 21:30 -0600, Mike McGrath wrote:
> On Sat, 31 Jan 2009, Frank Chiulli wrote:
>
> > So I've implemented the CSI (Security Policy) as previously posted by Mike
> >
(http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-si...)
> >
> > Now I'm seeing the following messages in /var/log/messages:
> > Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:00:16:01:41:10:5b:08:00 SRC=192.168.2.248
> > DST=192.168.2.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
> > SPT=137 DPT=137 LEN=58
> >
> > Jan 31 19:09:21 localhost kernel: FW-REJECT IN=eth0 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:00:0e:3b:02:0e:b7:08:00 SRC=192.168.2.250
> > DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP
> > SPT=138 DPT=138 LEN=209
> >
> >
> > 192.168.2.248 is a NAS device
> > 192.168.2.250 is a Hawking print server
> >
> > I'm not an iptables expert. Usually I just leave it alone. Can
> > someone help me write one or more rules to eliminate the messages?
> >
>
> I suspect that before you were blocking these messages but didn't notice.
> You'll see the "DPT=137" and "DPT=138". Those are both ports
that the
> various IP's are trying to hit on your machine. If you check out those
> ports in /etc/services
>
> In this case those devices seem to be using netbios. If you want to get
> rid of them you can just remove the:
>
> -A INPUT -j LOG --log-prefix "FW-REJECT "
>
> Or setup netbios, or block the ports explicitly or allow it and let them
> drop naturally.
Those are windows/samba/cifs ports. if you've got samba running and/or a
windows (or now-adays even a mac) running on the same network you'll
probably find your culprit.
-sv
I'm not running samba. If I put the following rule before the LOG
rule, will the packets be dropped and the messages stopped?
-A INPUT -p udp -s 192.168.0.0/24 -d 192.168.0.0/24 -m multiport
--ports 137,138 -j DROP
Frank
1:08 p.m.
On Sat, Jan 31, 2009 at 10:09 PM, Frank Chiulli <frankc.fedora(a)gmail.com> wrote:
I'm not running samba. If I put the following rule before the LOG
rule, will the packets be dropped and the messages stopped?
-A INPUT -p udp -s 192.168.0.0/24 -d 192.168.0.0/24 -m multiport
--ports 137,138 -j DROP
I normally go with 135:139 as they are noisy ports. On a public
network I have a list of ports I drop because they are noisy
-A INPUT -p tcp -m tcp --dport 67:68 -j DROP
-A INPUT -p tcp -m tcp --dport 135:139 -j DROP
-A INPUT -p tcp -m tcp --dport 445 -j DROP
-A INPUT -p udp -m udp --dport 67:68 -j DROP
-A INPUT -p udp -m udp --dport 135:139 -j DROP
-A INPUT -p udp -m udp --sport 177 --dport 177 -j DROP
-A INPUT -p udp -m udp --dport 445 -j DROP
-A INPUT -p udp -m udp --dport 1024:1030 -j DROP
The 1024:1030 UDP drop the enormouse anmount of UDP pop-up spam.
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
3:35 p.m.
On Sun, Feb 1, 2009 at 11:08 AM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Sat, Jan 31, 2009 at 10:09 PM, Frank Chiulli
<frankc.fedora(a)gmail.com> wrote:
>
> I'm not running samba. If I put the following rule before the LOG
> rule, will the packets be dropped and the messages stopped?
>
> -A INPUT -p udp -s 192.168.0.0/24 -d 192.168.0.0/24 -m multiport
> --ports 137,138 -j DROP
>
I normally go with 135:139 as they are noisy ports. On a public
network I have a list of ports I drop because they are noisy
-A INPUT -p tcp -m tcp --dport 67:68 -j DROP
-A INPUT -p tcp -m tcp --dport 135:139 -j DROP
-A INPUT -p tcp -m tcp --dport 445 -j DROP
-A INPUT -p udp -m udp --dport 67:68 -j DROP
-A INPUT -p udp -m udp --dport 135:139 -j DROP
-A INPUT -p udp -m udp --sport 177 --dport 177 -j DROP
-A INPUT -p udp -m udp --dport 445 -j DROP
-A INPUT -p udp -m udp --dport 1024:1030 -j DROP
The 1024:1030 UDP drop the enormouse anmount of UDP pop-up spam.
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
Stephen,
Thanks for the suggestions. I'm hoping that my router throws most of
those away because so far all I've seen in messages is local traffic.
I discovered something interesting while looking at messages. I saw
the following message repeated several times:
Feb 1 09:03:46 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:21:47:b7:86:61:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=40094
PROTO=UDP SPT=68 DPT=67 LEN=308
I was curious what it was because of 'SRC=0.0.0.0'. It turned out to
be my Wii. I discovered this based on my router which keeps track of
MAC addresses and IP addresses. I had forgotten that it was on my
net.
Frank
3:54 p.m.
On Sun, Feb 1, 2009 at 2:35 PM, Frank Chiulli <frankc.fedora(a)gmail.com> wrote:
On Sun, Feb 1, 2009 at 11:08 AM, Stephen John Smoogen
<smooge(a)gmail.com> wrote:
> On Sat, Jan 31, 2009 at 10:09 PM, Frank Chiulli <frankc.fedora(a)gmail.com>
wrote:
>
>>
>> I'm not running samba. If I put the following rule before the LOG
>> rule, will the packets be dropped and the messages stopped?
>>
>> -A INPUT -p udp -s 192.168.0.0/24 -d 192.168.0.0/24 -m multiport
>> --ports 137,138 -j DROP
>>
>
> I normally go with 135:139 as they are noisy ports. On a public
> network I have a list of ports I drop because they are noisy
>
>
> -A INPUT -p tcp -m tcp --dport 67:68 -j DROP
> -A INPUT -p tcp -m tcp --dport 135:139 -j DROP
> -A INPUT -p tcp -m tcp --dport 445 -j DROP
> -A INPUT -p udp -m udp --dport 67:68 -j DROP
> -A INPUT -p udp -m udp --dport 135:139 -j DROP
> -A INPUT -p udp -m udp --sport 177 --dport 177 -j DROP
> -A INPUT -p udp -m udp --dport 445 -j DROP
> -A INPUT -p udp -m udp --dport 1024:1030 -j DROP
>
> The 1024:1030 UDP drop the enormouse anmount of UDP pop-up spam.
>
>
>
> --
> Stephen J Smoogen. -- BSD/GNU/Linux
> How far that little candle throws his beams! So shines a good deed
> in a naughty world. = Shakespeare. "The Merchant of Venice"
>
Stephen,
Thanks for the suggestions. I'm hoping that my router throws most of
those away because so far all I've seen in messages is local traffic.
I discovered something interesting while looking at messages. I saw
the following message repeated several times:
Feb 1 09:03:46 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:21:47:b7:86:61:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=40094
PROTO=UDP SPT=68 DPT=67 LEN=308
I was curious what it was because of 'SRC=0.0.0.0'. It turned out to
be my Wii. I discovered this based on my router which keeps track of
MAC addresses and IP addresses. I had forgotten that it was on my
net.
Yeah... that one can be a shocker when first looked at :). As you
probably know, the reason is that a box booting up doesn't have an IP
address and the old standard was to use 0.0.0.0 as the default to
start up as. Some other boxes use a different from IP address, but for
the most part they are 0.0.0.0
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
5:19 p.m.
On Sun, Feb 1, 2009 at 3:35 PM, Frank Chiulli <frankc.fedora(a)gmail.com> wrote:
Feb 1 09:03:46 localhost kernel: FW-REJECT IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:21:47:b7:86:61:08:00 SRC=0.0.0.0
DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=64 ID=40094
PROTO=UDP SPT=68 DPT=67 LEN=308
I was curious what it was because of 'SRC=0.0.0.0'. It turned out to
be my Wii. I discovered this based on my router which keeps track of
MAC addresses and IP addresses. I had forgotten that it was on my
net.
This is a standard DHCP/BOOTP packet. When a system is booting up it
doesn't have an IP address to stick in there so it puts 0.0.0.0. The
DHCP server and/or DHCP relay uses the MAC address of the client to
send a response back.
--
Jeff Ollie
"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."
-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"
5556
days inactive
5556
days old
infrastructure@lists.fedoraproject.org
7 comments
5 participants
participants (5)
-
Frank Chiulli -
Jeffrey Ollie -
Mike McGrath -
Seth Vidal -
Stephen John Smoogen