Neighbor table overflow. Virus?

Hi,

Can a virus/spyware on a dialup link cause 'Neighbor table overflow"
in the access-server?

I run a small ISP which has dialup-clients. I run stock RH 9 on our
access-server (10 dial-in lines) and every once in a while I suddenly
get thousands of 'Neighbor table overflow" messages in the mesages log
and while that's happening I can't establish new connections.

The ARP table is also full of hunddreds of unconnected connections.

When this happens (maybe 4-5 times now over 1 year timespan) I track it
down to a user on dial-up whos' spewing out ARP requests or making
hundreds of connections. And when I kick that user off the problem is
solved (its a different user every time).

However, I would like to build in some protection against this.

I have changed /proc/sys/net/ipv4/ip_conntrack_max to 65528
But this helps little if any.
Values of /proc/sys/net/ipv4/neigh/default/gc_thresh1 is: 128
Values of /proc/sys/net/ipv4/neigh/default/gc_thresh2 is: 512
Values of /proc/sys/net/ipv4/neigh/default/gc_thresh3 is: 1024
Should I change those values and to what?

I'm also using iptables, how can I use this to restrict new
connections? what would be resonable values?

And finally, does anybody know what virus/malware is causing this?

Thanks!
Regards,
Tobias Skytte

(E-Mail Removed) <(E-Mail Removed)> wrote:

> Can a virus/spyware on a dialup link cause 'Neighbor table overflow"
> in the access-server?

You should check the /etc/hosts file, to see if someone has screwed with
the localhost line. The most frequent cause, by far, of "Neighbor table
overflow" errors is inability to resolve the localhost hostname.

Remember: The meathead with the root password is a much bigger system
threat than malware could ever aspire to be. ;->

ha ha. yes, except in this case I'm the only one with root privileges
and /etc/hosts is fine and incidently the loopback is also fine.
When I kicked off the user dialling-in, the problem immediately
disapeared. The user logged back on and the problem returned, I kicked
him off again (and suspended his account) and the problem was resolved
once more.
So it's definently because of this (and others) dialup user.

But I need protection against this. In this case its a virus/malware
(which is bad enough) but someone can also use this as a DoS attack....

regards,
Tobias Skytte

(E-Mail Removed) <(E-Mail Removed)> wrote:
> ha ha. yes, except in this case I'm the only one with root privileges
> and /etc/hosts is fine and incidently the loopback is also fine.
> When I kicked off the user dialling-in, the problem immediately
> disapeared. The user logged back on and the problem returned, I kicked
> him off again (and suspended his account) and the problem was resolved
> once more.
> So it's definently because of this (and others) dialup user.
>
> But I need protection against this. In this case its a virus/malware
> (which is bad enough) but someone can also use this as a DoS attack....

People tend to leap to the "malware" conclusion at the jump of a hat,
when what they really mean is "The system is doing something strange
that I don't understand."

If it were really malware, you wouldn't see the errors go away the
moment the user's dial-in session ceased.

I don't really have enough data to work from, but you might consider
checking the logfiles and configuration of/concerning the PPP daemon,
for clues.

I agree on the "malware" issue, except what I mean by it in this case
is that the malware is installed in the *dial-in clients computer*.
Sorry if I didn't make that clear. As soon as I disconnect that client
the problem disappears in the server. It is obvious from the ARP table
that hundreds of connections are comming from this client that cannot
be established. The client is running a windows version by the way.

Regards,
Tobias Skytte

(E-Mail Removed) <(E-Mail Removed)> wrote:
> I agree on the "malware" issue, except what I mean by it in this case
> is that the malware is installed in the *dial-in clients computer*.
> Sorry if I didn't make that clear. As soon as I disconnect that client
> the problem disappears in the server. It is obvious from the ARP table
> that hundreds of connections are comming from this client that cannot
> be established. The client is running a windows version by the way.

Ah, thanks for clarifying. Yes, it's distinctly possible that ARP
flooding might originate at such a dial-up client machine.

At a glance, you could increase the size of the system arp table by
increasing /proc/sys/net/ipv4/neigh/default/gc_thresh[123] , e.g., to
4096. The "man 7 arp" manpage has details.

There's also a userspace arpd, but I have no experience with it.

--
Cheers,
Rick Moen "vi is my shepherd; I shall not font."
(E-Mail Removed) -- Psalm 0.1 beta

