LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-12-2019, 06:01 AM   #16
timsoft
Member
 
Registered: Oct 2004
Location: scotland
Distribution: slackware 13.1,13.37,14.0,14.1,14.2 64 and 32bit and arm
Posts: 330

Original Poster
Rep: Reputation: 86

I had a look at the http://www.slackware.com/~alien/efg/ but it seams to be targetd at a machine with two interfaces.

As only port 22 (via a forward from port xxyy on the router) is visible from the outside, I just want to block non local ip's that are not from my own external address aa.bb.cc.dd
any clues
ie for filling out /etc/rc.d/rc.firewall file with

iptables clear all rules
iptables add blocking for non local (not 10.1.1.x) and not my remote aa.bb.cc.dd ip for just incoming on port 22

I can then get it to run from /etc/rc.d/rc.inet2 just before sshd is run.
 
Old 05-12-2019, 08:31 AM   #17
sevendogsbsd
Member
 
Registered: Sep 2017
Distribution: FreeBSD
Posts: 868

Rep: Reputation: Disabled
FYI, a non-standard port isn't going to stop or slow down anyone. Using non-standard ports is "security through obscurity" and is not a recommended security practice. When I do a (legal) pen test, I scan every port using nmap and if there is an open port, nmap will tell me what service is running on that port and I investigate.
 
Old 05-12-2019, 09:39 AM   #18
Gerard Lally
Senior Member
 
Registered: Sep 2009
Location: Brú na Bóinne, IE
Distribution: Slackware, NetBSD
Posts: 1,545

Rep: Reputation: 1022Reputation: 1022Reputation: 1022Reputation: 1022Reputation: 1022Reputation: 1022Reputation: 1022Reputation: 1022
Quote:
Originally Posted by timsoft View Post
I had a look at the http://www.slackware.com/~alien/efg/ but it seams to be targetd at a machine with two interfaces.
Not so. It can generate a firewall for a system with just one interface as well.
 
Old 05-12-2019, 09:59 PM   #19
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 127

Rep: Reputation: Disabled
iptables is by all means a complex beast. It's expected from an IT security professional to know it by all the deepest, obscure ways available to know it.

If this is not how you are making your living from, this heavy iptables knowledge might just no be practical. In that cases, tools like efg helps less than easier ones like Firewall Builder. It does not replaces knowledge, but gives a hell of a hand when dealing with iptables based firewall scripts for the masses.
 
Old 05-12-2019, 10:54 PM   #20
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 5,080
Blog Entries: 11

Rep: Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016
Quote:
Originally Posted by denydias View Post
iptables is by all means a complex beast.
It is obscure when you first begin to look at it, and there is a decided lack of well written tutorial type documentation available in my experience/opinion. But it really is not so difficult to learn if you will dedicate reasonable time and effort.

The rules syntax seems to be a hurdle to many people, so they turn to other scripts and managers with supposed "simpler" syntax... but they still have to learn some syntax or other, and in the end they still have to learn iptables syntax in order to understand what the generated rules are actually doing! Just roll up the old sleeves and learn your way around it!

Look for examples online to try to understand, but not to copy/paste. Once you learn your way around them man iptables, man iptables-extensions and man ipset are your best references - and they are actually complete and pretty good! If you don't understand something, test it as you would any scripting syntax!

From my own experience, if you are running any web facing host, it is much more than well worth the effort to learn your way around iptables. And in the end, it really isn't so difficult.

My suggestion would be to first set up a host on which you can write and test rules without disrupting your network or live services. Use it to write, test and explore different features of iptables - and keep clear notes! Get a hands on feel for how it works with simple rules.

Next, learn how to see what it is actually doing quickly and reliably. Learn to use the counters for a first quick look into where your traffic is actually going.

Set up the ability to easily and selectively log traffic with ulogd/nflog. Logging everything all the time is not very useful, but logging traffic of particular interest is. And having the ability to quickly enable or disable logging of specific traffic is extremely useful. In short, learn how to see what your traffic is doing, and how your rules are handling it.

Finally, organize your rules and/or scripts in a comprehensible way. I think that organization of rules and scripts is the biggest hurdle for most, and probably a major reason for the seeming lack of good tutorials! Every host and every user's needs are different, and organization of the firewall must be driven by those needs, so it can be difficult to explain your own methods to someone with very different needs!

