DComTalk.com

I'm running kerio 2.1x. Have rules defined for small number of internet
apps only, with fw set to block anything else -all protocols,even dns,
unless explicitly stated for a particular app (dns rules are specified
for each app).

This is a new ISP, an I am getting alot of UDP blocked packets in the
log from it and from all over the globe. When the block all else rule is
at the end of the ruleset and set to log, I get the snippet shown below.

The fw reports three ports listening p 137-139 for nbname, nbdatagram
and nbsession, yet no data exchange for these ports presumably due to my
block all else setting.

If I explicitly write a rule to block udp send and receive at the
beginning of the set, I cannot get get anything to communicate on the
net, but when the fw is just set to block all else I can communicate,
but I still see these blocked, mostly udp to p137 entries in my logs.

Why am I getting udp blocks incoming and outgoing from addresses from
other networks? Please take a look at the snippet below and advise what
is going on and if this is normal or not?

Why am I getting udp blocks incoming and outgoing from addresses from
other networks? Please take a look at the snippet below and advise what
is going on and if this is normal or not?

What????????????????????????

Duane :)

On Sat, 3 Dec 2005, in the Usenet newsgroup comp.security.firewalls, in article
<dmqqjf$jmu$1@domitilla.aioe.org>, watson wrote:

I'm running kerio 2.1x. Have rules defined for small number of internet
apps only, with fw set to block anything else -all protocols,even dns,
unless explicitly stated for a particular app (dns rules are specified
for each app).

Given the concept of a "personal firewall", that's probably a good
solution.

This is a new ISP, an I am getting alot of UDP blocked packets in the
log from it and from all over the globe.

1. UDP Source address _can_ and usually IS faked.
2. The last time I bothered to look at the UDP crap that was not DNS (to
and from port 53 on the nameservers my systems are configured to look to),
I was seeing over a thousand hits a day - mainly aimed at my ports 1025
to 1035. Inspecting representative packets showed it to be messenger spam
(fake windoze warning messages directing me to this or that web site to
get my computer "fixed"). As I'm not stupid enough to be using windoze,
I knew these packets could not be from my computer.

When the block all else rule is at the end of the ruleset and set to
log, I get the snippet shown below.

Snippit not found. I rarely (like once a year) bother to log packets
that have been dropped. My systems work, and have not been r00ted or
0w3n3d, so my firewall must be working correctly.

The fw reports three ports listening p 137-139 for nbname, nbdatagram
and nbsession, yet no data exchange for these ports presumably due to my
block all else setting.

You have windoze sharing turned on. You probably also have windoze
messenger enabled. Turning both off would help, do a google search to
find out how.

If I explicitly write a rule to block udp send and receive at the
beginning of the set, I cannot get get anything to communicate on the
net,

Because it takes precedence over the other rules - and is blocking DNS

but when the fw is just set to block all else I can communicate,
but I still see these blocked, mostly udp to p137 entries in my logs.

After turning off sharing, I'd suggest turning off this log function too.

Why am I getting udp blocks incoming and outgoing from addresses from
other networks?

Clueless people running a fools operating system. It's amazing that the
aftermarket is full of firewall programs that can be used by the average
user, and more amazing that they are needed because microsoft can't seem
to write the same quality programs. Still, the sheep keep buying it, and
that's all that matters to microsoft.

Please take a look at the snippet below and advise what
is going on and if this is normal or not?

Check the help screen, and try again - NO MORE THAN 30 LINES, NO MORE THAN
2400 CHARACTERS PLEASE.

Old guy

ibuprofin@painkiller.example.tld (Moe Trin) wrote in
news:slrndp45hi.bng.ibuprofin@compton.phx.az.us:

On Sat, 3 Dec 2005, in the Usenet newsgroup comp.security.firewalls,
in article <dmqqjf$jmu$1@domitilla.aioe.org>, watson wrote:

I'm running kerio 2.1x. Have rules defined for small number of
internet apps only, with fw set to block anything else -all
protocols,even dns, unless explicitly stated for a particular app (dns
rules are specified for each app).

Given the concept of a "personal firewall", that's probably a good
solution.

This is a new ISP, an I am getting alot of UDP blocked packets in the
log from it and from all over the globe.

1. UDP Source address _can_ and usually IS faked.
2. The last time I bothered to look at the UDP crap that was not DNS
(to and from port 53 on the nameservers my systems are configured to
look to), I was seeing over a thousand hits a day - mainly aimed at my
ports 1025 to 1035. Inspecting representative packets showed it to be
messenger spam (fake windoze warning messages directing me to this or
that web site to get my computer "fixed"). As I'm not stupid enough to
be using windoze, I knew these packets could not be from my computer.

When the block all else rule is at the end of the ruleset and set to
log, I get the snippet shown below.