On 24 Jan 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, (E-Mail Removed)
wrote:

>Sorry if I didn't make that clear. As soon as I disconnect that client
>the problem disappears in the server. It is obvious from the ARP table
>that hundreds of connections are comming from this client that cannot
>be established.

Entries in the ARP tables should only occur for IP addresses that are
local to this computer. Looking at your routing table should show what
the O/S deems to be local. Are you using some unusual netmasks?

>The client is running a windows version by the way.

In theory, sniffing the connection to see WTF it's trying to connect
to might help, as the dialin box isn't using ARP (a ppp connection does
not). This means you can see what address, port, and protocol is trying
to be used.

Old guy

Moe Trin wrote:
> On 24 Jan 2006, in the Usenet newsgroup comp.os.linux.networking, in article
> <(E-Mail Removed) .com>, (E-Mail Removed)
> wrote:
>
>
>>Sorry if I didn't make that clear. As soon as I disconnect that client
>>the problem disappears in the server. It is obvious from the ARP table
>>that hundreds of connections are comming from this client that cannot
>>be established.
>
>
> Entries in the ARP tables should only occur for IP addresses that are
> local to this computer. Looking at your routing table should show what
> the O/S deems to be local. Are you using some unusual netmasks?
>
>
>>The client is running a windows version by the way.
>
>
> In theory, sniffing the connection to see WTF it's trying to connect
> to might help, as the dialin box isn't using ARP (a ppp connection does
> not). This means you can see what address, port, and protocol is trying
> to be used.

The ARP tables contain MAC and IP addresses of hosts in the
local subnet and, temporarily, also the attempted accesses
to local subnet non-existent hosts until the ARP times out.

It seems that the client at the PPP connection is attempting
to reach all possible addresses in the local subnet. It might
be a network scan attempt.

The PPP client can imagine being a part of the local Ethernet
subnet, if the PPP router is using proxy ARP.

To verify, a tcpdump/Ethereal trace of the situation could
give the clue.

--

Tauno Voipio
tauno voipio (at) iki fi

On Tue, 24 Jan 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <iwwBf.379$(E-Mail Removed)>, Tauno Voipio wrote:

>The PPP client can imagine being a part of the local Ethernet
>subnet, if the PPP router is using proxy ARP.

I'm really not sure what you are trying to say here. For a dialup, the
peer that is dialing in has no concept of ARP - it's not even part of
the protocol. The function of the 'proxyarp' option to ANU ppp is to
add the "remote" IP address to the arp cache along with the MAC address
of "local" system. As ppp is a peer to peer protocol, there can be a
maximum number of such addresses - the O/P stated this server had ten
dialin lines, which adds just ten IP addresses. For an ISP type of
operation (clients on dialin accessing the Internet), proxyarp would
be a normal mode unless the server is masquerading.

Old guy

Moe Trin wrote:
> On Tue, 24 Jan 2006, in the Usenet newsgroup comp.os.linux.networking, in
> article <iwwBf.379$(E-Mail Removed)>, Tauno Voipio wrote:
>
>
>>The PPP client can imagine being a part of the local Ethernet
>>subnet, if the PPP router is using proxy ARP.
>
>
> I'm really not sure what you are trying to say here. For a dialup, the
> peer that is dialing in has no concept of ARP - it's not even part of
> the protocol. The function of the 'proxyarp' option to ANU ppp is to
> add the "remote" IP address to the arp cache along with the MAC address
> of "local" system. As ppp is a peer to peer protocol, there can be a
> maximum number of such addresses - the O/P stated this server had ten
> dialin lines, which adds just ten IP addresses. For an ISP type of
> operation (clients on dialin accessing the Internet), proxyarp would
> be a normal mode unless the server is masquerading.

There is the possibility to run the peer at the
remote end of a PPP link as a virtual member of the
backbone Ethernet connecting the PPP-to-Ethernet
router to the rest of the Net. It is set up so
that the PPP link gets an IP address of the backbone
local network and the router performs proxy ARP in
behalf of the remote PPP end.

In the configuration above, the peer at the remote
end of PPP will trigger ARP requests to the backbone
addressed to other hosts in the local net. If the
PPP user performs a local network scan, it will
fill the ARP table at the router.

--

Tauno Voipio
tauno voipio (at) iki fi