Hi John,
Your assumption seems correct.
That is obviously dhcp from an IP address of your cable modem service's internal
management trying to hand out IP addresses. It might even be your bridge (cable modem) itself.
In either case from a security standpoint this is not something to be really worried about .-)
IF the LOG VOLUME is bothering you I'd probably contact your provider.
There is at least one question: Are you sure you do have a "static ip" ?
Since obviously your providers "managing router" does try to connect to you,
maybe you just got a veeeerry long lease and now it is trying to broadcast a renew to you!?
Below is some more info that might help ...
Regards
Reinhold
============================================================================
First of all it's not a "valid" "legal" dhcp(d) request TO the outside or FROM the inside
It has to be rejected. Below you would see how this looks like in the log:
========================================================================================
initial ip request from SME server to Provider: "dhcpd"
---------------------------------------------------------------
Sep 29 10:17:54 mySMEserver dhcpcd: Starting dhcpcd:
Sep 29 10:17:55 mySMEserver dhcpcd[1534]: broadcasting DHCP_DISCOVER
Sep 29 10:17:55 mySMEserver dhcpcd: Starting dhcpcd succeeded
Sep 29 10:17:55 mySMEserver dhcpcd:
Sep 29 10:17:55 mySMEserver rc: Starting dhcpcd: succeeded
Sep 29 10:17:55 mySMEserver xinetd: Starting xinetd:
Sep 29 10:17:55 mySMEserver xinetd[1573]: xinetd Version 2.3.11 started with libwrap loadavg options compiled in.
Sep 29 10:17:55 mySMEserver xinetd[1573]: Started working: 0 available services
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: broadcastAddr option is missing in DHCP server response. Assuming xxx.xxx.31.255
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: dhcpT1value option is missing in DHCP server response. Assuming 1800 sec
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: dhcpT2value option is missing in DHCP server response. Assuming 3150 sec
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: broadcasting second DHCP_DISCOVER
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: DHCP_OFFER received from (xxx.xxx.31.1)
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: broadcasting DHCP_REQUEST for xxx.xxx.31.166
Sep 29 10:17:56 mySMEserver dhcpcd[1534]: DHCP_ACK received from (xxx.xxx.31.1)
Sep 29 10:17:56 mySMEserver e-smith[1618]: Processing event: ip-change xxx.xxx.31.166
dhcpd request to outside (provider):
---------------------------------------------------------------
Oct 14 15:10:34 mySMEserver dhcpcd[2099]: sending DHCP_REQUEST for xxx.xxx.31.166 to xxx.xxx.31.1
Oct 14 15:10:34 mySMEserver dhcpcd[2099]: DHCP_ACK received from (xxx.xxx.31.1)
dhcp request from inside:
---------------------------------------------------------------
Oct 8 07:43:51 mySMEserver dhcpd: DHCPDISCOVER from 00:01:01:03:04:05 via eth0
Oct 8 07:43:52 mySMEserver dhcpd: DHCPOFFER on 192.168.0.65 to 00:01:01:03:04:05 via eth0
=========================================
Now the ip you have in your log is from cox.net: I looked it up from
http://network-tools.com/default.asp?prog=express&Netnic=whois.arin.net&host=68.101.228.1+
68.101.228.1 [ip68-101-228-1.sd.sd.cox.net] and this is obviously your provider.
================================================================
Ports used are 67 and 68 bootp & DHCP
this is what robert graham
http://www.robertgraham.com/pubs/firewall-seen.html says:
DHCP (and the older version, BOOTP) are the protocols that assign your desktop computer an IP address.
Firewalls will see (and reject) a lot of DHCP requests from your local network.
This is an interesting problem with cable and DSL modems, because they create "virtual" local networks
including people in your nearby physical neighborhood. You can identify these local requests because
they are not sent to you, but are are instead to what's called the "local broadcast" address: 255.255.255.255.
These machines are asking to for an address assignment from a DHCP server.
You could probably hack into them by giving them such an assignment and specifying yourself as the local router,
then execute a wide range of man-in-the-middle attacks.
The client requests configuration on a broadcast to port 68 (bootps).
The server broadcasts back the response to port 67 (bootpc).
The response uses some type of broadcast because the client doesn't yet have an IP address that can be sent to.
You rarely see attackers from remote parts of the Internet trying to exploit DHCP vulnerabilities.
================================================================================================================
4 Replies
538 Views