LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   General (http://www.linuxquestions.org/questions/general-10/)
-   -   winxp hitting udp 68 blocked by portsentry (http://www.linuxquestions.org/questions/general-10/winxp-hitting-udp-68-blocked-by-portsentry-4175445626/)

rbees 01-14-2013 09:26 PM

winxp hitting udp 68 blocked by portsentry
 
Ladies & Gents

On my internal network I have an xp host that is misbehaving. After it gets it's ip it keeps hitting udp 68 for some reason. My ip lease time is set at about 12 hours.

I do have portsentry set at the very anal settings. I do not really want to change that. So far I have not found a way to tell portsentry to only listen to my external interface, but then other things have been more important until now.

Hopefully there is some way to stop xp from hitting that port continually. There is also a Brother networked printer that is doing the same kind of thing I think on my existing network, and has been blocked by portsentry. But I don't have to deal with that until I move it to the new network.

In syslog I have
Code:

Jan 14 20:16:13 external dhcpd: DHCPDISCOVER from 00:16:6f:8f:81:bc via eth1                           
Jan 14 20:16:14 external dhcpd: DHCPOFFER on 192.168.7.14 to 00:16:6f:8f:81:bc (Queenbee) via eth1     
Jan 14 20:16:14 external dhclient: DHCPDISCOVER on eth3 to 255.255.255.255 port 67 interval 7         
Jan 14 20:16:14 external dhcpd: Added new forward map from Queenbee.Torah-disciple.local to 192.168.7.14
Jan 14 20:16:14 external dhcpd: added reverse map from 14.7.168.192.in-addr.arpa. to Queenbee.Torah-disc
iple.local                                 
Jan 14 20:16:14 external dhcpd: Wrote 0 deleted host decls to leases file.                             
Jan 14 20:16:14 external dhcpd: Wrote 0 new dynamic host decls to leases file.                         
Jan 14 20:16:14 external dhcpd: Wrote 5 leases to leases file.                                         
Jan 14 20:16:14 external dhcpd: DHCPREQUEST for 192.168.7.14 (192.168.7.1) from 00:16:6f:8f:81:bc (Queen
bee) via eth1                             
Jan 14 20:16:14 external dhcpd: DHCPACK on 192.168.7.14 to 00:16:6f:8f:81:bc (Queenbee) via eth1       
Jan 14 20:16:16 external portsentry[3649]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
UDP port: 68                               
Jan 14 20:16:16 external portsentry[3649]: attackalert: Ignoring UDP response per configuration file set
ting.                                     
Jan 14 20:16:17 external portsentry[3649]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
UDP port: 68                               
Jan 14 20:16:17 external portsentry[3649]: attackalert: Host: 192.168.7.14 is already blocked. Ignoring
Jan 14 20:16:17 external portsentry[3649]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
UDP port: 68                               
Jan 14 20:16:17 external portsentry[3649]: attackalert: Host: 192.168.7.14 is already blocked. Ignoring
Jan 14 20:16:18 external portsentry[3649]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
UDP port: 68

And it just keeps filling the log.

Thanks

NyteOwl 01-14-2013 09:43 PM

Port 68 UDP is used by the BOOTP DHCP client to get an IP in a DHCP enabled environment. Not sure why it would keep polling once it has a valid IP and the lease hasn't expired. Might want to check the XP host config.

rbees 01-14-2013 09:45 PM

Partial portsentry config
Code:

# IPs from /etc/portsentry/portsentry.ignore.static:                                                   
127.0.0.1/32 
0.0.0.0     
192.168.7.1/32                                                                                                       
# dynamically fetched IPs(via ifconfig -a):                                                           
192.168.168.17
192.168.7.1
127.0.0.1


rbees 01-14-2013 09:52 PM

Thanks NyteOwl

I don't suppose you would have any idea how to turn that off?

I briefly looked through the network config but didn't see it.

rbees 01-14-2013 10:39 PM

Running wireshark on the connection gave me
Code:

0.000000000 Intel_3f:53:02 Broadcast ARP 60 Gratuitous ARP for 192.168.30.32 (Request)
The ip it is requesting is not even in my local range. Makes me think there is something suspisous about that request.

unSpawn 01-15-2013 04:13 PM

Quote:

Originally Posted by rbees (Post 4870142)
(..)I do have portsentry (..)

Please read http://www.linuxquestions.org/questi....php?p=1913481. Then note the date I wrote that.

rbees 01-20-2013 07:54 PM

Just for my own information what is the xp machine requesting?

Here is one of the packets that is causing the problem

Code:

Frame 381: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) in interface 0
  Interface id: 0
  WTAP_ENDCAP: 0
  Arrival Time: Jan 20, 2013 18:11:53:109587000 EST
  [Time shift for this packet: 0.000000000 seconds]
  Epoch Time: 1358723513.109587000 seconds
  [Time delta from previous captured frame: 0.576035000 seconds]
  [Time delta from previous displayed frame: 0.576035000 seconds]
  [Time since reference or first frame: 439039887000 seconds]
  Frame Number: 381
  Frame Length: 42 bytes (336 bits)
  Capture Length: 42 bytes (336 bits)
  [Frame is marked: False]
  [Frame is ignored: False]
  [Protocols in frame: eth:arp]
  [Coloring Rule Name: ARP]
  [Coloring Rule String: arp]
 
Ethernet II, Src: Intel_8f:81:bc (00:16:6f:8f:81:bc), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
  Destination: Broadcast (ff:ff:ff:ff:ff:ff)
    Address: Broadcast (ff:ff:ff:ff:ff:ff)
    .... ..1. .... .... .... .... = LG bit: Locally administered address (this in NOT the factory default)
    .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
  Source: Intel_8f:81:bc (00:16:6f:8f:81:bc)
    Address: Intel_8f:81:bc (00:16:6f:8f:81:bc)
    .... ..0. .... .... .... .... = LG but: Globally unique address (factory default)
    .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
  Type: ARP (0x0806)
 
Address Resolution Protocol (request/gratuitous ARP)
  Hardware type: Ethernet (1)
  Protocol type: IP (0x0800)
  Hardware size: 6
  Protocol size: 4
  Opcode: request (1)
  [Is gratuitous: True]
  Sender MAC address: Intel_8f:81:bc (00:16:6f:8f:81:bc)
  Sender IP address: 192.168.7.14 (192.168.7.14)
  Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
  Target IP address: 192.168.7.14  (192.168.7.14)

And there are a lot of these. They do not appear on my existing external which also has portsentry installed.

Ser Olmy 01-20-2013 08:36 PM

I think you may be confusing two entirely different types of packets: Gratuitous ARPs and UDP packets to port 68.

There's bound to be some traffic to port 68 in a network using DHCP (both DHCP and BOOTP use UDP ports 67 and 68). THe DHCP process goes like this:

1. DHCPDISCOVER from the client
2. DHCPOFFER from the server(s)
3. DHCPREQUEST from the client (requesting the address offered in step 2)
4. DHCPACK from the server, confirming the address assignment

At the very least you'll see 4 packets whenever a client requests an address. Also, the client will renew the address after a period of time equal to half the lease time.

As for the ARP packets, it's common practice for a client to send a gratuitous ARP whenever an IP address is successfully acquired, broadcasting the new IP/MAC binding to the entire network.

If you're seeing (gratuitous) ARP replies for IP addresses outside your range, look for misconfigured clients or routers/clients/servers running unauthorized DHCP services.

rbees 01-20-2013 10:09 PM

Thanks

From syslog right after the xp machine was connected

Code:

Jan 20 18:11:52 external dhcpd: Added new forward map from Queenbee.Torah-disciple.local to 192.168.7.14
Jan 20 18:11:52 external dhcpd: added reverse map from 14.7.168.192.in-addr.arpa. to Queenbee.Torah-disc
Jan 20 18:11:52 external dhcpd: DHCPREQUEST for 192.168.7.14 from 00:16:6f:8f:81:bc via eth1           
Jan 20 18:11:52 external dhcpd: DHCPACK on 192.168.7.14 to 00:16:6f:8f:81:bc (Queenbee) via eth1       
Jan 20 18:11:55 external portsentry[5494]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
Jan 20 18:11:55 external portsentry[5494]: attackalert: Ignoring UDP response per configuration file set
Jan 20 18:11:56 external portsentry[5494]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
Jan 20 18:11:56 external portsentry[5494]: attackalert: Host: 192.168.7.14 is already blocked. Ignoring
Jan 20 18:11:56 external portsentry[5494]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to
Jan 20 18:11:56 external portsentry[5494]: attackalert: Host: 192.168.7.14 is already blocked. Ignoring
Jan 20 18:11:57 external portsentry[5494]: attackalert: Connect from host: 192.168.7.14/192.168.7.14 to

The packet I posted was not one of the normal connection packets. Those are being acknowledged and handled correctly. This is something else. And this same host dose not do this on my existing external host, which also has portsentry installed, only the new one I am setting up to take its place does this happen on. My conclusion is that there must be some kind of miss-config. I also thought it may be related to ipv6.

Ser Olmy 01-21-2013 07:52 AM

It could be a DHCPINFORM packet. Windows systems use these packets to request additional DHCP options, and you wouldn't be the first to complain over "DHCPINFORM flooding" in a Windows network.

Some important information is missing from the truncated portsentry log you posted, so it's difficult to say exactly what kind of packets these are from that information alone. You could capture the traffic with tcpdump and analyze it with Wireshark.

According to the portsentry log, the packets are clearly IPv4 packets. Why would you think they were related to IPv6?

rbees 01-21-2013 10:19 AM

One of the lines, may not be in that packet but a different on I was looking at, said something about "unicast". I did not think ipv4 used unicast, but I know that ipv6 does.

I have captured a bunch of packets. I launched wireshark and captured packets form the time I switched networks with my laptop (debian wheezy) through the time I switch the xp laptop and the portsentry entries show up in syslog.

Thing is I don't know what the packets are telling me for the most part. So far other than manually entering them I haven't figured out how to post a bigger section of the capture.

Ser Olmy 01-21-2013 10:51 AM

Quote:

Originally Posted by rbees (Post 4874714)
One of the lines, may not be in that packet but a different on I was looking at, said something about "unicast". I did not think ipv4 used unicast, but I know that ipv6 does.

A unicast is a regular datagram going from one host to another. Unicasts account for the vast majority of IPv4 and IPv6 traffic.

The other two types of traffic are multicasts and broadcasts. IPv6 does not support broadcasting, but uses multicasting instead. IPv4 supports both, but a lot of IPv4 network equipment lacks proper multicast support.

Quote:

Originally Posted by rbees (Post 4874714)
I have captured a bunch of packets. I launched wireshark and captured packets form the time I switched networks with my laptop (debian wheezy) through the time I switch the xp laptop and the portsentry entries show up in syslog.

Thing is I don't know what the packets are telling me for the most part. So far other than manually entering them I haven't figured out how to post a bigger section of the capture.

You could just post the capture file. Use a capture filter to limit the amount of traffic captured.

rbees 01-21-2013 12:30 PM

I think I may have figured out part of the problem. Quite some time ago I had a local chat server running, long gone now but it seams that the windows box is trying to find it. Got to get that turned off, but I can't till tonight after business hours.

unSpawn 01-21-2013 08:16 PM

Moved: This thread is more suitable in the General forum and has been moved accordingly to help your thread/question get the exposure it deserves.


All times are GMT -5. The time now is 12:30 AM.