DMESG full of bizarre SFW2-Inext-DROP_DEFLT messages.

English Network/Internet
1

Can somebody please tell me what this means and how to fix it? I’m using SUSE 12.2 x86, KDE4.9, wired connection. When I look at dmesg, I get thousands of these:

[13915.864762] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:5c:63:bf:da:c5:37:08:00 SRC=58.132.91.246 DST=58.132.91.244 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=29630 PROTO=UDP SPT=7434 DPT=161 LEN=51 
[13935.954904] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:5c:63:bf:da:c5:37:08:00 SRC=58.132.91.246 DST=58.132.91.244 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=29650 PROTO=UDP SPT=7473 DPT=161 LEN=51 
[13972.559172] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:1a:a9:18:f0:d3:08:00 SRC=58.132.8.169 DST=58.132.91.244 LEN=44 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=2330 DPT=5656 LEN=24 
[14024.106826] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:21:97:cf:bc:ec:08:00 SRC=58.132.91.91 DST=58.132.91.244 LEN=105 TOS=0x00 PREC=0x00 TTL=64 ID=64851 PROTO=UDP SPT=1025 DPT=161 LEN=85 
[14024.250623] SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:25:11:f4:07:24:08:00 SRC=58.132.91.69 DST=58.132.91.244 LEN=64 TOS=0x00 PREC=0x00 TTL=64 ID=13032 DF PROTO=TCP SPT=2107 DPT=139 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B4010303000101080A000000000000000001010402) 
[14030.131128] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:21:97:cf:bc:ec:08:00 SRC=58.132.91.91 DST=58.132.91.244 LEN=105 TOS=0x00 PREC=0x00 TTL=64 ID=64855 PROTO=UDP SPT=1025 DPT=161 LEN=85 
[14036.123118] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:21:97:cf:bc:ec:08:00 SRC=58.132.91.91 DST=58.132.91.244 LEN=105 TOS=0x00 PREC=0x00 TTL=64 ID=64860 PROTO=UDP SPT=1025 DPT=161 LEN=85 
[14042.115136] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:21:97:cf:bc:ec:08:00 SRC=58.132.91.91 DST=58.132.91.244 LEN=105 TOS=0x00 PREC=0x00 TTL=64 ID=64868 PROTO=UDP SPT=1025 DPT=161 LEN=85 
[14074.914902] SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:38:60:77:28:bb:e2:08:00 SRC=58.132.91.17 DST=58.132.91.244 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=12430 DF PROTO=TCP SPT=2629 DPT=139 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
[14151.355039] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:1a:a9:18:f0:d3:08:00 SRC=58.132.8.169 DST=58.132.91.244 LEN=44 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=2330 DPT=5656 LEN=24 
[14182.777169] SFW2-INext-ACC-TCP IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:21:97:cb:12:da:08:00 SRC=58.132.91.76 DST=58.132.91.244 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=41984 DF PROTO=TCP SPT=2250 DPT=139 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405B401010402) 
[14334.116189] SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=00:26:6c:0e:83:0b:00:1a:a9:18:f0:d3:08:00 SRC=58.132.8.169 DST=58.132.91.244 LEN=44 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=2330 DPT=5656 LEN=24 
[14355.998298] SFW2-INext-ACC IN=eth0 OUT= MAC= SRC=58.132.91.244 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=44

I looked at another thread on these forums concerning the same from about a year ago that said something about MDNS in the hosts file, and then another posting seemed to contradict that one, so I wasn’t at all sure what to do. The probelm seems associated with applications opening slowly and hanging up, but that could just be a coincidence. Anyway, I’d like to find out, so please help me quash these messages I’m getting.

2

I do not know the anwer, but imho these are from the firewall (SFW2 = SuSEFireWall2) and contain MAC addresses and IP addresses. About dropping UTP messages outgoing from your eth0.

II hope this helps in searching

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In case it helps anymore:

