UDP connection attempts
Dan Lukes
dan at obluda.cz
Wed Jul 19 09:27:26 UTC 2006
George Mamalakis wrote:
> Jul 19 03:04:49 ns1 kernel: Connection attempt to UDP 127.0.0.1:512 from
> 127.0.0.1:52291
If you have net.inet.ip.check_interface=1 or your firewall block
packets with 127/8 addresses arriving via non-loopback interface then
the source address isn't spoofed.
Then - it's local comunication.
You should search for a local program causing this type of communication.
The packet content (use tcpdump -s1500 -X -i lo0 dst port 512) may (or
may not) help you.
> Jul 19 03:25:56 ns1 kernel: Connection attempt to UDP
> myexternaladdress:52299 from myexternaladdress:53
> Jul 19 09:33:11 ns1 kernel: Connection attempt to UDP
> myexternaladdress:52316 from myexternaladdress:53
It's probably DNS response to nonexistent or expired question.
In the first cast - it's an sort of attack. As you configured system to
report attacks, you want to see those messages. Please note the source
address may be forged and there is no way to determine true source of it
without upstream ISP cooperation.
In the second case - the packet is "too late response" - the process
which send's DNS question no longer wait for it. Unless the source
address spoofed, it's local-to-local DNS request. May be the program
sending it has too short timeout or it's 'question-related' problem (you
asked for a DNS record but apropriate DNS server responded slowly or
didn't respond at all).
You should identify the local program sending those questions and/or
the question trigerring those messages.
Please note, that NAT on myexternaladdress host nay cause that some
non-local communication appear to be local (e.g., some non-local process
communication look as local-process communication). But, your local
computers has no reason to contact your DNS server over external address
(I assume they use apropriate internal address), so it shouldn't
complicate your analysis. In that case you can block DNS question to
myexternaladdress for all internal interfaces - just for sure.
Dan
More information about the freebsd-security
mailing list