Then when you get down to writing real rules for your real web facing server, get out pencil and paper using whatever convenient notation you can understand (flow chart, sequence diagram, simple table, spreadsheet, whatever) write down as clearly as you can just what you want your firewall to do, then turn that into chains and rules! If you can't do that, you can't manage it using any syntax!

Write your reference document, then write and validate your rules on your test host, then implement and validate them on your live host. Monitor it closely. As you receive your baptism by fire, update your reference document and always use it as the starting point for managing and extending your rules set. Before long you will have a firewall you understand, which does exactly what you want it to do!

Last edited by astrogeek; 05-12-2019 at 11:03 PM. Reason: tpoys
 
5 members found this post helpful.
Old 05-13-2019, 03:08 AM   #21
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 127

Rep: Reputation: Disabled
Agreed 100%, @astrogeek.

But we may accept as true that not everybody will ever read O'Reilly's Linux Networking Cookbook in its entirety. Despite that, those poor souls may need a reasonable amount of protection for their servers on a VPS/VPC provider out there. I see no harm on choose the iptables scripts generator or copy/paste that suits better, change what is needed, add SPA/port knocking and learn how to use VPS/VPC access rules (e.g. AWS Security Groups).

One good addition to that defense stack would be to create a DDNS for people who needs console access to the servers, run a local cron job to update those DDNSes automatically and another cron job on the server to update the VPS/VPC access rules with the IP from the DDNS. That way you don't need to open administration services to the entire internet. Only the IPs from a know DDNS will have console access and no nmap scans will ever detect a port on that servers.

In the end, I think the following stack provides a good deal of defense:

1. iptables/pf (host based, you control)
2. SPA server (host based, you control)
3. VPS/VPC IP based access rules (3rd party)
4. DDNS (3rd party)
5. DDNS update script (local network, you control)
6. SPA client (localhost, you control)
 
Old 05-13-2019, 06:51 AM   #22
Labinnah
Member
 
Registered: May 2014
Location: Łódź, Poland
Distribution: Slackware-current
Posts: 44

Rep: Reputation: 10
Quote:
Originally Posted by timsoft View Post
any ideas of what else to check?
For those who tell to reinstall system - this is not always possible. I.e - you have order to fix problem on someone other system.

