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.

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.

Not so. It can generate a firewall for a system with just one interface as well.

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.

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!

5 members found this post helpful.

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)

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.

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:

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:

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

2 members found this post helpful.

Lynis is fairly decent to add to your list. Then

1 members found this post helpful.

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
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.?

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.

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!)...

Then use a single rule to accept from any in the set...

Then when you need to add a new network to work from, or remove a temporary one...

... 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...

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.

2 members found this post helpful.

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.

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.

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.