Printable View
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
On 2008-01-28, Tom N <tom@somewhere.invalid> wrote:[color=blue]
> 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
>[/color]
Just got one! An attempted ssh connection from:
netnum: 202.204.64.0 - 202.204.79.255
netname: NCEPUBJ-CN
descr: ~{;*115gA&4sQ'#(11>)#)~}
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: [email]hm-changed@net.edu.cn[/email] 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: [email]cernet-helpdesk-ip@net.edu.cn[/email]
trouble: [email]abuse@net.edu.cn[/email]
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: [email]cernet-helpdesk-ip@net.edu.cn[/email] 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: [email]ncepubj@163.net[/email]
nic-hdl: LX39-AP
notify: [email]address-allocation-staff@net.edu.cn[/email]
mnt-by: MAINT-NULL
changed: [email]hostmaster@net.edu.cn[/email] 19990419
source: APNIC
Two tries. Both failed.
Tom
--
calhobbit
at gee mail dot com
Tom N <tom@somewhere.invalid> wrote:[color=blue]
>Just got one! An attempted ssh connection from:[/color]
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
On 2008-01-28, Beej Jorgensen <beej@beej.us> wrote:[color=blue]
> Tom N <tom@somewhere.invalid> wrote:[color=green]
>>Just got one! An attempted ssh connection from:[/color]
>
> They really are out to get you! How did they even find you?! See, this
> is how the paranoia starts. ;)[/color]
I am getting a gun tomorrow!
[color=blue]
>
> In the last 21 days, one of my outside machines has had 12,826 root
> login attempts on ssh. Fer reals.[/color]
Kind of puts things in perspective, doesn't it?
If I was running ssh, I'd probably get more. But not that many!
[color=blue]
> -Beej, who disallows root logins on ssh, and keeps up on security patches[/color]
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
Tom N <tom@somewhere.invalid> wrote:[color=blue]
>I've heard there is a way to turn off ICMP echo request responses. Do you
>know how to do that?[/color]
Use Google, 'cause it's faster than waiting for me to respond. :)
[url]http://www.cyberciti.biz/faq/howto-drop-block-all-ping-packets/[/url]
# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
or
# iptables -A INPUT -p icmp -j DROP
-Beej
On 2008-01-28, Beej Jorgensen <beej@beej.us> wrote:[color=blue]
> Tom N <tom@somewhere.invalid> wrote:[color=green]
>>I've heard there is a way to turn off ICMP echo request responses. Do you
>>know how to do that?[/color]
>
> Use Google, 'cause it's faster than waiting for me to respond. :)[/color]
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 :-)
[color=blue]
>
> [url]http://www.cyberciti.biz/faq/howto-drop-block-all-ping-packets/[/url]
>
> # echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
>
> or
>
> # iptables -A INPUT -p icmp -j DROP
>[/color]
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
Tom N <tom@somewhere.invalid> wrote:[color=blue]
> 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0[/color]
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
On 2008-01-28, Beej Jorgensen <beej@beej.us> wrote:[color=blue]
> Tom N <tom@somewhere.invalid> wrote:[color=green]
>> 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0[/color]
>
> 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.[/color]
Okay. But is one computer considered a lan?
[color=blue]
> Also the useful command traceroute relies on getting ICMP packets back
> to you, although these are not ICMP echo or echo-reply packets.[/color]
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 [url]www.google.com[/url]
PING [url]www.l.google.com[/url] (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
--- [url]www.l.google.com[/url] 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
Tom N <tom@somewhere.invalid> wrote:[color=blue]
>Okay. But is one computer considered a lan?[/color]
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.
[color=blue]
>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.[/color]
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)
[color=blue]
>How do you explain this, Beej:[/color]
I can't--I'd think the iptables ICMP drop from any to any rule would
match this.
-Beej
On 2008-01-28, Beej Jorgensen <beej@beej.us> wrote:[color=blue]
> Tom N <tom@somewhere.invalid> wrote:[color=green]
>>Okay. But is one computer considered a lan?[/color]
>
> 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.[/color]
Good idea.
[color=blue]
>[color=green]
>>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.[/color]
>
> 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)[/color]
That's what I get.
[color=blue]
>[color=green]
>>How do you explain this, Beej:[/color]
>
> I can't--I'd think the iptables ICMP drop from any to any rule would
> match this.
>[/color]
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
Tom N <tom@somewhere.invalid> wrote:[color=blue][color=green]
>> # iptables -A INPUT -p icmp -j DROP
>>[/color]
>
>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[/color]
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.
On Jan 28, 8:25 am, kaukasoina708n8s6l...@sci.fi (Petri Kaukasoina)
wrote:[color=blue]
> Tom N <t...@somewhere.invalid> wrote:
>[color=green][color=darkred]
> >> # iptables -A INPUT -p icmp -j DROP[/color][/color]
>[color=green]
> >Thanks, Beej. I'll put that rule in my rc.iptables script and run
> >it with restart option.[/color]
>[color=green]
> >iptables -vL-n[/color]
>[color=green]
> >...
> > 0 0 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0[/color]
>
> 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.[/color]
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...
[color=blue]
>
> So, when you wonder why file downloads don't work from some sites, the
> reason is that you misconfigured your firewall.[/color]
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
On Mon, 28 Jan 2008 17:20:44 +0100, Tom N wrote:
[color=blue]
> On 2008-01-28, Beej Jorgensen <beej@beej.us> wrote:[color=green]
>> Tom N <tom@somewhere.invalid> wrote:[color=darkred]
>>>Okay. But is one computer considered a lan?[/color]
>>
>> 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.[/color]
>
> Good idea.
>
>[color=green][color=darkred]
>>>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.[/color]
>>
>> 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)[/color]
>
> That's what I get.
>
>[color=green][color=darkred]
>>>How do you explain this, Beej:[/color]
>>
>> I can't--I'd think the iptables ICMP drop from any to any rule would
>> match this.[/color][/color]
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
[color=blue][color=green]
>>[/color]
> I can ping lo or anywhere. Guess I better take a look at that webpage
> and RTFM.
>
> Thanks, Beej,[/color]
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
....
----------
On Mon, 28 Jan 2008 09:04:24 -0800, simpleman.s43 wrote:
[color=blue]
> Clearly, I'm not good enough yet with iptables to do the job right.[/color]
Clearly. Of course, it should be pointed out that this same problem
exists with everything else you do, also.
[color=blue]
> Tom[/color]
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:
[url]http://www.pearlgates.net/nanae/kooks/ac/fga.shtml[/url]