Snippit not found. I rarely (like once a year) bother to log
packets that have been dropped. My systems work, and have not been
r00ted or 0w3n3d, so my firewall must be working correctly.

The fw reports three ports listening p 137-139 for nbname, nbdatagram
and nbsession, yet no data exchange for these ports presumably due to
my block all else setting.

You have windoze sharing turned on. You probably also have windoze
messenger enabled. Turning both off would help, do a google search to
find out how.

I thought windows sharing was part of their network protocols and I only
have dialup tcp/ip installed. But I will double check, this is a new
machine/setup.

If I explicitly write a rule to block udp send and receive at the
beginning of the set, I cannot get get anything to communicate on the
net,

Because it takes precedence over the other rules - and is blocking DNS

Makes sense.

but when the fw is just set to block all else I can communicate,
but I still see these blocked, mostly udp to p137 entries in my logs.

After turning off sharing, I'd suggest turning off this log function
too.

Why am I getting udp blocks incoming and outgoing from addresses from
other networks?

Clueless people running a fools operating system. It's amazing that
the aftermarket is full of firewall programs that can be used by the
average user, and more amazing that they are needed because microsoft
can't seem to write the same quality programs. Still, the sheep keep
buying it, and that's all that matters to microsoft.

This OS is only installed as one of what will be several OS's including
BSD. Only reason I installed wincrap is that there are some software
packages that only run on this and I am most familiar with it. But my
intention is to shift to another OS ASAP.

Please take a look at the snippet below and advise what
is going on and if this is normal or not?

Check the help screen, and try again - NO MORE THAN 30 LINES, NO MORE
THAN 2400 CHARACTERS PLEASE.

I thought I just forgot to add it. Here it is, sorry for the confusion;
can you take a look and confirm what is happening here?

BLK:In TCP,4.240.150.93:3421->localhost:135,own:noowner
BLK:In TCP,4.240.150.93:3421->localhost:135,own:noowner
BLK:Out UDP,localhost:137->4.240.150.93:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:Out UDP,localhost:137->4.240.150.93:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:Out UDP,localhost:137->4.240.150.93:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:Out UDP,localhost:137->209.244.0.3:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:Out UDP,localhost:137->209.244.0.3:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:Out UDP,localhost:137->209.244.0.3:137,own:C:\WINDOWS\RUNDLL32.EXE
BLK:In TCP,4.240.150.93:1947->localhost:445,own:noowner
BLK:In
UDP,218.66.104.208:44753->localhost:1028,own:E:\Kerio\PFWADMIN.EXE
BLK:In UDP,218.66.104.208:44753->localhost:1030,own:noowner BLK:In
TCP,4.240.123.247:4969->localhost:139,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:In UDP,61.233.41.180:37908->localhost:1028,own:E:\Kerio\PFWADMIN.EXE
BLK:In UDP,61.233.41.180:37908->localhost:1029,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1033,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1030,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1031,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:4257,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1032,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:4257,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1028,own:E:\Kerio\PFWADMIN.EXE
BLK:In UDP,61.233.41.180:37908->localhost:1030,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1031,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1029,own:noowner
BLK:In UDP,61.233.41.180:37908->localhost:1033,own:noowner
BLK:In
TCP,4.240.123.247:4969>localhost:139,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->218.66.104.208:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->218.66.104.208:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->218.66.104.208:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->4.240.123.247:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->4.240.123.247:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE
BLK:Out
UDP,localhost:137->4.240.123.247:137,own:C:\WINDOWS\SYSTEM\RNAAPP.EXE

Just background noise from the Internet.

UDp traffic is usually NETBIOS attacks/scans, Microsoft WIndows Pop Up
spamming, and a few other minor ones. Welcome to why people use
firewalls.

If you run any peer-to-peer sharing client (especially gnutella or
bittorrent clients) you will draw a flood of traffic to your internet
address. It will be a mix of udp or tcp depending upon
client/protocol.


watson <watson@comehere.org> wrote:

I'm running kerio 2.1x. Have rules defined for small number of internet
apps only, with fw set to block anything else -all protocols,even dns,
unless explicitly stated for a particular app (dns rules are specified
for each app).

This is a new ISP, an I am getting alot of UDP blocked packets in the
log from it and from all over the globe. When the block all else rule is
at the end of the ruleset and set to log, I get the snippet shown below.

The fw reports three ports listening p 137-139 for nbname, nbdatagram
and nbsession, yet no data exchange for these ports presumably due to my
block all else setting.

If I explicitly write a rule to block udp send and receive at the
beginning of the set, I cannot get get anything to communicate on the
net, but when the fw is just set to block all else I can communicate,
but I still see these blocked, mostly udp to p137 entries in my logs.

Why am I getting udp blocks incoming and outgoing from addresses from
other networks? Please take a look at the snippet below and advise what
is going on and if this is normal or not?

