Robert although your response accurately reflects the risks of relying on
packet filtering to protect your network, I believe the question was with
the regards to the raw socket that is listening in Gerardo's machine.
The Raw IP Networking FAW at http://www.ntua.gr/rin/rawfaq.html#12 describes
it as follows:
----- start here ----
2.2.3) How can I listen for packets with a raw socket?
Traditionally the BSD socket API did not allow you to listen to just any
incoming packet via a raw socket. Although Linux (2.0.30 was the last
version I had a look at), did allow this, it has to do with their own
implementation of the TCP/IP stack. Correct BSD semantics allow you to get
some packets which match a certain category (see below).
There's a logical reason behind this; for example TCP packets are always
handled by the kernel. If the port is open, send a SYN-ACK and establish the
connection, or send back a RST. On the other hand, some types of ICMP (I
compiled a small list below), the kernel can't handle. Like an ICMP echo
reply, is passed to a matching raw socket, since it was meant for a user
program to receive it.
The solution is to firewall that particular port if it was a UDP or TCP
packet, and sniff it with a packet capturing API (a list is mentioned
above). This prevents the TCP/IP stack from handling the packet, thus it
will be ignored and you can handle it yourself without intervention.
If you don't firewall it, and reply yourself you'll wind up having
additional responses from your operating system!
Here's a concise explanation of the semantics of a raw BSD socket, taken
from a Usenet post by W.
Richard Stevens
From <[EMAIL PROTECTED]> (Sun Jul 6 12:07:07 1997) :
"The semantics of BSD raw sockets are:
- TCP and UDP: no one other than the kernel gets these.
- ICMP: a copy of each ICMP gets passed to each matching raw socket,
except
for a few that the kernel generates the reply for: ICMP echo request,
timestamp request, and mask request.
- IGMP: all of these get passed to all matching raw sockets.
- all other protocols that the kernel doesn't deal with (OSPF, etc.):
these
all get passed to all matching raw sockets."
After looking at the icmp_input() routine from the 4.4BSD's TCP/IP stack, it
seems the following ICMP types will be passed to matching raw sockets:
Echo Reply: (0)
Router Advertisement (9)
Time Stamp Reply (13)
Mask Reply (18)
---- ends here ---
I don't believe that Gerardo's machine has been compromised because a raw
socket is listening, rather it is a normal listening port in a Linux
machine. If I understand it correctly, a raw socket listening on "port" 1
is waiting for ICMP packets (ICMP has been assigned protocol number 1)
Somebody correct me if I am wrong 'cause my Linux systems also show
listening raw sockets... ;-)
To add a spin to this... any security implications with listening raw
sockets? What if a raw socket is listening for protocol 6 (TCP)?
-----Original Message-----
From: Paul D. Robertson [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 24, 1999 9:26 AM
To: Gerardo Soto
Cc: [EMAIL PROTECTED]
Subject: Re: raw connections
On Wed, 23 Jun 1999, Gerardo Soto wrote:
> Hi to everyone.
> I have configured my router ( cisco 2511 IOS 11.1) to deny
> everything but tcp 25, udp & tcp 53 , tcp 80 .
1. Have you tested the filter rules to make _sure_ they work?
2. Now you have to secure the services that you're allowing. If you're
running BIND for DNS, that means moving to a fixed version, there are
exploits in older versions. Whatever version of mail software, the same
thing probably. Lastly for a Web server, you have to make sure you're
not on a buggy version of the server daemon *and* that there are no
exploitable scripts accessable.
3. Are there any other machines on the subnet that could be used as an
attack vector (such as a trojaned Win9x machine)?
4. Could any of the client programs you're using be trojaned (if
applicable), or if that's not a factor, are you blocking outbound traffic
that isn't DNS or ESTABLISHED?
Once you're sure you've done all of that, make sure that your router
isn't accessable from the Internet. The number of routers getting
compromised seems pretty large now-a-days, especially if they have HTTP
configs enabled.
Lastly, did you reload the OS after the original compromise? You could
be running a trojaned service or library if you didn't.
If you had an idea of the attack vector used to compromise the host, it'd
be a lot easier. If possible, I'd suggest logging the services you do
allow off to a second log-only host.
Paul
----------------------------------------------------------------------------
-
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