The boxes attempting to connect to your box: 58.132.91.246,
58.132.8.169, 58.132.91.91, 58.132.91.17, 58.132.91.76
The ports being attempted on your system: 5353 (multicast DNS), 139
(something windows/netbios-ish, 161 (SNMP), 5656 (not a commonly-used port).

I doubt this has anything to do with applications on your machine
starting slowly. This set of packets is blocked over the course of
several minutes so this is hardly a big bunch of data. As many boxes
are involved in making the connections they may all be misconfigured.
Either way, blocked inbound packets, at least at this low rate,
shouldn’t affect application startup. It may help if you describe your
applications problem (in the applications forum, if you have not done so
already) including when it started, if it ever worked, if other machines
work, if anything affects the performance (first-time load vs.
second-time, etc.), and maybe the solution to the real problem will come
then. Finding firewall messages in dmesg is interesting but probably
not a cause for concern when it’s just a dozen in five minutes.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQoRIoAAoJEF+XTK08PnB5vCgP/2BqoZq5ntCIBh2ZkaKWnbfN
/AfO/GjGVqEUQ0hEZYD3HU406HKXcASs9b4/hVyI9ZoW7rEu9cviAeaBGWx0yfKs
iNe85qMgdEG9Dqx2AMORwJPZSvmZx9LrajOjOffqBr3HPKtnzO3nPQyD83swQ7p7
VscTkZfJSHUIPdUH14P1Y0rcJunijW8k1Qf64ID4U7ddpKataBfldJTw0NyEzB2k
45PGNkivnIs3jVax8UmtDKssSFVm3aTMeVGu9vFXbhMekel/Z0LcTYjUrX9W+Giq
FubBV0/92d2+UiTveadcHaxXB48yxl7uVDTn97ZBKbWlzk/RXiIAtBzan2B3TqOq
CQ3VHdScrp31km+bS0332NiOIU+m6DeIxJ7efAzE0U2Ilv6O/tUKKcEPZui3DdMi
ZwPjm3DHkK3cv+Z79Q+zOgLInu5CRzCTShT5BFwVtJCcfoJPMUflb/HYhsK+XBkQ
w7ttGcLbESbQUvRGS3rSGclQ+3jU3C16UDJOCkmSafz2OCRd6iqCxDJU7wmysoY+
+mq0kjrrt/3K8qhfPLlD8zCHddRx7uWVBH+pmZqtn7Ktzjvc80ROvzLhSLngh4Np
EsjT07oUNF9Hob8sLtEAMPpFuKTuYu9CzEIHFFiwp1rp6m4XkAYKGCindqFPgYC0
ep+6IoKbc3XMXIMFbxdF
=kN8K
-----END PGP SIGNATURE-----

4

On 2012-11-12 16:13, ab wrote:
> In case it helps anymore:
>
> The boxes attempting to connect to your box: 58.132.91.246,
> 58.132.8.169, 58.132.91.91, 58.132.91.17, 58.132.91.76
> The ports being attempted on your system: 5353 (multicast DNS), 139
> (something windows/netbios-ish, 161 (SNMP), 5656 (not a commonly-used port).

Those can be attacks. I looked the whois on the first one and it comes
from PRC. It depends on what the OP has and where he is.

But those are not the rejections the OP asked about, I think.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Looking at the original dmesg output you may also see that these are
from his own network. If it really is a VERY slow scan, from multiple
hosts, on the OP’s own network, that network is pretty infected. Based
on the slow rate I’d bet this isn’t an attack, but more analysis is
probably needed to know for sure.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQoWI/AAoJEF+XTK08PnB5DyoP/0qa0fO1a3NAjJwkH7w8ENc8
6MT7B+bST5EOqKxb0snxbbcHCG6XVH9omsVnybV9hTPDVgW+IxlG/UanOb/rPIRl
AQ4ZlPQjW9qwmHmOa3UQBSFqOfwjWZO8EXj9aQn0nGnf8pkn0rraND+hLSp1nmz+
hqu7FArc963t4LA0HszY5okBBJxd2i4o6DOThZkHKxwN0qu/X2BRIqYPzOA7ABzl
/temPWjxX62QHft6bvAwJ6/fJLV763XHjxe4SgOXkWBJEyJv34lo2C6pFvtS3laE
A7undDohsNQ7LpzkO1nimHXjadcuDMQWEkYarAG2YIoL/lWIvH80Ei4OSydOcNa+
Fzqsw/NoA+sx5QDBn3a3HEmOoXAbiBXrq929RTOytFaNqqTOhw5KTTNSkfCwCNnZ
V3g1oN8D66jZiCjjqSY2QBQOUa5iy/bOIjot0VVbdDD067K7VuR2FGo6S4iuzDNJ
U/OQtsNDJPPrGH3uX3ltzvNzC5/tY+BznVVMl0yA4iyb6TH4VLNRTtZmQ5uUgvtV
jR0rWOKEB8k8+sTLCMhuVPf+AV9JbMMAsAKbMi4rfkA5W6XdRIeyf+L59zEQxZjA
Ug5Z6lwtBwrF/sX8VTYcU60UwiyjniEr2llR5/UpejRus9nXd/LqTzJzG2FJ4i3t
Nhgc179wrLQd8BWglJgD
=aXA5
-----END PGP SIGNATURE-----

6

On 2012-11-12 21:55, ab wrote:
> Looking at the original dmesg output you may also see that these
> are from his own network. If it really is a VERY slow scan, from
> multiple hosts, on the OP’s own network, that network is pretty
> infected. Based on the slow rate I’d bet this isn’t an attack, but
> more analysis is probably needed to know for sure.


[13915.864762] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
MAC=00:26:6c:0e:83:0b:5c:63:bf:da:c5:37:08:00 SRC=58.132.91.246
DST=58.132.91.244 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=29630 PROTO=UDP
SPT=7434 DPT=161 LEN=51

At first glance, this one is incoming from internet. What an external
IP tries to do accessing snmp on his machine, dunno, can be an attack
unless he knows that IP. But yes, it is the same internet network
(Beijing Education Information Network), so that changes things a
lot… I would go to the next table or room in that university and ask
them what the heck they are doing.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

7

On 11/12/2012 7:48 PM, Carlos E. R. wrote:
<snip>
>
> At first glance, this one is incoming from internet. What an external
> IP tries to do accessing snmp on his machine, dunno, can be an attack
> unless he knows that IP. But yes, it is the same internet network
> (Beijing Education Information Network), so that changes things a
> lot… I would go to the next table or room in that university and ask
> them what the heck they are doing.
>
>
Or you could always use something like Wireshark to capture the packets being
exchanged on the network. IMHO it is not surprising to find snmp(simplified
network management protocol) being used on an educational network.

Port 139 is assigned to netbios-ssn and would be expected if you have Samba’s
nmbd running. Notice that these packets are accepted.

P.V.
“We’re all in this together, I’m pulling for you” Red Green

8

On 2012-11-13 03:28, PV wrote:
> On 11/12/2012 7:48 PM, Carlos E. R. wrote:
> <snip>

> Or you could always use something like Wireshark to capture the packets
> being exchanged on the network. IMHO it is not surprising to find
> snmp(simplified network management protocol) being used on an
> educational network.

But it is not that typical that the network is running on Internet, it
is usually a local network.

> Port 139 is assigned to netbios-ssn and would be expected if you have
> Samba’s nmbd running. Notice that these packets are accepted.

Huh. Dangerous.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

9

On 11/12/2012 9:28 PM, Carlos E. R. wrote:
> On 2012-11-13 03:28, PV wrote:
>> On 11/12/2012 7:48 PM, Carlos E. R. wrote:
>> <snip>
>
>
>> Or you could always use something like Wireshark to capture the packets
>> being exchanged on the network. IMHO it is not surprising to find
>> snmp(simplified network management protocol) being used on an
>> educational network.
>
> But it is not that typical that the network is running on Internet, it
> is usually a local network.
>
>> Port 139 is assigned to netbios-ssn and would be expected if you have
>> Samba’s nmbd running. Notice that these packets are accepted.
>
> Huh. Dangerous.
>
snmp packets (port 161) are being dropped. There should be no harm here.

You can close port 139 by going to YaST>Security and Users>Firewall>Allowed
Services and Disallow the Netbios Server. However, do not be surprised to see
that Samba (Windows file/printer sharing) fails to resolve names. Moreover,
depending on the role of the machine, the whole Window’s network cannot resolve
names.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

10

I’m impressed with the sleuth work I see here! Actually, I work in a school in Beijing, so these are not cyber-attacks from a Chinese source. Interestingly, the internal LAN here uses public IP addresses for all the machines on the network; so, despite being in the 58.* range they’re still private IP’s AFAIK. I managed to get rid of most of the messages by turning off firewall logging for accepted packets, but there are still a few messages appearing occasionally. The reason other hosts on the network are sending packets to my machine is that I have a Samba (actually CIFS) share set up on my machine, password protected, for sharing files with my colleagues. However, some of those addresses that were logged are outside the privilege circle, so would that necessarily mean that others are attempting to log in, or would these be routine service discovery packets? I don’t have anything top-secret on my machine that requires high security, but I would like to know if someone’s snooping.

P.S.
The performance problems I mentioned before are being caused by an unrelated kworker issue, where kworker pegs the CPU whenever I plug in the office printer into my USB. I once tried to set the printer up as a shared printer on the network from my Suse box, but failed :frowning:

11

You can close port 139 by going to YaST>Security and Users>Firewall>Allowed
Services and Disallow the Netbios Server. However, do not be surprised to see
that Samba (Windows file/printer sharing) fails to resolve names. Moreover,
depending on the role of the machine, the whole Window’s network cannot resolve
names.

I don’t use netbios names anyway. I don’t think the IT staff here would much appreciate me setting up a name server on their network ;-). I set up all my Samba shares by IP. The netbios port is open (probably) because of that time I tried to set up a network printer.

12

On 11/12/2012 11:26 PM, HuaiDan wrote:
>
> I’m impressed with the sleuth work I see here! Actually, I work in a
> school in Beijing, so these are not cyber-attacks from a Chinese source.
> Interestingly, the internal LAN here uses public IP addresses for all
> the machines on the network; so, despite being in the 58.* range they’re
> still private IP’s AFAIK. I managed to get rid of most of the messages
> by turning off firewall logging for accepted packets, but there are
> still a few messages appearing occasionally. The reason other hosts on
> the network are sending packets to my machine is that I have a Samba
> (actually CIFS) share set up on my machine, password protected, for
> sharing files with my colleagues. However, some of those addresses that
> were logged are outside the privilege circle, so would that necessarily
> mean that others are attempting to log in, or would these be routine
> service discovery packets? I don’t have anything top-secret on my
> machine that requires high security, but I would like to know if
> someone’s snooping.
>
<snip>
HuaiDan;

If your machine became a Local Master Browser you would expect queries from
other machines in your Windows network. Since the Local Master is determined by
an election of all the machines in the Window’s network, the role of your
machine can change periodically.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

13

On 11/12/2012 11:36 PM, HuaiDan wrote:
>
<snip>
> I don’t use netbios names anyway. I don’t think the IT staff here
> would much appreciate me setting up a name server on their network ;-).
> I set up all my Samba shares by IP. The netbios port is open (probably)
> because of that time I tried to set up a network printer.
>
>
HuaiDan;

