Igor, just wondering how long have you been on the list if you have messages going back a couple of weeks you should find a discussion topic specifically about bogon filtering however I included in that the bash script I created to handle the updating and as I mentioned at the time it could be adapted to other things, I am thinking some small modifications to it and it may suit your needs, your mentioning the desire for comments in the file the script as written supports ip networks in CIDR form so you may want to alter that to using hash:ip instead, if all your admin team use exactly one ip address so you arn't adding /32 to every line, but perhaps CIDR support will have it's uses for you if some staff could appear from a subnet of addresses.
It supports comments in the source files in the form of hash comments both whole of line and end of line variants. I also strongly would recommend if you still have the discussion reading the points about the recreation performance, when you do the method I use in the latest version will make more sense, compared to a basic read loop doing ipset adds the latest method is faster by a significant magnitude on the large set in question it is the difference between around 3-5 minutes throughout that time making system responsiveness poor and more like 3-5 seconds and only ever managing to get to about 60% of one core with no noticeable shift in system responsiveness. It is explained more in the original posts but simply it uses a one line command substitution arrangement to convert the input file on the fly into ipset save's own format and then pipes it to ipset restore building a new setnametmp ipset, swapping it with the old setname then destroying the tmp (now obsolete) the same pattern of updating as my example yesturday actually, this method being used as it guarantees that there will not be a window where some entries are missing, furthermore as the set is only swapped in after it is built the currently working live ipset remains live and working should the rebuild fail for any reason ipset bails with an error if any of the restore operation fails. I personally feel in your use case also that an effective noop is a preferable failure mode should there ever be a problem relative to the alternative of a partially filled or totally empty set which would result in locking out some or all of the previously approved administrators, likely to be fail-deadly depending on the physical locations of the systems and the availability of quickly being able to secure local console access with the affected system, Not doing anything to the existing set until we have a good set to work with sounds like the better fail-safe for you here. Take a look if you have the messages from that discussion still, messages will be dated around the 23rd/24th of February, if you don't have them drop me a quick mail off list and I can forward you copies. Hmm probably is an archive somewhere actually but not sure I can easily forward copies though I just marked them to be easy to find if you do need them anyway. Also, just to mention the script was initially designed to pull updates from exactly the sort of master file you are describing over HTTP, I am aware you did say push so that may or may not be useful to you but you could possibly use it to grab the master file and auto update, it uses curl to issue the HTTP GET request with IfModifiedSince so it only pulls the list if there has been an actual change as such I seem to recall you said something like 5 clients? so you could most likely check with the master quite frequently with minimal overhead, no change it's just the outgoing few bytes of request and the 304 reply which will be the size of the HTTP headers for the resource plus the TCP header without sitting and trying to add it up I suspect we are looking at a number on the order of a kB or two per request with the TCP open handshake, request, reply and the TCP close. Pushing could also work with this script though, a friend of mine used a slightly modified version and a few lines of php script to handle a push via a HTTPS POST. Think he used the suexec module to run the job as a non-privilaged user in the correct group to execute ipset configured with file capabilities, while not a big one seemed he was still happier not adding the web server itself to that group, personally in this case thinking that might be worrying a little too much not sure if apache2 has caps support yet but if/when it does that is likely to be I think that is the one a process elects to maintain when dropping privs to retain the ability to change bindings on <1024 ports Another way of doing a push would be to configure the script the same as you would for a pull but omit adding the cron job, then execute the command via ssh instead, or combine them say an hourly cronjob but knowing you can always push changes if you are in a hurry. On 12/03/13 09:47, Igor Sverkos wrote: > Hi, > > Matt Joyce wrote: >> I just thought I'd offer as a suggestion here, I think this can be done >> nice and tidy as a one line job I'm presuming from your example that ssh >> is available and is therefore a viable option. [...] > Thank you. > > I am thinking of something similar. Actual I am facing the problem, that > I don't want to dump every ipset in one file (so I would need a way to > dump only the sets I want; this is not a problem with ipset, but need to > be implemented in my solution) and I need documentation at least on the > master, so using ipset dumps is not quite an option (I prefer recreation). > > Let me clarify the last point: > When you need to whitelist or blacklist a new IP/net/system you can just > run the "ipset add $setname $ip/net/system" command. > > On shutdown/stop, you would just dump all the ipsets (ipset save > > myipsets.dat) so that you can read this file on startup/start (ipset > restore < myipsets.dat). > > But: > 1) Do you remember *why* IP/net/system is part of your whitelist/blacklist? > > 2) How can you be sure that your ipset only contain trusted data? Isn't > it possible that someone manipulate the data (hack, ex-colleague in his > final days...) > > That's why I prefer recreation: > I am thinking about a simple bash script which starts with > >> ipset -exist create allowed_ssh4 hash:ip family inet hashsize 64 >> >> # sys administration building 03/e4/pc427 >> ipset add allowed_ssh4 192.168.24.117 > Well, you could also omit the inline comments, because I am going to > store the file in a VCS, so you have commit logs. > > This will address #1 and #2. We know exactly the state of our ipsets and > why, when and who changed something. > > Well, the script I am working on will do something more, e.g. providing > a "update" method using ipset's swap command, but I think you will get > the point. > > When I have solve this problem, I have the infrastructure to > automatically update the ipsets on any clients. > I am actual not sure if a cronjob should update ipsets automatically or > if we prefer pushing the updates (this could be issuing a ssh command to > the client to run the updater). > When we would store the actual "data" (the "ipset add ..." commands) > separate from the logic, we could also easily create individual ipsets > per client. > >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
