[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