[OT] Attn: Joost - Intruder Alarm... - Slackware

This is a discussion on [OT] Attn: Joost - Intruder Alarm... - Slackware ; Hey Joost. Here's what I'm doing to keep track of attempted connections to my box: tethereal -i eth0 | grep SYN Not much going on in that arena. Looks like clearwire does a pretty good job of firewalling their network. ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: [OT] Attn: Joost - Intruder Alarm...

  1. [OT] Attn: Joost - Intruder Alarm...

    Hey Joost. Here's what I'm doing to keep track of attempted connections
    to my box:

    tethereal -i eth0 | grep SYN

    Not much going on in that arena. Looks like clearwire does a pretty good
    job of firewalling their network. The interface is running in promiscuous mode.

    I am mostly seeing the SYN and SYN, ACK from my own activities.

    I realize that this is simplistic, but it's all I need. I am not being targetted
    by pros and have a good, basic firewall of my own.

    Tom

    --
    calhobbit
    at gee mail dot com


  2. Re: [OT] Attn: Joost - Intruder Alarm...

    On 2008-01-28, Tom N wrote:
    > Hey Joost. Here's what I'm doing to keep track of attempted connections
    > to my box:
    >
    > tethereal -i eth0 | grep SYN
    >
    > Not much going on in that arena. Looks like clearwire does a pretty good
    > job of firewalling their network. The interface is running in promiscuous mode.
    >
    > I am mostly seeing the SYN and SYN, ACK from my own activities.
    >
    > I realize that this is simplistic, but it's all I need. I am not being targetted
    > by pros and have a good, basic firewall of my own.
    >
    > Tom
    >


    Just got one! An attempted ssh connection from:

    netnum: 202.204.64.0 - 202.204.79.255
    netname: NCEPUBJ-CN
    descr: 华北电力犴鸹大学(北京)
    descr: North China Electric Power University (beijing)
    descr: Beijing 102206,China
    country: CN
    admin-c: LX39-AP
    tech-c: LX39-AP
    tech-c: CER-AP
    remarks: origin AS4538
    changed: hm-changed@net.edu.cn 19990419
    mnt-by: MAINT-CERNET-AP
    status: ASSIGNED NON-PORTABLE
    source: APNIC

    role: CERNET Helpdesk
    address: Room 224, Main Building
    address: Tsinghua University
    address: Beijing 100084, China
    country: CN
    phone: +86-10-6278-4049
    fax-no: +86-10-6278-5933
    e-mail: cernet-helpdesk-ip@net.edu.cn
    trouble: abuse@net.edu.cn
    admin-c: XL1-CN
    tech-c: SZ2-AP
    nic-hdl: CER-AP
    remarks: Point of Contact for admin-c
    mnt-by: MAINT-CERNET-AP
    changed: cernet-helpdesk-ip@net.edu.cn 20010903
    source: APNIC

    person: Lei Xu
    address: Department Of Information Engneering
    address: North China Electric Power University (beijing)
    address: Beijing 102206,China
    phone: +86-010-80795666 ext. 3654
    e-mail: ncepubj@163.net
    nic-hdl: LX39-AP
    notify: address-allocation-staff@net.edu.cn
    mnt-by: MAINT-NULL
    changed: hostmaster@net.edu.cn 19990419
    source: APNIC

    Two tries. Both failed.

    Tom


    --
    calhobbit
    at gee mail dot com


  3. Re: [OT] Attn: Joost - Intruder Alarm...

    Tom N wrote:
    >Just got one! An attempted ssh connection from:


    They really are out to get you! How did they even find you?! See, this
    is how the paranoia starts.

    In the last 21 days, one of my outside machines has had 12,826 root
    login attempts on ssh. Fer reals.

    -Beej, who disallows root logins on ssh, and keeps up on security patches


  4. Re: [OT] Attn: Joost - Intruder Alarm...

    On 2008-01-28, Beej Jorgensen wrote:
    > Tom N wrote:
    >>Just got one! An attempted ssh connection from:

    >
    > They really are out to get you! How did they even find you?! See, this
    > is how the paranoia starts.


    I am getting a gun tomorrow!

    >
    > In the last 21 days, one of my outside machines has had 12,826 root
    > login attempts on ssh. Fer reals.


    Kind of puts things in perspective, doesn't it?

    If I was running ssh, I'd probably get more. But not that many!

    > -Beej, who disallows root logins on ssh, and keeps up on security patches


    But do you patch your bluejeans?

    That attempt was the only one in the last hour or so.

    I've heard there is a way to turn off ICMP echo request responses. Do you
    know how to do that?

    Tom

    --
    calhobbit
    at gee mail dot com


  5. Re: [OT] Attn: Joost - Intruder Alarm...

    Tom N wrote:
    >I've heard there is a way to turn off ICMP echo request responses. Do you
    >know how to do that?


    Use Google, 'cause it's faster than waiting for me to respond.

    http://www.cyberciti.biz/faq/howto-d...-ping-packets/

    # echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

    or

    # iptables -A INPUT -p icmp -j DROP

    -Beej


  6. Re: [OT] Attn: Joost - Intruder Alarm...

    On 2008-01-28, Beej Jorgensen wrote:
    > Tom N wrote:
    >>I've heard there is a way to turn off ICMP echo request responses. Do you
    >>know how to do that?

    >
    > Use Google, 'cause it's faster than waiting for me to respond.


    But not as intelligent and learned and eloquent.

    And you don't come with hundreds of ads (like googlebooks) disguised as hits!

    Besides, I'm not in a hurry :-)

    >
    > http://www.cyberciti.biz/faq/howto-d...-ping-packets/
    >
    > # echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
    >
    > or
    >
    > # iptables -A INPUT -p icmp -j DROP
    >


    Thanks, Beej. I'll put that rule in my rc.iptables script and run
    it with restart option.

    iptables -vL-n

    ....
    0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0
    ....

    Looks good!

    Tom

    --
    calhobbit
    at gee mail dot com


  7. Re: [OT] Attn: Joost - Intruder Alarm...

    Tom N wrote:
    > 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0


    Note on that there was a URL on that page that points out how to
    restrict this to ICMP echo replies if you want to do that. Check the
    man page for --icmp-type for more info.

    What you have there is drop on all ICMP traffic from all hosts, which of
    course works. But it can be really convenient sometimes to run ping on
    your own lan, so you might consider allowing ICMP traffic from within
    your lan.

    Also the useful command traceroute relies on getting ICMP packets back
    to you, although these are not ICMP echo or echo-reply packets.

    -Beej


  8. Re: [OT] Attn: Joost - Intruder Alarm...

    On 2008-01-28, Beej Jorgensen wrote:
    > Tom N wrote:
    >> 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0

    >
    > Note on that there was a URL on that page that points out how to
    > restrict this to ICMP echo replies if you want to do that. Check the
    > man page for --icmp-type for more info.
    >
    > What you have there is drop on all ICMP traffic from all hosts, which of
    > course works. But it can be really convenient sometimes to run ping on
    > your own lan, so you might consider allowing ICMP traffic from within
    > your lan.


    Okay. But is one computer considered a lan?

    > Also the useful command traceroute relies on getting ICMP packets back
    > to you, although these are not ICMP echo or echo-reply packets.


    Okay. It looks like it needs fine-tuning. Until then, if I need to ping
    127.0.0.1 or use traceroute, I'll just drop my firewall.

    I was thinking that I also ought to grep for any outgoing packets as well
    as SYN (although most of them will be caught by the SYN regex).

    How do you explain this, Beej:

    ping www.google.com
    PING www.l.google.com (72.14.253.104) 56(84) bytes of data.
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=1 ttl=242 time=32.0 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=2 ttl=242 time=28.8 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=3 ttl=242 time=33.0 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=4 ttl=242 time=29.0 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=5 ttl=242 time=33.2 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=6 ttl=242 time=37.3 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=7 ttl=242 time=33.1 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=8 ttl=242 time=29.2 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=9 ttl=242 time=33.3 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=10 ttl=242 time=29.0 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=12 ttl=242 time=37.5 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=13 ttl=242 time=41.9 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=14 ttl=242 time=29.2 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=15 ttl=242 time=50.2 ms
    64 bytes from po-in-f104.google.com (72.14.253.104): icmp_seq=16 ttl=242 time=37.6 ms

    --- www.l.google.com ping statistics ---
    16 packets transmitted, 15 received, 6% packet loss, time 15015ms
    rtt min/avg/max/mdev = 28.891/34.342/50.217/5.709 ms

    iptables shows no packets registered under that rule...

    Tom

    --
    calhobbit
    at gee mail dot com


  9. Re: [OT] Attn: Joost - Intruder Alarm...

    Tom N wrote:
    >Okay. But is one computer considered a lan?


    Yes, but from a practical standpoint, you won't be pinging on eth0 to
    the local machine; pings will go through the lo (local loopback)
    interface. So you could change your iptables command to target the eth0
    (or whatever) interface and leave lo alone.

    >Okay. It looks like it needs fine-tuning. Until then, if I need to ping
    >127.0.0.1 or use traceroute, I'll just drop my firewall.


    127.0.0.1 is usually lo. If you ifconfig lo, you should get something
    like this:

    $ ifconfig lo
    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:417863 errors:0 dropped:0 overruns:0 frame:0
    TX packets:417863 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:79827444 (76.1 MiB) TX bytes:79827444 (76.1 MiB)

    >How do you explain this, Beej:


    I can't--I'd think the iptables ICMP drop from any to any rule would
    match this.

    -Beej


  10. Re: [OT] Attn: Joost - Intruder Alarm...

    On 2008-01-28, Beej Jorgensen wrote:
    > Tom N wrote:
    >>Okay. But is one computer considered a lan?

    >
    > Yes, but from a practical standpoint, you won't be pinging on eth0 to
    > the local machine; pings will go through the lo (local loopback)
    > interface. So you could change your iptables command to target the eth0
    > (or whatever) interface and leave lo alone.


    Good idea.

    >
    >>Okay. It looks like it needs fine-tuning. Until then, if I need to ping
    >>127.0.0.1 or use traceroute, I'll just drop my firewall.

    >
    > 127.0.0.1 is usually lo. If you ifconfig lo, you should get something
    > like this:
    >
    > $ ifconfig lo
    > lo Link encap:Local Loopback
    > inet addr:127.0.0.1 Mask:255.0.0.0
    > inet6 addr: ::1/128 Scope:Host
    > UP LOOPBACK RUNNING MTU:16436 Metric:1
    > RX packets:417863 errors:0 dropped:0 overruns:0 frame:0
    > TX packets:417863 errors:0 dropped:0 overruns:0 carrier:0
    > collisions:0 txqueuelen:0
    > RX bytes:79827444 (76.1 MiB) TX bytes:79827444 (76.1 MiB)


    That's what I get.

    >
    >>How do you explain this, Beej:

    >
    > I can't--I'd think the iptables ICMP drop from any to any rule would
    > match this.
    >


    I can ping lo or anywhere. Guess I better take a look at that webpage
    and RTFM.

    Thanks, Beej,

    Tom

    --
    calhobbit
    at gee mail dot com


  11. Re: [OT] Attn: Joost - Intruder Alarm...

    Tom N wrote:
    >> # iptables -A INPUT -p icmp -j DROP
    >>

    >
    >Thanks, Beej. I'll put that rule in my rc.iptables script and run
    >it with restart option.
    >
    >iptables -vL-n
    >
    >...
    > 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0


    Note that TCP relies on ICMP to discover the maximum transmission unit (MTU)
    for the connection. If you drop ICMP error messages, the other end will
    never find out that its packets are too big. As a result, it will retransmit
    the packets repeatedly with the same size, up to its maximum number of
    retransmissions and, when it gets no responses, it will terminate the
    connection.

    So, when you wonder why file downloads don't work from some sites, the
    reason is that you misconfigured your firewall.

  12. Re: Attn: Joost - Intruder Alarm...

    On Jan 28, 8:25 am, kaukasoina708n8s6l...@sci.fi (Petri Kaukasoina)
    wrote:
    > Tom N wrote:
    >
    > >> # iptables -A INPUT -p icmp -j DROP

    >
    > >Thanks, Beej. I'll put that rule in my rc.iptables script and run
    > >it with restart option.

    >
    > >iptables -vL-n

    >
    > >...
    > > 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0

    >
    > Note that TCP relies on ICMP to discover the maximum transmission unit (MTU)
    > for the connection. If you drop ICMP error messages, the other end will
    > never find out that its packets are too big. As a result, it will retransmit
    > the packets repeatedly with the same size, up to its maximum number of
    > retransmissions and, when it gets no responses, it will terminate the
    > connection.


    That's really interesting. I wonder if the reason that rule isn't
    working
    is that it's been overridden by the kernel/netfilter(?).

    Because I can ping anywhere...

    >
    > So, when you wonder why file downloads don't work from some sites, the
    > reason is that you misconfigured your firewall.


    Thank you, Petri. I'll put this in a startup file instead:

    # echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

    Clearly, I'm not good enough yet with iptables to do the job right.

    Tom

  13. Re: [OT] Attn: Joost - Intruder Alarm...

    On Mon, 28 Jan 2008 17:20:44 +0100, Tom N wrote:

    > On 2008-01-28, Beej Jorgensen wrote:
    >> Tom N wrote:
    >>>Okay. But is one computer considered a lan?

    >>
    >> Yes, but from a practical standpoint, you won't be pinging on eth0 to
    >> the local machine; pings will go through the lo (local loopback)
    >> interface. So you could change your iptables command to target the
    >> eth0 (or whatever) interface and leave lo alone.

    >
    > Good idea.
    >
    >
    >>>Okay. It looks like it needs fine-tuning. Until then, if I need to ping
    >>>127.0.0.1 or use traceroute, I'll just drop my firewall.

    >>
    >> 127.0.0.1 is usually lo. If you ifconfig lo, you should get something
    >> like this:
    >>
    >> $ ifconfig lo
    >> lo Link encap:Local Loopback
    >> inet addr:127.0.0.1 Mask:255.0.0.0
    >> inet6 addr: ::1/128 Scope:Host
    >> UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:417863
    >> errors:0 dropped:0 overruns:0 frame:0 TX packets:417863
    >> errors:0 dropped:0 overruns:0 carrier:0 collisions:0
    >> txqueuelen:0
    >> RX bytes:79827444 (76.1 MiB) TX bytes:79827444 (76.1 MiB)

    >
    > That's what I get.
    >
    >
    >>>How do you explain this, Beej:

    >>
    >> I can't--I'd think the iptables ICMP drop from any to any rule would
    >> match this.


    Maybe the fresh blocking rules are set too late after oter
    already allowing the entrance?
    Tom may have to post the output (not too "manged", please ;-) of:
    # iptables -L -n

    >>

    > I can ping lo or anywhere. Guess I better take a look at that webpage
    > and RTFM.
    >
    > Thanks, Beej,


    To get some enticement on reading the manpages and more here's a trailer ;-)
    that's if you want something a bit overkill for a personal desktop, here's
    a part of what I have in my standard rc.iptables script, it's even in my personal
    machines because I don't bother about having different settings at home and work,
    although, this part is only declenched at home if I start up the rc.ip* script
    with a parameter involving I want it ("parano"):

    (this post is to be read unwrapped, some lines are a bit long...)

    ----------
    # /etc/rc.d/rc.iptables

    IP locale : 192.168.0.5
    usage /etc/rc.d/rc.iptables start|stop|restart|block|parano|easy [log[bad]]
    ----------

    as it is a short excerpt from the script I'll
    remind for the slow reading the predefined variables are
    ----------
    IPTA=path to iptables program
    IFACE=your eth device
    MONIPLOCALE=your local IP (eg: 192.168.0.5)
    ----------

    here's the excerpt:
    ----------
    ###
    ${IPTA} -N icmp-in
    ${IPTA} -N icmp-out
    ###
    ${IPTA} -A INPUT -i ${IFACE} -p icmp -j icmp-in
    ${IPTA} -A OUTPUT -o ${IFACE} -p icmp -j icmp-out
    ###
    ### Accept 0,3,4,11,12,14,16,18 in.
    ###
    GOOD_ICMP_IN="0 3 4 11 12 14 16 18"
    ###
    for ll in ${GOOD_ICMP_IN}
    do
    ${IPTA} -A icmp-in -i ${IFACE} -p icmp --icmp-type ${ll} -s 0/0 -d ${MONIPLOCALE} -j RETURN
    done
    ###
    ### Allow 4,8,12,13,15,17 out.
    ###
    GOOD_ICMP_OUT="4 8 12 13 15 17"
    ###
    for ll in ${GOOD_ICMP_OUT}
    do
    ${IPTA} -A icmp-out -o ${IFACE} -p icmp --icmp-type ${ll} -s ${MONIPLOCALE} -d 0/0 -j RETURN
    done
    ###
    ### Allow also 3 out, for my DNS and DSLrouter only.
    ###
    for ll in ${NAMESERVERS} ${MYBOX};
    do
    ${IPTA} -A icmp-out -o ${IFACE} -p icmp --icmp-type 3 -s ${MONIPLOCALE} -d ${ll} -j RETURN
    done
    ###
    ### Any ICMP not already allowed is logged and then dropped.
    ###
    ${IPTA} -A icmp-in -i ${IFACE} -j LOG --log-prefix "FW ICMP-BAD-TYPE-IN: "
    ${IPTA} -A icmp-in -i ${IFACE} -j DROP
    ${IPTA} -A icmp-out -o ${IFACE} -j LOG --log-prefix "FW ICMP-BAD-TYPE-OUT: "
    ${IPTA} -A icmp-out -o ${IFACE} -j DROP
    ###
    ### let the previously validated live on
    ###
    ${IPTA} -A INPUT -i ${IFACE} -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
    ${IPTA} -A OUTPUT -o ${IFACE} -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
    ----------

    After activation it'll give
    ----------
    # iptables -L -n
    ....
    Chain icmp-in (1 references)
    target prot opt source destination
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 0
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 3
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 4
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 11
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 12
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 14
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 16
    RETURN icmp -- 0.0.0.0/0 192.168.0.5 icmp type 18
    LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FW ICMP-BAD-TYPE-IN: '
    DROP all -- 0.0.0.0/0 0.0.0.0/0

    Chain icmp-out (1 references)
    target prot opt source destination
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 4
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 8
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 12
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 13
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 15
    RETURN icmp -- 192.168.0.5 0.0.0.0/0 icmp type 17
    ....
    LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FW ICMP-BAD-TYPE-OUT: '
    DROP all -- 0.0.0.0/0 0.0.0.0/0
    ....
    ----------

  14. Re: Attn: Joost - Intruder Alarm...

    On Mon, 28 Jan 2008 09:04:24 -0800, simpleman.s43 wrote:

    > Clearly, I'm not good enough yet with iptables to do the job right.


    Clearly. Of course, it should be pointed out that this same problem
    exists with everything else you do, also.

    > Tom


    Well, you're posting from another username today, but your still "Tom
    N".... err I mean "Alan Connor". Still just as stupid.


    --
    "Tom N" - the latest nymshift of "Alan Connor".
    Read more about the netkook Alan Connor here:
    http://www.pearlgates.net/nanae/kooks/ac/fga.shtml


+ Reply to Thread