Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: SloopJohnB on October 14, 2003, 04:41:20 AM
-
I have the following output to my logs that's happening continuously and seems to be bogging down the harddrive.
Oct 13 16:35:49 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=42600 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 13 16:35:51 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=68.8.132.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=42712 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 13 16:35:51 lvds12 kernel: denylog:IN=eth1 OUT=
Well you get the picture. Any idea how to stop this??
SloopJohnB
-
Try looking for denylog:IN=eth1 and select all dates.
Appearently this means that nic eth1 is loosing it's connection.
I'm guessing that eth1 is your internet connection.
If you have an extra networkcard lying around, I would advise you to change it to rule out that the networkcard is not faulty.
Big change thow that it is your internet connection that is causing the problem.
-
MORE INFORMATION ON THIS ISSUE. Ok techies, I have switched the cards around and also have tried to reconfigure the server (switching configurations for eth0 & eth1) Itseem that there is eith a remote request coming into the outside nic for DHCP or BOOTP or the server is sending a outbound request on the outside nic for DHCP or BOOTP. Here is the log file sampling again (it logs every 10 secs).
Oct 14 09:11:21 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=68.101.228.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=38192 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:24 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=38317 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:43 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=68.8.132.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39110 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:43 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39112 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:48 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=68.101.236.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39310 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:48 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39312 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:51 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=68.101.228.1 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39471 PROTO=UDP SPT=67 DPT=68 LEN=308
Oct 14 09:11:51 lvds12 kernel: denylog:IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:30:b8:03:3b:50:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=255 ID=39473 PROTO=UDP SPT=67 DPT=68 LEN=308
*********************************************NOTE********************* On a trace route the IP addresses go back to the ISP... This is a static connection to the ISP with static settings on the external nic card... Please help!! And yes I did search the archives to no avail.
-
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.
================================================================================================================
-
Ok all, I contacted COX and yes, it is a true static connection according to the tech, however he could not deny the "long lease" on this ip address. He termed this broadcasting as "TCP OVERHEAD" and we are compensated with extra bandwith to cover any losses.
So now the next question, how do I turn off broadcast logging??
SloopJohnB