nmbd is not really a name server unless it was setup as a wins server. However,
If you close port 139 then it would be wise to make sure nmb(d) does not start
at boot.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

14

On 2012-11-13 06:26, HuaiDan wrote:
>
> I’m impressed with the sleuth work I see here! Actually, I work in a
> school in Beijing, so these are not cyber-attacks from a Chinese source.
> Interestingly, the internal LAN here uses public IP addresses for all
> the machines on the network; so, despite being in the 58.* range they’re
> still private IP’s AFAIK.

That’s a very dangerous practice, IMO.

> I managed to get rid of most of the messages
> by turning off firewall logging for accepted packets, but there are
> still a few messages appearing occasionally.

That is like someone is hitting another person and you plug your ears
not to hear it. The danger remains even if you shut the log.

> The reason other hosts on
> the network are sending packets to my machine is that I have a Samba
> (actually CIFS) share set up on my machine, password protected, for
> sharing files with my colleagues.

Actually, you have it open to the entire world.

> However, some of those addresses that
> were logged are outside the privilege circle, so would that necessarily
> mean that others are attempting to log in, or would these be routine
> service discovery packets?

Of course they try. And now that you have published your IP range in
internet, you may find real targeted attacks to your network. MMMMmmmm,
how nice, Windows services on internet… CANDY!