1. Some tools may be compromised, but this is rare. Even rarest is if all of them are altered - I've newer encounter that situation. In most cases this are only limited automated hacks. I had only one online fight with live hacker...
2. Run "rkhunter".
3. Shutdown/kill all process you can for easier analysis.
4. You can copy your own tools from "clean" system.
5. Use "-p" option for "netstat" it shows proces PID which you can...
6. ... use in "lsof -p" or ...
7. ... "strace -p"
8. Use "htop" to look at process list ("s" and l" options!). I've never see it altered. You can always compare it to "top" or even look manualy in "/proc/[PID]/" directories.
9. Files can be hidden in ls but this is unlikely in "mc".
10. If you trace binary but it is deleted you can restore it by "debug2fs" to further analysis.
11. Check crontabs for all user for malware restarts.
12. Same for /etc/initab.
13. Also check startup scripts especially rc.local for restarts after reboot.
14. Sshfs to that system to have clean look to filesystem from outside.


There is probably more things I do but I don't remember it now. But I think by use this list you can trace and fix most breaking-ins.

But you also must identify hole and patch it!
 
1 members found this post helpful.
Old 05-13-2019, 12:39 PM   #23
chrisVV
Member
 
Registered: Aug 2010
Posts: 346

Rep: Reputation: 169Reputation: 169
Quote:
Originally Posted by timsoft View Post
i think i'll have to use iptables to block all external ip's apart from my own, although it does mean if i am out and about i won't be able to do maintenance, as wherever i am that ip will be blocked.
If you have ssh open so you can do remote maintenance, and you are the only person who you want to have remote login on the computer in question, which is the position I am in, then the first thing to do is to set the AllowUsers option to your login name. This will prevent any other login name succeeding. Then set PasswordAuthentication and ChallengeResponseAuthentication to 'no' and provide yourself with a key of reasonable complexity (with passphrase protection in case you have it on a laptop which is stolen). I have mine with RSA 2048 bit strength. I also forward incoming port 22 traffic which is not ESTABLISHED or RELATED to a chain I call SSH_CHAIN and limit the number of login attempts permitted in a given period on that chain with this iptables rule:

Code:
  iptables -A SSH_CHAIN -m state --state NEW \
           -m recent --update --seconds $SSH_LOGIN_PERIOD --hitcount $SSH_TRIES -j DROP
  iptables -A SSH_CHAIN -m state --state NEW -m recent --set -j ACCEPT
I have SSH_TRIES set to 3 and SSH_LOGIN_PERIOD set to 45 seconds, but you can choose whatever you want. This will drop more login attempts that that within this window and pass others (you may want a separate rule after this that accepts other ssh traffic on the chain meeting your requirements). At that point, short of an ssh bug it should take longer than the heat death of the universe to crack the key.

I don't do this normally, but you could instead limit the access of port 22 traffic which is not ESTABLISHED or RELATED to a particular internet domain on a particular interface with a rule like:

Code:
  iptables -A SSH_CHAIN -i eth0 -s $PERMITTED_NET -j ACCEPT
  iptables -A SSH_CHAIN -j DROP
where PERMITTED_NET can be, say, '1.2.3.4/24'

See 'man iptables' and 'man iptables-extensions' for more on this. Also, test your rules to make sure they behave as you expect (it is easy to get them wrong but straightforward to test them).

This is for IPv4 access. For IPv6 you would need the equivalent, using ip6tables.

None of this will protect you if you have other ports than 22 open and they have vulnerable services running on them.

Edit: hitcount rule corrected

Last edited by chrisVV; 05-13-2019 at 01:48 PM. Reason: Add missing rule to update source list
 
2 members found this post helpful.
Old 05-13-2019, 02:59 PM   #24
ChuangTzu
Senior Member
 
Registered: May 2015
Location: Where ever needed
Distribution: Slackware/Salix while testing others
Posts: 1,298

Rep: Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187Reputation: 1187
Quote:
Originally Posted by Labinnah View Post
For those who tell to reinstall system - this is not always possible. I.e - you have order to fix problem on someone other system.

1. Some tools may be compromised, but this is rare. Even rarest is if all of them are altered - I've newer encounter that situation. In most cases this are only limited automated hacks. I had only one online fight with live hacker...
2. Run "rkhunter".
3. Shutdown/kill all process you can for easier analysis.
4. You can copy your own tools from "clean" system.
5. Use "-p" option for "netstat" it shows proces PID which you can...
6. ... use in "lsof -p" or ...
7. ... "strace -p"
8. Use "htop" to look at process list ("s" and l" options!). I've never see it altered. You can always compare it to "top" or even look manualy in "/proc/[PID]/" directories.
9. Files can be hidden in ls but this is unlikely in "mc".
10. If you trace binary but it is deleted you can restore it by "debug2fs" to further analysis.
11. Check crontabs for all user for malware restarts.
12. Same for /etc/initab.
13. Also check startup scripts especially rc.local for restarts after reboot.
14. Sshfs to that system to have clean look to filesystem from outside.


There is probably more things I do but I don't remember it now. But I think by use this list you can trace and fix most breaking-ins.

But you also must identify hole and patch it!
Lynis is fairly decent to add to your list. Then
Code:
lynis audit system
 
1 members found this post helpful.
Old 05-14-2019, 10:49 AM   #25
timsoft
Member
 
Registered: Oct 2004
Location: scotland
Distribution: slackware 13.1,13.37,14.0,14.1,14.2 64 and 32bit and arm
Posts: 330

Original Poster
Rep: Reputation: 86
thanks everyone for all the tips and pointers. I tried lynis, it does seem to hang for a long time just after "checking for old files in /tmp"

I've come up with a firewall script to allow ssh only locally or from a known ip
Code:
#!/bin/sh
SAFEIPS="/etc/safeips.conf"
MYEXTIP="aa.bb.cc.dd"
LOOPBACK="127.0.0.0"
LOCALLAN="10.1.1.0\24"
IPTP="/usr/sbin/iptables"
if [ ! -euid = "0" ]; then
  echo "$0 needs to be run as root"
  exit 1
fi
#default to open and clear any rules.
$FWP --policy INPUT ACCEPT
$FWP --policy OUTPUT ACCEPT
$FWP --policy FORWARD ACCEPT
$IPTP -F
#allow known external ip to ssh
if [ -f $SAFEIPS -a -r $SAFEIPS ]; then
  for i in `cat $SAFEIPS|grep -v "^#"|awk '{print $1}'`; do
    if [ "x$i" != "x" -a `echo $i|awk -F"." '{print NF}'` -eq 4 ]; then
      echo "adding save ip $i to firewall to allow ssh access"
      iptables -A INPUT -p tcp --dport 22 -s $i -j ACCEPT
    fi
  done
else
  echo "added $MYEXTIP to filewall to allow ssh access"
  iptables -A INPUT -p tcp --dport 22 -s $MYEXTIP -j ACCEPT
fi
#allow local machine to ssh
iptables -A INPUT -p tcp --dport 22 -s $LOOPBACK -j ACCEPT
#allow local lan to ssh
iptables -A INPUT -p tcp --dport 22 -s $LOCALLAN -j ACCEPT
#block everyone else
iptables -A INPUT -p tcp --dport 22 -j DROP
obviously, aa.bb.cc.dd is replaced by a real ip4 address, or /etc/safeips contains a list of safe ip's, one per line
as only port xxyy on the router is forwarded to port 22 on the server, that should be enough to make it unavailable.

I would like to run apache as well, visible from outside.
Does anyone have some general tips on keeping it safe, from a base of a stock 14.2 install, suitably patched with all security updates.?

Last edited by timsoft; 05-15-2019 at 01:54 PM. Reason: fix more typos
 
Old 05-14-2019, 10:58 AM   #26
Habitual
LQ Veteran
 
Registered: Jan 2011
Location: Yawnstown, Ohio
Distribution: Mojave
Posts: 9,374
Blog Entries: 37

Rep: Reputation: Disabled
https://www.linuxquestions.org/quest...llected-35954/

bottom of page

###Site Hack ###
"Aw Snap" My website has been hacked!
Steps to Take When you Know your PHP Site has been Hacked
 
1 members found this post helpful.
Old 05-14-2019, 03:08 PM   #27
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_10{.0|.1|.2}
Posts: 5,080
Blog Entries: 11

Rep: Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016Reputation: 3016
Quote:
Originally Posted by timsoft View Post
I've come up with a firewall script to allow ssh only locally or from a known ip
Code:
#!/bin/sh
SAFEIPS="/etc/safeips.conf"
MYEXTIP="aa.bb.cc.dd"
LOOPBACK="127.0.0.0"
LOCALLAN="10.1.1.0\24"
IPTP="/usr/bin/iptables"
if [ ! -euid = "0" ]; then
  echo "$0 needs to be run as root"
  exit 1
fi
#default to open and clear any rules.
$FWP --policy INPUT ACCEPT
$FWP --policy OUTPUT ACCEPT
$FWP --policy FORWARD ACCEPT
$IPTP -F
I would definitely suggest changing the default policy to DROP on all chains, at least INPUT and FORWARD. It is much more safe and easier to DROP everything then write rules for what you want to explicitly ACCEPT. Using a default ACCEPT policy means that you must write rules for everything you don't want while everyone else gets in!

You might also consider using an ipset set to manage those IPs from which you want to accept SSH connections. It makes it easier in my opinion to add or remove networks in the set than to write a new rule.

Something like this, first create the set, or load from saved file (Written from memory, see man ipset!)...

Code:
ipset create sshallow hash:net family inet hashsize 1024 maxelem 65536 counters
ipset add sshallow aaa.bbb.0.0/16
ipset add sshallow ccc.ddd.eee.0/24
Then use a single rule to accept from any in the set...

Code:
-A INPUT -p tcp -m tcp --dport $SSHIN_PORT \
-m conntrack --ctstate NEW -m set --match-set sshallow src -j ACCEPT
... All other SSH attempts fall through to default DROP policy or rule ...
... RELATED,ESTABLISHED handled by separate rule ...
Then when you need to add a new network to work from, or remove a temporary one...

Code:
ipset add sshallow jjj.kkk.lll.0/24
ipset del sshallow jjj.kkk.lll.0/24
... no need to change your iptables rules, and you can add or delete networks easily from a root shell.

You can use multiple sets, they are very efficient.

To keep a managed set of permanently banned networks, create a ban set and DROP anything that matches right up front of your other rules.

A little simple shell scripting allows you to easily manage your sets, keep persistent data in text files and summarize the state of the sets.

UPDATE: I neglected to mention your HTTP question...

With a default DROP policy and an applicable RELATED,ESTABLISHED rule, you can accept all HTTP and HTTPS traffic with something like this...

Code:
-A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW -j ACCEPT
Alternatively, you might want to send those to a custom chain to impose a connection limits or other restrictions.

But again, use a default DROP policy to begin with, then explicitly add rules for everything you want to accept - you will be much happier!

UPDATE 2: Obviously, if you set policy DROP on OUTPUT chain, which is a good idea, you will need a --ctstate ESTABLISHED,RELATED rule to respond to incoming traffic. You will also want to allow NEW for DNS (port 53 TCP and UDP) and any other services needed by the server.

Last edited by astrogeek; 05-14-2019 at 10:16 PM. Reason: typos formatting, OUTPUT rules
 
2 members found this post helpful.
Old 05-15-2019, 04:10 AM   #28
timsoft
Member
 
Registered: Oct 2004
Location: scotland
Distribution: slackware 13.1,13.37,14.0,14.1,14.2 64 and 32bit and arm
Posts: 330

Original Poster
Rep: Reputation: 86
thanks chrissvv and astrogeek (and others who have contributed). rkhunter and lynis are added to my tools. I did find /dev/.eudev hidden folder on the server, which was flagged by rkhunter but being 13.1, maybe it is supposed to be there. As I will rebuild the machine with 14.2, it is probably irelevant anyway.

rate limiting could prove a useful protection from brute force ssh attacks if I need to allow connections from unknown ip's, (I would use ssh keys as well, to reduce the chance of someone getting lucky, which is what I think happened.)
on other attempts I had a block everything by default and only allow certain stuff firewall, but when using rsync samba, sendmail/procmail and pop3/dovecot, as well as web and ssh I found I was actually only opening the ports I was servicing, as any other ports didn't have services so were closed.

if I could figure out how to implement rate limiting on remote login's to my web app, that would protect the http side of things as well. It's challenging when web sites are stateless, and you don't want to limit access to web content, only the login.
As far as the ssh stuff I've now got a good selection of things to try out, and this thread will hopefully prove a useful resource for others, or even myself if I forget in a few years time :-), so I'll mark it solved.
 
Old 05-15-2019, 07:36 AM   #29
montagdude
Senior Member
 
Registered: Apr 2016
Distribution: Slackware
Posts: 1,481

Rep: Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103Reputation: 1103
Quote:
Originally Posted by timsoft View Post
I've come up with a firewall script to allow ssh only locally or from a known ip
Not that there's anything wrong with your solution, but is there any reason not to just do this on the router side? That's what I do for my server.
 
2 members found this post helpful.
Old 05-15-2019, 07:54 AM   #30
timsoft
Member
 
Registered: Oct 2004
Location: scotland
Distribution: slackware 13.1,13.37,14.0,14.1,14.2 64 and 32bit and arm
Posts: 330

Original Poster
Rep: Reputation: 86
most routers that are used by people who have my servers do not have full firewall control, only basic nat/port forwarding options, and some DOS flood blocking options. Maybe if they were running openwrt or something they would allow more on the router firewall control, but I just use "off the shelve" economical routers.
 
  


Reply

Tags
hacked, slackware, ssh


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
My web server has been hacked. SU password has been disabled rcrosoer Linux - Security 11 06-27-2008 02:18 PM
Server has been hacked, help please Seventh Linux - Security 11 09-26-2006 11:57 AM
LXer: Another Debian server has been hacked into LXer Syndicated Linux News 0 09-07-2006 03:03 PM
Been hacked Any way of getting ip of hacker? mattfraunfelter Linux - Security 14 03-30-2005 06:02 PM
My server has been hacked, how to remove SUCKIT? ruleman Linux - Security 7 06-20-2004 06:25 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:38 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration