[lug] outgoing port 220 exploit?

D. Stimits stimits at comcast.net
Sun Jan 18 17:31:54 MST 2004

Jordan Crouse wrote:

> >Well, netstat seems to work only for existing tcp connects, or if it
> >is run right at the instant of a connect attempt. What I have here is
> >a period failed connect to outside port 220, it is blocked both on the
> >local machine and on the bridge firewall, so it never gets beyond a
> >SYN packet. I'm thinking what I need is a tcpdump. Only I'm having a
> >problem with the tcpdump syntax. Can anyone tell me the syntax to use
> >tcpdump to continuously dump info of any port 220 destination packets?
> >And is there a way to give source application info the way netstat
> >does with the -lenp argument?
> You can also use ethereal if you want something a little bit more "user
> friendly".  It does most of the ugly work for you in terms of figuring
> out the different layers.  its a GTK user interface, so its requires the
> overhead of any GUI app and the user interaction, but its invaluable at
> figuring out the gooey innards of the packets (unless you can remember
> how big an 802.1D packet is from memory.. :D ).

So far this has proved useless, as the firewall rules prevent any actual 
outbound traffic...apparently this is blocked prior to tcpdump or 
ethereal seeing the traffic (tested from both the machine in question 
and a transparent bridge/firewall). It seems to be an attempt to relay 
without port 25 being involved, and with all the commonly exploited 
ports firewalled in 2 locations.

> Another option is to use iptables to log any outgoing attempts on port
> 220.  The advantage here is that it will be logged automatically,
> without having to run tcpdump or ethereal.  For example, here is the
> chain that I use to log incoming ICMP packets that get dropped (I
> like to know when people try to ping me):

I am using ipchains on this particular machine (don't worry, packages 
are updated), which I have gone through for days and concluded is not 
hacked or rooted. Most people don't block outgoing ports, but I do block 
outgoing ports if they are related to a service not used (and I don't 
use imap so 220 is blocked both locally and at the bridge, with both 
logging). The inbound source is eluding me.

> iptables -A LDROP --proto icmp -j LOG --log-level info \
>                                            --log-prefix "ICMP Drop "
> iptables -A ICMP -p icmp --icmp-type echo-request  -J LDROP
> Check the iptables man pages for more information on the
> --log-level and--log-prefix params.
> As for determining which specific processes are sending the offending
> ports, thats a bit more difficult.  You might need to end up writing a
> program or a script that monitors /proc/net/udp and /proc/net/tcp for
> the right numbers, and then either logs the information, sends you an
> email, or sounds an alarm (or maybe all three).

Whatever it is has to work to log even on an attempt to send outbound 
traffic, as the ipchains is blocking it before tcpdump or ethereal or 
netstat can track anything.

D. Stimits, stimits AT comcast DOT net

More information about the LUG mailing list