> I don’t have anything top-secret on my
> machine that requires high security, but I would like to know if
> someone’s snooping.

Snooping would be the least of my worries.

You really should set up the entire network as a local network behind a
good firewall. No reason at all to use Internet addresses unless you
provide services to the outside, and then there are other means.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>

 [13915.864762] SFW2-INext-DROP-DEFLT IN=eth0 OUT=
> MAC=00:26:6c:0e:83:0b:5c:63:bf:da:c5:37:08:00 SRC=58.132.91.246
> DST=58.132.91.244 LEN=71 TOS=0x00 PREC=0x00 TTL=127 ID=29630
> PROTO=UDP SPT=7434 DPT=161 LEN=51

>
> At first glance, this one is incoming from internet. What an
> external IP tries to do accessing snmp on his machine, dunno, can be
> an attack unless he knows that IP. But yes, it is the same internet
> network (Beijing Education Information Network), so that changes
> things a lot… I would go to the next table or room in that
> university and ask them what the heck they are doing.

I have no idea how you could glean that this is “incoming from Internet”
when both IP addresses are on the same network. Unless you mean
“coming from an IP address that isn’t reserved for private networks” as
“coming from the Internet”, which is a pretty gross generalization at
best, it just simply isn’t a true statement. As a result the stated
danger is probably not as significant as initially believed. Getting
SNMP, mDNS, and NetBIOS traffic (even if all but the last are rejected)
from the other room isn’t weird and I would bet many large organizations
have things misconfigured to cause this from time to time.

