44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] ampr-ripd 1.8 released
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 02/12/2014 06:15 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob,
>
> -w is a good idea and I will implement it.
>
> Regarding the daemon function, AFAIK it is not available on all systems and
> does not have a standardized behavior.
> I wrote the code as portable as possible (e.g. static memory allocations,
> minimal needed libraries).
> Since the only action on the parent is exit(), I don't think that waiting
> time is relevant.
>
> Thank you for your input.
>
> Marius, YO2LOJ
Ok. I think daemon is available on many Unix/Linux-like platforms. However, it is not a
very complicated function. What you wrote in ampr-ripd is nearly the same, except for
that daemon() closes stdin, stdout and stderr when going to daemon mode.
At least on a debian system, when ampr-ripd is started from a shell script under /etc/init.d,
and when it does not close the controlling tty, init keeps a process running (startpar) that
waits until it does that. I think that is part of the logic that prints the OK or FAIL messages
in the init procedure.
So, you could add some fclose or close calls in that part of the code. (only when verbose=0)
I used the following workaround before I discovered daemon():
ampr-ripd -options </dev/null >/dev/null 2>&1
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] 44Net Digest, Vol 3, Issue 33
> From:
> Steve Wright <stevewrightnz(a)gmail.com>
> Date:
> 02/11/2014 11:41 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>> >
>> >
>> > Any connects from ports
>> >below 1024 are highly suspect for being reflection attacks so above I
>> >block them all.
> Another good trick is to block all outgoing connects to port 80 - this
> makes it quite inconvenient for a virus to download its payload. In fact,
> block all outgoing connects, and allow only what YOU want to do.
Well, I do have that on the webserver at work. What those injection-attacks on
PHP programs often do is include something that is fetched from a remote webserver.
As the webserver cannot make outgoing connects, this always fails.
However, for a typical hamradio computer that serves both as a server and a client,
blocking outgoing port 80 is a bit unpractical.
The attack is still/again going on, this time with source port 119:
21:49:23.716879 216.18.208.109 -> 44.137.41.97 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:24.514385 216.18.208.109 -> 44.137.41.101 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:24.819003 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:25.914034 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:25.927587 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:27.009032 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:27.349359 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
21:49:28.106015 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] ampr-ripd 1.8 released
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 02/11/2014 06:00 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hello OMs,
>
> Another addition and a new version.
>
> Added support for setting a specific route metric for the created routes
> using the -m option (regular routes until now had metric 0).
> This allows routes from other sources, e.g. BGP or OSPF to take precedence
> over those created by ampr-ripd.
When you make another version, consider:
- a -w option to set the window (now fixed at 840), setting 0 means no window setting.
- in the section to become a daemon, make use of the daemon() function. e.g.:
if (FALSE == debug)
{
if (daemon(0,verbose)<0)
{
PERROR("Can not become a daemon");
}
}
The advantage is that the program detaches from the terminal, which is required when
you want to start it in a /etc/init.d script and do not want to keep init waiting for the program.
Rob
>
>
> Any connects from ports
> below 1024 are highly suspect for being reflection attacks so above I
> block them all.
Another good trick is to block all outgoing connects to port 80 - this
makes it quite inconvenient for a virus to download its payload. In fact,
block all outgoing connects, and allow only what YOU want to do.
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] 44Net Digest, Vol 3, Issue 31
> From:
> John Ronan <jpronans(a)gmail.com>
> Date:
> 02/10/2014 10:01 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Hi Rob/all,
> Well as long as it wasn't just me the packets were hitting, I'm happier :). I guess your 'firewall' is a chain you created yourself? Either that or my iptables/kernel is quite a bit older than yours.
>
> Thats a nice/handy ruleset actually, thanks for the reply.
>
> Oh, apologies for my slowness in replying, birthday party (my own) Saturday meant I was recovering yesterday.
>
> Regards
> John
> EI7IG
Yes, "firewall" is a chain that is joined to the INPUT chain for some of the traffic.
In a typical Linux tunneling server you first separate the raw input and the tunnel input, and then
deal with that in separate chains. In my tunnel router I have 4 of them, one for internet traffic
to the public IP address, one for traffic destined to the 44-net address of the router, one
for 44-net traffic routed thu to systems behind my router, and one for traffic destined to my
locally running copy of NETCHL (most others would use JNOS there).
It gets kind of difficult to handle all of that in one INPUT chain.
So my INPUT chain is built like this:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth0 -d 111.222.333.444 -j firewall
iptables -A INPUT -i tunl0 -j firewall2
etc, and similar for the FORWARD chain.
BTW, the "attack" on http (which probably was not sourced from the addresses in the packets, but
was rather meant to be a reflection attack on some other party) continued through today and ended
a few hours ago.
The second example that I posted became the main attack later, and I added another rule below
the first line in my example:
iptables -A firewall -p tcp -m multiport --sport 0:1023 --syn -j DROP
This blocks any incoming connects that are coming FROM port numbers below 1024.
Those do not occur in normal practice. Port numbers below 1024 are "special" ports for protected
system services and normally are never the source port for connects. Any connects from ports
below 1024 are highly suspect for being reflection attacks so above I block them all.
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] incoming traffic.
> From:
> John Ronan <jpronans(a)gmail.com>
> Date:
> 02/09/2014 05:10 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Hi All,
>
> I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same?
>
>
> I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down.
>
> Regards
> John
> EI7IG
It is not specifically from that address. It appears to be a distributed attack on http servers, at least
to network 44. I see the same incoming stream of connects to several hosts in my subnet, all from
a different source IP. Sometimes after several hours it stops and starts from another IP.
I have crafted iptables rules that block it effectively:
iptables -A firewall -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A firewall -p tcp --syn -m recent --name tcp --set
iptables -A firewall -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 15 -j DROP
iptables -A firewall -p tcp --dport 80 --syn -j ACCEPT
iptables -A firewall -p tcp --dport 443 --syn -j ACCEPT
iptables -A firewall -p tcp -j DROP
It just drops any source IP that sends more than 15 connects in 30 seconds.
Adjust for the port numbers that you want to accept (80 and 443 in this example)
There is also an internet-wide scan from source address 64.78.174.63 with traffic like this:
21:04:33.762663 64.78.174.63 -> 44.137.40.2 TCP 52 [TCP Port numbers reused] http > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
I see it on another server outside net-44 as well.
It is blocked by the same rule but I have just firewalled the entire 64.78.160.0/20 net as this does not look like someone I want to deal with.
Rob
Thanks to all that replied.
Got the iptables to forward the connects to my linux side where the
commercial postfix server is running.
Postfix doing what it's supposed to and killing it all if it's not a user
on my box.
Again, thank you to all who gave suggestions.
Bill
KG6BAJ
Hi All,
I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu.
from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else
seeing the same?
I've disabled my tunnel for the moment as I don't have the time at the
moment to chase it down.
Regards
John
EI7IG