On Sun, 4 Dec 2005, in the Usenet newsgroup comp.security.firewalls, in article
<dmu0pd$pvs$1@domitilla.aioe.org>, watson wrote:

Moe Trin wrote

watson wrote:

I thought windows sharing was part of their network protocols and I only
have dialup tcp/ip installed. But I will double check, this is a new
machine/setup.

Dialup is networking. Microsoft makes no differentiation between dialup,
wireless, or Ethernet. They assume you want to share your system with any
computer you can connect to in any way.

Why am I getting udp blocks incoming and outgoing from addresses from
other networks?

Clueless people running a fools operating system.

This OS is only installed as one of what will be several OS's including
BSD. Only reason I installed wincrap is that there are some software
packages that only run on this and I am most familiar with it. But my
intention is to shift to another OS ASAP.

http://www.catb.org/~esr/faqs/smart-questions.html

Include details that the people need - O/S, distribution and version, and
so on. While there are only a handful of BSDs (such as FreeBSD, NetBSD and
OpenBSD), there are at least 20 different branded UNIX, and over 380 Linux
distributions - never mind the Mac O/S. All have different warts.

I thought I just forgot to add it. Here it is, sorry for the confusion;
can you take a look and confirm what is happening here?

OK, I put this into a file so I could look at it - lets look first at the
sources:

[compton ~]$ grep In ZZZ | cut -d',' -f2 | cut -d':' -f1 | sort -un
4.240.123.247
4.240.150.93
61.233.41.180
218.66.104.208
[compton ~]$

The two 4.240.x.x addresses resolve to Dial1.Phoenix1.Level3.net which is
a point of presence provider (they rent dialup service to ISPs - here, this
is the Phoenix Arizona market). The other two are Chinese blocks.
61.232.0.0 - 61.237.255.255 is the China Railway Telecom Center, while
218.66.0.0 - 218.67.127.255 is CHINANET Fujian province network. While both
are official arms of the Chinese government (Railway Administration and Army
respectively), they act as commercial ISPs, providing connectivity to Chinese
businesses. Most of what we see outside of China is fast buck artists selling
IP space to anyone. That mainly means spammers.

[compton ~]$ grep Out ZZZ | cut -d'>' -f2 | cut -d':' -f1 | sort -un
4.240.123.247
4.240.150.93
209.244.0.3
218.66.104.208
[compton ~]$

The new one here (209.244.0.3) is resolver1.level3.net, a name server.

The Chinese stuff is all windoze messenger spam - not much you can do to
prevent it from wasting your bandwidth (my recent experience, it's about
1000 packets a day - about a half megabyte). All you can do it to DROP
(ignore) the packets. While I call this 'Chinese', UDP source addresses
(especially messenger spam like this) are often faked. Last month, I ran
logging for a week (tcpdump -n udp and not port 53 >> /tmp/udp.watch) and
while looking at the claimed source addresses, noted such blocks as 1.x.x.x
and 94.x.x.x, neither of which were ever released by IANA.

The stuff between you and the two 4.240.x.x dialups is two windoze boxes
attempting to share. I'd strongly recommend disabling that. Then you will
be left with other systems waving their undies at you on ports 135, 137-139
and 445 yelling 'Hello Sailor'. Best thing to do there is to block it,
either DROP (ignore) or REJECT (reply with a 'FOAD' packet).

Bottom line - another day contaminated by open windoze boxes and messenger
spam. Nothing new.

Old guy

Thanks very much Old guy for the detailed analysis. Eventually I will
put up a hardware firewall once I get the other OSs installed. But Kerio
has done pretty good by me so far. Glad to know the Chinese commies
aren't sleeping under my bed, haha.

(next I have to figure out why this
milan newserver is run by such a bunch of jerks)

ibuprofin@painkiller.example.tld (Moe Trin) wrote in
news:slrndp6bo5.n0u.ibuprofin@compton.phx.az.us:

On Sun, 4 Dec 2005, in the Usenet newsgroup comp.security.firewalls,
in article <dmu0pd$pvs$1@domitilla.aioe.org>, watson wrote:

Moe Trin wrote

watson wrote:

The Chinese stuff is all windoze messenger spam - not much you can do
to prevent it from wasting your bandwidth (my recent experience, it's
about 1000 packets a day - about a half megabyte). All you can do it
to DROP (ignore) the packets. While I call this 'Chinese', UDP source
addresses (especially messenger spam like this) are often faked. Last
month, I ran logging for a week (tcpdump -n udp and not port 53
/tmp/udp.watch) and while looking at the claimed source addresses,
noted such blocks as 1.x.x.x and 94.x.x.x, neither of which were ever
released by IANA.