If I saw these IP addresses (or any non-my-network addresses for that
matter) getting traffic to my boxes on these ports I’d be concerned, but
that’s simply because traffic from outside my network, whatever IP
ranges are used inside or outside, should not be allowed to reach my
network in an unsolicited way. The same is probably true for the OP
where these types of packets will not be seen coming from the outside.
It is not a rare practice to have public IP addresses listed for a
network and still to have the barrier between those “internal” IP
addresses and the rest of the world separated by a firewall that serves
the same purpose as a NAT for those with less experience/ability or
resources in the form of IPs. If you have an entire Class A range there
can be benefits to using the “real” addresses internally.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQokYvAAoJEF+XTK08PnB5KXEQALPf3wHYimAtRPomXFFxw6Eo
eW4t45mEGmN6ZUEKR3ypmItsXbJjGEAWsWHCZ5acdTDfkxdhbOa3qJP7shkBh4QX
1aQeb7EjW/RZqPukwneoB32YrQRvOvV/PHrkZD2/urdUYAJYxvmlqgtKziPLDE/o
ZuBA+PwzW2RwOH3KeuPSdzFS7aXFc9v2Elfo+EIsqwVtcAzdw2eo7t/JWjb2GAqC
NeoNohGik5wZlxxXVkZMuEPWxSeSQpVDx1eG6+RoCHkbFMFNXR3UZDgPOlfwOYxz
OdRfY6JWxCXI7cr9K86YRhppz1y2e9xok044f51pzVhbf2H3qYHG79TGmDNdhicu
KzJadNPN8ZcFOp3KzZ4U6Pa7eNxYwIlrFxOgke5iH4XPUget1Qcu3e2FX1XyqP01
ENgSOEgPCSGlIzCNWhoaDtUT2J2ciQNHaO+J1cZje4w1XoKwLG99hjoDDvXPDZ5A
L/x+GXHTywG8W3201xoTqaIEuU5r6db40wx93P/SyKbJBWUle1k1Vyq98vrVw4tv
8CQkHR3zC5DbpROUs04T30vLGD1mo+RpeLshbPt3ff2tq/P8hTe6Ra/JoX3tXfKU
/pGploLWt12p+iehD+Q58beD4MiY8qWNJDQfWgjdq5tXLI26rPkQmWwShXDqFiuW
aShTAQOilejDtf+MviJC
=lL8u
-----END PGP SIGNATURE-----

16

I think you are mixing up the usage of IP addresses from non-private ranges in a LAN with having no firewall (and with that I mean a real firewall, not the “personal firewall” that is on many PCs).

I have no doubt the OP has a firewall between the outside world and the company’s/institution’s network. I do not understand why you think he hasn’t.

The only thing about using precious non-private IP ranges is that when everybody would have done this, we would have run out of IPv4 addresses years ago ;).

17

Carlos E. R. wrote:
> On 2012-11-13 06:26, HuaiDan wrote:
>> I’m impressed with the sleuth work I see here! Actually, I work in a
>> school in Beijing, so these are not cyber-attacks from a Chinese source.
>> Interestingly, the internal LAN here uses public IP addresses for all
>> the machines on the network; so, despite being in the 58.* range they’re
>> still private IP’s AFAIK.
>
> That’s a very dangerous practice, IMO.

Not really. It does depend on the quality of the firewall / boundary
routers, though. And the skills of the administrators.

> Actually, you have it open to the entire world.

No, it’s open to the internal network. The network’s firewall decides
what the entire world can see.

> You really should set up the entire network as a local network behind a
> good firewall.

IIUC, that’s exactly what is already there. Can you contact any machine
on that network? I can’t.

> No reason at all to use Internet addresses unless you
> provide services to the outside, and then there are other means.

That might be easier said than done. It used to be best practice to set
up a network the way it is. Think Sun, for example. Changing the
addressing strategy for a whole network can be quite complicated and
potentially expensive. So unless there’s some indication that the
existing design isn’t fit for purpose, it might be difficult to make an
argument for change.

18

On 2012-11-13 14:36, hcvv wrote:

> I have no doubt the OP has a firewall between the outside world and the
> company’s/institution’s network. I do not understand why you think he
> hasn’t.

He said he was getting entries in his firewall log from machines outside
his “local” network, IIUC.

> The only thing about using precious non-private IP ranges is that when
> everybody would have done this, we would have run out of IPv4 addresses
> years ago ;).

Indeed.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))

19

Then you didn’t read the rest of the thread were this was proven to be not true.

20

On 2012-11-13 21:56, hcvv wrote:
> Then you didn’t read the rest of the thread were this was proven to be
> not true.

Yes, I have read it all entirely.

–
Cheers / Saludos,

Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))