GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
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.
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.
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.
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?
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.
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
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.