The stuff between you and the two 4.240.x.x dialups is two windoze
boxes attempting to share. I'd strongly recommend disabling that. Then
you will be left with other systems waving their undies at you on
ports 135, 137-139 and 445 yelling 'Hello Sailor'. Best thing to do
there is to block it, either DROP (ignore) or REJECT (reply with a
'FOAD' packet).

Bottom line - another day contaminated by open windoze boxes and
messenger spam. Nothing new.

Old guy

On Mon, 5 Dec 2005, in the Usenet newsgroup comp.security.firewalls, in article
<dn0d72$n4$2@domitilla.aioe.org>, watson wrote:

Thanks very much Old guy for the detailed analysis. Eventually I will
put up a hardware firewall once I get the other OSs installed. But Kerio
has done pretty good by me so far.

][compton ~]$ grep In ZZZ | cut -d',' -f2 | cut -d':' -f1 | sort -un
]4.240.123.247
]4.240.150.93
]61.233.41.180
]218.66.104.208
][compton ~]$

][compton ~]$ grep Out ZZZ | cut -d'>' -f2 | cut -d':' -f1 | sort -un
]4.240.123.247
]4.240.150.93
]209.244.0.3
]218.66.104.208
][compton ~]$

Things are not completely perfect. Notice that your system is trying to
talk to the two dialins and one of the "Chinese" addresses. This implies
that traffic got past your "inbound" filter. This could be a logging issue
where your firewall is trying to ask the remotes what their name is.

Glad to know the Chinese commies aren't sleeping under my bed, haha.

Many, perhaps most, of the spammers are either Russian or Yank - mainly
the latter. They're merely taking advantage of the dirt cheap hosting
in Asia. Often, the sites that I see being spamvertised (I'm in the USA)
are actually in the US (Florida, Texas, Washington state or California
seeming to be listed most often).

(next I have to figure out why this
milan newserver is run by such a bunch of jerks)

What's wrong with your ISP's server?

Old guy

Windows likes to talk to itself.

Instead of concepts like Unix-Domain sockets, MS binds local stuff to
(of all things) 127.0.0.1.
so allow 127.0.0.1 i/o tcp/udp all ports as a first rule

to get print/file sharing, only allow local address from your LAN
allow 192.168.0/32 i/o tcp/udp ports 135-139,445 as a second rule

the deny from the internet can go directly under rule 2
deny all i/o tcp/udp ports 135-139,445 and you don't need to log
it either.

leave the deny all all all at the bottom and log these to see who's
attempting what.

--
---
Jeff B (remove the No-Spam to reply)

On Tue, 13 Dec 2005, in the Usenet newsgroup comp.security.firewalls, in article
<78KdnRvpv-wP3ALeRVn-tA@adelphia.com>, Jeff B wrote:

Windows likes to talk to itself.

Network aware computers tend to do so.

Instead of concepts like Unix-Domain sockets, MS binds local stuff to
(of all things) 127.0.0.1.
so allow 127.0.0.1 i/o tcp/udp all ports as a first rule

There's nothing _wrong_ with using 127.0.0.1 (or any address in 127.0.0.0/8
for that matter) AS LONG AS it's only on the loopback interface. In another
newsgroup, there's a person complaining about packets coming in from other
ISP customers with a source address of 127.0.0.1 - through the cable modem.
While the operating system should be smart enough to realize that such a
packet is a waste of bandwidth and ignore it, not all do. RFC2827
recommends filtering such traffic (along with other non-sensical addresses
like 169.254.0.0/8, and perhaps 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16
if your ISP doesn't use these for internal services).

to get print/file sharing, only allow local address from your LAN
allow 192.168.0/32 i/o tcp/udp ports 135-139,445 as a second rule

1878 Variable Length Subnet Table For IPv4. T. Pummill, B. Manning.
December 1995. (Format: TXT=19414 bytes) (Obsoletes RFC1860) (Status:
INFORMATIONAL)

A /32 is a host address, and thus should have a fourth octet in the address.
Rather than specify 192.168.0.0/24 (the network 192.168.0.x), the setup
should refer to actual address block used on the LAN - not all people use
192.168.0.0/24.

the deny from the internet can go directly under rule 2
deny all i/o tcp/udp ports 135-139,445 and you don't need to log
it either.

Ignoring 135-139,445 from the Internet is a great idea, but rather than
blocking this or that port - block ALL, and only _allow_ specific stuff
you need to allow. A home user should not be allowing any services IN
(with the possible exception of 113/tcp - required by some mail servers).

leave the deny all all all at the bottom and log these to see who's
attempting what.

Logging is only needed when you are changing things. If you add a new
service and it doesn't work, turn on the firewall log which may explain
why. On the other hand, who gives flying f**k if every computer in
$COUNTRY is trying to connect to a trojan you haven't installed. Your
firewall is blocking it - ignore the noise, stop wasting disk space and
CPU cycles, and get on with your life.

Old guy